Les KEXTs dit Legacy, pourquoi et comment

( 10 Votes )

Ceci consiste a créer une extension du kernel (kext) ne contenant pas de fichier binaire exécutable et uniquement une property list (plist). Le but de manoeuvre étant de s’affranchir d'éditer des extensions originale Apple afin de faire fonctionner certain périphériques de votre PC.



L’historique :


Traditionnellement on modifiait le fichier plist de kext Apple pour faire fonctionner certains drivers correctement. La manoeuvre de base étant d’ajouter les device et vendor IDs de notre matériel dans le driver correspondant a celui ci. L'inconvénient majeur de cette méthode est qu’a chaque mise à jour du système notre kext modifié ce faisait écrasé par ça nouvelle version.


Pour contourner ce problème le dossier /Extra/Extensions de Chameleon fit son apparition, malheureusement cette alternative ne suffit pas a résoudre complètement le problème. On ce retrouva alors face a des conflits de versions entre les kexts modifiés du dossier extra et ceux originaux du dossier système. Une autre contrainte liée a l’utilisation du dossier /Extra/Extensions vains s’ajouter au problème: la résolution des dépendances des kexts placés dans ce dossier. En effet un kext à souvent besoin de ces camardes à coté de lui pour ce charger correctement. Comme déplacer un kext et toutes ces dépendances dans le dossier /Extra/extensions tournait au ridicule, on vit apparaitre les kexts dit legacy.



Le principe :


Il est détaillé dans la documentation Apple sur les extensions du kernel que celles ci peuvent ne pas contenir de binaire exécutable et ainsi si on le souhaite reconfigurer à la volée les réglage d’un autre kext. Le principe est simple, un kext contient une plist, c’est le fichier de configuration du kext. A l'intérieur de cette plist on peut spécifier des réglages en destination d’un exécutable bien précis qui ce trouver dans un autre kext. A partir du moment ou cette autre kext est présente dans le dossier système alors nous pourront pointer notre Legacy kext vers celle ci afin d’overrider ces réglages prédéfinis pour les faire correspondre à nos besoins.


http://developer.apple.com/...

La pratique :


Dans un premier temps copiez le kext que vous souhaitez modifier sur votre bureau. Afin d'éditer la plist contenue dans le fichier kext facilement je vous recommande vivement d’utiliser un éditeur de plist (ex: Property List Editor.app). Une fois le kext sur votre bureau faites un clic droit dessus et choisissez «Afficher le contenu du paquet», puis dans le dossier «Contents» supprimez tous les fichier sauf «info.plist». Une fois que c’est fait on peut attaquer l'édition du fichier info.plist.


  • Dans ce fichier plist vous trouverez un couple clé/valeur intitulé «Executable file», il faut  supprimer ces informations. En suite on supprime également le couple «Bundle versions string, short».

  • Afin d'éviter les conflit de versions il va maintenant falloir rebaptiser le kext en suivant quelques règles simple. Renommer votre fichier kext comme bon vous semble, mais sans utiliser de caractère du type «espace», «/», «.» ou encore «:», etc. Inspirez vous de la syntaxe des kext fournies par Apple. Une fois que vous avez renommé le kext il faut répercuter ces modifications dans la plist.

  • Dans le couple «Bundle name» vous devez reporter la syntaxe exacte de votre nom de fichier kext.

  • Dans le couple «Bundle identifier» vous devez respecter le standard de recherche DNS inversée, pas de panique c’est très simple. Il suffit de respecter le format suivant : com.mon_nom.driver.nom_de_mon_kext (ex: org.darwinx86.driver.HDAInjector)

  • Dans le champs «Get Info string» vous pouvez entrer une description de votre kext legacy.

  • Il faut en suite supprimer le dictionnaire «OSBundleLibraries» afin de  ne pas créer des problèmes de résolution des dépendances.
    nb: dans certain cas rares il faut conserver ce dictionnaire

  • Dernière étape de l'édition du squelette de votre kext, le couple «OSBundleRequired». Cette étape n’est pas obligatoire, vous devez ajouter ou modifier ce champ uniquement si vous souhaitez utiliser votre kext legacy dans le dossier /Extra/Extensions. Il faut savoir qu’un fichier kext qui contient «OSBundleRequired»»Root» sera toujours charger par le bootloader, même lors du boot en mode sans échec, donc si votre legacy kext venait a faire paniquer le kernel pour une raison X ou Y vous ne pourrez pas contourner ce bug facilement. Ceci étant dit c’est a vous de décider.


Et voila le squelette de votre kext et fin prêt, il faudra maintenant procéder au modifications dont vous avez besoin dans le dictionnaire «IOKitPersonalities». D’une manière générale, il ne faut rien ajouter ou supprimer à l'intérieur de ce dictionnaire, par contre vous pouvez modifier tout ce dont vous avez besoin

Dans ce dictionnaire vous trouverez d’autres dictionnaires qui eux même contiennent les informations de configuration du driver. Le driver (kext) ciblé est désigné dans le champ «CFBundleIdentifier». Les modifications que vous apporterez a l'intérieur de ce dictionnaire seront répercutées uniquement vers ce driver

On peut donc créer un kext legacy unique qui reconfigurera plusieurs autre kexts à la volée. Il suffit pour ceci d’ajouter les dictionnaires contenu dans «IOKitPersonalities» d’un autre kext au sains du votre kext legacy puis de procéder au modifications dont vous avez besoin. Ainsi vous serez capable de réunir au sains d’un seul et même legacy kext toute les modifications que vous souhaitez injecter a la volée.

 

Commentaires 

 
0 #1 Boombeng 31-01-2010 21:43
Merci encore une fois Trauma, et voici un petit exemple de construction de "kext legacy"
darwinx86.net/.../...
Citer
 
 
0 #2 NuDub 01-02-2010 10:04
Guide très pratique, sa va permettre de savoir ce qui se cachai derrière ces Legacy Kext

Merci Trauma.
Citer
 
 
0 #3 coucou78 15-02-2010 18:21
une très très bonne explication, on sait à quoi ils servent et pourquoi ils sont là.

Merci Trauma.
Citer
 
 
0 #4 03-06-2010 14:47
Merci, je commence enfin à comprendre
Citer