我正在嘗試反彙編一個由多個部分組成的複合文件，其中之一是夾在幾個其他文件之間的未壓縮內核。我試圖找到內核部分的確切長度，但這被證明是困難的。
vmlinux 標頭中是否有指示引導程式在執行之前應讀取多少數據，或者是否假設 vmlinux 檔案的所有內容都會在引導程式切換時載入？
答案1
簡單的答案是“不”，但如果這是一個 ELF 圖像，那麼通過一些黑客攻擊，你可能會找到內核。請參閱readelf下面的黑客。
引導程式負責了解核心和根檔案系統所在的任何檔案的格式。這包括了解核心檔案的大小，無論其格式如何。在 PowePC 和 Blackfin 上，引導程式負責解壓縮整個核心（如果壓縮），並將其寫入 RAM 中的最終位置。在 ARM 上，核心可以自解壓縮，引導程式只需將原始核心檔案複製到 RAM 中方便的位置並開始執行。
如果核心是自解壓縮的，那麼指示壓縮核心檔案大小的符號可能會也可能不會出現在檔案開頭的解壓縮程式碼中，具體取決於所使用的解壓縮演算法，但您無法知道在沒有特定核心建立的鏈接器映射的情況下在哪裡。當然引導程式無法知道。
未壓縮的核心程式碼本身由兩個符號括起來，_stext其_end位址是核心本身的開頭和結尾，但不包括任何包含的 initramfs 的範圍（如果 initramfs 已連結到核心二進位檔案）。 initramfs 的範圍由連結器在兩個核心符號__initramfs_start和中設定__initramfs_end。引導程式通常沒有能力讀取核心符號表（它在檔案中System.map），如果沒有這種能力，它們將無法知道_end和__initrams_end符號在核心檔案中的位置。也就是說，符號的位置不是距離二進位檔案開頭的固定偏移量。它是在連結時確定的，並且可能根據核心建置配置而變化。
177 E L F對於 ELF 格式的未壓縮內核，您可以透過尋找 ELF 標頭（在od -c複合檔案的轉儲中）來識別 vmlinux 檔案的開頭。然後，您可以從此時開始對檔案的其餘部分執行readelf -e「或」操作objdump -h，以尋找具有最高檔案偏移量 ( ) 的部分.shstrtab。將部分大小新增至此偏移量中，這會將您帶到 vmlinux 的末端。我使用未剝離的 PPC vmlinux 測試了此方法，並獲得了與獨立 vnlinux 檔案大小完全匹配的大小。剝離內核後，此方法給出的結果比剝離的圖像大小少了 1283 位元組。
嵌入式系統通常使用一種檔案格式來mkimage打包核心、rootfs、裝置樹和其他元件。例如，U-boot 可以識別 mkimage，因此它知道核心二進位檔案在 mkimage 檔案內的開始和結束位置，並且知道核心是否被壓縮以及將核心檔案寫入哪個 RAM 位址。