ソフトな手法からハードなパッチへ — macOS Mach-O リバースエンジニアリング方法論の振り返り

起点きてん

ある日ひの現実げんじつの問題もんだい：手元に macOS Universal Mach-O App があり、ソースコードも、開発者かいはつしゃ証明書しょうめいしょも、サーバーへのアクセス権限けんげんもない前提ぜんていで、それを動うごかす必要ひつようがあった。こういう場面ばめんは、実際じっさいの攻防こうぼうではそれほど珍めずらしくない — ひとつのバイナリを手てに入いれ、その内部ないぶの判断はんだん経路けいろを理解りかいし、意味いみを変かえない前提ぜんていで、ある分岐ぶんきを自分じぶんの望のぞむ方向ほうこうへ進すすませたい、という状況じょうきょうだ。

以下いかでは、変更へんこうされた App が何なにだったのかは扱あつかわず、方法ほうほうだけを扱あつかう。すべての trick は、日常にちじょうのセキュリティ監査かんさ、debug、グレーボックステストにそのまま応用おうようできる。

前提ぜんてい：本稿ほんこうでは、あなたがそのバイナリに対たいして**合法ごうほうなリバース権けん**を持もっていることを想定そうていしている — 自分じぶんの製品せいひん、CTF の課題かだい、許可きょかを得えたセキュリティ監査かんさ対象たいしょう、またはすでに公開こうかい終了しゅうりょうしているが購入こうにゅうしたことのある古ふるいソフトウェアなどだ。この技術ぎじゅつを他人たにんの商用しょうよう製品せいひんに向むけることは、この記事の想定そうていする場面ばめんではない。

ネタバレ：この実戦じっせんの 8 時間じかんのうち、6 時間じかんはソフトな方法ほうほうでつまずき、2 時間じかんで最終的さいしゅうてきな 18 個このパッチの 90% を仕上しあげた。以下いかの 5 つの教訓きょうくんは、この 8 時間じかんの振ふり返かえりだ。Ghidra を少すくなくとも一度いちどは使つかったことがあるが、patch を実際じっさいに動作どうさする app へ反映はんえいしたことはまだない、という人ひとに向むいている。

最初さいしょの教訓きょうくん：まずソフトな方法ほうほうを尽つくす。ただし、いつ諦あきらめるかを知しる

正式せいしきにバイナリをいじり始はじめる前まえに、私は「ソフトな方法ほうほう」にまるまる数時間すうじかんを費ついやした — ユーザー空間くうかんの設定せっていを変かえる、Keychain を変かえる、hosts を変かえる、外向そとむきファイアウォールを張はる。これらの試こころみはどれも失敗しっぱいしたが、失敗しっぱいの仕方しかたはそれぞれ違ちがい、その一ひとつひとつが一ひとつのことを教おしえてくれた：

まず crash log を見みる：binary に手てを入いれる前まえの最初さいしょの動作どうさは、逆ぎゃくコンパイルではなく ~/Library/Logs/DiagnosticReports/<app>-*.ips だ。Dyld の初期しょきエラー（Library not loaded: @rpath/...、Symbol not found、unknown library ordinal -8、bundleIdentifierVerification）は、たいてい termination reasons と exception フィールドにかなり率直そっちょくに書かかれていて、次つぎにフレームワークの整合性せいごうせい、シンボル輸出ゆしゅつテーブル、receipt 検証けんしょうパスのどれを掘ほるべきかを直接ちょくせつ教おしえてくれる。この一手いっては下したのどのソフトな方法ほうほうよりも「ソフト」で、ソフトな方法ほうほうの系譜けいふにおける第だい 0 歩ほであるべきだ。
plist preferences を変かえる：feature flag に見みえる key の多おおくは、実際じっさいには i18n localization key にすぎない。i18n key と本物ほんものの状態じょうたい key を区別くべつするための識別しきべつ信号しんごうの一ひとつは、app がこの文字列もじれつを受うけ取とったあと、直接ちょくせつ表示ひょうじするのか、それとも判定はんていブランチに使つかうのか、という点てんだ。reflection metadata の中なかの命名めいめい規約きやくを見みれば、たいていすぐに見分みわけられる。
Keychain entries を偽造ぎぞうする：現代げんだいの Swift app は、永続化えいぞくかデータに Ed25519 署名しょめいを付つけるのが一般的いっぱんてきだ。秘密鍵ひみつかぎがなければ正当せいとうな署名しょめいは生成せいせいできない。entry を書かき込こんだとしても、ロード段階だんかいを過すぎたところで署名しょめい検証けんしょうに落おとされ、hasCachedXxx=false の形かたちでログに記録きろくされる — それでもあなたは、認識にんしきされたと思おもってしまう。
/etc/hosts でブロックする：Cloudflare WARP / iCloud Private Relay / 何らかのユーザー空間くうかん DNS リゾルバを使つかっている機械きかいでは、/etc/hosts はそもそも参照さんしょうされない。これは特とくに覚おぼえておく価値かちがある。なぜなら、hosts ファイルを見みつめながら、なぜ nslookup が本物ほんものの IP を返かえすのかと疑問ぎもんに思おもうことになるからだ — 見みかけと事実じじつが完全かんぜんに切きり離はなされている。
外向そとむきファイアウォール（LuLu）：work はするが、移植性いしょくせいがない。別べつの Mac に替かえるとやり直なおしになる。

