著者: M15tak3(skyman.soul@gmail.com)

CTF分野の詳細ガイド

1. CTFとは

CTF（Capture The Flag）は情報セキュリティ競技の形式です。参加者は解析、脆弱性利用、復号、リバース、フォレンジックなどを通じて flag（通常は特定形式の文字列）を取得し、得点します。

CTFの本質はツールコマンドの暗記ではなく、システム原理・安全機構・攻防思考を総合的に理解することにあります。

1.1 よくある大会形式

• Jeopardy: 分野別問題（Web、Pwn、Reverse、Crypto、Misc など）を順に解いて flag 提出
• Attack-Defense: 相手チームを攻撃しつつ自チームのサービスを防御
• King of the Hill: 目標を継続占有して得点

1.2 CTFの価値

• 実践力向上: 断片知識を攻撃/防御チェーンに統合
• 工学力向上: 自動化、デバッグ、ログ分析、復盤の習慣化
• 協業力向上: 分業、並行実行、時間管理、戦略判断

1.3 問題の特徴

• 多くは「1つの利用可能な欠陥」を中心に設計され、実運用と完全一致しない
• ノイズ情報が意図的に混ざっており、手掛かり選別が必要
• 高得点問題は複数ステップ連鎖が多い

2. Web分野

2.1 コア

Webアプリの動作を理解し、設計/実装上の欠陥から機密情報（flag など）を取得する。

2.2 代表的な問題

• SQLインジェクション
• XSS（反射/格納/DOM）
• ファイルアップロード脆弱性
• 逆シリアライズ問題
• SSRF
• コマンド実行（RCE）
• 認証/セッション不備
• アクセス制御不備（権限昇格・越権）
• SSTI
• パストラバーサル / LFI/RFI

2.3 必要知識

• HTTP/HTTPS基礎
• 主要バックエンドの挙動（Flask、Django、PHP、Node）
• SQL基礎
• 入力/処理/出力の安全モデル
• エンコード/デコード

2.4 よく使うツール

• Burp Suite
• ブラウザDevTools
• sqlmap
• ffuf / dirsearch
• Postman / curl

2.5 解法の基本フロー

1. 画面・API・パラメータ・認可ロジックを棚卸し
2. 入力可能点を特定
3. 境界挙動（特殊文字、長大入力、型不一致）を確認
4. エラー/応答から脆弱性タイプを判断し payload 構築
5. 初期突破後に横展開（ファイル読み取り、権限昇格、内部探索）

3. Misc分野

3.1 コア

Miscは総合問題。情報処理力、スクリプト自動化、分野横断の発想力が問われる。

3.2 代表的な問題

• エンコード/デコード
• ステガノグラフィ
• 通信解析（pcap、HTTP/TCP）
• フォレンジック断片（ログ、圧縮、メタデータ）
• 自動化ミニゲーム/プロトコル対話
• QR/バーコード/キーボードログ/モールス等

3.3 必要知識

• ファイル形式構造（PNG/JPG/ZIP/PDF）
• ネットワーク基礎（TCP/HTTP/DNS）
• Linux CLI
• Python処理（正規表現、バイト列、バッチ処理）

3.4 よく使うツール

• CyberChef
• Wireshark / tshark
• binwalk / foremost
• stegsolve / zsteg / exiftool
• Python

3.5 解法の基本フロー

1. アーティファクト種別を見極める
2. メタデータ/構造（ヘッダ、フッタ、magic bytes）を確認
3. 可逆変換を試す
4. 反復作業は早めにスクリプト化

4. Crypto分野

4.1 コア

CTFのCryptoは、現代暗号の総当たりよりも、弱いパラメータ・実装ミス・運用ミスの悪用が中心。

4.2 代表的な問題

• 古典暗号
• RSA系脆弱性
• 共通鍵暗号の誤用（ECB、IV再利用、padding oracle）
• ハッシュ関連問題
• 予測可能乱数

4.3 必要知識

• 剰余演算、ユークリッド互除法、逆元
• 素数、オイラー関数、高速べき乗
• 暗号モード（ECB/CBC/CTR/GCM）
• 署名/認証基礎

4.4 よく使うツール

• Python + pycryptodome
• SageMath
• factordb / yafu
• RsaCtfTool

4.5 解法の基本フロー

1. 数学問題か実装不備問題かを判定
2. 既知/未知を整理
3. 数学的関係を立て、可解性確認
4. 弱点パラメータ/再利用を優先検証

5. Pwn分野

5.1 コア

バイナリのメモリ安全性欠陥を利用し、実行フローを制御して最終的に flag 取得または shell 奪取を目指す。

