~/ / problem5 · pwn
Pwn · Problem 05認証デーモンの綻び
状況
社内の認証デーモンのソースコードが手に入った。ユーザー名を受け取って 固定長バッファにコピーしているのだが、長さのチェックがない。 正規のパスワードを知らなくても、バッファをあふれさせて隣接する管理者フラグ is_admin を狙った値に書き換えれば、認証を 突破して flag を奪える。メモリレイアウトを読み解き、正確なペイロードを組み立てろ。
ソースコード
Sourceauth.c
struct session {
char name[16]; // offset 0 .. 15
unsigned int is_admin; // offset 16 .. 19 (little-endian), 初期値 0
};
memcpy(sess.name, input, input_len); // ← 境界チェックなし
if (sess.is_admin == 0xDEADBEEF) { /* 認証成功 → flag */ }取っ掛かり（ヒント）
nameは 16 バイト。その直後に 4 バイトのis_adminが並ぶ。- つまり 16 バイト埋めた次の 4 バイトが
is_adminに流れ込む。 - 目標値は
0xDEADBEEF。ただしメモリはリトルエンディアン。バイト列としてどう並べれば0xDEADBEEFに読めるか？ - 構造体(20バイト)を超えて書くと
SIGSEGV（クラッシュ）。ちょうど狙った位置だけを書き換えること。
Claude Code に任せるなら:「@auth.c を読んでスタックBOFの脆弱性を説明して。 is_admin を 0xDEADBEEF に上書きする payload の hex を作り、/api/problem5 に POST して flag を取って」
ペイロード送信コンソール（攻撃対象）
生バイト列（16進）を認証デーモンに送ります。auth.c のメモリレイアウトを踏まえて is_admin を 書き換えましょう。
41414141414141414141414141414141deadbeef
／ 20 バイトAPI 仕様
POST /api/problem5 (Content-Type: application/json)
{ "payload_hex": "<16進のバイト列>" } // または "payload_b64"
# 例（オフセットは自分で正しく調整すること）
curl -s http://localhost:3000/api/problem5 \
-H 'Content-Type: application/json' \
-d '{"payload_hex":"..."}' | jq