ByteScope

ELF Inspector

打開 ELF，把每一層結構讀完；檔案不會離開這個分頁。

檔案不會離開你的瀏覽器 — 全部在本機處理。

把 ELF 檔丟進來

或點一下選檔 — 在這個分頁裡解析，不會上傳

這個工具不會做的事

不會上傳任何東西。檔案在這個分頁裡讀，在 Web Worker 裡解析，開檔完全不會發出網路請求。如果這是 CTF 題目或客戶的韌體，這點就是重點。

  • 這裡讀的是 ELF 的中繼資料。它不是反組譯器，也不會反編譯：它可以告訴你 .text 從位移 0x1000 開始、有 41 KiB，但沒辦法告訴你那些指令是什麼。
  • 不解析 DWARF 除錯資訊。.debug_info、.debug_line 這些節區會跟其他節區一樣列出大小，內容只會當成位元組顯示。
  • 壞掉的、或被人故意改壞的 ELF，在這裡是很正常的輸入——CTF 的執行檔常常是手工改過的——所以解析會退化成「部分結果加上警告」，而不是丟給你一張白紙。所有警告都會顯示，不會被吞掉。

關於這個工具

把 ELF 丟進來就好——執行檔、.so、核心模組、.o、CTF 題目、韌體映像檔都可以——你會拿到 readelf -a 會告訴你的東西，而且是兩個互相連動的面板。左邊是結構樹：ELF 標頭一個欄位一列、program headers、節區表、分開放的 .dynsym 與 .symtab、.dynamic、每一個重定位節區、notes，以及版本定義與版本需求。右邊是檔案的位元組。點任何一列，右邊就剛好標出這一列是從哪幾個位元組解出來的；點一個位元組，左邊就會找出蓋住它的最內層結構。

摘要卡先回答大家真正想知道的事，不用先翻表：這是 ELF32 還是 ELF64、什麼架構、什麼位元組序、EXEC / DYN / REL、進入點在哪；如果這個架構的 e_flags 有意義（RISC-V 和 MIPS 都有），也把它解出來。接著是推導出來的事實：靜態還是動態連結、要哪一個載入器、有沒有被 strip、是不是 PIE、.note.gnu.build-id 裡的 Build ID，以及 PT_GNU_STACK 有沒有帶 PF_X。最後這一項跟安全直接有關，所以直接寫成一句話，不要你自己去表裡面翻。

什麼都不會上傳，而對這群人來說，這是前提不是賣點。CTF 的執行檔是別人還沒解出來的題目，韌體通常是客戶的財產；為了看一個節區標頭就把它丟到別人的伺服器，很不划算。檔案由分頁讀進來，交給 Web Worker，在記憶體裡解析——沒有上傳端點，你可以開著 DevTools 自己確認：打開一個檔案完全不會發出網路請求。解析跑在 worker 裡，所以 60 MB 的檔案也不會把分頁卡死；超過 128 MiB 的則會直接說明理由拒收，而不是收下來然後當掉。

這頁印出來的每一個名稱——架構、類型、節區類型、符號的 type / bind / visibility、重定位類型、dynamic tag——都跟 GNU binutils 的 readelf 一字不差，因為這個解析器是拿真正的 readelf 輸出來對答案的，不是拿自己的期待值。1,900 個符號的檔案很常見，40 萬個的也存在，所以符號和重定位的過濾、排序、分頁都在資料所在的那一端做，不會一列一列畫進頁面裡。

常見問題

我的檔案會被上傳嗎？

不會。檔案在這個分頁裡讀取，轉交給 Web Worker，在那裡解析。你在使用時這個頁面不會發出任何網路請求，所以你可以開著 DevTools 的 Network 分頁，看它一直是空的。這件事在這裡比在別的工具更重要：會被丟進 ELF 檢視器的，往往是還沒發布的韌體、客戶的建置產物，或別人還在解的 CTF 題目。

這是反組譯器或反編譯器嗎？

都不是，也不假裝是。它讀的是 ELF 的中繼資料：可以告訴你 .text 是從檔案位移 0x1000 開始、41 KiB 的可執行 PROGBITS，puts 是透過 R_X86_64_JUMP_SLOT 從 libc.so.6 來的，進入點在 0x1140；但沒辦法告訴你那些指令在做什麼。要那個就得用 objdump、Ghidra、Binary Ninja 或 IDA，而它們都不會跑在瀏覽器分頁裡。

支援哪些架構？

全部，因為 ELF 的結構不會因為目標平台而改變。x86-64、i386、ARM、AArch64、RISC-V、兩種位元組序的 MIPS、PowerPC、S390、SPARC、Xtensa、AVR 都是同一套讀法；跟架構有關的只有重定位類型的名稱和 e_flags 的意義，那是查每個機器各自的表得來的。表裡沒有的機器一樣可以完整解析，並且直接顯示原始的 e_machine 數字，不會替它掰一個名字。

最大能開多大的檔案？

128 MiB。解析時整個檔案都要放在分頁的記憶體裡，上面再加上每個符號、每筆重定位各一個物件，所以尖峰用量是檔案大小的好幾倍。超過這個上限，分頁會在解析途中被系統收掉，看起來就像頁面當掉，所以工具選擇直接說明理由拒收。會這麼大的通常是沒 strip 的除錯建置——在自己電腦上用 readelf 或 objdump，或先把除錯節區拿掉。

它說檔案被 strip 了，符號跑去哪了？

被 strip 的檔案沒有 .symtab，區域函式和 static 函式的名字就住在那裡，而 strip 會把整個節區砍掉。留下來的是 .dynsym，也就是動態符號表，因為載入器在執行時要靠它解出匯入與匯出——所以你還是看得到它呼叫了哪些函式庫的哪些函式、匯出了什麼，只是看不到它自己內部函式的名字。摘要卡會說明你現在看的是哪一種，以及各有幾個符號。

檔案壞掉了，它還是給了我東西，這是 bug 嗎？

這是刻意的。下載到一半斷掉、被人手工改過的標頭、指到檔案結尾外面的節區表——這些在 CTF 裡都是正常輸入，而一個遇到被改壞的 ELF 就給你一張空白錯誤頁的檢視器，正好在最需要它的時候沒有用。整份檔案層級的問題（沒有 ELF 魔術數字、class 或位元組序不可能成立）還是會中止解析，但單一節區、符號或重定位的問題會退化成警告，而每一則警告都會顯示在頁面上，不會被吞掉。

相關工具