教訓きょうくんは「ソフトな方法ほうほうは役やくに立たたない」ではない。教訓きょうくんは — ソフトな方法ほうほうにはそれぞれ解決かいけつできる問題もんだい領域りょういきがあり、目標もくひょうの検証けんしょうチェーン全体ぜんたいがこちらで変かえられる範囲はんいの外そとにあるとき、ソフトな方法ほうほうをいくら重かさねてもノイズでしかない、ということだ。このときは迷まよわずバイナリ層そうへ切きり替かえるべきだ。

この臨界点りんかいてんを判断はんだんする大おおまかな信号しんごうがある：目標もくひょうの状態じょうたい機械きかいがどう動うごくかはもう把握はあくしているが、どの状態じょうたいへの入口いりぐちも署名しょめい / サーバー / キャッシュで交差こうさ的に守まもられている、という状況じょうきょうだ。この段階だんかいでまだ外側そとがわからパッチを当あて続つづけるのは、検証けんしょうチェーンと競走きょうそうしているようなものだ。

ソフトな方法ほうほうを尽つくしたあとの判断点はんだんてんを越こえたら、次つぎはツールチェーンの選択せんたくに入はいる。

二ふたつ目めの教訓きょうくん：ツールチェーンは積つみ重かさねて使つかうもので、代替だいたい関係かんけいではない

実際じっさいにバイナリ層そうへ入はいったあとに使つかったツール群ぐん：

