ELF を開いて構造を読む。バイナリはこのタブから出ません。
ファイルはブラウザから送信されません — 処理はすべてローカルで行われます。
ELF バイナリをドロップ
クリックして選択も可 — このタブ内で解析し、アップロードはしません
アップロードは一切ありません。バイナリはこのタブで読み、Web Worker で解析します。ファイルを開いてもネットワークリクエストは 1 本も出ません。CTF のバイナリや顧客のファームウェアなら、そこが肝心です。
実行ファイル、.so、カーネルモジュール、.o、CTF のバイナリ、ファームウェアイメージ — ELF ならここにドロップするだけで、readelf -a が教えてくれる内容が 2 つのペインで連動して出てきます。左は構造ツリー: ELF ヘッダーのフィールド、プログラムヘッダー、セクションテーブル、.dynsym と .symtab（別々に）、.dynamic、各リロケーションセクション、ノート、バージョン定義と要求。右はファイルのバイト列。行をクリックすればその行の元になったバイトがちょうど光り、バイトをクリックすればそれを含む一番内側の構造が選択されます。
サマリーカードは、テーブルを開く前に片付けたい問いに先に答えます。ELF32 か ELF64 か、どのアーキテクチャとバイト順か、EXEC か DYN か REL か、エントリポイントはどこか、そして e_flags が意味を持つアーキテクチャ（RISC-V と MIPS はどちらもそうです）ではその中身。続けて導かれる事実として、静的リンクか動的リンクか・どのローダーを要求しているか、strip 済みか、PIE か、.note.gnu.build-id の Build ID、そして PT_GNU_STACK に PF_X が立っているか。最後のものはセキュリティに直結する事実なので、表の中に埋めずにそのまま書きます。
アップロードは一切ありません。この読者層にとってそれは機能ではなく前提です。CTF のバイナリは他人がまだ解いていない問題で、ファームウェアはたいてい顧客の資産です。セクションヘッダーを 1 つ見るために、それを見知らぬサーバーへ送るのは割に合いません。ファイルはタブで読み、Web Worker に渡して、メモリ上で解析します。アップロード先は存在せず、DevTools を開いたまま確認できます — バイナリを開いてもネットワークリクエストは 1 本も出ません。解析は Worker で走るので 60 MB のバイナリでもタブは固まらず、128 MiB を超えるファイルは受け取って固まる代わりに理由を添えて断ります。
このページが出す名前 — アーキテクチャ、種別、セクション種別、シンボルの type / bind / visibility、リロケーション種別、ダイナミックタグ — はすべて GNU binutils の readelf と同じ綴りです。パーサーが自分の期待値ではなく実際の readelf 出力と突き合わせてテストされているからです。シンボルが 1,900 個のバイナリは普通で、400,000 個のものも存在するので、シンボルとリロケーションの絞り込み・並べ替え・ページングはデータのある側で行い、1 行ずつページへ描き出すことはしません。
されません。ファイルはこのタブで読み、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 されたバイナリには .symtab がありません。ローカル関数や static 関数の名前はそこにあり、strip はそのセクションごと削除します。残るのは .dynsym（動的シンボルテーブル）です。ローダーが実行時にインポートとエクスポートを解決するために必要だからで、どのライブラリのどの関数を呼ぶか、何をエクスポートしているかは見えますが、内部関数の名前は見えません。どちらを見ているのか、それぞれ何個あるのかはサマリーカードに出ます。
仕様です。途中で切れたダウンロード、手で書き換えたヘッダー、ファイル末尾を越えるセクションテーブル — CTF ではどれも普通の入力で、細工された ELF に白いエラーページを返すビューアは、いちばん必要な場面で役に立ちません。ファイル全体の問題（ELF マジックがない、クラスやバイト順があり得ない）は今でも解析を止めますが、個々のセクション・シンボル・リロケーションの問題は警告に劣化し、その警告は握りつぶさずページに出します。
APK からネイティブの .so を取り出して、ここで読む。
同じ hex ペインで、どんなファイルの生バイトも開ける。
そもそも ELF か分からない？ マジックバイトで種類を判定。