5.2 代表的な問題

• スタックオーバーフロー
• ヒープ攻撃
• フォーマット文字列脆弱性
• 整数オーバーフロー起点のOOBアクセス
• サンドボックス脱出（上級）

5.3 必要知識

• C言語メモリモデル
• x86/x64呼び出し規約
• ELF/動的リンク
• Linux/syscall基礎
• 防御機構（NX, Canary, PIE, RELRO, ASLR）

5.4 よく使うツール

• gdb + pwndbg/gef
• pwntools
• checksec
• IDA / Ghidra
• one_gadget / ropper

5.5 解法の基本フロー

1. checksec で保護機構確認
2. 制御可能入力と危険経路を特定
3. クラッシュ点とオフセット制御を検証
4. 保護機構に応じて攻撃チェーン選択
5. ローカル成功後にリモート移植（libc差分・タイミング調整）

6. Reverse分野

6.1 コア

静的/動的解析でロジックを復元し、重要データ・検証式・鍵を取り出す。

6.2 代表的な問題

• 文字列検証と軽い難読化
• 制御フロー平坦化/偽分岐
• 逆デバッグ/逆サンドボックス
• 独自暗号の復元
• APK/so/スクリプト混合解析

6.3 必要知識

• アセンブリ基礎
• コンパイラ最適化の影響
• PE/ELF/APK構造
• ブレークポイント追跡

6.4 よく使うツール

• IDA Pro / Ghidra
• x64dbg / OllyDbg
• gdb
• JADX / apktool
• Frida

6.5 解法の基本フロー

1. まず実行してI/O挙動確認
2. 重要関数を静的に特定
3. ブレークポイントで仮説検証
4. アルゴリズム復元またはパッチで検証回避

7. AIセキュリティ分野

7.1 コア

モデル・データ・推論パイプライン・統合層に対する攻撃と防御を扱う。

7.2 代表的な問題

• Prompt Injection
• Jailbreak
• Data Leakage
• Tool Abuse / 権限逸脱
• RAG汚染
• Model Extraction / Membership Inference
• 敵対的サンプル

7.3 必要知識

• LLMのロール階層（system/user/assistant）
• RAGパイプライン
• Agentのツール呼び出しと権限境界
• 入力フィルタ、出力監査、ポリシーエンジン

7.4 よく使う方法

• 手動ペイロード設計
• モデル入力出力とツール呼び出しログ監査
• Red Teamベンチマーク
• 自動注入テスト

7.5 解法の基本フロー

1. システム境界の把握
2. 低リスク探索
3. レイヤー別に突破
4. 再現性の確認
5. 対策提示（最小権限・文脈分離・ガードレール）

7.6 防御チェックリスト

• System命令はユーザー入力で上書き不可
• 取得文脈とユーザー入力の分離
• ツール呼び出しの権限ゲート
• 高リスク出力のポリシー検査と人手確認
• フルログ保全による再現/追跡

8. チーム分業の提案

• Web: APIと業務ロジック脆弱性
• Pwn: バイナリ攻撃チェーン
• Reverse: アルゴリズム復元と補助スクリプト
• Crypto: 数学/暗号問題と検証スクリプト
• Misc: 通信・ステガノ・雑多問題の高速処理
• AIセキュリティ: モデル/Agent攻撃面

成熟チームでは各分野に主担当とバックアップを置くのが効果的。

9. まとめ

CTFはツール競争ではなく、知識構造・分析手法・自動化力・チーム連携の総合力です。

まずは1〜2分野を深掘りして安定得点源を作り、その後に他分野を広げると効率よく成長できます。

この記事は2026-05-14にM15tak3のBlogで公開され、最終更新日は2026-05-14です

本ブログのすべての文書は、特に指定されていない限り、BY-NC-SAライセンスに従っています。引用の際は出典を明記してください！

著者: M15tak3(skyman.soul@gmail.com)

AIが私たちをイタカへ近づけはじめたとき…

いつからだろう。問題にぶつかったとき、最初の動作が「AIに聞くこと」になっていた。

最初は、もちろんワクワクした。AIは、いつでも点けられる灯りのようだった。以前なら自分で長く手探りしなければならなかった場所を照らしてくれる。コードが読めなければ聞けばいい。エラー原因が分からなければ聞けばいい。CTFで手が止まっても聞けばいい。Web、Reverse、Pwn、Crypto。昔は資料を探して徹夜で試行錯誤していたものが、急に手の届く場所へ来た。

