BUILD AN EXISTING CIOS

I) PREAMBLE This article describes an empirical method to build a cIOS from its WAD file. II) INTRODUCTION CIOS is an official IOS (= its base) with additional features obtained by patching some of its modules/contents and adding it some custom modules/contents. Obviously, changes into IOS modules/contents and its slot involve an adjustment of its metadata (TMD file) and its ticket. The IOS TMD and ticket files are officially named tmd.y [yyyy] and cetk but 00000001000000xx.tmd and 00000001000000xx.tik "in their decrypted format" with its version y[yyyy] in decimal format and its slot xx in hexadecimal format. As part of a cIOS, the metadata concerned are: - Title ID to install the cIOS in a given slot - Title Revision to install the cIOS with a given version - Number of contents to take the custom modules/contents into account - Contents by adding a new item in the list for each custom module/content (calculation of their metadata ID, index, type, size and SHA1 hash) and adjusting some metadata related to the patched official modules/contents (SHA1 hash recalculation and type fixing to the unshared value).

III) CIOS MAPPING Based on its definition, we can imagine to map a cIOS with the following XML data structure:
<?xml version="1.0" encoding="utf-8"?> <ciosmaps ciosgroupscount="1"> <ciosgroup name="d2x v3" version="21003" basescount="1"> <base ios="37" version="5662" contentscount="22" modulescount="7"> <content id="0x1f" patchscount="3"> <patch offset="0x00" size="14" originalbytes="0x66,0x69,0x72,0x6D,0x77,0x61,0x72,0x65,0x2E,0x36,0x34,0x2E,0x31,0x30" newbytes="0x77,0x61,0x6E,0x69,0x6E,0x6B,0x6F,0x6B,0x6F,0x00,0x52,0x56,0x4C,0x2E" /> <patch offset="0x0F" size="9" originalbytes="0x33,0x31,0x36,0x31,0x31,0x30,0x32,0x00,0x00" newbytes="0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39" /> <patch offset="0x30" size="15" originalbytes="0x61,0x64,0x6D,0x69,0x6E,0x40,0x46,0x57,0x50,0x55,0x42,0x4C,0x49,0x53,0x48" newbytes="0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00" /> </content> <content id="0x10" patchscount="2"> <patch offset="0x6E5" size="1" originalbytes="0x01" newbytes="0x00" /> <patch offset="0x775" size="1" originalbytes="0x01" newbytes="0x00" /> </content> <content id="0x18" /> <content id="0x20" /> <content id="0x21" /> <content id="0x5" /> <content id="0x12" /> <content id="0x13" /> <content id="0x14" /> <content id="0x9" /> <content id="0xa" /> <content id="0x1d" /> <content id="0xc" /> <content id="0x15" /> <content id="0x22" patchscount="1"> <patch offset="0x26E54" size="4" originalbytes="0xFF,0xFF,0x5B,0x4E" newbytes="0x13,0x6D,0x00,0x11" /> </content> <content id="0x23" module="MLOAD21" tmdmoduleid="-1" /> <content id="0x24" module="FAT21003" tmdmoduleid="-1" /> <content id="0x25" module="SDHC21" tmdmoduleid="-1" /> <content id="0x26" module="EHCI21003" tmdmoduleid="3" /> <content id="0x27" module="DIPP21" tmdmoduleid="-1" /> <content id="0x28" module="ES21" tmdmoduleid="-1" /> <content id="0x29" module="FFSP21003" tmdmoduleid="-1" /> </base> </ciosgroup> </ciosmaps>

In our example, the XML data structure provides the cIOS d2x v3 base 37 map knowing that: - The version attribute of the ciosgroup tag provides its revision - The modulescount attribute of the base tag provides the custom modules/contents count - The id attribute of content tags is obtained from the associative array between the decrypted modules/contents of its base (downloadable with NUS downloader) and its decrypted modules/contents extracted with ShowMiiWads from its WAD file built by ModMii or Bluedump. The id attribute value of its first custom module/content is equal to the highest id detected among the contents/modules of its base incremented by 1. For example, here is the d2x cIOS v3 base 37 associative array obtained by comparing the concerned contents/modules file sizes:

IOS37 v5662 0000001f.app 00000010.app 00000018.app 00000020.app 00000021.app 00000005.app 00000012.app 00000013.app 00000014.app 00000009.app 0000000a.app 0000001d.app 0000000c.app 00000015.app 00000022.app

cIOS d2x v3 base 37 00000000.app 00000001.app 00000002.app 00000003.app 00000004.app 00000005.app 00000006.app 00000007.app 00000008.app 00000009.app 0000000a.app 0000000b.app 0000000c.app 0000000d.app 0000000e.app

The content tags must be encoded in a specific order. The first content tag provides information related to its 00000000.app content/module, the second the information related to its 00000001.app content/module - The patchscount attribute in a content tag allows specifying the patch(s) count to apply to the concerned decrypted official module/content. The detection of the official modules/contents to modify and their patches can be obtained with the DOS command FC:
FC /B <cIOS base decrypted module/content> <corresponding cIOS decrypted module/content>

For the cIOS d2x v3 base 37, the commands to execute are:
FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC /B /B /B /B /B /B /B /B /B /B /B /B /B /B /B ..../0000001f.app ..../00000010.app ..../00000018.app ..../00000020.app ..../00000021.app ..../00000005.app ..../00000012.app ..../00000013.app ..../00000014.app ..../00000009.app ..../0000000a.app ..../0000001d.app ..../0000000c.app ..../00000015.app ..../00000022.app ..../00000000.app ..../00000001.app ..../00000002.app ..../00000003.app ..../00000004.app ..../00000005.app ..../00000006.app ..../00000007.app ..../00000008.app ..../00000009.app ..../0000000a.app ..../0000000b.app ..../0000000c.app ..../0000000d.app ..../0000000e.app

The patch tags encoding is based on the results provided by the FC command. - The custom modules/contents are the subject of last content tags. The module attributes value depends on the order in which they are added (known with the ModMii sources for example) and their implementation in the installer source code. The tmdmoduleid attribute allows repositioning some custom modules/contents in the TMD (required for some technical reasons). In our example, the cIOS d2x v3 base 37 EHCI module/content is repositioned in the fourth position in the TMD. The other attributes are quite evocative. IV) NOTES By extension, the XML data structure described in this article allows encoding a channel, a system menu, an IOS (patched or official), ...