the catcher in the lie

ソフトウェアの原子構造とも言える機械語を読み解いてそこから逆に作っていこうという考え方の
リバース・エンジニアリングの観点から今回は"逆アセンブラ"に挑戦してみたので記録として

機械語(以下、バイナリコード)を読み解くには色々なソフトがあるらしい。
今回は、ど定番中のド定番　Stirling を使ってみた。

 Stirlingの面構えはこんな感じ。
もうすでに2つのファイルを開いてある。

今回のミッションは１つ
　１つ、改変されたデータをバイナリレベルで生データと比較し改変方法を理解する。
Stirlingには２つのファイルを比較するのに適した機能を有している。
検索・移動　→　比較　を選択する
 逆アセンブリを行うとやっぱり記述が全然違う。 
８、12、14行目ではデータをレジスタにロードしているようだ。　

8行目を見ると　
06 83 というコードで　ld b,83 という命令らしい　(レジスタbに83をloadする？)
※そもそも83ってのがなんだかわからない　データなのかそれともアドレスなのか・・・・。
0x06=0b 0000 0110 どれかのビットで1が経つと命令、レジスタを指定しているのか・・・

14行目を見ると
26 56 というコードで　ld h,56 という命令らしい
 0x26=0b0010 0110  ?????

どういうビットパターンの場合でどういう命令になっているかはわからなかった。
しかし　命令コード　＋　データコード　という構造で記述されていることは理解した。
もとのバイナリコードを見てみると
 逆アセンブリして8,12,14行目に記述されていた命令がやっぱりバイナリコードにも記述されていることがわかる。　　　
ここからは仮設だか、汎用レジスタに行き先のアドレスがloadされているのなら
改変(ぶっちゃけ暗号化)されたファイルのアセンブリコードをトレースしながら実行していき
どこかでループしている箇所を突き止め　ループに入るアドレスを書き換えることが出来るのなら
改変を回避することが出来るかもしれない。

まとめると
バイナリコードを確認する
逆アセンブリを実行してアセンブリコードを得る
アセンブリコードを見ながらソフトもしくは机上トレース(鬼畜かも？)を行いループ箇所などを突き止める
正規のルートから外れてループに入る前のアドレスを書き換える
突き止めたアドレスをStirlingを使って書き換える。
ループ回避で正常動作なのでは？　
 
簡単に書いたけれど"トレース"が結構鬼門。
とりあえず。まとめて書いてみた。