これは確かに進歩だ。否定するつもりはない。AIは多くの障壁を下げ、意味の薄い摩擦を取り除いてくれる。環境構築や専門用語、断片情報で入口に立てなかった人たちが、より自然に学習へ入れるようになった。セキュリティ学習者にとって、この助けは本物だ。難しい知識にやわらかい入口を作り、孤独な学習時間に疲れない伴走者を与えてくれる。

ただ、同時に、別の何かが静かに軽くなっている。

以前のCTFでは、詰まることは普通だった。コードを見ても脆弱性が見えない。payloadを何度作っても反応がない。逆コンパイル結果で迷子になり、通信ログの中から異常を探し、レジスタとスタックの間でプログラムの次の挙動を推測する。学習は遅かった。多くの夜は、きれいな結果ではなく失敗の山だけが残った。

でも振り返ると、残っているのはその「遅さ」だった。すぐ答えが出ない時間が、観察する力を育てた。間違った仮説が、境界を教えてくれた。なかなか解けない問題が、セキュリティは脆弱性名の暗記ではなく、不確実性の中で疑い続けることだと教えてくれた。

今は答えが来るのが速すぎる。問題と向き合う前に、提出へ急いでしまう。流暢な説明が、30分の沈黙の推論を置き換えてしまう。完成度の高そうな解法が、理解した気にさせてしまう。

少し悲しい。AIが強すぎるからではない。私たちが「分からない状態」に耐えにくくなっているからだ。分からないことは、学習の最も自然な入口だった。立ち止まらせ、空白を認めさせ、未知へ少しずつ近づかせる入口だった。今はその空白がすぐ埋まる。画面には自信に満ちた、整った、やさしい答えが現れる。不安は一時的に消える。

でも、理解も一緒に消えるかもしれない。

CTFで本当に重要なのはflagそのものだけではない。flagは終点かもしれないし、合図かもしれない。人を変えるのは、そこへ向かう過程だ。なぜここを疑ったのか。なぜこの経路が成立するのか。なぜ別の方向は失敗したのか。なぜ同じpayloadが環境を変えると通らないのか。この道を自分で歩かなければ、最後の文字列だけ見ても中身は空っぽになりやすい。

AIは答えを出すのが得意だ。でも、答えを自分のものにさせるのは別の話だ。特にセキュリティでは危険が大きい。セキュリティは判断力であり、境界への感度であり、「正常に見えるもの」を疑う態度だからだ。AIは脆弱性を説明し、スクリプトを生成し、専門用語を流暢に並べられる。でも間違う。そしてしばしば、正しそうに間違う。流暢さは誤りをもっともらしくし、推測を結論に見せる。検証する力がなければ、その体裁を真実と取り違えやすい。

AIは、泥道を避けられる近道のようにも見える。でも脚力の一部は、その泥の中で育つ。遠回りは減るが、問題と格闘する時間も減る。結果には速く着けるが、本質には必ずしも近づかない。

これは反AIの話ではない。これからも使うし、もう手放せないことも分かっている。盲点を見せ、時間を節約し、混乱の中で出発点をくれる。だからこそ忘れたくない。道を照らせるのは道具だが、目を育てるのは自分だ。

CTFでAIを使う最良の姿は、解答を代行させることではなく、問題の前にとどまる自分に伴走させることかもしれない。方向を示してくれても、そこに本当に道があるかは自分で判断する。スクリプトを書いてくれても、各行がなぜ必要かは自分で説明できるようにする。答えをくれても、「これは本当に理解した上での答えか」と問い直す。

私たちは、答えがどんどん安くなる時代に入っている。だからこそ、遅くなることに価値がある。遅いことは後退でも無能でもない。問題への敬意であり、理解を自分の手元に残す方法だ。

すべてが進捗、結果、スクリーンショット、要約へ圧縮される時代に、遅くなるには勇気がいる。

セキュリティでは、焦りはとくに危険だ。セキュリティは早押しではなく検証だ。先に脆弱性名を言えた人が真実に近いわけではない。先にpayloadを走らせた人が本質を理解しているわけでもない。必要なのは、忍耐と疑い、そして「もっともらしい場所」で一呼吸置く姿勢だ。多くの脆弱性は、速さではなく、反復的な観察・検証・問い直しによって見つかる。

だから、まだ遅くなることを学びたい。

AIを拒むのでも、過去へ戻るのでもない。使いながら、自分のための距離を残す。まず問題を見る。まず境界を考える。問題を頭の中に少し置いておく。

空白を答えで急いで埋めない。生成された文章で不安を急いで塞がない。

残しておくべき空白がある。

人はそこで思考を始めるからだ。

AIは私たちをイタカへ早く運んでくれる。

でも到着する前に、私たちは本当に海を見ただろうか。