Ghidra 11.3.2 headless mode — 主力しゅりょくのデコンパイラ。Swift バイナリは Hopper/IDA にとっても簡単かんたんではないが、Ghidra 内蔵ないぞうの Swift demangler + decompiler なら、10MB 規模きぼの Mach-O に対たいする完全かんぜんな AutoAnalysis はだいたい 7〜8 分ふんで終おわる。一度いちど走はしらせてから、自分じぶんの Java スクリプトで解析済かいせきずみの .gpr project を何度なんども query するのがよい。毎回まいかい Analysis を走はしらせ直なおすべきではない。
xcrun llvm-objdump --disassemble --start-address=X --stop-address=Y — Ghidra が吐はく擬似ぎじ C が信用しんようできないときは、asm に戻もどって見みる。具体的ぐたいてきには、ある cbnz/tbnz の immediate を spot-check したり、movz/movk で組くみ立たてられたインライン Swift 文字列もじれつを確認かくにんしたりする。
xcrun swift-demangle — nm の出力しゅつりょくを pipe すれば、_$s10AppName14SomeManagerC... がどの class のどの method かすぐ分わかる。Swift は構造こうぞう情報じょうほうのあまりにも多おおくを mangling の中なかに隠かくしているので、demangle できないと作業さぎょうにならない。
rabin2 -zz (radare2) — すべての cstring / objc methname / Swift reflstr を vaddr 付つきで一括いっかつ dump する。strings -a よりずっと強つよい。
lldb -b -s commands.txt — batch mode で patch が本当ほんとうに実行中じっこうちゅうの image に入はいっているかを検証けんしょうする。Attach + memory read --size 4 --count 1 --format x <addr> で、期待きたいする byte と照合しょうごうする。これは「ファイルを変かえた」ことと「実行中じっこうちゅうのプロセスが本当ほんとうに新あたらしいコードを実行じっこうしている」ことを区別くべつできる唯一ゆいいつの方法ほうほうだ — 後者こうしゃでは ASLR slide も考慮こうりょしなければならない。
otool -l / lipo -detailed_info — Universal binary の fat header から arm64 slice の offset を取とる。Universal binary の universal-offset と arm64-slice-offset には固定こていの base 差さがあり、この値あたいは app ごとに違ちがうため、毎回まいかい lipo -detailed_info <bin> | grep -A4 arm64 で現物げんぶつを確認かくにんする必要ひつようがある（出力しゅつりょくの offset フィールドがその base）。自分じぶんも最初さいしょに base を計算けいさんし間違まちがえて痛いたい目めを見みた。patch は書かけたように見みえるのに、byte がまったく無関係むかんけいな場所ばしょに落おちていたのだ。これは新人しんじんがもっとも踏ふみやすい罠わな：スクリプトを書かくときは universal offset と slice offset を別々べつべつの変数名へんすうめいで厳密げんみつに区別くべつする。
dyld_info -fixups <bin> / dyld_info -exports <bin> — macOS 12+ に標準ひょうじゅんで入はいっている。nm より強つよいのは、dyld が実際じっさいに見みている chained fixups と export trie の視点してんを教おしえてくれることだ。nm に見みえる「export された記号きごう」と、dyld が実際じっさいに bind に使つかう export trie は一致いっちしないことがある（build script が class を半端はんぱに rename したときによくある）。これは nm だけでは絶対ぜったいに見抜みぬけない罠わなだ。
codesign --force --deep --sign - — byte を変かえたら必かならず再署名さいしょめいする。macOS の sealed-resource 検証けんしょうは deep mode だと Contents/ 内ないの小ちいさなファイルまで見みに行いく。見分みわけ方かた：codesign --verify --verbose /Applications/<app>.app が sealed resource is missing or invalid を報告ほうこくしたら、エラー情報じょうほうの中なかに具体的ぐたいてきな path が示しめされる（たいていは内蔵ないぞう framework / bundle 資源しげんのどれか）。そのファイルを .app の外そとへ移動いどうしてから sign し、署名後に戻もどす。app ごとに「違反いはんファイル」は違ちがうが、特定とくていのパターンは固定こていだ。
hdiutil create -format UDZO — 変更後へんこうごの .app を DMG に戻もどし、「別べつの機械きかい」に配布はいふできる媒体ばいたいにする。

3つ目めの教訓きょうくん：「キラー補丁パッチ」を探さがせ、すべての callsite を巡回じゅんかいするな

逆向ぎゃくこう 8 時間じかんの中なかでいちばん価値かちがあった認識にんしきの変化へんか：36 個この callsite にそれぞれ補丁パッチを当あてるより、そこから共通きょうつうして呼よばれる関数かんすうを探さがしたほうがいい。

具体的ぐたいてきには：badge 描画びょうが、modal 表示ひょうじ、feature gate、メニュー項目こうもくクリック応答おうとう — 表面上ひょうめんじょうは 36 個この独立どくりつした UI / action callsite だ。だがいくつか逆ぎゃくアセンブルすると、どれも同おなじ pattern を通とおることが分わかる：

bl  <some_fn>       ; bitmask を返す
mvn wN, w0          ; 反転
and wN, wN, MASK    ; 注目する数 bit を取り出す
cbnz xN, deny_path  ; 全部 0 でなければ拒否

違ちがいは MASK だけ。すべての callsite が同おなじ <some_fn> 判断はんだん関数かんすうを共有きょうゆうしている。このときは、その関数かんすうの prologue をそのまま movn x0, #0; ret（0xFFFFFFFFFFFFFFFF を返す）に書かき換かえれば、すべての callsite が同時どうじに「MASK が完全かんぜんに一致いっち、通過つうか」と見みなす。1 箇所かしょの変更へんこうが 36 箇所かしょぶんになる。

