  |
「プロテクトかけたアルゴリズムを実装したバージョンに差し替え」たなんて言われると本当に「プロテクト」がかかっているのか確かめてみたくなるのが人情というもの。というわけで、プロテクト強化後のもふったー(v0.9.6b)からconsumersecretが抜けるか試してみた。結論から言うと、あっけなく取り出せた。以下に手順を記す。
動作がよくわかっていないアプリケーションを解析して仕様を明らかにすることをリバースエンジニアリングと呼ぶ。ソフトウェアのリバースエンジニアリングは基本的に対象を逆アセンブルしてひたすら読むことによって行う(その補助に1命令ずつ実行してレジスターやメモリーの様子を観察することもある)。しかし、よっぽど小規模なものでなければオブジェクトコード全体を逆アセンブルして最初から最後まで読むなんてのは不可能だ。人間の読速度には限界があるし、時間も有限だからだ。そして、詳しい動作を知りたい部分というのは全体のごく一部であることが多いので全逆アセンブリを読むのには非常に無駄が多い。
だから、リバースエンジニアリングではいかに詳らかにすべき動作を行っているコードを絞り込むか(=読むべき逆アセンブリを少なくするか)が重要になる。
この場合も同様だ。TwitterのGUIクライアントを頭から読むのは到底無理なので、どうやって解析すべきコードの範囲を狭めるかを考えた。それにはOAuth認証においてconsumersecretがどのような役割を果たすのかを知る必要がある。
OAuth認証で、consumersecretはそのままサーバーに送信されたりはしない。signatureの生成にHMAC-SHA1が使われ、その鍵にconsumersecretが使われる。HMACは次のように算出される。
HMAC (K,m) = H ((K ⊕ opad) ∥ H ((K ⊕ipad) ∥ m))
ここで
である。
まずはこのあたりから攻めようと思った。SHA-1の計算にはいくつか特徴的な定数が使われるので、そこからSHA-1の計算に使われているであろう関数444190を特定する。この関数のエントリーポイントに中断点(ブレークポイント)を設定してOAuth認証をさせるべくもふったーの「ブラウザで認証」ボタンを押す。狙い通り中断するので関数を抜けるまで実行する。関数401100の4012DAに出た。少し下を見るとこのようになっている。
CPU DisasmAddress HexdumpCommand Comments00401311 |.33F6xor esi, esi00401313 | 8D8C24 A40000 /lea ecx, [local.54]0040131A |. 394C24 14 |cmp dword ptrss:[local.90], ecx0040131E |. 75 0E |jne short 0040132E00401320 |.3BF5 |cmp esi,ebp00401322 |. 73 29 |jae short 0040134D00401324 |. 0FB68434 A400 |movzx eax,byte ptrss:[esi+esp+0A4]0040132C |. EB 21 |jmp short 0040134F0040132E |3BF5 |cmp esi,ebp00401330 |. 731B |jae short 0040134D00401332 |. 8B5424 18 |mov edx, dword ptrss:[local.89]00401336 |. 52 |push edx ; /Arg1 = [LOCAL.89]00401337 |. 8D8C24 FC0000 |lea ecx, [local.33] ; |0040133E |. 8BD6 |mov edx, esi ; |00401340 |. E8 CB4D0000 |call 00406110 ; \mofooter.0040611000401345 |. 83C4 04 |addesp, 400401348 |. 0FB6C0 |movzx eax, al0040134B |. EB 02 |jmp short 0040134F0040134D |33C0 |xor eax, eax0040134F | 34 5C |xor al, 5C00401351 |. 888434 B80000 |movbyte ptrss:[esi+esp+0B8], al00401358 |. 83C6 01 |add esi, 10040135B |. 83FE 40 |cmp esi, 400040135E |.^ 72 B3 \jb short 0040131300401360 |. 895C24 3C mov dword ptrss:[local.80], ebx
0040134F | 34 5C |xor al, 5C
が注意を引く。もしかしてこれはopadとのxorではないか?
00401351 |. 888434 B80000 |movbyte ptrss:[esi+esp+0B8], al
はxorした結果を格納している。
先ほどの中断点は無効化しこのループを抜けた地点である401360まで飛ばす。この時点でesp+0B8を見ると次のようになっている。
Hexdump64 2E 16 64|37 04 32 6D|0F 0D 26 29|3A 37 1F 2F|18 69 6E 6E|0D 25 2933|11 34 29 69|12 3624 1E|05 1633 6A|043B 0E 68|7A 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|
あとはこれと5Cとをxorすればconsumersecretが手に入る。終わり。
はてなは増田のスーパーpre記法で半角の＜＞が含まれていると投稿が出来ないのを早く直してください。
もふったーの作者から反応があった。「本気だったつもりのもふったーのデバッグ処理が残ってた」らしい(http://blog.livedoor.jp/blackwingcat/archives/1763951.html)。修正したとのことなので最新版(v0.9.6e)を見てみた。確かに若干変更されているが何の問題もない。SHA-1の呼び出しに中断点を設置して渡されているバイト列を見るだけ。
CPU DisasmAddress HexdumpCommand Comments00401324 |. 8D442420 |lea eax, [local.102]00401328 |. 50 |push eax ; /Arg1 = 00401329 |. E8 623A0400 |call 00444D90 ; \mofooter.00444D90
ここでeaxが指すメモリーを見ると以下のようになっている。
0123 45 67|89 ABCDEF|FEDCBA 98|76 54 3210|F0 E1D2C3|00 02 00 00|00 00 00 00|40 00 00 00|40 4F 73 53|62 54 5C 7E|59 57 53 42|55 45 7A 57|61 47 7A 5B|42 4F 7B 61|5D 66 5E 7A|42 7F 40 63|79 66 05 55|79 4C 60 42|0210 36 36|36 36 36 36|36 36 36 36|36 36 36 36|36 36 36 36|36 36 36 36|
http://anond.hatelabo.jp/20130323004725 SHA1 の入り口にブレーク張られて THE END か。 だいたい SHA1 みたいなルーチンってできあいのもの使ってるからこういう風に抜き出されたら対応不可能な気が...
http://anond.hatelabo.jp/20130323004725 SHA1 の入り口にブレーク張られて THE END か。だいたい SHA1 みたいなルーチンってできあいのもの使ってるからこういう風に抜き出されたら対応不可能な気が...
http://anond.hatelabo.jp/20130323004725 SHA1 の入り口にブレーク張られて THE END か。だいたい SHA1 みたいなルーチンってできあいのもの使ってるからこういう風に抜き出されたら対応不可能な気が...
http://anond.hatelabo.jp/20130323004725 SHA1 の入り口にブレーク張られて THE END か。だいたい SHA1 みたいなルーチンってできあいのもの使ってるからこういう風に抜き出されたら対応不可能な気が...
http://anond.hatelabo.jp/20130323004725 SHA1 の入り口にブレーク張られて THE END か。だいたい SHA1 みたいなルーチンってできあいのもの使ってるからこういう風に抜き出されたら対応不可能な気が...
http://anond.hatelabo.jp/20130323004725 SHA1 の入り口にブレーク張られて THE END か。だいたい SHA1 みたいなルーチンってできあいのもの使ってるからこういう風に抜き出されたら対応不可能な気が...
28