この記事は2026-05-07にM15tak3のBlogで公開され、最終更新日は2026-05-07です

本ブログのすべての文書は、特に指定されていない限り、BY-NC-SAライセンスに従っています。引用の際は出典を明記してください！

著者: M15tak3(skyman.soul@gmail.com)

LinuxでのPython管理（pyenvのインストールと使い方）

新しいLinux（例: Ubuntu 24.04）では、pip でシステム全体にパッケージを入れようとすると externally-managed-environment エラーが出ることがあります。つまり、pip によるグローバルインストールがそのままでは許可されません。

システムのPython環境を壊さず、Pythonバージョン管理もしやすくするために、pyenv（必要に応じて仮想環境）を使うのがおすすめです。

ビルド依存関係のインストール

Ubuntu/Debian の場合:

sudo apt-get update; sudo apt-get install -y make build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm libncursesw5-dev xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev

CentOS 系の場合:

sudo yum install -y gcc zlib-devel bzip2 bzip2-devel readline-devel sqlite sqlite-devel openssl-devel xz xz-devel libffi-devel findutils

pyenv のインストール

公式スクリプトでインストールします。

curl https://pyenv.run | bash

シェル設定を追加して反映

echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init -)"' >> ~/.bashrc
 
# Zsh を使う場合は .bashrc を .zshrc に置き換えてください

source ~/.bashrc
# Zsh を使う場合は .bashrc を .zshrc に置き換えてください

# 確認
pyenv --version

pyenv の基本操作

# pyenv install python-version 例: 3.13.3 をインストール
pyenv install 3.13.3

# pyenv global python-version 例: グローバルを 3.13.3 に設定
pyenv global 3.13.3

# pyenv local python-version 例: プロジェクトローカルを 3.13.3 に設定
cd my-project/
pyenv local 3.13.3

# pyenv shell python-version 例: 現在のシェルだけ 3.13.3 に設定
pyenv shell python-version

# pyenv virtualenv python-version myproject-env 例: 3.13.3 の ctf 仮想環境を作成
pyenv virtualenv 3.13.3 ctf

# pyenv activate myproject-env 例: ctf 仮想環境を有効化
pyenv activate ctf

# pyenv deactivate 仮想環境を終了
pyenv deactivate

この記事は2026-05-06にM15tak3のBlogで公開され、最終更新日は2026-05-06です

本ブログのすべての文書は、特に指定されていない限り、BY-NC-SAライセンスに従っています。引用の際は出典を明記してください！

著者: M15tak3(skyman.soul@gmail.com)

WSL2 + Ubuntu をゼロから導入する

はじめに

WSL は、Windows 上で動く軽量な仮想環境として捉えられ、VMware よりローカルファイル連携がしやすいのが特徴です。

注意: サブシステム導入後に Windows を Home から Pro へアップグレードすると、サブシステム側のファイルが破損する可能性があります。必ずバックアップを取ってください。

WSL のインストール

機能の有効化

Windows の設定 -> システム -> オプション機能 -> Windows のその他の機能 を開きます。

Linux 用 Windows サブシステム と 仮想マシン プラットフォーム を有効にして OK を押します。機能のインストール後、再起動を求められるので再起動します。

WSL Ubuntu のインストール

ターミナルを開いて次を実行します。

wsl --install -d Ubuntu-22.04

この環境では Ubuntu 24.04 が自動取得されるので、進行バー完了まで待てばOKです。

インストール後はサブシステムが自動で起動し、ユーザー名設定を求められます。ディストリによって命名規則が少し異なるため、弾かれた場合は指示に合わせて修正してください。

サブシステムを別ドライブへ移動する

WSL で取得した Linux は通常 C ドライブに入ります。移動したい場合は、まず Linux シェルで exit を実行します。

次に、WSL を停止して導入済み Ubuntu 22.04 をエクスポート（バックアップ）します。

wsl --shutdown
wsl --export Ubuntu-22.04 E:\WSL\ubuntu2204.tar

保存先は任意ですが、ファイル名は .tar で終わる必要があります。

続いて現在のサブシステムを登録解除し、先ほどの tar を指定して希望パスへインポートします。

wsl --unregister Ubuntu-22.04
wsl --import Ubuntu-22.04 E:\WSL\Ubuntu2204 E:\WSL\ubuntu2204.tar
wsl -d Ubuntu-22.04

これでサブシステムの保存先が変更され、既存ファイルもそのまま保持されます。

この記事は2026-05-06にM15tak3のBlogで公開され、最終更新日は2026-05-06です

本ブログのすべての文書は、特に指定されていない限り、BY-NC-SAライセンスに従っています。引用の際は出典を明記してください！