この考かんがえ方かたは防御側ぼうぎょがわでも成なり立たつ：コードを監査かんさするときは、こういう「全局ぜんきょく判断点はんだんてん」関数かんすうを見みつける。それらは攻撃者こうげきしゃにとって最高価値さいこうかちの標的ひょうてきであると同時どうじに、防御ぼうぎょで重点的じゅうてんてきに守まもるべき対象たいしょうでもある（多重たじゅう検証けんしょう、runtime 完全性かんぜんせい、名前なまえの難読化なんどくか）。

caller-side の安全あんぜん準則じゅんそくを補足ほそく

「callee の prologue を movn x0, #0; ret に変かえる」この定石じょうせきは、基本型きほんがた / 整数せいすう bitmask を返す関数かんすうにしか安全あんぜんではない。callee が Swift 関数かんすうで retain-counted な class instance / Optional を返すなら、caller はほぼ確実かくじつに swift_retain(x0)、bl _objc_release、x0 を log 引数ひきすうとして stack に保存ほぞん、さらに後続こうぞくで swift_release_n(x0, #2) などを行おこなう。このとき callee に 0 / nil を返させると、caller はすぐ nil を object として dereference して SIGSEGV になる。

実践じっせん準則じゅんそく：

callee をいじる前まえに、caller が戻もどり値ちをどう使つかうか見みる。mov x28, x0 の直後ちょくごに bl _swift_retain が続つづくなら危険きけん信号しんごうだ。
戻もどり値ちが再利用さいりようされるなら、caller 側がわから call 全体ぜんたいを迂回うかいするほうが安全あんぜん — tbnz / cbz を 1 本ぽん変かえて常つねに「すでに条件じょうけんを満みたした」分岐ぶんきへ行いかせ、callee がそもそも呼よばれないようにする。あるいは呼よばれても caller が「戻もどり値ちを消費しょうひしない」path に進すすませる。
callee 入口いりぐちを直接ちょくせつ ret に変かえる前提条件ぜんていじょうけんは：callee がもともと void-ish な戻もどりであること、または caller が x0 に対して retain / release / dereference をしないこと。

これは当あたり前まえに聞きこえるが、自分じぶんは初回しょかいの試行しこうでそのまま SIGSEGV したので、この落おとし穴あなを明確めいかくに書かいておく。

第だい四よんの教訓きょうくん：再現可能性さいげんかのうせいは最低さいてい条件じょうけん

どんなに野心的やしんてきな patch プロジェクトでも、初日しょにちから reapply スクリプトを必かならず添そえるべきだ。理由りゆうは：

システムアップグレード / app 更新こうしん / 自分じぶんの手てすべりで一度いちど上書うわがきした — こういう場合ばあいに 30 秒びょう以内いないで patched 状態じょうたいへ戻もどる必要ひつようがある。
作業さぎょうを二台目にだいめの Mac に複製ふくせいするとき、「自分じぶんが手動しゅどうでどのバイトを変かえたか」だけが唯一ゆいいつのドキュメントだと破滅的はめつてき。
復盤ふくばんやチーム共有きょうゆうのとき、スクリプトは最良さいりょうの「何なにをしたか」の叙述じょじゅつになる — 各行かくぎょうが明確めいかくな一ひとつの動作どうさだからだ。

スクリプト形式けいしきの推奨すいしょう：

テーブル駆動くどうにする。hex blob ではない。各かく entry は (univ_offset, expected_old_hex, new_hex, description)。
各かく patch は書かき込こむ前まえに、元もとのバイトが期待通きたいどおりか check する。不一致ふいっちなら skip + ログ記録きろくし、スクリプト全体ぜんたいを abort しない — そうすればスクリプトは idempotent で、繰くり返かえし実行じっこうしても無害むがい。
patch 後ごに codesign --verify を一度いちど呼よんで、再署名さいしょめいされた状態じょうたいを確認かくにんする。
最後さいごに、環境側かんきょうがわの強化策きょうかさく（たとえば自動更新じどうこうしんの無効化むこうか）も再度さいど reassert する。この部分ぶぶんは per-user defaults なので、移行時いこうじに失うしなわれやすい。

