akabulous/so_you_want_to_build_a_nethunter_kernelGuide pas à pas pour créer des kernels Kali NetHunter personnalisés pour Android : récupération des sources, choix de la toolchain, compilation croisée et flashage.
Le plus grand obstacle pour la plupart des gens qui souhaitent configurer un appareil Nethunter est l'exigence du noyau. À moins que votre appareil ne dispose déjà d'un noyau précompilé (et maintenu), on vous dira d'en compiler un vous-même. Il existe déjà beaucoup de documentation sur ce processus, mais d'après mon expérience, il peut être difficile de savoir ce qui s'applique à votre cas et ce qui ne s'applique pas.
Ce problème est aggravé par des connards des gens qui écrivent des guides avec des titres putaclic comme « Construisez un noyau Nethunter pour N'IMPORTE QUEL appareil Android ! » ou avec de fausses promesses comme « Apprenez à compiler un noyau Nethunter en dix minutes ! » C'est aussi une réalité malheureuse d'Internet en 2025 que beaucoup d'idiots de gens pensent que ChatGPT ou d'autres grands modèles de langage ont des réponses autoritaires à leurs questions, alors que tout ce que ces modèles ont vraiment, ce sont des informations qu'ils ont extraites des connards susmentionnés.
J'écris ce guide aussi minutieusement et honnêtement que possible. Il n'est pas destiné à être le seul document que vous devrez lire pour ce processus, cependant – vous aurez sûrement des questions auxquelles ce document ne peut pas répondre. Je vous encourage à chercher des réponses à ces questions dans la documentation logicielle pertinente, et PAS sur YouTube ou avec ChatGPT.
Avant de commencer QUOI QUE CE SOIT de ce processus, vous devriez DÉJÀ avoir :
apt update && apt upgrade -y (facultatif : ajouté des métapaquets)Pour mener à bien ce processus, vous aurez besoin de :
cd, rm, ls, mkdir, find, diff, grep, etc.)vim pour les gens cool, sinon nano)build-devel sur les distributions basées sur Arch, build-essential sur celles basées sur Debian) – je recommande également d'installer Perl + Python3 car certains Makefiles du noyau les exigentEst-ce que ce sera possible pour mon appareil ?
Le noyau Linux est sous licence GNU General Public License 2.0, qui est une licence copyleft. Cela signifie que le code source du noyau Linux est distribué librement et que vous pouvez modifier le code source comme vous le souhaitez (comme chaque fabricant Android l'a fait), CEPENDANT, votre code source résultant doit AUSSI être distribué librement.
À la surprise de absolument personne, beaucoup des corporations géantes qui utilisent du code sous licence GPL se moquent des termes de cette licence. Elles refusent soit de distribuer leur code source, soit n'en publient qu'une partie (généralement cassée, obsolète et avec des blobs binaires intégrés). S'il n'y a pas de code source disponible pour le noyau de votre appareil, alors il n'y a aucun moyen de créer un noyau Nethunter pour celui-ci.
Votre capacité à déverrouiller le bootloader et à installer une ROM personnalisée dépend aussi énormément des caprices du fabricant de votre appareil. Même s'ils autorisent le déverrouillage du bootloader et que vous avez pu rooter votre téléphone avec Magisk, s'ils ne publient pas d'arborescences d'appareil (device trees), il n'y a probablement pas de ROM personnalisée pour votre appareil. Dans ce cas, il est extrêmement douteux que le code source du noyau qu'ils ont publié (s'il y en a un) ait reçu la moindre maintenance depuis sa publication, ou même qu'il compile sans modifications. Si vous ne voyez personne d'autre maintenir quoi que ce soit (noyaux, ROM, recoveries) pour votre appareil, alors il sera difficile, voire impossible, de transformer cet appareil en un Nethunter complet.
Une note sur les versions du noyau
Imaginons qu'il existe des ROM personnalisées/noyaux/recoveries mis à jour régulièrement et maintenus pour votre appareil, mais simplement pas de noyau Nethunter. Dans ce cas, vous devriez pouvoir mener à bien ce processus, mais le processus variera selon la version du noyau Linux utilisée par votre appareil.
Les informations de ce guide sont basées sur mon expérience de modification des noyaux 4.14.x. Il existe des guides plus anciens qui parlent d'utiliser les chaînes d'outils GCC (au lieu de LLVM/clang, comme nous allons l'utiliser) qui s'appliquent aux noyaux 3.x. Si votre appareil utilise une version 5.x/6.x du noyau Linux, les informations de ce guide ne suffiront pas pour mener à bien ce processus. La méthode de compilation Android change tout le temps, et vous devriez chercher un guide qui couvre les noyaux GKI et l'utilisation de Bazel/Kleaf.
Un bon moyen de trouver des dépôts contenant le code source du noyau pour votre appareil est d'utiliser son nom de code. Chaque Android en a un, bien que certains fabricants (c.-à-d. OnePlus) s'amusent un peu plus que d'autres (c.-à-d. Samsung). Le nom de code de mon Xiaomi Poco X3 NFC est « surya », tandis que celui de mon Samsung A51 est « SM-A515F ». En général, les dépôts de code source du noyau suivent la convention de nommage
android_kernel_FABRICANT_NOM_DE_CODE
où le fabricant est la société mère, c.-à-d. android_kernel_xiaomi_surya, pas android_kernel_poco_surya.
Cependant, il peut aussi y avoir des dépôts basés sur le SoC (system-on-a-chip) de votre appareil, parfois « unifiés » pour inclure les fichiers source d'autres appareils dotés du même SoC. C'est le cas pour le Samsung que j'ai mentionné, dont le dépôt source s'appelle android_kernel_samsung_exynos9611. Jetez un œil sur github/gitlab et voyez ce que vous pouvez trouver.
Pour les besoins de ce guide, j'utiliserai la dernière LineageOS 22.2 (construite le 2025-08-04) sur surya, donc je voudrai cloner le code source du noyau depuis le dépôt LineageOS. Mais avant de faire cela, je veux copier deux fichiers de mon appareil vers l'ordinateur que j'utiliserai pour compiler le noyau : /proc/config.gz et /proc/version.
Je pourrais copier le premier fichier, /proc/config.gz, vers /sdcard, le récupérer de l'appareil avec ADB, le décompresser avec gunzip et le renommer. Mais cela semble être beaucoup d'étapes, alors ce que j'ai fait à la place, c'est ceci :
Ensuite, sur l'appareil lui-même, j'ai exécuté (en root)
Que se passe-t-il ici ?
Sur mon ordinateur portable : nc (netcat) -l (écouter les connexions entrantes) -p (port) 4545 (vraiment, cela pourrait être n'importe quel nombre entre 1024 et 65535, mais j'utilise généralement 4545) > (écrire dans le fichier) surya-defconfig-lineageos22.2-20250804 (nom de fichier descriptif) < (entrée depuis le fichier) /dev/null (périphérique nul – cela garantit que si je touche le clavier, la frappe ne sera pas envoyée dans le fichier que je reçois, risquant de l'endommager).
Sur le téléphone : zcat (comme la commande cat pour concaténer, mais pour les fichiers gzippés) /proc/config.gz (la configuration du noyau avec laquelle le noyau actuellement en cours d'exécution a été compilé) | (envoyer la sortie de ce processus comme entrée du processus suivant) nc (encore netcat) 192.168.1.42 (l'adresse IP locale de mon ordinateur portable) 4545 (le port que j'ai défini avant)
Bien que cela devrait vous donner le fichier .config qui a servi à compiler votre noyau actuellement en cours d'exécution, ce n'est pas toujours le cas. Certains appareils plus modernes/versions de ROM plus récentes refuseront de démarrer si la configuration enregistrée dans /proc/config.gz ne correspond pas au .config utilisé pour compiler le noyau d'origine. Heureusement, c'est le seul contrôle qui a lieu (pas quelque chose de beaucoup plus difficile à contourner comme une somme de contrôle SHA256 du noyau entier), donc certaines personnes astucieuses ont trouvé un moyen d'usurper le fichier dans /proc/config.gz pour qu'il corresponde au noyau d'origine, malgré leurs modifications. Si vous n'êtes pas sûr que le fichier de votre appareil soit réel ou usurpé, vous pouvez exécuter zcat /proc/config.gz | head puis uname -r. Si les numéros de version ne correspondent pas, le fichier dans /proc a été usurpé. Dans ce cas, bien que vous puissiez toujours continuer avec ce guide, vous voudrez peut-être exécuter diff pour comparer la configuration extraite avec certains des fichiers que vous trouvez dans le répertoire arch/arm64/configs de votre source du noyau.
Quant à /proc/version, il n'est peut-être pas si nécessaire d'envoyer ce fichier, car tout ce dont nous avons vraiment besoin, c'est l'information sur la version de clang/ld.lld qui a été utilisée pour le compiler. Nous pouvons donc simplement exécuter cat /proc/version et y jeter un œil :
Oups ! On dirait que celui qui a compilé ce noyau a fait un petit « oopsie » et que son Makefile a enregistré tous les -CFLAGS qu'il a utilisés avec clang, mais pas la version de Clang. Cependant, nous pouvons voir qu'ils ont utilisé une chaîne d'outils Android précompilée, et qu'ils ont utilisé ld.lld version 19.0.1.
Voici une image un peu plus utile. La première sortie provient de /proc/version avant la modification, la compilation et l'installation d'un nouveau noyau sur Samsung A51. La deuxième sortie provient de /proc/version actuellement.
Vous remarquez quelque chose ? (Non, pas mon nom d'utilisateur et mon nom d'hôte bizarres).
La meilleure astuce pour choisir une chaîne d'outils est d'utiliser la chaîne d'outils EXACTE qui a compilé le noyau actuellement en cours d'exécution.
Dans ce cas, c'était Neutron clang 18.0.0git, qui a été assez facile à trouver :
Et regardez donc, les md5sum correspondent et tout.
Juste pour le plaisir, jetons un coup d'œil rapide à la chaîne /proc/version d'un appareil considérablement plus ancien, le Samsung J7 (2016), nom de code j7xelte :
C'est un appareil assez ancien pour qu'il utilise encore des chaînes d'outils GCC pour compiler le noyau.
Mais quand je cherche « gcc version 4.9.x 20150123 prerelease », je trouve deux dépôts :
Alors lequel dois-je télécharger ?
La réponse : les deux. GCC est différent de Clang en ce sens que pour construire des compilateurs/binutils/éditeurs de liens/etc. pour la compilation croisée, il faut construire une chaîne d'outils séparée pour chaque « triple cible ». Le triple cible prend (soi-disant) le format
machine-vendor-operating_system
Mais comme nous allons le voir, cette « règle » a un million d'exceptions. Mais commençons par « machine ».
Dans la section « vous aurez besoin de » de ce document, j'ai dit que vous aviez besoin d'un ordinateur 64 bits utilisant un processeur Intel ou AMD avec GNU/Linux. C'est parce que les chaînes d'outils que nous allons utiliser sont compilées pour être exécutées sur x86_64-linux-gnu.
Cependant, ces chaînes d'outils sont des compilateurs croisés, ce qui signifie que le code machine qu'elles génèrent à partir des fichiers de code source C ne s'exécutera pas sur cet ordinateur, mais sur un autre avec son propre triple cible.
Aarch64, également connu sous le nom d'arm64, est l'architecture utilisée par presque tous les appareils Android. Arm, sans le « 64 », fait référence aux implémentations 32 bits des puces ARM. La plupart des noyaux Android sont compilés en utilisant à la fois un triple aarch64 et arm, pour assurer la rétrocompatibilité avec les logiciels 32 bits.
Passons à la partie suivante : « Linux ». Évident. C'est un noyau Linux.
Mais la dernière partie de ces « triples » mérite d'être expliquée, au moins brièvement, parce que c'est un tel sac de nœuds et que chaque compilateur qui utilise des « triples » (GCC, Rust, Go, LLVM) le fait légèrement différemment. « Android », le premier exemple, a du sens, mais qu'est-ce que « androideabi » ? EABI signifie « embedded application binary interface », mais vous n'avez pas vraiment à vous inquiéter de cela – considérons simplement EABI comme la troisième valeur « de base ». Vous verrez aussi « gnueabi », ce qui a maintenant un peu plus de sens – l'implémentation GNU de l'EABI, n'est-ce pas ? (Ce à quoi cela fait réellement référence, c'est à la bibliothèque C de GNU, glibc, ce qui explique pourquoi vous verrez aussi des triples comme arm-linux-musleabi lors de la compilation contre une bibliothèque C alternative comme musl). Vous pourriez aussi voir « gnueabihf ». HF signifie « hard float », et si vous voulez savoir comment ARM a implémenté une solution sur puce pour les opérations en virgule flottante, allez lire un article Wikipédia.
Voici ce que nous devons savoir :
Si vous utilisez une chaîne d'outils LLVM, nous déclarerons notre intention de faire de la compilation croisée en définissant CROSS_COMPILE=aarch64-linux-gnu- CROSS_COMPILE_32=arm-linux-gnueabi- (comme ça, avec le trait d'union final à la fin) sur la ligne de commande.
Si vous compilez pour un appareil très ancien et donc en utilisant une chaîne d'outils GCC, nous aurons besoin de deux ensembles de fichiers, préfixés avec des triples différents. Ceux-ci peuvent être les mêmes que les valeurs de l'exemple LLVM, ou ils peuvent être différents, comme dans les chaînes d'outils pour j7xelte.
Mais POURQUOI y a-t-il autant de façons d'écrire la même chose ? i386, i686, 386, i32, i64, x86, x64, x86_64, amd64 – quelle raison possible pourrait-il y avoir à une telle variation ?!
Bande dessinée pertinente de xkcd :
Revenons à l'exemple que je vais compiler aujourd'hui (surya), il se trouve que j'ai enregistré les informations /proc/version d'un autre noyau, qui disait :
C'est plus ou moins à quoi cela devrait ressembler, avec le lien, les sommes de contrôle, les versions du compilateur/éditeur de liens, etc. Et puisque les versions de clang et LLD ici étaient toutes deux 17.0.3 et que le /proc/version mutilé que nous avons de la LineageOS actuelle montre LLD 19.0.3, je pense qu'il est raisonnable de chercher une chaîne d'outils qui ait 19.0.3 pour les deux.
Après environ trois minutes de recherche, j'ai trouvé un dépôt que nous pouvons cloner comme sous-module (pour faciliter une compilation reproductible) ici : https://gitlab.com/kei-space/clang/r536225/ Cette chaîne d'outils s'est avérée avoir de sérieux problèmes, alors je suis allé avec Neutron Clang 19. (Nous y reviendrons).
Nous avons donc notre source et notre chaîne d'outils prêtes à cloner, ce qui nous amène à :
J'ai décidé de créer un nouvel utilisateur pour ce tutoriel, surtout pour pouvoir utiliser gh auth login et exécuter des commits sans les faire accidentellement sur mon compte github principal. Mais pour ce faire, j'ai dû créer un compte (dans un navigateur), configurer un nouvel utilisateur, générer des clés SSH pour lui…
Copiez .ssh/id_ed25519.pub dans GitHub, puis exécutez gh dans le terminal
Et puis je suis prêt
…presque. Je dois encore forker le dépôt dans mon navigateur,
puis l'initialiser/le cloner dans le terminal.
Donc une fois que tout est prêt (sources à jour, origin défini, etc.), nous pouvons commencer à cloner les sous-modules.
La syntaxe est git submodule add URL directory/
Rappelez-vous, pour un historique de commits très propre, nous voulons exécuter git add . et git commit -a après chaque modification.
Je ne vais pas encore exécuter git push, mais quand je le ferai éventuellement, cela mettra à jour tous les commits.
C'est ici que vous vous attendez probablement à ce que le guide parle de faire des modifications au code source du noyau pour ajouter le support Nethunter. Cela arrive – bientôt. AVANT cela, cependant, voyons comment la source non modifiée compile avec notre chaîne d'outils et notre configuration.
Cette configuration du noyau actuellement en cours d'exécution doit être copiée dans le répertoire source du noyau, mais puisque nous allons utiliser out/ pour nos binaires compilés, je dois aussi l'y copier. Je dois aussi ajouter le répertoire bin/ de la chaîne d'outils à ma variable PATH. Je pourrais écrire export PATH=/home/build_user/android_kernel_xiaomi_surya/toolchain/bin:$PATH mais une façon plus simple est de simplement cd vers ce répertoire puis d'exécuter export PATH=$(pwd):$PATH. $() se développe en le résultat d'une commande qu'il contient, et pwd affiche le chemin complet vers le répertoire de travail actuel.
J'ai aussi listé le contenu du répertoire bin/ de la chaîne d'outils pour que vous puissiez voir comment les binutils LLVM ont leur propre préfixe. Idéalement, le Makefile contient une instruction où si je déclare LLVM=1, il définit automatiquement AR=llvm-ar, AS=llvm-as, etc. Voyons donc ce qu'il y a dans le Makefile.
Excellent ! Je peux simplement déclarer LLVM=1 et ne pas avoir à déclarer individuellement le reste… la plupart. J'ai aussi besoin d'utiliser l'assembleur LLVM, mais cela a sa propre déclaration, LLVM_IAS :
Donc maintenant tout ce que j'aurai à déclarer, c'est ARCH=arm64 LLVM=1 LLVM_IAS=1 AS=llvm-as O=out CROSS_COMPILE=aarch64-linux-gnu- CROSS_COMPILE_32=arm-linux-gnueabi-. Cela peut sembler beaucoup, mais c'est bien moins que de déclarer chaque binutil individuellement.
Alors exécutons notre commande pour ouvrir la configuration….
Attendez. On dirait que cette chaîne d'outils a quelques problèmes. J'ai donc décidé de désinitialiser le sous-module et d'utiliser plutôt Neutron Clang 19.0.0 depuis ici, et je vais le télécharger avec wget
Puis l'extraire dans un répertoire toolchain/ nouvellement créé (en oubliant d'abord la syntaxe pour extraire les fichiers .tar.zst)
Et ensuite j'ajoute ce répertoire au fichier .gitignore.
Maintenant, quand j'exécute ceci :
Cela fonctionne, ouvrant le menu nconfig :
Beaucoup de tutoriels vous diront d'utiliser menuconfig, mais je préfère nconfig parce que 1) il est plus joli 2) il n'a pas la même tendance que menuconfig à ne pas se charger parce qu'il ne trouve pas les bibliothèques ncurses que vous avez déjà installées. En tout cas, ce n'est qu'un noyau de test, donc nous pouvons charger .config et l'enregistrer (encore comme .config) et nous en avons fini pour l'instant.
Et maintenant, nous essayons de compiler Image.gz, et…
Notre première erreur ! Hourra !
D'après ceci, c'est parce qu'une mise à jour d'Arch a cassé quelque chose.
Bien qu'Arch reprenne, Arch donne aussi, dans ce cas sous la forme du paquet AUR libxml-legacy. J'ai donc installé cela, relancé make, et cette fois :
Félicitations aux mainteneurs de LineageOS, car tout le noyau a compilé avec un seul avertissement :
Donc maintenant dans out/arch/arm64/boot/ nous pouvons trouver Image.gz. Mais comment flasher cela sur notre appareil ?
Nous devons créer un zip AnyKernel3.
Il y a deux façons de faire cela :
Image, cela peut être le Image.gz que nous avons créé et rien de plus, cela peut être Image.gz-dtb (une image combinant device tree et kernel – ces dernières sont moins courantes de nos jours, mais si votre appareil en attend une, il vous faudra activer « Build a concatenated Image.gz-dtb » dans la configuration de votre kernel), ou cela peut être Image.gz, dtbo.img et/ou dtb.img.
Dans le cadre de ce guide, j’ai téléchargé l’un des nombreux kernels distribués sur Telegram avec un nom d’anime stupide et sans source liée. N’installez jamais un de ces kernels.
Mais nous ne ferons pas cela, ne vous inquiétez pas, nous empruntons juste leur configuration de zip AnyKernel. Je renomme donc le fichier et je le décompresse
Et j’ai modifié le script anykernel.sh pour changer aussi la chaîne du nom du kernel. Maintenant, remplaçons le Image.gz de ce zip par notre nouveau fichier
Utiliser zip -f (pour « freshen ») remplace simplement le fichier à l’intérieur par la nouvelle version. 0 correspond à une compression nulle.
Voyons si je peux flasher ce kernel et s’il démarrera, mais d’abord :
Il est bien plus facile de suivre ses zips de kernel quand on y inclut des chaînes date et heure.
Cependant, par souci de perfeccionnisme (et de dépendre le moins possible des kernels Telegram), je vais vous expliquer comment créer vos propres fichiers dtb.img et/ou dtbo.img, car la documentation à ce sujet est douloureusement insuffisante.
Il existe deux programmes AOSP pour cela. Le premier, mkdtboimg, est écrit en Python, ce qui permet de simplement télécharger et exécuter mkdtboimg.py depuis le site officiel d’AOSP. Cependant, vous aurez peut-être aussi besoin de l’autre, mkdtimg, écrit en C et fourni sans Makefile. Selon la documentation, les fichiers Android.bp suffisent -- il suffit de récupérer l’intégralité du code AOSP pour pouvoir exécuter les commandes qui y sont listées. Je trouve cela complètement insensé, alors j’ai pris le Makefile que quelqu’un d’autre avait créé il y a longtemps pour compiler cet outil indépendamment, mis à jour les fichiers sources avec la dernière version, puis je l’ai compilé en static-PIE contre Musl. Vous pouvez télécharger ce binaire (qui fonctionnera sur n’importe quel ordinateur Linux x86_64, comme celui que vous utilisez pour compiler le kernel) depuis ici, ou le compiler vous-même à partir du code source.
Voici maintenant la partie délicate : les fichiers .dtbo produits lors d’une compilation de kernel ne sont pas convertibles en fichiers dtb.img/dtbo.img sans un petit effort supplémentaire. Android exige que l’appel à dtc inclue le drapeau -a 64. Comme nous appelons déjà DTC_EXT=/usr/bin/dtc pour forcer le Makefile à utiliser notre joli DTC mis à jour depuis le gestionnaire de paquets et non celui cassé présent dans beaucoup de kernels, il n’est pas bien difficile de placer cette commande entre guillemets simples et d’ajouter le drapeau. Vous pouvez simplement passer DTC_EXT='/usr/bin/dtc -a 64'. Dans mon cas, cependant, j’aime créer (et tester) des scripts build.sh pour tous les kernels que je maintiens, afin que même sans lire ce guide, n’importe qui, même un parfait n00b, puisse compiler le sien à partir des sources. Alors que je me débattais avec des couches et des couches de logique bash à guillemets simples et doubles, j’ai trouvé une solution simple, bien que peu élégante, qui garantit que DTC est appelé avec le bon drapeau : un script wrapper.
J’ai simplement créé un fichier exécutable nommé dtc dans le répertoire racine de mon kernel, contenant les lignes suivantes :
#!/bin/sh
exec /usr/bin/dtc -a 64 $@
Ensuite, j’ai pointé DTC_EXT= vers ce fichier, et cela a réglé le problème.
Vous vous demandez peut-être : « Quels fichiers .dtbo ? Mes compilations de kernel n’en génèrent jamais ! » Dans ce cas, vérifiez que ce symbole de kernel est activé :
Alors, comment utiliser ces outils ? La première chose que j’ai faite a été d’analyser les fichiers dtb.img et dtbo.img trouvés dans d’autres zips de kernel pour voir quel type de fichiers c’était. (Je sais, je sais, nous ne voulons pas dépendre des étranges kernels de la scène ROM custom pour les nôtres, mais cela vaut la peine de vérifier). La commande file dtb.img a renvoyé :
dtb.img: Device Tree Blob version 17, size=345849, boot CPU=0, string block size=31481, DT structure block size=314312
ce qui est (presque) exactement le même résultat que j’obtiens quand j’exécute file ../arch/arm64/boot/dts/qcom/sdmmagpie.dtb :
../arch/arm64/boot/dts/qcom/sdmmagpie.dtb: Device Tree Blob version 17, size=345856, boot CPU=0, string block size=31481, DT structure block size=314312
Cette petite différence m’inquiétait, jusqu’à ce que j’exécute diff <(strings dtb.img) <(strings ../arch/arm64/boot/dts/qcom/sdmmagpie.dtb) et découvre qu’ils contenaient exactement les mêmes éléments. J’ai donc pu supposer sans risque que créer mon propre dtb.img revenait simplement à copier sdmmagpie.dtb et à changer le nom.
Quant à dtbo.img, file ne nous aide pas beaucoup :
dtbo.img: data
Mais c’est là que nous pouvons utiliser mkdtimg ou mkdtboimg.py pour l’analyser. Quand j’exécute mkdtimg dump dtbo.img, j’obtiens :
Je sais donc que pour créer le mien, je dois passer soit
mkdtimg create dtbo.img --page_size=4096 ../arch/arm64/boot/dts/qcom/sdmmagpie-idp-overlay.dtbo
ou
mkdtboimg create --page_size=4096 dtbo.img ../arch/arm64/boot/dts/qcom/sdmmagpie-idp-overlay.dtbo
Les deux commandes produisent des fichiers identiques. Vous pouvez aussi exécuter mkdtimg dump dtbo.img ensuite et comparer les valeurs avec l’autre fichier. Si vous devez inclure plus d’un fichier .dtbo dans votre image, ajoutez simplement son chemin à la fin de l’une ou l’autre commande.
Revenons maintenant au kernel de test que nous avons créé. La bonne nouvelle, c’est qu’il se flash sans problème ; la mauvaise, c’est que je vais devoir corriger ce Makefile qui produit un /proc/version si moche.
Mais cela peut attendre. Nous en sommes enfin arrivés à :
Il est temps d’ajouter quelques sous-modules. D’abord, celui-ci, qui est accompagné d’instructions très faciles à suivre. (Note : il contient désormais aussi les symboles kernel du sous-système CAN, car ma pull request qui les ajoutait a été fusionnée, même si vous ne le verrez pas dans les captures ci-dessous).
Et maintenant, quand je relance make nconfig (même commande qu’avant)
Nous avons cette charmante nouvelle option
Ceci activera tout cela. Sélectionnez cette option, enregistrez sous .config – mais attention, cela enregistrera dans out/.config et nous supprimerons tout ce répertoire avant de recompiler. Donc, une fois sorti de nconfig, copiez ce fichier dans le répertoire source du kernel.
Il est maintenant temps de patcher quelques fichiers sources. Ajoutons donc le dépôt des scripts de compilation nethunter comme sous-module :
On fait cd vers le nouveau répertoire et on lance ./build.sh, puis on choisit l’option 4: Apply Nethunter kernel patches.
Si vous obtenez un message indiquant « the test run was completed with errors », N’appliquez PAS le patch. Sinon, allez-y. Dans mon cas, j’ai appliqué les patches 4, 5 et 8.
Maintenant que nous avons fait des modifications, retournons dans le répertoire source racine du kernel et commitons-les.
À ce stade, vous pourriez simplement recompiler le kernel et ce serait terminé. Mais je suis du genre à en faire trop, et je veux inclure le support d’un tas de trucs en plus, à savoir :
Nous devrons modifier le Kconfig et le Makefile dans drivers/net/wireless/realtek pour que ces nouveaux pilotes soient pris en compte dans la configuration, mais aussi :
Assurez-vous de passer la plateforme dans le rtl8812au/Makefile à ANDROID_ARM64 (ainsi que pour rtl8188eus).
Il vaut aussi la peine de revérifier le Kconfig des pilotes nouvellement ajoutés pour voir comment s’appelle l’option de configuration :
Je sais donc que je dois y faire référence sous le nom 88XXAU dans le Makefile situé un niveau au-dessus.
Heureusement, le Kconfig est simplement sourcé comme ceci :
Je vais devoir modifier ces fichiers à nouveau après avoir ajouté rtl88x2bu et la branche ARM de rtl8188fu. (Et il s’avère que l’option de configuration de rtl88x2bu s’appelle RTL8822BU, d’où l’intérêt de toujours vérifier).
Passons maintenant aux pilotes MediaTek rétroportés. En utilisant ce commit comme guide, j’ai réussi à porter ces pilotes sur deux appareils différents utilisant des kernels 4.14.x. (Vous voyez pourquoi l’historique des commits est important ?) Mais il nous faut d’abord le répertoire mt76 avec tous ses fichiers.
Plutôt que de devoir git cloner un kernel 4.19, copier les fichiers, puis appliquer les patches nécessaires à ces fichiers dans votre nouvelle copie, vous pouvez simplement ajouter https://github.com/akabul0us/mt76.git comme sous-module. Modifiez ensuite le Makefile et le Kconfig dans le répertoire drivers/net/wireless/mediatek :
En ajoutant ce dépôt avec les patches du commit mentionné précédemment déjà appliqués à leur source, nous pouvons passer directement aux modifications à apporter aux autres fichiers du kernel. Le premier est celui-ci :
Mais il s’avère que notre source de kernel possède déjà cette structure :
Nous passons donc au fichier suivant à modifier, include/linux/overflow.h. Celui-ci comporte bien quelques modifications, mais comme elles sont très claires dans le commit d’origine, je vous épargne d’autres captures. include/linux/skbuff.h et include/linux/scatterplot.h ont aussi des changements, mais aucun n’est nécessaire pour include/net/cfg80211.h. Les changements nécessaires dans include/net/mac80211.h sont mineurs – il suffit d’insérer RX_ENC_HE comme dernière ligne dans enum mac80211_rx_encoding { } et d’ajouter u8 vht_flag; dans struct ieee80211_rx_status { }. Le fichier net/wireless/of.c existe déjà et est identique à celui du commit que nous sommes en train de cherry picker, donc nous en avons fini avec cela. (Ouf !)
Quant au support Docker, grâce (encore une fois) à cyberknight777 pour ceci, nous n’avons qu’à copier-coller
Et maintenant, nous sommes prêts à refaire nconfig ! … presque. D’abord, commitez et pushez les changements, puis rm -rf out/ (en vous assurant d’avoir enregistré votre .config en dehors de là), mkdir -p out, et ENSUITE nous pouvons revenir dans la configuration.
Une note à propos des pilotes USB Realtek hors arborescence que nous avons ajoutés au kernel : Ils sont un peu nuls. Si vous essayez d’en compiler plus d’un en inline, vous obtiendrez des erreurs à l’édition de liens. Une solution de longue date consiste à n’en compiler qu’un seul (1) en inline et le reste en modules. Les pilotes Mediatek, eux, peuvent être compilés en inline sans problème.
J’ai fini par activer tout un tas d’autres choses ; si vous voulez voir le diff complet, je l’ai mis ici : ici. Mais bon, compilons !
Bon début - c’est toujours agréable d’apercevoir de nouveaux fichiers objet que l’on vient d’ajouter en train d’être compilés sans erreurs ni avertissements.
Ça ? Moins agréable, mais facile à corriger. Il suffit de retirer -Wno-stringop-overread du Makefile qui utilise ce drapeau d’avertissement. Et pendant qu’on y est, -Werror est un peu hardcore, vous ne trouvez pas ? (Ce drapeau signifie « traiter tous les avertissements comme des erreurs », ce qui arrête la compilation à la moindre alerte, y compris un drapeau -W inconnu).
Au moins, celui-ci est facile à corriger.
Un simple # devant cette ligne et nous sommes prêts à relancer make – et cette fois, il est allé jusqu’au bout !
Mais comme j’ai configuré certains pilotes en modules, nous n’avons pas tout à fait terminé. Nous devons lancer make modules, ou plus précisément, make -j $(nproc --all) ARCH=arm64 O=out CROSS_COMPILE=aarch64-linux-gnu- CROSS_COMPILE_32=arm-linux-gnueabi- LLVM=1 LLVM_IAS=1 AS=llvm-as modules. Et croyez-moi, le code du pilote Realtek pour rtl8188fu est un vrai merdier :
Pourrais-je corriger manuellement chacune des lignes à l’origine de ces avertissements ? Bien sûr. Vais-je le faire ? Non. Il y a une raison pour laquelle je compile ces pilotes en modules et non en inline, et j’encourage activement tout le monde à éviter les adaptateurs Realtek. Cependant :
Ils ont au moins compilé avec succès. On y revient dans un instant. D’abord, rafraîchissons notre zip de kernel :
(J’ai failli oublier - ce n’est plus un kernel « test », c’est un vrai kernel Nethunter).
Pour les modules, les fichiers .tar sont vraiment la meilleure solution car ils préservent tout ce qui concerne les fichiers qu’ils contiennent – mais ils préservent aussi les chemins. À moins d’y remédier, lorsque l’on extrait notre archive de modules, on crée tout un tas de répertoires, comme drivers/net/wireless/realtek/rtl8188fu/rtl8188fu.ko par exemple. Créons donc un répertoire (et ajoutons-le au .gitignore), copions-les dedans, puis créons l’archive.
Peut-on les flasher comme on flasherait un kernel ?
Ils doivent être extraits quelque part sur votre appareil. Je dis « quelque part » parce que l’endroit n’a pas vraiment d’importance, tant que quand vous lancez insmod /whatever/path/to/whatever.ko, le module se charge. Vous pourriez le faire dans /sdcard, ce serait très bien, mais rappelez-vous, j’aime en faire trop, donc je les extrairai au « bon » endroit pour cet appareil, /vendor/lib/modules. Bien sûr, /vendor est monté en lecture seule, il faudra donc d’abord ouvrir un shell root (PAS dans le terminal Nethunter – c’est un chroot – même si vous pouvez utiliser l’application terminal Nethunter en sélectionnant « New Session → Root Shell ») et lancer mount -o rw,remount /vendor avant de pouvoir toucher à cette partition. Puis cd /vendor/lib/modules; tar xzvf /sdcard/or/wherever/you/saved/the/tarball.tgz; mount -o ro,remount /vendor et en voilà fini avec les modules.
Si vous obtenez une erreur d’espace insuffisant sur cette partition, vous pouvez aussi utiliser un lien symbolique – rangez le fichier dans, par exemple, /sdcard/modules, puis créez un lien avec le chemin absolu. Si nous faisions cela avec 88x2bu.ko, nous lancerions ln -s /storage/emulated/0/modules/88x2bu.ko /vendor/lib/modules/88x2bu.ko.
Faites un dernier push sur votre dépôt et, si vous voulez, enregistrez le .config que vous avez utilisé comme nouvelle defconfig pour nethunter. (C’est vraiment un coup de main pour ceux qui compilent à partir des sources).
Est-ce que ça marche ? Ça se flash sans problème, d’accord, mais est-ce que ça marche ?
Bon, il est déjà tard ici donc je ne vais pas tester absolument toutes les fonctionnalités maintenant, mais commençons par la plus cruciale : le mode moniteur/injection de paquets sur les pilotes que j’ai ajoutés au kernel. Commençons par rtl88x2bu :
Pas mal du tout, pour un pilote Realtek.
Et maintenant, le plat de résistance : mt76x2u :
Ça, c’est un appareil de pentest !
La dernière étape consiste à téléverser votre .zip et .tar.gz sur GitHub en tant que release. Ensuite, allez en parler sur xdaforums, Telegram, Twitter, partout où vous pensez que d’autres utilisateurs du même appareil/ROM le trouveront et en profiteront.
Et quand un pauvre type ingrat au cul sale répondra à votre post « NOW U MAKE KARNEL FOR DEVICE BUTTPHONE 34AC PRO EDITION?!!? », donnez-lui le lien vers ce guide et dites-lui de git gud.
Bonne nuit à tous.
--Akabul0us