akabulous/so_you_want_to_build_a_nethunter_kernelSchritt-für-Schritt-Anleitung zum Erstellen benutzerdefinierter Kali-NetHunter-Kernel für Android: Quellcode-Beschaffung, Toolchain-Auswahl, Cross-Kompilierung und Flashen.
Das größte Hindernis für die meisten Menschen, die ein Nethunter-Gerät einrichten möchten, ist die Kernel-Anforderung. Wenn dein Gerät nicht bereits über einen vorgebauten (und gepflegten) Kernel verfügt, wirst du aufgefordert, selbst einen zu bauen. Es gibt bereits viele Dokumentationen zu diesem Prozess, aber meiner Erfahrung nach kann es schwierig sein zu wissen, was in deinem Fall zutrifft und was nicht.
Dieses Problem wird durch Arschlöcher Leute verschärft, die Anleitungen mit Clickbait-artigen Titeln wie „Bau einen Nethunter-Kernel für JEDES Android-Gerät!“ oder mit falschen Versprechungen wie „Lerne, in zehn Minuten einen Nethunter-Kernel zu kompilieren!“ schreiben. Es ist außerdem eine unglückliche Realität des Internets im Jahr 2025, dass viele Idioten Leute glauben, dass ChatGPT oder andere große Sprachmodelle autoritative Antworten auf ihre Fragen haben, obwohl diese Modelle in Wirklichkeit nur Informationen besitzen, die sie von den zuvor genannten Arschlöchern eingesammelt haben.
Ich schreibe diesen Leitfaden so gründlich und ehrlich wie möglich. Er ist jedoch nicht dazu gedacht, das einzige Dokument zu sein, das du für diesen Prozess lesen musst – sicherlich wirst du Fragen haben, die dieses Dokument nicht beantworten kann. Ich möchte dich ermutigen, nach Antworten auf diese Fragen in der relevanten Softwaredokumentation zu suchen und NICHT auf YouTube oder bei ChatGPT.
Bevor du mit irgendetwas in diesem Prozess beginnst, solltest du bereits:
apt update && apt upgrade -y (optional: Metapakete hinzugefügt)Um diesen Prozess abzuschließen, benötigst du:
cd, rm, ls, mkdir, find, diff, grep, usw.)vim für die Coolen, sonst nano)build-devel bei Arch-basierten Distributionen, build-essential bei Debian-basierten) – ich würde außerdem empfehlen, Perl + Python3 zu installieren, da einige Kernel-Makefiles diese benötigenWird das bei meinem Gerät möglich sein?
Der Linux-Kernel ist unter der GNU General Public License 2.0 lizenziert, einer Copyleft-Lizenz. Das bedeutet, dass der Quellcode des Linux-Kernels frei verbreitet wird und du den Quellcode nach Belieben ändern darfst (wie es jeder Android-Hersteller getan hat), ABER dein resultierender Quellcode muss ebenfalls frei verbreitet werden.
Zur absoluten Überraschung von niemandem missachten viele der gigantischen Konzerne, die GPL-lizenzierten Code verwenden, die Bedingungen dieser Lizenz. Sie weigern sich entweder, ihren Quellcode zu verbreiten, oder veröffentlichen nur einen Teil davon (meist kaputt, veraltet und mit eingebetteten Binärblobs). Wenn für den Kernel deines Geräts kein Quellcode verfügbar ist, gibt es keine Möglichkeit, einen Nethunter-Kernel dafür zu erstellen.
Deine Fähigkeit, den Bootloader zu entsperren und eine Custom-ROM zu installieren, hängt ebenfalls stark von den Launen deines Geräteherstellers ab. Selbst wenn das Entsperren des Bootloaders erlaubt ist und du dein Telefon mit Magisk rooten konntest: Wenn der Hersteller keine Device Trees veröffentlicht, gibt es wahrscheinlich keine Custom-ROMs für dein Gerät. In diesem Fall ist es äußerst zweifelhaft, dass der von ihm veröffentlichte Kernel-Quellcode (falls vorhanden) seit seiner Veröffentlichung gewartet wurde oder dass er sich überhaupt ohne Änderungen bauen lässt. Wenn du niemanden siehst, der irgendetwas (Kernel, ROMs, Recoveries) für dein Gerät pflegt, wird es schwierig, wenn nicht unmöglich sein, dieses Gerät in ein vollwertiges Nethunter zu verwandeln.
Eine Anmerkung zu Kernel-Versionen
Nehmen wir an, es gibt regelmäßig aktualisierte und gepflegte Custom-ROMs/Kernel/Recoveries für dein Gerät, aber einfach keinen Nethunter-Kernel. In diesem Fall solltest du diesen Prozess abschließen können, aber der Prozess variiert je nachdem, welche Version des Linux-Kernels dein Gerät verwendet.
Die Informationen in diesem Leitfaden basieren auf meiner Erfahrung mit der Änderung von 4.14.x-Kerneln. Es gibt ältere Anleitungen, die von GCC-Toolchains (anstatt LLVM/clang, wie wir sie verwenden werden) sprechen und auf 3.x-Kernel zutreffen. Wenn dein Gerät eine 5.x/6.x-Version des Linux-Kernels verwendet, reichen die Informationen in diesem Leitfaden nicht aus, um diesen Prozess abzuschließen. Die Android-Baumethode ändert sich ständig, und du solltest nach einem Leitfaden suchen, der GKI-Kernel und die Verwendung von Bazel/Kleaf abdeckt.
Eine gute Möglichkeit, Repos mit dem Kernel-Quellcode für dein Gerät zu finden, ist die Verwendung seines Codenamens. Jedes Android-Gerät hat einen, auch wenn einige Hersteller (z. B. OnePlus) dabei etwas mehr Spaß haben als andere (z. B. Samsung). Der Codename meines Xiaomi Poco X3 NFC ist „surya“, während der Codename meines Samsung A51 „SM-A515F“ ist. Typischerweise folgen Kernel-Quell-Repos der Namenskonvention android_kernel_MANUFACTURER_CODENAME, wobei der Hersteller das Mutterunternehmen ist, also android_kernel_xiaomi_surya, nicht android_kernel_poco_surya.
Es kann jedoch auch Repos geben, die auf dem SoC (System-on-a-Chip) deines Geräts basieren, manchmal „unified“ (vereinheitlicht), um Quelldateien für andere Geräte mit demselben SoC zu enthalten. Das ist bei dem von mir erwähnten Samsung der Fall, dessen Quell-Repo android_kernel_samsung_exynos9611 heißt. Schau dich auf github/gitlab um und sieh, was du finden kannst.
Für die Zwecke dieses Leitfadens verwende ich das neueste LineageOS 22.2 (Build vom 2025-08-04) auf surya. Daher möchte ich den Kernel-Quellcode aus dem LineageOS-Repo klonen. Aber bevor ich das tue, möchte ich zwei Dateien von meinem Gerät auf den Computer kopieren, mit dem ich den Kernel bauen werde: /proc/config.gz und /proc/version.
Ich könnte die erste Datei, /proc/config.gz, nach /sdcard kopieren, sie per ADB vom Gerät ziehen, mit gunzip entpacken und umbenennen. Aber das scheint eine Menge Schritte zu sein, also habe ich stattdessen Folgendes getan:
Dann habe ich auf dem Gerät selbst (als root) Folgendes ausgeführt:
Was passiert hier?
Auf meinem Laptop: nc (netcat) -l (auf eingehende Verbindungen lauschen) -p (Port) 4545 (eigentlich könnte das jede Zahl zwischen 1024-65535 sein, aber ich verwende normalerweise 4545) > (in Datei schreiben) surya-defconfig-lineageos22.2-20250804 (beschreibender Dateiname) < (Eingabe aus Datei) /dev/null (Nullgerät – das stellt sicher, dass ein versehentlicher Tastendruck nicht in die Datei gesendet wird, die ich empfange, und sie möglicherweise beschädigt).
Auf dem Telefon: zcat (wie der Befehl cat zum Verketten, aber für gzip-komprimierte Dateien) /proc/config.gz (die Kernel-Konfiguration, mit der der aktuell laufende Kernel gebaut wurde) | (Ausgabe dieses Prozesses als Eingabe an den nächsten Prozess senden) nc (wieder netcat) 192.168.1.42 (die lokale IP-Adresse meines Laptops) 4545 (der Port, den ich vorher gesetzt habe)
Obwohl dir das eigentlich die .config-Datei liefern sollte, mit der dein aktuell laufender Kernel gebaut wurde, ist das nicht immer der Fall. Einige modernere Geräte/neuere ROM-Builds verweigern den Boot, wenn die in /proc/config.gz gespeicherte Konfiguration nicht mit der .config übereinstimmt, die zum Bauen des Stock-Kernels verwendet wurde. Glücklicherweise ist das die einzige Prüfung, die stattfindet (nichts viel Schwereres zu umgehen wie z. B. eine SHA256-Prüfsumme des gesamten Kernels selbst), sodass einige clevere Leute einen Weg gefunden haben, die Datei in /proc/config.gz zu spoofen, damit sie trotz ihrer Änderungen zum Stock-Kernel passt. Wenn du dir unsicher bist, ob die Datei auf deinem Gerät echt oder gespooft ist, kannst du zcat /proc/config.gz | head und dann uname -r ausführen. Wenn die Release-Nummern nicht übereinstimmen, wurde die Datei in /proc gespooft. In diesem Fall kannst du zwar weiterhin diesem Leitfaden folgen, aber du solltest vielleicht diff ausführen, um die extrahierte Konfiguration mit einigen Dateien zu vergleichen, die du im Verzeichnis arch/arm64/configs deiner Kernel-Quelle findest.
Was /proc/version betrifft, ist es möglicherweise nicht so notwendig, diese Datei zu übertragen, da wir eigentlich nur die Informationen darüber benötigen, welche Version von clang/ld.lld zum Kompilieren verwendet wurde. Wir können also einfach cat /proc/version ausführen und uns das ansehen:
Hoppla! Sieht so aus, als hätte die Person, die diesen Kernel gebaut hat, einen kleinen Patzer gemacht, und ihr Makefile hat zwar alle -CFLAGS aufgezeichnet, die sie mit clang verwendet hat, aber nicht die Version von Clang. Wir können jedoch sehen, dass sie eine vorkompilierte Android-Toolchain und ld.lld Version 19.0.1 verwendet haben.
Hier ist ein etwas hilfreicheres Bild. Die erste Ausgabe stammt von /proc/version, bevor ich einen neuen Kernel auf dem Samsung A51 modifiziert, gebaut und installiert habe. Die zweite Ausgabe stammt vom aktuellen /proc/version.
Fällt dir etwas auf? (Nein, nicht mein bizarrer Benutzername und Hostname).
Der beste Trick bei der Auswahl einer zu verwendenden Toolchain ist, die EXAKTE Toolchain zu verwenden, mit der der aktuell laufende Kernel kompiliert wurde.
In diesem Fall war das Neutron clang 18.0.0git, das recht einfach zu finden war:
Und sieh an, die md5sums stimmen überein und alles.
Nur zum Spaß werfen wir einen kurzen Blick auf den /proc/version-String eines deutlich älteren Geräts, Samsung J7 (2016), Codename j7xelte:
Das ist ein Gerät, das alt genug ist, um zum Kompilieren des Kernels noch GCC-Toolchains zu verwenden.
Wenn ich jedoch nach „gcc version 4.9.x 20150123 prerelease“ suche, finde ich zwei Repositories:
Welches sollte ich also herunterladen?
Die Antwort: beide. GCC unterscheidet sich von Clang dadurch, dass beim Bauen von Compilern/Binutils/Linkern usw. für das Cross-Compiling eine separate Toolchain für jedes „Target-Triple“ erstellt werden muss. Das Target-Triple hat (angeblich) das Format
machine-vendor-operating_system
Aber wie wir sehen werden, hat diese „Regel“ eine Million Ausnahmen. Beginnen wir aber mit „machine“.
Im Abschnitt „Was du benötigst“ dieses Dokuments habe ich gesagt, dass du einen 64-Bit-Computer mit Intel- oder AMD-Prozessor benötigst, auf dem GNU/Linux läuft. Das liegt daran, dass die Toolchains, die wir verwenden werden, für die Ausführung auf x86_64-linux-gnu kompiliert wurden.
Diese Toolchains sind jedoch Cross-Compiler, d. h. der Maschinencode, den sie aus den C-Quellcodedateien erzeugen, läuft nicht auf diesem Computer, sondern auf einem anderen mit einem eigenen Target-Triple.
Aarch64, auch als arm64 bekannt, ist die Architektur, die fast jedes Android-Gerät verwendet. Arm ohne das „64“ bezieht sich auf die 32-Bit-Implementierungen von ARM-Chips. Die meisten Android-Kernel werden sowohl mit einem Aarch64- als auch mit einem Arm-Triple kompiliert, um Abwärtskompatibilität mit 32-Bit-Software zu bieten.
Weiter zum nächsten Teil: „Linux“. Selbsterklärend. Es ist ein Linux-Kernel.
Aber der letzte Teil dieser „Triples“ ist zumindest kurz eine Erklärung wert, weil es ein so verworrenes Durcheinander ist und jeder Compiler, der „Triples“ verwendet (GCC, Rust, Go, LLVM), dies etwas anders tut. „Android“, das erste Beispiel, ergibt Sinn, aber was ist „androideabi“? EABI steht für „embedded application binary interface“, aber du musst dir darüber wirklich nicht zu viele Gedanken machen – betrachten wir EABI einfach als den „Basis“-dritten Wert. Du wirst auch „gnueabi“ sehen, was jetzt etwas mehr Sinn ergibt – die GNU-Implementierung von EABI, richtig? (Was das wirklich bedeutet, ist die C-Bibliothek von GNU, glibc, weshalb du auch Triples wie arm-linux-musleabi siehst, wenn du gegen eine alternative C-Bibliothek wie musl baust). Du könntest auch „gnueabihf“ sehen. HF steht für „hard float“, und wenn du wissen willst, wie ARM eine On-Chip-Lösung für Gleitkomma- und Ganzzahloperationen implementiert hat, lies einen Wikipedia-Artikel.
Hier ist, was wir wissen müssen:
Wenn wir eine LLVM-Toolchain verwenden, erklären wir unsere Absicht zu cross-kompilieren, indem wir CROSS_COMPILE=aarch64-linux-gnu- CROSS_COMPILE_32=arm-linux-gnueabi- setzen (genau so, mit dem abschließenden - am Ende) in der Kommandozeile.
Wenn du für ein sehr altes Gerät kompilierst und daher eine GCC-Toolchain verwendest, benötigen wir zwei Dateisätze, die mit verschiedenen Triples präfixiert sind. Diese können dieselben sein wie die Werte im LLVM-Beispiel, oder sie können anders sein, wie bei den Toolchains für j7xelte.
Aber WARUM gibt es so viele Möglichkeiten, dasselbe zu schreiben? i386, i686, 386, i32, i64, x86, x64, x86_64, amd64 -- was für einen Grund könnte es für eine solche Abweichung geben?!
Relevanter Comic von xkcd:
Zurück zu dem Beispiel, das ich heute kompilieren werde (surya): Ich habe zufällig die /proc/version-Informationen eines anderen Kernels gespeichert, die wie folgt lauteten:
So sollte es mehr oder weniger aussehen, mit Link, Prüfsummen, Compiler-/Linker-Versionen usw. Und da die clang- und LLD-Versionen hier beide 17.0.3 waren und das verstümmelte /proc/version, das wir vom aktuellen LineageOS haben, LLD 19.0.3 zeigt, denke ich, dass es naheliegt, nach einer Toolchain zu suchen, die für beides 19.0.3 hat.
Nach etwa drei Minuten Suche fand ich ein Repo, das wir als Submodul klonen können (um einen reproduzierbaren Build zu erleichtern): https://gitlab.com/kei-space/clang/r536225/ Diese Toolchain erwies sich als ernsthaft problematisch, also entschied ich mich für Neutron Clang 19. (Wir werden darauf zurückkommen).
Wir haben also unseren Quellcode und unsere Toolchain zum Klonen bereit, was uns zu Folgendem bringt:
Ich habe beschlossen, für dieses Tutorial einen neuen Benutzer anzulegen, hauptsächlich damit ich gh auth login verwenden und Commits ausführen kann, ohne sie versehentlich auf meinem Haupt-GitHub-Konto zu machen. Aber dazu musste ich (in einem Browser) ein Konto erstellen, einen neuen Benutzer einrichten und SSH-Schlüssel für ihn generieren…
Kopiere .ssh/id_ed25519.pub in GitHub und führe dann gh wieder im Terminal aus.
Und dann bin ich bereit.
…fast. Ich muss das Repo noch in meinem Browser forken,
und es dann im Terminal initialisieren/klonen.
Sobald also alles bereit ist (Quellen aktuell, Origin gesetzt usw.), können wir mit dem Klonen der Submodule beginnen.
Die Syntax ist git submodule add URL directory/
Denke daran: Für eine sehr saubere Commit-Historie sollten wir nach jeder Änderung git add . und git commit -a ausführen.
Ich werde git push noch nicht ausführen, aber wenn ich es schließlich tue, aktualisiert das alle Commits.
Hier erwartest du wahrscheinlich, dass der Leitfaden darüber spricht, wie der Kernel-Quellcode geändert wird, um Nethunter-Unterstützung hinzuzufügen. Das kommt – bald. ZUERST wollen wir jedoch sehen, wie der unveränderte Quellcode mit unserer Toolchain und Konfiguration kompiliert.
Diese Konfiguration des aktuell laufenden Kernels muss in das Kernel-Quellverzeichnis kopiert werden, aber da wir out/ für unsere kompilierten Binärdateien verwenden werden, muss ich sie auch dorthin kopieren. Außerdem muss ich meine PATH-Variable um das bin/-Verzeichnis der Toolchain ergänzen. Ich könnte export PATH=/home/build_user/android_kernel_xiaomi_surya/toolchain/bin:$PATH schreiben, aber einfacher ist es, einfach per cd in dieses Verzeichnis zu wechseln und dann export PATH=$(pwd):$PATH auszuführen. $() wird durch das Ergebnis eines enthaltenen Befehls ersetzt, und pwd gibt den vollständigen Pfad zum aktuellen Arbeitsverzeichnis aus.
Ich habe außerdem den Inhalt des bin/-Verzeichnisses der Toolchain aufgelistet, damit du siehst, wie LLVM-Binutils ihr eigenes Präfix haben. Idealerweise enthält das Makefile eine Anweisung, die bei LLVM=1 automatisch AR=llvm-ar, AS=llvm-as usw. setzt. Schauen wir uns also an, was im Makefile steht.
Ausgezeichnet! Ich kann einfach LLVM=1 setzen und muss den Rest nicht einzeln setzen … größtenteils. Ich brauche auch den LLVM-Assembler, aber der hat seine eigene Deklaration, LLVM_IAS:
Jetzt muss ich also nur noch ARCH=arm64 LLVM=1 LLVM_IAS=1 AS=llvm-as O=out CROSS_COMPILE=aarch64-linux-gnu- CROSS_COMPILE_32=arm-linux-gnueabi- setzen. Das mag nach viel klingen, ist aber weitaus weniger, als jedes einzelne Binutil zu setzen.
Also führen wir unseren Befehl aus, um die Konfiguration zu öffnen …. Moment. Sieht so aus, als hätte diese Toolchain einige Probleme. Also habe ich beschlossen, das Submodul zu deinitialisieren und stattdessen Neutron Clang 19.0.0 von hier zu holen; das werde ich mit wget herunterladen.
Dann extrahiere ich es in ein neu erstelltes Verzeichnis toolchain/ (wobei ich zunächst die Syntax zum Extrahieren von .tar.zst-Dateien vergessen hatte).
Und dann füge ich dieses Verzeichnis zur .gitignore-Datei hinzu.
Wenn ich nun das hier ausführe:
Es funktioniert und öffnet das nconfig-Menü:
Viele Anleitungen raten dir, menuconfig zu verwenden, aber ich bevorzuge nconfig, weil 1) es besser aussieht und 2) es nicht dieselbe Neigung hat wie menuconfig, nicht zu laden, weil es die bereits installierten ncurses-Bibliotheken nicht finden kann. Wie dem auch sei, das ist nur ein Testkernel, also können wir .config laden und speichern (erneut als .config), und fürs Erste sind wir fertig.
Und nun versuchen wir, Image.gz zu bauen, und …
Unser erster Fehler! Hurra!
Laut diesem hat ein Arch-Update etwas kaputt gemacht.
Wie Arch nimmt, so gibt Arch auch – in diesem Fall in Form des AUR-Pakets libxml-legacy. Also habe ich das installiert, make erneut ausgeführt, und diesmal:
Respekt an die LineageOS-Maintainer, denn der gesamte Kernel wurde mit nur einer Warnung gebaut:
Jetzt können wir in out/arch/arm64/boot/ die Image.gz finden. Aber wie flashen wir das auf unser Gerät?
Wir müssen ein AnyKernel3-Zip erstellen.
Es gibt zwei Möglichkeiten, das zu tun:
Image sein, das von uns erstellte Image.gz und sonst nichts, Image.gz-dtb (ein kombiniertes Device-Tree-/Kernel-Image – diese sind heutzutage weniger verbreitet, aber wenn dein Gerät eines erwartet, musst du in deiner Kernel-Konfiguration „Build a concatenated Image.gz-dtb“ aktivieren), oder Image.gz, dtbo.img und/oder dtb.img.
Für diesen Leitfaden habe ich einen der vielen Kernel heruntergeladen, die auf Telegram mit einem bescheuerten Anime-Namen und ohne verlinkte Quelle verbreitet werden. Installiere niemals einen dieser Kernel.
Aber das machen wir nicht, keine Sorge, wir borgen uns nur deren AnyKernel-Zip-Konfiguration. Also benenne ich die Datei um und entpacke sie
Und ich habe das Skript anykernel.sh bearbeitet, um auch den Kernel-Namensstring zu ändern. Jetzt überschreiben wir das Image.gz aus diesem Zip mit unserem neuen
Mit zip -f (für „freshen“) wird einfach die Datei darin durch die neue Version ersetzt. 0 steht für keine Kompression.
Mal sehen, ob ich diesen Kernel flashen kann und ob er bootet, aber zuerst:
Es ist viel einfacher, Kernel-Zips im Blick zu behalten, wenn man Datums- und Zeitangaben einfügt.
Da ich jedoch gründlich sein möchte (und so wenig wie möglich von Telegram-Kerneln abhängen will), erkläre ich dir, wie du deine eigenen dtb.img- und/oder dtbo.img-Dateien erstellst, denn die Dokumentation dazu ist schmerzhaft unzureichend.
Es gibt zwei AOSP-Programme, die für diesen Zweck existieren. Eines davon, mkdtboimg, ist in Python geschrieben, sodass man einfach mkdtboimg.py herunterladen und ausführen kann, direkt von der offiziellen AOSP-Website. Möglicherweise benötigst du aber auch das andere, mkdtimg, das in C geschrieben ist und ohne Makefile ausgeliefert wird. Laut der Dokumentation reichen die Android.bp-Dateien aus – du musst nur den gesamten AOSP-Code auschecken, um die dort aufgeführten Befehle ausführen zu können. Ich halte das für völlig verrückt, also habe ich das Makefile genommen, das jemand anderes vor langer Zeit erstellt hatte, um dieses Tool eigenständig zu bauen, die Quelldateien auf die neueste Version aktualisiert und es dann als static-PIE gegen Musl gebaut. Du kannst dieses Binärprogramm (das auf jedem x86_64-Linux-Rechner läuft, wie dem, mit dem du den Kernel baust) hier herunterladen oder es selbst aus dem Quellcode bauen.
Jetzt kommt der knifflige Teil: Die .dtbo-Dateien, die während eines Kernel-Builds erzeugt werden, lassen sich nicht ohne ein wenig Zusatzaufwand in dtb.img/dtbo.img-Dateien umwandeln. Android benötigt den Aufruf von dtc mit dem Flag -a 64. Da wir bereits DTC_EXT=/usr/bin/dtc aufrufen, um das Makefile zu zwingen, unser schönes, aktualisiertes DTC aus dem Paketmanager zu verwenden und nicht das kaputte, das sich in vielen Kerneln findet, ist es nicht schwer, diesen Befehl einfach in einfache Anführungszeichen zu setzen und das Flag hinzuzufügen. Du kannst einfach DTC_EXT='/usr/bin/dtc -a 64' übergeben. In meinem Fall erstelle (und teste) ich jedoch gern build.sh-Skripte für alle Kernel, die ich pflege, sodass jeder – egal wie sehr n00b – seinen eigenen Kernel aus dem Quellcode bauen kann, ohne diesen Leitfaden lesen zu müssen. Während ich mit Schichten über Schichten aus Bash-Logik mit einfachen und doppelten Anführungszeichen kämpfte, fand ich eine einfache, wenn auch nicht elegante Lösung, die sicherstellt, dass DTC mit dem richtigen Flag aufgerufen wird: ein Wrapper-Skript.
Ich habe einfach eine ausführbare Datei namens dtc im obersten Verzeichnis meines Kernels erstellt, die die folgenden Zeilen enthielt:
#!/bin/sh
exec /usr/bin/dtc -a 64 $@
Dann habe ich DTC_EXT= auf diese Datei zeigen lassen, und das hat die Sache erledigt.
Du fragst dich vielleicht: „Was für .dtbo-Dateien? Meine Kernel-Builds erzeugen so etwas nie!“ In dem Fall solltest du prüfen, ob dieses Kernel-Symbol aktiviert ist:
Wie nutzen wir diese Tools also? Als Erstes habe ich die dtb.img- und dtbo.img-Dateien analysiert, die ich in anderen Kernel-Zips gefunden habe, um zu sehen, um welche Art von Dateien es sich handelt. (Ich weiß, ich weiß, wir wollen für unsere eigenen Kernel nicht von den seltsamen Custom-ROM-Szene-Kerneln abhängen, aber das ist eine Überprüfung wert). Der Befehl file dtb.img lieferte:
dtb.img: Device Tree Blob version 17, size=345849, boot CPU=0, string block size=31481, DT structure block size=314312
was (fast) genau dasselbe Ergebnis ist, das ich erhalte, wenn ich file ../arch/arm64/boot/dts/qcom/sdmmagpie.dtb ausführe:
../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
Dieser geringfügige Unterschied hat mich beunruhigt, bis ich diff <(strings dtb.img) <(strings ../arch/arm64/boot/dts/qcom/sdmmagpie.dtb) ausführte und feststellte, dass sie exakt dieselben Inhalte hatten. Ich konnte also getrost davon ausgehen, dass das Erstellen meiner eigenen dtb.img nur eine Frage des Kopierens von sdmmagpie.dtb und des Umbenennens ist.
Was dtbo.img betrifft, bekommen wir von file nicht viel Hilfe:
dtbo.img: data
Aber hier können wir entweder mkdtimg oder mkdtboimg.py verwenden, um sie zu analysieren. Wenn ich mkdtimg dump dtbo.img ausführe, erhalte ich:
Ich weiß also, dass ich beim Erstellen meiner eigenen Datei entweder
mkdtimg create dtbo.img --page_size=4096 ../arch/arm64/boot/dts/qcom/sdmmagpie-idp-overlay.dtbo
oder
mkdtboimg create --page_size=4096 dtbo.img ../arch/arm64/boot/dts/qcom/sdmmagpie-idp-overlay.dtbo
übergeben sollte. Beide Befehle erzeugen identische Dateien. Du kannst danach auch mkdtimg dump dtbo.img ausführen und die Werte mit der anderen Datei vergleichen. Wenn du mehr als eine .dtbo-Datei in dein Image aufnehmen musst, hängst du einfach ihren Pfad ans Ende eines der beiden Befehle an.
Zurück zu dem Testkernel, den wir erstellt haben. Die gute Nachricht ist, dass er ohne Probleme geflasht werden konnte, die schlechte Nachricht ist, dass ich dieses Makefile reparieren muss, das ein so hässliches /proc/version erzeugt.
Aber das kann warten. Jetzt sind wir endlich angelangt bei:
Zeit, einige Submodule hinzuzufügen. Zuerst dieses hier, das mit sehr leicht verständlichen Anweisungen daherkommt. (Anmerkung: Es enthält inzwischen auch die Kernel-Symbole des CAN-Subsystems, da mein Pull Request, der sie hinzugefügt hat, gemergt wurde, auch wenn du das in den folgenden Screenshots nicht sehen wirst).
Und wenn ich jetzt erneut make nconfig ausführe (derselbe Befehl wie zuvor)
Wir haben diese schöne neue Option
Das aktiviert all diese Dinge. Wähle das aus, speichere als .config – aber Vorsicht: Das speichert es in out/.config und wir werden dieses gesamte Verzeichnis löschen, bevor wir erneut bauen. Sobald du nconfig also beendet hast, kopiere diese Datei in das Kernel-Quellverzeichnis.
Jetzt ist es an der Zeit, einige Quelldateien zu patchen, also fügen wir das Repository der Nethunter-Build-Skripte als Submodul hinzu:
Wir wechseln mit cd in das neue Verzeichnis, führen ./build.sh aus und wählen Option 4: Apply Nethunter kernel patches.
Falls du Meldungen wie „the test run was completed with errors“ erhältst, wende den Patch NICHT an. Ansonsten leg los. In meinem Fall habe ich die Patches 4, 5 und 8 angewendet.
Nachdem wir Änderungen vorgenommen haben, gehen wir zurück in das oberste Kernel-Quellverzeichnis und committen sie.
An diesem Punkt könntest du den Kernel einfach erneut bauen und wärst fertig. Aber ich bin eben extra, und ich möchte Unterstützung für eine Menge zusätzlicher Dinge einbauen, nämlich:
Wir müssen die Kconfig und das Makefile in drivers/net/wireless/realtek anpassen, damit diese neu hinzugefügten Treiber in der Konfiguration auftauchen, aber auch:
Stell sicher, dass du die Plattform im rtl8812au/Makefile auf ANDROID_ARM64 umstellst (ebenso für rtl8188eus).
Es lohnt sich auch, die Kconfig in den neu hinzugefügten Treibern zu prüfen, um zu sehen, wie die Konfigurationsoption heißt:
Jetzt weiß ich, dass ich im Makefile eine Ebene darüber darauf als 88XXAU verweisen muss.
Glücklicherweise wird die Kconfig einfach so eingebunden:
Ich werde diese Dateien erneut bearbeiten müssen, nachdem ich auch rtl88x2bu und den ARM-Zweig von rtl8188fu hinzugefügt habe. (Und wie sich herausstellt, heißt die Konfigurationsoption von rtl88x2bu RTL8822BU, weshalb es sich immer lohnt, nachzusehen).
Jetzt zu den zurückportierten MediaTek-Treibern. Mit diesem Commit als Orientierung habe ich diese Treiber erfolgreich auf zwei verschiedene Geräte mit 4.14.x-Kerneln portiert. (Siehst du, warum die Commit-Historie wichtig ist?) Aber zuerst brauchen wir das mt76-Verzeichnis mit all seinen Dateien.
Anstatt ein 4.19-Kernel-Repository zu klonen und die Dateien daraus zu kopieren und dann die notwendigen Patches in deiner neuen Kopie anzuwenden, kannst du einfach https://github.com/akabul0us/mt76.git als Submodul hinzufügen. Bearbeite dann das Makefile und die Kconfig im Verzeichnis drivers/net/wireless/mediatek:
Indem wir dieses Repository hinzufügen, dessen Quellcode die Patches aus dem zuvor erwähnten Commit bereits enthält, können wir direkt zu den Änderungen springen, die wir an anderen Kernel-Dateien vornehmen müssen. Die erste ist diese:
Aber es stellt sich heraus, dass unser Kernel-Quellcode diese Struktur bereits enthält:
Also gehen wir zur nächsten zu ändernden Datei über, include/linux/overflow.h. Diese weist zwar einige Änderungen auf, aber da sie im ursprünglichen Commit gut zu lesen sind, erspare ich dir weitere Screenshots. include/linux/skbuff.h und include/linux/scatterplot.h haben ebenfalls Änderungen, aber keine davon ist für include/net/cfg80211.h nötig. Die nötigen Änderungen an include/net/mac80211.h sind gering – lediglich RX_ENC_HE als letzte Zeile innerhalb von enum mac80211_rx_encoding { } einzufügen und u8 vht_flag; zu struct ieee80211_rx_status { } hinzuzufügen. Die Datei net/wireless/of.c existiert bereits und ist identisch mit der aus dem Commit, den wir gerade cherry-picken, also sind wir damit fertig. (Puh!)
Was den Docker-Support betrifft, nun, dank (schon wieder) cyberknight777 für dieses können wir einfach kopieren und einfügen:
Und jetzt sind wir bereit, wieder nconfig auszuführen! …fast. Zuerst Änderungen committen und pushen, dann rm -rf out/ (stell sicher, dass du deine .config außerhalb davon gespeichert hast), mkdir -p out, und DANN können wir zurück in die Konfiguration.
Eine Anmerkung zu den Out-of-Tree-Realtek-USB-Treibern, die wir in den Kernel aufgenommen haben: Sie sind irgendwie mies. Wenn du versuchst, mehr als einen von ihnen inline zu bauen, erhältst du Fehler beim Linken. Eine seit Langem bewährte Lösung ist, nur einen (1) inline zu bauen und den Rest als Module. Die MediaTek-Treiber können dagegen problemlos inline gebaut werden.
Am Ende habe ich noch eine ganze Menge anderer Dinge aktiviert. Wenn du den vollständigen Diff sehen möchtest, findest du ihn hier: hier. Aber egal, lasst uns bauen!
Guter Start – es ist immer schön, wenn man kurz neue Objektdateien sieht, die man gerade hinzugefügt hat und die ohne Fehler oder Warnungen kompiliert werden.
Das? Weniger schön, aber leicht zu beheben. Wir müssen nur -Wno-stringop-overread aus dem Makefile entfernen, das dieses Flag als Warnungsflag gesetzt hat. Und wenn wir schon dabei sind: -Werror ist doch etwas hart, oder? (Dieses Flag bedeutet „alle Warnungen als Fehler behandeln“ und stoppt die Kompilierung bei jedem noch so kleinen Haken, einschließlich eines unbekannten -W-Flags).
Zumindest dieses hier ist leicht zu beheben.
Ein schnelles # vor diese Zeile, und schon können wir make erneut ausführen – und diesmal hat es den ganzen Weg durchgeschafft!
Aber da ich einige Treiber als Module konfiguriert habe, sind wir noch nicht ganz fertig. Wir müssen make modules ausführen, genauer gesagt: 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. Und Junge, ist der Realtek-Treibercode für rtl8188fu ein einziges Chaos:
Könnte ich jede einzelne Zeile, die diese Warnungen verursacht, manuell korrigieren? Sicher. Werde ich es tun? Nein. Es gibt einen Grund, warum ich diese Treiber als Module und nicht inline kompiliere und alle aktiv dazu ermutige, auf Realtek-basierte Adapter zu verzichten. Jedoch:
Sie wurden zumindest erfolgreich kompiliert. Zu denen kommen wir gleich zurück. Zuerst frischen wir unser Kernel-Zip auf:
(Fast vergessen – das ist kein „Test“-Kernel mehr, sondern ein richtiger Nethunter-Kernel).
Was die Module betrifft, sind .tar-Dateien wirklich der richtige Weg, weil sie alles an den enthaltenen Dateien bewahren – allerdings bewahren sie auch Pfade. Wenn wir nichts dagegen tun, erzeugen wir beim Extrahieren unseres Module-Tarballs einen Haufen Verzeichnisse, wie zum Beispiel drivers/net/wireless/realtek/rtl8188fu/rtl8188fu.ko. Erstellen wir also ein Verzeichnis (und fügen es der .gitignore hinzu), kopieren die Dateien hinein und erstellen dann das Archiv.
Kannst du diese wie einen Kernel flashen?
Sie müssen irgendwo auf deinem Gerät extrahiert werden. Ich sage „irgendwo“, weil es nicht wirklich darauf ankommt, wo, solange das Modul beim Ausführen von insmod /whatever/path/to/whatever.ko lädt. Du könntest es in /sdcard tun, das wäre in Ordnung, aber denk daran: Ich bin eben extra, also werde ich sie an der „richtigen“ Stelle für dieses Gerät extrahieren, unter /vendor/lib/modules. Natürlich ist /vendor schreibgeschützt gemountet, also muss ich zuerst eine Root-Shell starten (NICHT im Nethunter-Terminal – das ist ein Chroot – du kannst aber die Nethunter-Terminal-App verwenden, wenn du „New Session → Root Shell“ auswählst) und mount -o rw,remount /vendor ausführen, bevor ich irgendetwas an dieser Partition ändern kann. Dann cd /vendor/lib/modules; tar xzvf /sdcard/or/wherever/you/saved/the/tarball.tgz; mount -o ro,remount /vendor, und schon bist du mit den Modulen fertig.
Falls du eine Fehlermeldung über fehlenden Speicherplatz auf dieser Partition erhältst, kannst du auch einfach einen symbolischen Link verwenden – lege die Datei zum Beispiel in /sdcard/modules ab und erstelle dann einen Link mit dem absoluten Pfad. Wenn wir das mit 88x2bu.ko machten, würden wir ln -s /storage/emulated/0/modules/88x2bu.ko /vendor/lib/modules/88x2bu.ko ausführen.
Gib deinem Repository noch einen letzten Push und speichere, wenn du möchtest, die verwendete .config als neue Defconfig für Nethunter. (Das hilft Leuten, die aus dem Quellcode bauen, wirklich enorm).
Funktioniert es? Es lässt sich zwar problemlos flashen, aber funktioniert es wirklich?
Nun, es ist ziemlich spät hier, also werde ich nicht jetzt jede einzelne Funktion testen, aber nehmen wir die entscheidende: Monitor Mode/Paket-Injection auf den Treibern, die ich in den Kernel eingebaut habe. Beginnen wir mit rtl88x2bu:
Gar nicht so übel, für einen Realtek-Treiber.
Und jetzt zum Hauptevent: mt76x2u:
Das nenne ich ein Pentesting-Gerät!
Der letzte Schritt ist, deine .zip und .tar.gz als Release auf github hochzuladen. Dann veröffentliche es auf xdaforums, Telegram, Twitter oder wo auch immer du denkst, dass andere Nutzer desselben Geräts/ROMs es finden und davon profitieren können.
Und wenn irgendein undankbarer Idiot mit einem ungewaschenen Arsch auf deinen Beitrag antwortet mit „JETZT DU MACHEN KARNEL FÜR GERÄT BUTTPHONE 34AC PRO EDITION?!!?“, gib ihm den Link zu diesem Leitfaden und sag ihm, er soll git gud lernen.
Gute Nacht, allerseits.
--Akabul0us