1. Présentation du dossier "Extra"

Le dossier "Extra" est exploité par le boot loader pour charger des extensions au démarrage d'os x. L'intérêt de ce dossier est donc d'héberger les drivers essentiels au bon fonctionnement de votre hack. Au démarrage le boot loader ira donc chercher les kext ou le mkext placés dans ce dossier avant de commencer à charger les extensions placées dans le dossier traditionnel "System/Library/Extensions".

L'intérêt de cet méthode est d'héberger tous vos drivers modifier dans un seul et même dossier plutôt que de les mélanger au extensions authentiques d'Apple. L'avantage de cette méthode est que l'on maîtrise parfaitement les fichiers vitaux pour le bon fonctionnement de notre système d'exploitation.

Actuellement cet methode est prise en charge par les boot loaders suivant :

BOOT-132 DFE r146 aka Chameleon DFE
PCEFI v9
La future version de Chameleon

2. Utilisation du dossier "Extra"

Le dossier "Extra" est vue par le boot loader de la même façon que le dossier "Library". On reproduira donc la même arborescence dans "Extra" que dans "Library". Les boot loaders exploitant le dossier "Extra" reconnaissent deux types de fichiers: les KEXT (Extensions du kernel / driver) et les MKEXT (cache des extensions).


Voici un exemple en image du contenu du fameux dossier:

3. Quelles extensions du noyau fonctionneront dans le dossier "Extra" :

Si vous utilisez déjà le dossier "Extra" vous avez sûrement remarqué que certaines extensions du noyau ne ce charge pas ! En générale si une extensions ne fonctionne pas quand elle est placée dans le ce dossier c'est soit parce qu'elle est d'une version antérieur à celle présente dans /S/L/Extensions soit que ces dépendances ne sont pas satisfaites ! Par ailleurs pour qu'une extension soit prise en compte par le boot loader il est nécessaire que le fichier info.plist de cette extension ce termine comme ceci :

</dict>
<key>OSBundleRequired</key>
<string>Root</string>
</dict>
</plist>


Pour remédier a ce problème il existe différentes solutions :

Utiliser un kext "legacy"

Éditer la property list comme indiquez au dessus

Modifié la version du kext (et de ces plugins et de ces dépendances) dans ces plist par une version plus récente. Ex: 1.2.1 remplacé par 2.0.0 dans info.plist et version.plist afin que le système pense quelle est plus récente.

Si il n'y a pas de problème de version, alors il faut placer toutes les dépendances du kext en question dans le dossier "/Extra/Extensions"

4. Les legacy kext :

Un kext legacy est une fausse extensions du noyaux qui ne contient qu'une plist (property list). L'idée de ce faux kext est de résoudre à la fois les problèmes de versions et de dépendance. La property list nommée info.plist doit renseigner le kernel sur le driver qu'il doit charger. A savoir le matériel associé au driver via sont "Device IDentifier" et la version du driver en question. Cettte méthode fonctionne uniquement lorsque le fichier binaire du driver n'a pas été modifié. La plus par du temps une simple édition de cette plist permet d'utiliser un driver authentique Apple pour exploiter un périphérique !

Ex: contrôleur de disque dur via AppleAHCIPort.kext + LegacyAppleAHCIPort.kext.

5. Comment identifier les dépendances d'un KEXT ?

C'est relativement simple ! La plus part du temps ces dépendances sont incluses dans le kext lui même. Elles
se trouvent dans le dossier plugins. Dans ce cas pas problèmes !



Pour connaitre la liste exacte des dépendances il faut aller voir dans le fichier info.plist du kext . Toutes les lignes contenant "com.apple.iokit" désignent les dépendances, dans ce cas IOACPIFamily.kext et IOPCIFamily.kext.

<key>OSBundleLibraries</key>
<dict>
<key>com.apple.iokit.IOACPIFamily</key>
<string>1.0.0d1</string>
<key>com.apple.iokit.IOPCIFamily</key>
<string>1.1</string>
<key>com.apple.kernel.libkern</key>
<string>1.1</string>
<key>com.apple.kpi.iokit</key>
<string>8.7.2</string>
<key>com.apple.kpi.libkern</key>
<string>8.7.2</string>
<key>com.apple.kpi.unsupported</key>
<string>8.7.2</string>
</dict>

6. Doit on placer tous les drivers modifiés dans le dossier "Extra" ?

La réponse est non ! Il y a plusieurs critères a prendre en compte :

Historiquement cette fonction a été implémentée par David Elliott (aka. DFE) dans son "boot-132 r146". L'idée était de booter le DVD Retail d'osx 10.5.0 en bootant précédemment sur un CD possédant un bootloader et en gros le dossier "Extra". Il suffisait alors de mettre sur le CD de boot les kext essentiel pour pouvoir booter le DVD original d'OS X. Etant donné qu'il n'existait qu'une seul version du DVD retail d'osx le problème du conflit des versions ne se posait pas !

Si on part du principe que seul les extensions authentiques d'Apple seront remplacées lors des mises à jours, alors toutes les extensions spécialement créer pour OSx86 ne le seront pas ! Par exemple AppleDecrypt.kext n'est pas une extensions "Apple" donc elle ne sera jamais remplacée par une update du système ! On peut donc la placée indifféremment dans "Extra" ou dans /S/L/Extensions....

Le gros avantages de ce dossier est surtout de pouvoir rassembler les kexts vitaux de votre configuration ensemble et en sécurité au sain d'un même dossier. On ne polluera donc pas le dossier /S/L/Extensions avec des extensions "trafiquées" et on profitera d'une meilleur vue d'ensemble des fichier nécessaire au bon fonctionnement de notre hack.

Via l'utilisation de kexts dit "Legacy" on profite aussi de la possibilité de faire les maj Apple en s'assurant de résister au mise à jour des drivers.

Lorsque votre configuration matériel le permet, le dossier "Extra" permet de s'affranchir de toute modification du dossier /S/L/Extensions.

Installer Os X: MBR ou GUID?		Le Kernel (noyau)