五いつつ目めの教訓きょうくん：検証けんしょうは patch 自体じたいより時間じかんがかかる

patch ファイルを書かき、署名しょめいし、プロセスを起動きどうする — これはまだ第一歩だいいっぽにすぎない。本当ほんとうに有効ゆうこうになったことを確認かくにんするには、次つぎのステップが必要ひつよう：

静的確認せいてきかくにん：xxd でディスク上じょうのバイトが確たしかに変かわったことを見みる。
再署名確認さいしょめいかくにん：codesign -dv で signature が新あたらしくなっていることを確認かくにんする（codesign は、ほんの数すうバイト変かえただけだからといって文句もんくは言いわないが、再署名さいしょめいを忘わすれると文句もんくを言いう）。
読込確認よみこみかくにん：プロセスが立たち上あがったら vmmap <pid> で Load Address を取得しゅとくし、ASLR slide を計算けいさんしてから、lldb attach で実行中じっこうちゅうメモリ内ないの patch 後ごの位置いちを読よむ。元もとの stp ではなく movn の encoding が見みえれば、patch が本当ほんとうに CPU の実行経路じっこうけいろに乗のっていることになる。
挙動確認きょどうかくにん：patch 経路けいろを通とおる UI / API を発火はっかさせ、目視もくしまたはログで挙動変化きょどうへんかを確認かくにんする。
回帰確認かいきかくにん：app を十分じゅうぶんな時間じかん走はしらせ、patch したのが一回限いっかいかぎりの初期化経路しょきかけいろではなく、安定あんていして効きく箇所かしょであることを確認かくにんする。

この五いつつはどれも欠かかせない。何度なんどか、step 1 + 2 は問題もんだいなさそうに見みえたのに、step 3 で ASLR slide の計算けいさんが間違まちがっていると分わかったことがある — プロセス内ないのバイトはまだ古ふるいままだった。理由りゆう：

ファイル不一致ふいっち：改変かいへんしたのが /Applications/... 内ないで実際じっさいに起動きどうされているコピーではなかった。
署名しょめいキャッシュ：codesign 後ご、macOS カーネルには cache があり、古ふるい app インスタンスの Code Signing Identifier が新あたらしく署名しょめいしたものと一致いっちしなくても、カーネルがすぐには認識にんしきしない。
ASLR slide 計算けいさんミス：Mach-O 64-bit executable の __TEXT vmaddr base は 0x100000000（これは link 時じに決きまる。otool -l <bin> | grep -A4 'segname __TEXT' の vmaddr フィールドで確認かくにんする）；dylib / framework の base は通常つうじょう 0x0。slide = LoadAddress - static_base であり、LoadAddress 自体じたいではない。executable の slide 計算けいさんには 0x100000000 を、framework には 0x0 を使つかう — 混同こんどうしないこと。
TCC 権限けんげんが CDHash で失効しっこうする：codesign の再署名さいしょめいで binary の CDHash が変かわり、macOS の TCC（Privacy & Security）は CDHash を権限けんげんの主しゅキーとして扱あつかう。以前いぜん付与ふよした Accessibility / Input Monitoring / Screen Recording / Full Disk Access はすべて黙だまって失効しっこうする — UI 上じょうの toggle はオンに見みえるが、実際じっさいには権限けんげんがない。症状しょうじょう：⌥d / グローバルショートカットなどが突然とつぜん反応はんのうしなくなる。修正法しゅうせいほう：System Settings → Privacy & Security → Accessibility（または対応項目たいおうこうもく）で、app を**削除さくじょしてから再追加さいついか**する。toggle off/on ではない。

どれも一度いちどは 20〜30 分ぷんを失うしなわせてくれた。

チーム share で何なにを話はなせるか

この作業さぎょうを社内しゃない share に落おとし込こむなら、こういう構成こうせいを勧すすめる：

