複数の部分で構成された複合ファイルを逆アセンブルしようとしています。そのうちの1つは、異なるファイル間に挟まれた非圧縮カーネルです。カーネルセクションの正確な長さを見つけようとしましたが、これは難しかったです。
vmlinuxヘッダーに、ブートローダが実行される前に読み取る必要があるデータ量が表示されていますか？それとも、ブートローダが切り替えられたときにvmlinuxファイルの内容全体がロードされると思いますか？
ベストアンサー1
短い答えは「いいえ」です。しかし、これがELFイメージであれば、ハッキングを通じてカーネルを見つけることができます。readelf以下のハッキングを参照してください。
ブートローダは、カーネルの形式とルートファイルシステムを含むすべてのファイルを理解する役割を果たします。これには、フォーマットに関係なくカーネルファイルのサイズを知ることが含まれます。 PowePCとBlackfinでは、ブートローダはカーネル全体（圧縮されている場合）を解凍し、RAMの最終位置に書き込むのに役立ちます。 ARMでは、カーネルは自動的に抽出され、ブートローダは元のカーネルファイルをRAMの便利な場所にコピーして実行を開始します。
カーネルが自動解凍の場合、圧縮されたカーネルファイルのサイズを示す記号は、使用された解凍アルゴリズムによってファイルの先頭の解凍コードに表示される場合と表示されない場合があります。リンクは特定のカーネルなしで構築されます。サーバーマッピングの場合はどこにありますか？もちろん、ブートローダにはわかりません。
圧縮されていないカーネルコード自体は、アドレスがカーネル自体の始まりと終わりの2つのシンボルで囲まれていますが、_stextinitramfs_endを含む範囲は除外されます（initramfsがカーネルバイナリに接続されている場合）。 initramfsの範囲は、リンカーによって2つのカーネル記号__initramfs_startと__initramfs_end。ブートローダには通常、カーネルシンボルテーブル（ファイル内）を読み取る機能がなく、この機能がないとカーネルファイル内とシンボルがどこにあるかはわかりませSystem.mapん。つまり、シンボルの位置はバイナリの先頭の固定オフセットではありません。これはリンク時に決定され、カーネルビルドの構成によって異なります。_end__initrams_end
177 E L Fod -cELF形式の圧縮されていないカーネルの場合は、ELFヘッダー（複合ファイルのダンプから）を見つけて、vmlinuxファイルの先頭を識別できます。その後、この時点からファイルの残りの部分をreadelf -eORして、objdump -h最も高いファイルオフセット（）を持つセクションを見つけることができます.shstrtab。このオフセットに部分サイズを追加すると、vmlinux が終了します。ストリップされていないPPC vmlinuxを使用してこの方法をテストしたところ、スタンドアロンvnlinuxファイルサイズと正確に一致するサイズが得られました。カーネルを削除した後、この方法は削除された画像サイズより1283バイト小さい結果を提供します。
組み込みシステムは通常、ファイル形式を使用してmkimageカーネル、rootfs、デバイスツリー、その他のコンポーネントをパッケージ化します。たとえば、U-boot は mkimage を認識するので、mkimage ファイル内のカーネル バイナリの開始と終了位置を知り、カーネルが圧縮されているかどうか、カーネル ファイルが書き込まれる RAM アドレスを知っています。