akabulous/so_you_want_to_build_a_nethunter_kernelAndroid向けカスタムKali NetHunterカーネルを構築するためのステップバイステップガイド：ソースの取得、ツールチェーンの選択、クロスコンパイル、フラッシュ。
Nethunter デバイスをセットアップしたいほとんどの人にとって最大のハードルは、カーネルの要件です。お使いのデバイスにプリビルド（およびメンテナンス済み）のカーネルが既にあるのでない限り、自分でビルドするように言われるでしょう。このプロセスに関するドキュメントはすでにたくさんありますが、私の経験では、自分のケースに何が当てはまり、何が当てはまらないのかを判断するのは難しいことがあります。
この問題をさらに厄介にしているのは、「Build a Nethunter kernel for ANY Android device!」のようなクリックベイト的なタイトルや、「Learn how to compile a Nethunter kernel in ten minutes!」のような誤った約束をするガイドを書くバカ人たちです。また、2025年のインターネットの残念な現実として、多くの頭の悪い人々が、ChatGPTや他の大規模言語モデルが自分の質問に対して権威ある答えを持っていると思い込んでいますが、それらのモデルが実際に持っているのは、前述のバカたちからスクレイピングした情報にすぎません。
私はこのガイドを、可能な限り徹底的かつ正直に書いています。ただし、これはこのプロセスで読む必要がある唯一のドキュメントであることを意図していません。このドキュメントが答えられない疑問も必ず出てくるでしょう。そうした疑問に対する答えは、該当するソフトウェアのドキュメントで探すことをお勧めします。YouTubeやChatGPTで探すのはやめてください。
このプロセスのいずれかを始める前に、既に以下のことを済ませておく必要があります：
apt update && apt upgrade -y (任意：メタパッケージを追加している)このプロセスを完了するために必要なもの：
cd, rm, ls, mkdir, find, diff, grep, など）vim、それ以外はnano）build-devel、Debian系ではbuild-essential） – また、一部のカーネルMakefileがこれらを必要とするため、Perl + Python3をインストールすることもお勧めします私のデバイスでも可能でしょうか？
Linuxカーネルは、コピーレフトライセンスであるGNU General Public License 2.0の下でライセンスされています。これは、Linuxカーネルのソースコードが自由に配布され、あなたが望むようにソースコードを変更できることを意味します（各Androidメーカーが行っているように）。しかし、その結果得られたソースコードもまた、自由に配布されなければなりません。
誰も驚かないことに、GPLライセンスのコードを使用している巨大企業の多くは、このライセンスの条件を無視しています。彼らはソースコードの配布を拒否するか、一部だけを公開します（通常は壊れていたり、古かったり、インラインのバイナリブロブが含まれています）。お使いのデバイスのカーネル用のソースコードが利用できない場合、そのデバイス用のNethunterカーネルを作成する方法はありません。
ブートローダーのロックを解除してカスタムROMをインストールできるかどうかも、デバイスメーカーの気まぐれに大きく依存します。たとえブートローダーのロック解除を許可し、Magiskでスマートフォンをroot化できたとしても、デバイスツリーを公開していなければ、お使いのデバイス向けのカスタムROMはおそらく存在しません。この場合、彼らが公開したカーネルソースコード（もしあれば）がリリース以降メンテナンスされている可能性は極めて低く、変更なしでもビルドできるかどうかも疑わしいです。お使いのデバイス向けに他の誰も（カーネル、ROM、リカバリを）メンテナンスしていないのなら、そのデバイスを完全なNethunterにするのは、不可能でないにしても困難でしょう。
カーネルバージョンに関する注意
お使いのデバイス向けに定期的に更新・メンテナンスされたカスタムROM/カーネル/リカバリが存在するが、Nethunterカーネルだけは存在しないと想像してみましょう。この場合、このプロセスを完了できるはずですが、そのプロセスはお使いのデバイスが使用するLinuxカーネルのバージョンによって異なります。
このガイドの情報は、4.14.xカーネルを変更した私の経験に基づいています。3.xカーネルに適用される、（これから使用するLLVM/clangではなく）GCCツールチェーンを使用することについて書かれた古いガイドもあります。お使いのデバイスが5.x/6.xバージョンのLinuxカーネルを使用している場合、このガイドの情報だけではこのプロセスを完了するのに不十分です。 Androidのビルド方法は常に変化しているため、GKIカーネルとBazel/Kleafの使用を扱ったガイドを探すべきです。
お使いのデバイスのカーネルソースを含むリポジトリを見つける良い方法は、コードネームを使用することです。すべてのAndroidデバイスにはコードネームがありますが、一部のメーカー（例：OnePlus）は他社（例：Samsung）よりも少し遊び心があります。私のXiaomi Poco X3 NFCのコードネームは「surya」で、私のSamsung A51のコードネームは「SM-A515F」です。通常、カーネルソースのリポジトリは次の命名規則に従います。
android_kernel_MANUFACTURER_CODENAME
ここで、manufacturerは親会社です。つまり、android_kernel_poco_suryaではなくandroid_kernel_xiaomi_suryaです。
ただし、お使いのデバイスのSoC（システム・オン・チップ）に基づくリポジトリもあるかもしれません。同じSoCを持つ他のデバイスのソースファイルを含めるために「統合」されていることもあります。先ほど言及したSamsungがそのケースで、そのソースリポジトリはandroid_kernel_samsung_exynos9611と呼ばれています。github/gitlabを探して、何が見つかるか見てみてください。
このガイドでは、suryaで最新のLineageOS 22.2（2025-08-04ビルド）を使用します。したがって、LineageOSリポジトリからカーネルソースをクローンしたいと思います。ただし、その前に、デバイスからカーネルビルドに使用するコンピュータへ2つのファイル（/proc/config.gzと/proc/version）をコピーしたいと思います。
最初のファイル/proc/config.gzを/sdcardにコピーし、ADBでデバイスからpullし、gunzipして、名前を変更するという方法もあります。しかし、それは多くの手順のように思えるので、代わりに私が行ったのはこれです：
次に、デバイス自体で（rootとして）実行しました
ここで何が起こっているのでしょうか？
ラップトップ側：nc（netcat）-l（受信接続を待ち受ける）-p（ポート）4545（実際には1024〜65535の任意の番号で構いませんが、私はたいてい4545を使います）>（ファイルに書き込む）surya-defconfig-lineageos22.2-20250804（説明的なファイル名）<（ファイルからの入力）/dev/null（ヌルデバイス – これにより、キーボードに触れても、受信しているファイルにキーストロークが送り込まれて壊れるのを防げます）。
スマートフォン側：zcat（連結のためのcatコマンドに似ていますが、gzip圧縮ファイル用）/proc/config.gz（現在実行中のカーネルがビルドされたときのカーネル構成）|（そのプロセスの出力を次のプロセスへの入力として送る）nc（再びnetcat）192.168.1.42（私のラップトップのローカルIPアドレス）4545（先ほど設定したポート）
これにより、現在実行中のカーネルのビルドに使用された.configファイルが得られるはずですが、常にそうとは限りません。一部の新しいデバイス/新しいROMビルドでは、/proc/config.gzに保存されている構成が、ストックカーネルのビルドに使用された.configと一致しない場合、起動を拒否します。幸いなことに、チェックされるのはそれだけです（カーネル全体のSHA256チェックサムのような、もっと破りにくいものではありません）。そのため、賢い人々は、変更を加えているにもかかわらず、/proc/config.gzのファイルをストックカーネルに一致するように偽装する方法を考案しました。デバイスのファイルが本物か偽装かを確認するには、zcat /proc/config.gz | headを実行し、次にuname -rを実行します。リリース番号が一致しない場合は、/proc内のファイルは偽装されています。その場合でもこのガイドを進めることはできますが、抽出したconfigをカーネルソースのarch/arm64/configsディレクトリにあるいくつかのファイルと比較するためにdiffを実行するとよいかもしれません。
/proc/versionについては、そのファイルを送信する必要はあまりありません。実際に必要なのは、コンパイルに使用されたclang/ld.lldのバージョン情報だけだからです。したがって、単にcat /proc/versionを実行して確認するだけで十分です：
おやおや！このカーネルをビルドした人はちょっと「おっと」という感じで、Makefileにclangで実行したすべての-CFLAGSを記録したものの、Clangのバージョンを記録していないようです。ただし、プリビルドのAndroidツールチェーンを使用し、ld.lldバージョン19.0.1を使用したことはわかります。
もう少し役立つ画像を紹介します。最初の出力は、Samsung A51で新しいカーネルを変更・ビルド・インストールする前の/proc/versionからのものです。2番目の出力は現在の/proc/versionからのものです。
何か気づきましたか？（いいえ、私の奇妙なユーザー名とホスト名のことではありません）
使用するツールチェーンを選ぶ最良のコツは、現在実行中のカーネルをコンパイルしたまったく同じツールチェーンを使うことです。
この場合、それはNeutron clang 18.0.0gitでした。見つけるのは非常に簡単でした：
そして見てください、md5sumが一致しています。完璧です。
楽しみのために、かなり古いデバイスであるSamsung J7（2016年）、コードネームj7xelteの/proc/version文字列を少し見てみましょう：
これは、カーネルのコンパイルにまだGCCツールチェーンを使用していた十分に古いデバイスです。
しかし「gcc version 4.9.x 20150123 prerelease」を検索すると、2つのリポジトリが見つかります：
では、どちらをダウンロードすべきでしょうか？
答え：両方です。GCCはClangと異なり、クロスコンパイル用のコンパイラ/binutils/リンカなどをビルドする際、「ターゲットトリプル」ごとに個別のツールチェーンをビルドする必要があります。ターゲットトリプルは（おそらく）次の形式を取ります。
machine-vendor-operating_system
しかし、これから見るように、この「ルール」には無数の例外があります。まずは「machine」から始めましょう。
このドキュメントの「必要なもの」セクションで、GNU/Linuxを実行しているIntelまたはAMDプロセッサを使用する64ビットコンピュータが必要だと言いました。それは、これから使用するツールチェーンがx86_64-linux-gnu上で実行されるようにコンパイルされているからです。
ただし、これらのツールチェーンはクロスコンパイラです。つまり、Cソースコードファイルから生成されたマシンコードはそのコンピュータでは実行されず、独自のターゲットトリプルを持つ別のコンピュータ上で実行されます。