「ソフトな方法ほうほう vs ハードな方法ほうほうの転換点てんかんてんの見極みきわめ」 — これは経験けいけんであって、知識ちしきではない。5 つの具体的ぐたいてきなソフト方法ほうほうの失敗しっぱいと、それぞれの失敗しっぱいが何なにを露呈ろていしたかを話はなす。新人しんじんはたいてい、ある種しゅのソフト方法ほうほうに丸一日まるいちにち食くらいつくので、他人たにんの失敗しっぱいパターンを見みるだけで時間じかんを節約せつやくできる。
「ツールチェーンは並列へいれつの代替だいたいではなく、スタック式しきの積つみ重かさね」 — Ghidra のデコンパイルで大筋おおすじを見みて、llvm-objdump で局所的きょくしょてきな asm を掘ほり、lldb で runtime を検証けんしょうする。IDA だけ、あるいは r2 だけを使つかう同僚どうりょうを見みたことがあるが、ある種しゅの場面ばめんで詰つまる。
「キラーパッチを探さがす考かんがえ方かた」 — callgraph ツールで入次数にゅうじすうが最もっとも高たかい関数かんすうを列挙れっきょする。静的解析せいてきかいせきと組くみ合あわせて判断点はんだんてんを特定とくていする。このパターンは防御側ぼうぎょがわで「重要じゅうような保護対象ほごたいしょう」を識別しきべつするのにも同おなじように有効ゆうこう。
「reapply スクリプトと再現性さいげんせいの規律きりつ」 — これは最もっとも過小評価かしょうひょうかされやすい。demo と組くみ合あわせる：練習用れんしゅうよう app を使つかって一連いちれんの流ながれを最後さいごのスクリプトまで通とおし、チームメンバーにその場ばで「うわ patch が消きえた — スクリプトを走はしらせる — 戻もどった」を体感たいかんしてもらう。
「検証けんしょうの 5 階層かいそう」 — 上うえの 5 ステップそれぞれに、実際じっさいに踏ふんだ落おとし穴あなの事例じれいを 1 つずつ添そえる。

テーマの着地点ちゃくちてんは必かならずしも「どう crack するか」ではなく、「バイナリ層そうの観測可能性かんそくかのうせいと再現性さいげんせい」。このスキルセットは、本番ほんばん crash の調査ちょうさ、セキュリティ監査かんさ、third-party SDK の sanity check にも使つかえる。

結むすび

この 8 時間じかんのうち、6 時間じかんはソフトな方法ほうほうを試ためすことに費ついやし、2 時間じかんで最終的さいしゅうてきな 18 個この patch の 90% を作つくった。効率こうりつが悪わるく聞きこえるかもしれない — でも、その 6 時間じかんは無駄むだではなかった。ソフトな方法ほうほうが失敗しっぱいするたびに、ターゲットの内部構造ないぶこうぞうについて 1 つ学まなびがあり、それらの情報じょうほうは後のちにすべて、最終的さいしゅうてきな patch 箇所かしょの判断はんだんに沈殿ちんでんしていった。もし最初さいしょからいきなり Ghidra で黙々もくもくとデコンパイルしていたら、事前仮説じぜんかせつがないまま、むしろ間違まちがった関数かんすうにもっと時間じかんを使つかっていただろう。

リバースエンジニアリングの本質ほんしつは、「情報密度じょうほうみつどの最適化さいてきか」という仕事しごとだ — 手元てもとにあるバイナリは高こうエントロピーであり、限かぎられた時間じかんのなかでツールを使つかってそのエントロピーを圧縮あっしゅくし、「どの数行すうぎょうのコードが、どのユーザー可視かしの挙動きょどうを決きめているのか」という問いといに答こたえる。この意味いみで、攻防演習こうぼうえんしゅうの訓練価値くんれんかちは最終的さいしゅうてきな patch にあるのではなく、「制約せいやくされた情報じょうほうのもとで構造こうぞうを推論すいろんする」筋肉記憶きんにくきおくにある。

この筋肉記憶きんにくきおくは、コードを書かいてプロダクトを作つくる人ひとたちにも役立やくだつ。

# ソフトな手法からハードなパッチへ — macOS Mach-O リバースエンジニアリング方法論の振り返り