# macOS IM クライアントのアップグレードでリバースの難度が上がる理由

同じ macOS IM クライアントでも、アップグレードのたびに、リバースのコストは少しずつ高くなる。これは「ホットアップデート」から「小バージョン」への段差だんさの記録きろくであり、何度なんども検証けんしょうされた経験けいけんでもある。バージョンをまたいで再利用さいりようできるのは、決してけっしてハードコードされた座標ざひょうではない。

2つのアップグレード、難度なんどは一桁ひとけた違う

• ホットアップデート：コードの位置いちだけを移しうつし、関数本体かんすうほんたいは変わらないかわらない → 前まえのバージョンのアンカーを変位へんいに合わせてあわせて全体平行移動ぜんたいへいこういどうすれば再利用さいりようできる。
• 小バージョン：関数本体かんすうほんたいを書き換えるかえる → 全体平行移動ぜんたいへいこういどうはすべて無効むこうになり、再度特定さいどとくていしなければならない。

同じ「アップグレード」でも、この2つではリバースの作業量さぎょうりょうが一桁ひとけた違う。

key を取るとる段差だんさが最ももっとも急きゅう

初期しょきバージョンでは、復号ふくごうに使うつかう key が識別しきべつできる形かたちでプロセスのメモリに残されてのこされていた。そのため、多くの「読み取りよみとりだけ」のツールは、メモリをスキャンするだけで key を取得しゅとくできた。新しいバージョンはこの道みちを塞いだふさいだ——すべての「純粋じゅんすいなメモリスキャン」による key 取得方法しゅとくほうほうが、一斉いっせいにゼロへ戻されたもどされた。

結論けつろんはとても明快めいかいだ。key 取得しゅとくは「静的せいてきなメモリスキャン」から「実行時じっこうじの動的観察どうてきかんさつ」へと追い込まれおいこまれ、敷居しきいが急激きゅうげきに上がったあがった。この一刀いっとうで切り落とされたきりおとされたのは、コミュニティで最大さいだいの部類ぶるいに属するぞくするツールだった。

関数本体かんすうほんたいが書き換えられてかえられても、どうやって見分けるみわけるのか？

「呼び出し点よびだしてんのトポロジー」による。ある関数かんすうがどの子関数こかんすうを呼び出してよびだしているか、そしてそれぞれの呼び出し点よびだしてんが関数内かんすうないのどの相対位置そうたいいちにあるかは、関数本体かんすうほんたいそのものよりも、バージョンをまたいでずっと保守的ほしゅてきに残るのこる。

関数本体かんすうほんたいが派手はでにすっかり変わってかわっていても、呼び出し点よびだしてんの位置列いちれつが一つずつ対応たいおうできるなら、新バージョンでも同じ関数かんすうだと見分けられるみわけられる。これは「関数かんすうサイズで判定はんていする / オフセットで全体平行移動ぜんたいへいこういどうする」よりずっと安定あんていしている。後者こうしゃは関数本体かんすうほんたいの書き換えかえに遭うあうと役に立たなくやくにたたなくなるが、前者ぜんしゃは呼び出し構造よびだしこうぞうが残ってのこっているかぎり有効ゆうこうだ。

メタな教訓きょうくん

ハードコードされたアドレス、メモリ上じょうのリテラルに対するたいするスキャンは、どれも流砂りゅうさだ——次つぎのバージョンで洗い流されてあらいながされてしまう。生き残れるいきのこれるのは、構造こうぞうの不変条件ふへんじょうけん（呼び出しよびだしトポロジー、命令めいれいパターン）と**動的観察どうてきかんさつ**だけだ。

ターゲットが強化きょうかされているなら、リバースも「座標ざひょうを探すさがす」ことから「不変条件ふへんじょうけんを探すさがす」ことへ進化しんかしなければならない。