Cette article a pour objectif de vous démontrer que la construction d'un cIOS est très facile à implémenter à partir du moment où l'on dispose de son fichier wad. On n'abordera pas ici l'aspect programmation en détail de manière à se focaliser sur le principe en essayant d'imaginer une méthode empirique permettant la prise en charge de n'importe quel cIOS.

Un cIOS n'est rien d'autre qu'un IOS officiel (= base du cIOS) munis de fonctionnalités supplémentaires obtenues en patchant certains modules/contenus de sa base et en lui ajoutant des modules/contenus personnalisés supplémentaires. Evidemment, une modification au niveau des modules/contenus et du slot d'un IOS implique une adapation de ses métadonnées (fichier tmd) et de son ticket au niveau de l'ID du "title". Dans le cadre d'un cIOS, les métadonnées susceptibles d'être modifiées sont principalement:
- ID du "title" pour installer le cIOS dans un slot donné
- Version du "title" pour installer le cIOS avec une révision donnée
- Nombre de contenus vu que l'on ajoute des nouveaux modules/contenus lors de la construction du cIOS
- Contenus en ajoutant une nouvelle entrée dans la liste pour chaque module/contenu ajouté (calul de leurs métadonnées ID, index, type, taille et SHA1 hash) et en modifiant certaines métadonnées des modules/contenus existant modifiés (recalcul du SHA1 hash et fixation du type pour rendre le module/contenu modifié non partagé).

Sur base de ce qui a été dit précédemment, on peut donc imaginer de "mapper un cIOS" avec une structure de données XML du style:

Cette manière d'encoder les cIOS va grandement faciliter la programmation de leur installateur à tous les points de vue (ajout ou mise à jour des cIOS, conception de l'interface graphique, ...) à condition de stocker leur carte dans une structure de données appropriée. Dans notre exemple, La structure de données XML fournit la carte du cIOS d2x v3 base 37 sachant que:
- l'attribut version de la balise ciosgroup correspond à la révision avec laquelle le cIOS est installé
- l'attribut modulescount de la balise base correspond aux nombres de modules/contenus supplémentaires à ajouter au cIOS
- l'attribut id des différentes balises content est déterminé à partir de la table de correspondance entre les modules/contenus officiels décryptés (téléchargeables avec NUS downloader) de la base du cIOS et les modules/contenus decryptés du cIOS dans sa version existante (récupérable par exemple avec modmii ou bluedump de manière à extraire son contenu avec ShowMiiWads). Pour les modules/contenus personnalisés, l'attribut id du premier module/contenu ajouté est (l'id le plus grand parmi les contenus/modules officiels de la base+1). Voici par exemple la table de correspondance (pouvant s'obtenir la plupart du temps par simple comparaison des tailles de fichier) du cIOS d2X v3 base 37.
- la présence d'un attribut patchscount différents de 0 dans une balise content indique le nombre de patch(s) à appliquer sur le module/contenu officiel décrypté concerné. La détection des modules/contenus officiels à modifier et les patchs à leur appliquer peuvent être obtenus avec la commande DOS suivante
Dans le cas du cIOS d2x v3 base 37, les commandes à effectuer sont:

La construction des différentes balises patch devient alors relativement aisée.
- les modules/contenus à ajouter au cIOS font l'objet des dernières balises content dans la carte du cIOS. La valeur des attributs module dépend de l'ordre (connu et fourni par les sources de modmii par exemple) dans lequel ils sont ajoutés et de la manière avec laquelle le code source de l'installateur les prend en charge. La raison d'être de l'attribut tmdmoduleid réside dans le fait qu'il est parfois nécessaire de repositionner (pour certaines raisons techniques) un module/contenu personnalisé dans le tmd. Dans l'exemple qui nous occupe, le module/contenu EHCI du cIOS d2x v3 est repositionné en 4ème position dans le tmd.

Pour le reste, les autres attributs sont relativement évocateurs.

La lecture des données XML dans d2x cIOS installer a été implémentée en utilisant la "version wii" de la librairie mxml. Dans le code source:
- la fonction getCiosMaps permet de lire les cartes des cIOS tout en vérifiant leur cohérence afin de les stocker dans une structure de données
- la fonction patchBytesData permet de patcher un contenu/module décrypté à condition que les bytes concernés présentent les valeurs attendues
- la fonction addModule permet d'ajouter un contenu/module dans un tmd en le repositionnant si nécessaire
- la fonction getCiosModule s'occupe de réferencer les modules/contenus personnalisés des cIOS pris en charge par l'installateur. Il s'agit de la fonction qui détermine les valeurs possibles des attributs module présents dans les cartes des cIOS.

Gardez à l'esprit qu'il ne faut pas nécessairement une Wii pour participer à un projet de développement Wii. Dans le cadre des IOS/cIOS par exemple, le développement et le test de fonctionnalités avancées les concernant peut se faire sur PC en partant, pourquoi pas, directement de leur forme décryptée