解析の為のアセンブラ その２

強固なシェアウェアへの道

現在シェアウェアはたくさん出回っていますが，大抵のもの(しょぼいのを除く)はクラックされているのが現状です．

かくいう僕も昔シェアウェアを作りましたが，あっけなくクラックされパスワードが流出した覚えがあります．ということで今回はクラック対策を考えてみます．

敵を知るための下準備

とはいってもどうやって対策を立てるのでしょうか？
ここは，実践的に代表的なシェアウェアを解析してみることにします(crackじゃないよ)．

というわけで対象は超有名テキストエディタhide(匿名希望).exeでいきましょう(ごめんなさいっっ(^^;; )．

とりあえずdiswinで逆アセンブラします．
diswin -b -s filename.exe
でいけます．
このとき出力されるログもかなり重要なので忘れずにファイルにリダイレクトしておきましょう．

あとはテキストエディタ(wordpadでよい)とバイナリエディタとリソースエディタがあれば無敵です．ま，VCがあればそれであとは何もいりません(APIに関する知識が必要なのでVCは必須といっても良いかもしれない)．
さて，これで準備万端です．

いざ解析

で，解析するんですが，どこから手をつけていいのか困ります．
まさかプログラムの開始アドレスから順に探していくわけにもいかないです．
とりあえずは，解析の基点となるレジスト関連のダイアログのコードを見つけていくことにします．

手っ取り早いメッセージが間違った番号を入力したときに発生する
「送金代行番号または暗証番号に誤りがあります。」
でしょうか．このダイアログを開いている部分が分かればチェックしているルーチンもすぐ見つかりそうです．
VCでリソースを開いてみると，このストリングのIDは252と判明．もちろん文字列はリソースに埋めてあるとは限りませんので注意．

252 (=fdh)を代入している or pushなどしている場所を見つけることにします．
00fd(BYTE単位で検索すると死ぬ)で検索するといくつか引っかかりますが， 代入しているのはこの行だけ．


004212bc b9fd000000         mov     ecx,000000fd
004212c1 e865ab0000         call    0042be2b
004212c6 eb0f               jmp     short 4212d7

call 0042be2b がMessageBoxを呼ぶ処理をしていればいいんですが．
トレースすると見事にMessageBoxを呼んでいます．
ということはこれはパスワード入力失敗時に呼ばれるコードと確定してよいでしょう．
そのコードを呼んでいるのは少し上にあります．


004212ad ff15acc94600       call    dword ptr [KERNEL32.lstrcmpiA]
004212b3 85c0               test    eax,eax
004212b5 7505               jnz     4212bc

あーもろそれっぽい条件分岐だし(笑
とりあえずこのルーチンの先頭を探すと004211e7．
それを呼び出しているところを探します．


004213cc 53                 push    ebx
004213cd bae7114200         mov     edx,004211e7
004213d2 b9b1000000         mov     ecx,000000b1
004213d7 e89d8d0000         call    0042a179
004213dc 83f801             cmp     eax,+01
004213df 7505               jnz     4213e6
004213e1 e83fea0000         call    0042fe25

ここからひとつだけ参照しているところが見つかりました．
しかもedxに代入しているだけで呼び出してはいません．
じゃあ call 0042a179 が怪しい．
というわけで調べると何やらDialogBoxを開くらしい．
ならb1h(=177)はダイアログIDかな?

調べてみるとビンゴ，送金の確認ID．それっぽいです．
004211e7はそのウィンドウプロシージャだったようです．
ウィンドウプロシージャとして見ていくと，色々分かります．
とりあえず番号チェックでしょ，それから笑える処理が...(以下検閲により削除)．
気合(?)入っているなあ(笑

call後に注目すると戻り値1で何やらcallしているようです．
送金確認ダイアログから1(TRUE)が返ってきて呼ばれるもの．それは...
言わなくても分かりますよね．
まあ触りだけ見ておきましょう．


0042fe25 6a01               push    +01
0042fe27 58                 pop     eax
0042fe28 50                 push    eax
0042fe29 689cad4500         push    0045ad9c
0042fe2e a3fc3a4600         mov     [00463afc],eax
0042fe33 e8cdcfffff         call    0042ce05

0045ad9cをpushして0042ce05をcallしています．
0042ce05を読むとどうやらレジストリを開いているようです．
ということはこれ以降は...(やばいなあ)
じゃあ0045ad9cって何でしょう．
これはdiswinが吐き出したメッセージにヒントがあります．


section : .data
    Virtual size          =   11b94
    Virtual address       =   5a000
    Size of raw data      =    5200
* Writing binfile: hide03.bin  ...

この5a000に注目．ベースが400000なのでつまりは4da000から11b94バイトのダンプがhide03.binなわけです．よってそのファイルをバイナリエディタで覗くと.."Env"．うわそれっぽい(汗

あとは


mov     [00463afc],eax

という1を代入しているのが怪しいです．
もしかしてなんかのフラグ?

こういうときは00463afcで検索をかけます．
なんかそれっぽいところがいくつか．
一番顕著に分かるのが，


0040a792 833dfc3a460000     cmp     dword ptr [00463afc],+00
0040a799 7468               jz      40a803
以下


ですね．
調べると分かりますが，AboutBoxのWM_INITDIALOGにあたる部分です．
登録前後でAboutBoxのコントロールが変化するのは予想がつくでしょう．
そのことからもコントロールIDを頼りにここを見つけ出すことが出来ます．
その場合APIが並んでいるので分かりやすいですし，最初から00463afcが分かるので結構手っ取り早いです．

(実は最初はここを基点に解析しました．解説も自分が解析したとおりに書き始めようかと思ったけど，
最初は簡単なMessageBoxからがいいかなあ，と思ってやりはじめたら，ここまできてしまった)


とりあえずこれ以上やるとまずいのでここまでにしておきます．

結局対策は？

分かったこと．

• GUI，とりわけDialogに注目すると解析の糸口がすぐ見つかってしまう．
  特にResourceのIDで検索かけると効果的．
• 見つかればあとは野となれ山となれ．
ですね(じゃねー)．

とりわけバイナリ弄りでのクラックは楽でしょう．
パス確認ルーチン解析となるとちょっと面倒そうですが...
VBとか逆アセではどうにもなりそうにもないのはどうなるのか知りません．


じゃあ，どう対処するのか．

登録関係にリソースはなるべく使わない．もしくはリソースの暗号化を行う．
リソースの暗号化は昔InsideWindowsに載ってたような気がします．
まあ，面倒でしょうけど．

しかし，これを行うとかなり解析は大変になるんじゃないでしょうか．
まず暗号を外すところから解析する必要があるので．

だけどデバッガ使って実行して解除された状態でリソースダンプされたら一巻の終わりかな?
じゃあ，使うときだけ暗号を解く...のがいいですね．その場合リソースでやるときつそうですが．
とにかく解析の基点を与えないようにはGUI関係のID等を全て隠蔽するのがいいと思いました．
デバッガも使ってくるでしょうから，その対処も必要です．

が，もしDialog関係の呼び出しアドレスなどをフックされたら間違い無く 呼び出し先アドレスが割れて解析の基点ができそうです．
普通のデバッガで追えないようなアクロバット(VxD関係とかデバッグレジスタとか)でその辺の処理を行うのもひとつの手かもしれませんが，ウイルスまがいなのでやめといたほうがよいでしょう(^^; どっちにしろ解析されそうだし．

自己書き換えも惑わすのには有効かな．どこからも参照されていないコードが作れるわけで，いいかも．だけどまともな逆アセをかますとばれそうですね．

それプラスコードの暗号化とか．データセグメントに暗号化した再配置可能なコードを入れておいて必要なときだけ展開+ロード，実行後はまた元に戻す．だめかな．
その部分だけ仮想CPUで動かすのもいいかもしれません(ぉ

それとバイナリ書き換えに対応する自分自身のCRCチェックは必須かも．
ウイルス対策にもなるしね．
これもそのチェック部分から外されたらもう終わりだけど．

X68000のゲームソフトも結構こんなん外せるかー！？的なプロテクトがかかっていたけど 結局全部誰かに外されていたし，まあ，仕方ないのかな．

あと，他に解析したことないので，多分気合の入っている奴は僕には想像もつかないことをしているのでしょう．bleemとか．そういうのを解析して参考にすると良いかもしれません(ぐは)．

ってそんな終わり方じゃいけないので，誰か誰にもクラックできないシステムを考えましょう．がんばって！！
終わり(ぉ

もうちょっとだけ解析

暇なので当り触りの無さそうな解析を続けますか．

さらに他のDialogから解析を試みましょう．
とりあえず登録部分の概要を知るために，登録方法の選択Dialogを探します．
IDは195(=C3h)です．
探すとそれっぽいのが2つ見つかります．後から見つかるほうは良く分からんので
まずは最初に見つかった


004212f7 bad8104200         mov     edx,004210d8
004212fc 53                 push    ebx
004212fd b9c3000000         mov     ecx,000000c3
00421302 e8728e0000         call    0042a179

を見ましょう．
42a179はダイアログを開くルーチンでしたね．
ということは，あたりのようです(後のほうもあたりである可能性もあるが)．
4210d8はそのダイアログのウィンドウプロシージャということになります．
で，調べていくとどうやらチェックされたボタン(Radio)のIDを返すようです．

で，そのIDに従って処理を振り分けています．
"まだ使い込んで..."だと無条件にリターン
"使い込んだけど..."以外だと0042136c以下のそれぞれの確認ルーチンへ，
"使い込んだけど..."だと警告ダイアログでOKが押されるまでダイアログ+スリープの刑．うーん良心的．




00421381 81fe2a010000       cmp     esi,0000012a

で特別免除か判定．
以下"本当ですか？"ダイアログが開き，チェックを行う．
その後を辿れば0042fe25がcallされているのが確認できます．

普通の登録では 番号を00452f80でチェック，と．

421xxx付近にそれ系のルーチンが固まっていますねえ．


あと，なんでこんなのを書いているかというと研修が無茶苦茶暇なのであった．
仕事が早く終わりすぎて持て余しすぎ．
あるのはVCだけ．
となると解析しかないな〜って感じです．
ぐは


ああ，それからアドレスだとかリソースIDなんてのはビルド毎に変わると思って良いでしょう．
よってこのデータを使って手持ちの同ソフトを解析しようとしても多分無理です．
(同じ手は通用すると思うけどね^^;)

この鬼のようなクラック対策を見よ(Reget編)

調子に乗って家に帰ってから ReGet Free Beta version 1.5 (build 416) の 解析を試みました．

まずはdiswinで逆アセっと．
が，なんとソースコードが１行たりとも出てきません．
てめーはCIHかッ，てな感じですが，諦めずにdasmでも挑戦．結果は同じ．
仕方ないのでEntry Pointを見てみると...

Address of entry point =0xa4000

ちなみにコードセグメントの開始アドレス,サイズは
Virtual address = 1000
Virtual size = 44000
です．がーーん，EntryPointがコードセグメント外ですかい．データセグメントのバイナリを実行しているのね〜
具体的には5番目に生成されるreget05.binです．
こいつを逆アセするのですが..diswinでのやり方がよく分からなかったので，
dasmでreget05.binを逆アセ．
コード出てきました．
ぐは，初っ端からCIHを連想させるマニアックさ．

えーと．

・・・・・・・・．

凄いです．
なんというかシェアウェアの鑑というか，このスタートアップ部分はフルアセンブラでしょうねえ．

最小限のLoadLibrary,GetProcAddress,GetModuleHandleしかimportしていないので，
まずはVirtualAlloc,VirtualFreeをkernel32.dllからロード．
で，何をするかと思えばメモリ確保していきなりデータ展開．
そして自分のコードの直後ろ(EntryPointのcbh byte後ろ)に展開後のデータをコピー．
展開が終わると自動的にそのコードになだれ込んで，なんとまた展開．
もう，ぐはあ，って感じでそれ以上見てませんが，こりゃ大変ですよ．
リソースも当然と言うべくして，リソースエディタでは開けません．
とりあえずさっき解析したEXEの段階に持っていくまでに相当苦労しなくてはだめです．

面倒なのでこれ以上は解析してませんが，デバッガは必須です．
展開後のデータを取るときとか無いとかなり辛いでしょう．

というかデバッガで追っても分け分かりませんでしたが(ぷ
どうなってんじゃこりゃ？というくらい複雑にEIPは変化し，自己展開が続きます．
うーん凄いね．だけど若干展開ルーチン回りに汎用臭さが有る気がしたんだけどその部分だけmodule化してあるのかな．いやそれよりもどうやって何でリンクしているんだろう??

とにかく，まじでトリッキーなので一度見てみるべし！(おいおい)


しかしこれだとクラック対策にも相当の金が掛かってるような(^^;
送金したお金の40%はクラック対策費です．っていや〜ん(ぉ