本格的にコードを解析したい方を手助けすることもできます。今回は、FE8の関数アドレスをFE6の関数アドレスに自動的に変換したりすることができる、ポインタの自動計算機能を紹介します。編集ポインタの自動計算機能FEBuilderGBAには、関数やデータアドレスの移植機能が搭載されています。この機能を使うと、FE8Jの関数アドレスから、FE7Uの関数アドレスを求めることができます。LZ77圧縮されたデータを解凍する関数を探してみましょう。先人たちの解析により、私たちは、この関数の場所が以下であることを知っています。FEBuiderGBAに自動的にやらせてみましょう。FE8UのLZ77解凍関数を求めてみましょう。編集StepA01まずは、FE8JのROMを開きます。編集StepA03ポインタ計算ツールが起動します。編集StepA05次に、“別ROM読込”ボタンをクリックして、FE8UのROMを開きます。いう数字が表示されました。魔法?いったいどうやって実現しているのでしょうか?これはバイナリ比較を行うことで実現しています。その関数と似たような処理は似たようなアセンブリコードを持っているはずだという仮説から作られています。間違うこともあるのですが、かなりの精度で正解を言い当ててくれます。(当然ですが、バイナリ比較には、MAPファイルを利用していません。)再度検索したい場合は、アドレスの項目でエンターキーを押してください。編集FE8JからFE6の関数を見つけるそれでは、今度は、FE6の同様の関数を見つけてみましょう。編集StepB01“別ROM読込”ボタンを押して、FE6のROMを読みこみます。編集StepB02おや、今度はうまくいきませんでした。見つからなかったようです。これがこのツールの限界なのでしょうか?そんなことはありません。自動追跡システムのレベルを上げればよいのです。ディフォルトでは、正確さを重視しています。FE8J→FE8Uのような同世代のROMならば、これでもいいのですが、FE8J→FE6のような世代を超える場合は、バイナリが多少違います。そのため、多少の正確性を犠牲にして、自動追尾レベルを上げる必要があります。自動追尾レベルを上げると、曖昧でもマッチするようになります。編集StepB03とりあえず、早速やってみましょう。今回は、最大の追跡レベル7にしてしみましょう。追跡レベルを変更したあとは、再検索をするために、アドレスのテキストボックスでエンターを押してください。編集StepB04アドレスのテキストボックスでエンターキーを押すと、解析が開始されます。今回は、追跡レベルを上げたので、比較に少し時間がかかります。編集StepB05今回は、08013CA4という数字が表示されました。この数字は、FE6のLZ77解凍関数の数字と一致しています。自動的に、FE8Jの関数から、FE6の関数のアドレスを見つけることができました。編集データ追尾機能ROMのデータを自動的に追跡できることがわかりました。それでは、RAMのデータはどうでしょうか?FE80202BCECステージの領域{J}0202BCF0ステージの領域{U}今までは追跡でませんでしたが、新しく参照値から検索機能が実装されました。FE8Uのステージの領域を検索してみましょう。編集StepC01アドレスのテキストボックスに、0202BCECと入力します。“別ROM読込”でFE8UのROMを読みこみます。編集StepC030202BCF0という数字が表示されました。これは、FE8Uのステージの領域の数字と一致しています。RAM領域も検索することできてしまいました。魔法?これはLDR参照を利用した技です。アルゴリズムは以下の通りです。そこから関数のプロローグまでさかのぼる。相手ROMに関数があった場合、そのアドレスに、先ほどさかのぼったバイト数をアドレス加算する。LDR参照だった場合、その値を採用する.これもまた、処理が似ているならソースコードも似ているだろうという仮説から由来するアルゴリズムです。LDR値はRAMポインタですから、検索することができませんが、それを呼び出しているコードはROMデータですから、検索することができます。コードは処理が同じならたいてい似ているものです。検索オプション検索オプションを変更すると、手動でもっと細かい比較をすることができます。自動追跡では誤判定をさけるために、ある程度のところまでしか追跡しません。深いレベルで追跡したい場合は、手動で設定を変えることができます。比較サイズ比較するバイナリサイズを指定します。当然ですが、小さい方がマッチしやすいです。小さすぎると誤判定の可能性がより高まります。長い比較サイズを利用することが大切です。探したいものが、ASM関数なのか、データなのかを設定します。ように完全にマッチしたデータのみが検出されます。一部に?ワイルドカードを利用したマッチを行います。パターンマッチデータは、“内容”で設定したもので変わります。ポインタと思われる部分がワイルドカードに置き換われます。ポインタはROMが違えば違うので、ここを無視して比較することで、マッチする可能性を高めます。ASMの場合は、LDR参照やBL呼び出しがワイルドカードに置き換わります。ROMによって、LDR直値のデータや、BL呼び出しは違いますし、中には、構造体のオフセット値が違う場合があります。そのため、これらをワイルドカードに変換してマッチさせます。指定したバイトをジャンプし無視して検索します。push時にpushされるレジスタの数が違ったりします。これらを無視して検索します。自動追跡システムこれらの検索オプションを手でいちいち試すのは面倒なので、自動で勝手にオプションを調整して検索してくれるモードです。本来は手動で検索オプションを調整して、厳格な検査からスタートして、それでも見つからなければ曖昧な比較としていっていたのですが、面倒になったため開発されました。これを利用することで、エンターキー押すだけで自動的に比較してくれます。警告システム新しく追加した機能です。ディフォルトは、真ん中のレベルの“参照あれば警告を無視する”です。間違ったマッチを避けるために、あまりに元ROMと異なるアドレスとマッチしたり、ゼロがたくさんある領域とマッチしたときは警告を表示します。自動追跡システムで検索したときに、この警告が出たマッチを、成功とみなすかどうかの設定です。マッチ成功とみなせば、それ以降の検索をしません。警告があれば、マッチしなかったものとします。警告があったとしても、そのアドレスへの参照が取れれば、マッチしたとみなします。警告が出たとしても、マッチしたとみなします。一括処理バッチまとめてアドレスの変換をやりたい場合、手でいちいちコピペするのは面倒です。そこで、tsv形式とかで張り付けると、関数アドレスぽいところを自動で検出して、アドレスを求めてくれる機能を作りました。編集StepD01tsv形式とかでデータを作り、コピペしてボタンを押すだけです。080D4E34(FFFFFFFF->FFFFFFFF,FFFFFFFF->080D013C)MPlayContinue{J}080D4E50(FFFFFFFF->FFFFFFFF,FFFFFFFF->080D0158)MPlayFadeOut{J}080D4E70(FFFFFFFF->FFFFFFFF,FFFFFFFF->080D0178)m4aSoundInit{J}080D4EE8(FFFFFFFF->FFFFFFFF,0029B4C8->080D01F0)m4aSoundMain{J}080D4EF4(FFFFFFFF->FFFFFFFF,FFFFFFFF->080D01FC)m4aSongNumStart{J}編集アドレスの種類判定アドレスマッチとは関係ない機能です。等のアドレスにであったとします。これは何のデータなのか?疑問に思うときがあります。そんなとき、いちいち資料を探すのは面倒です。アドレスの欄に、あなたが調べたいアドレスを入れて、“アドレスの種類判別”ボタンを押してください。FEBuilderGBAが知っている領域であれば、その領域の名前が表示されます。この名前は、repoint用機能のデバッグ用に持っているデータなので、簡素なものですが、ヒントにはなります。ちなみに、0x085C5528は、何かと問い合わると、MenuDef4だという答えを得られます。0x085C5528は、デバッグメニューの一部の領域のアドレスでした。MenuDef4と表示されました。以前のリビジョンバックリンク文書の先頭へ。