FEBuilderGBA是一个易于修改GBAFE的工具、
也可以真正地帮助想分析代码的人。

这次，我来介绍一下将FE 8的函数地址自动转换到FE 6的函数地址。

FEBuilderGB中搭载了函数和数据地址的移植功能。
使用这个功能的话，可以从FE 8J的函数地址中寻求FE 7U的函数地址。


例如，试着寻找解压缩LZ77的数据的函数。。
根据前人的分析，我们知道这个函数的位置是以下。

FEBuiderGBA自动去做吧。

FE8
08013008	LZ77圧縮されているデータの解凍AutoCopyOrDecompressImageToVRAM	void	r0:圧縮データ	r1:解凍場所	{J}
08012f50	LZ77圧縮されているデータの解凍AutoCopyOrDecompressImageToVRAM	void	r0:圧縮データ	r1:解凍場所	{U}

FE7
08013688	LZ77圧縮されているデータの解凍AutoCopyOrDecompressImageToVRAM	void	r0:圧縮データ	r1:解凍場所	{J}
08013168	LZ77圧縮されているデータの解凍AutoCopyOrDecompressImageToVRAM	void	r0:圧縮データ	r1:解凍場所	{U}

FE6
08013ca4	LZ77圧縮されているデータの解凍AutoCopyOrDecompressImageToVRAM	void	r0:圧縮データ	r1:解凍場所	{J}

首先，我们来看看FE 8 J的LZ 77解压缩函数08013008中的一些小修改，以找到FE 8 U的LZ77解压缩函数。

首先打开FE8J的ROM。

从菜单中选择工具 →指针计算器。

指针计算工具启动。

将FE 8 J的LZ77解压缩功能08013008插入地址部分。

接下来，点击“另外的ROM读取”按钮打开FE 8U的ROM。

然后，会自动进行比较・・・・

08012F50 这个数字显示了。
该编号与FE 8U的LZ77解压缩功能08012F50的值相同。

到底是怎么实现的呢？？
这是通过进行二进制比较而实现的。
它是由这样的假设得出的，即类似于该函数的处理应该具有类似的汇编代码。


当然，有些时候我会犯错，但我会以相当精确的方式告诉你正确的答案。

(当然，我们不使用MAP文件进行二进制比较。)

如果您想再次搜索，请按地址栏中的回车键。

让我们来看看这次FE6的一个类似的功能。

按下“另外ROM读入”按钮读取FE 6的ROM。
于是，自动进行比较・・・・

哎呀，这次没能顺利进行。
0xFFFFFFFF 显示。好像找不到了。


这就是这种工具的界限吧？
不会的。

提高自动跟踪系统的水平就可以了。
默认情况下，我们重视准确性。
如果是像FE 8 J → FE 8 U那样的同代ROM，这很好，但是如果它超过了像FE 8 J → FE 6这样的世代，二进制就有些不同了。
因此，您需要提高自动跟踪级别，但要牺牲一些准确性。
即使含糊不清，增加自动跟踪级别也会使其匹配。

让我们马上去做。
我们这次设置最大跟踪级别7。

更改跟踪级别后，请在地址文本框中按回车键重新搜索。

在地址文本框中按下回车键将开始解析。
这一次，我增加了跟踪级别，因此需要一些时间进行比较。

这次显示了编号08013CA4。
这个数字与FE 6的LZ77减压功能的数量一致。

我做到了。 从FE 8 J的功能自动地，可以找到FE 6功能的地址。

发现可以自动跟踪ROM数据。
那么RAM数据呢？？

FE8
0202BCEC	ステージの領域	{J}
0202BCF0	ステージの領域	{U}

到目前为止，它并没有进行跟踪，但搜索功能是从参考值新实现的。
我们现在就做。

我们从FE 8 J阶段的0202 BCEC区域搜索FE 8 U的阶段区域。

在地址文本框中输入0202BCEC。
然后用“另外ROM读入”读取FE8U的ROM。

然后，自动搜索完成・・・・

显示了0202BCF0这个数字。
这与FE 8U阶段的数字一致。
我也可以搜索RAM区域。

这是一种使用LDR参考的技术。
该算法如下。

1. 查找引用原始ROM中指定的编号的LDR部分
↓
2. 从那里追溯到函数的序言。（为了增加搜索的余地）
↓
3. 以前的字节数记录
↓
4. 检查功能是否在伙伴ROM中
↓
5. 如果在伙伴ROM中有一个功能，

地址就会反向添加到地址字节中。

↓
6. 看看添加的地方是否是LDR参考
↓
7. 当它是LDR参考时，其值被采用

再次，这是一个算法，它源于假设，如果处理过程类似，源代码将是相似的。

由于LDR值是RAM指针，因此无法搜索、
由于调用它的代码是ROM数据，因此您可以搜索。
如果过程相同，代码大多相似。

如果更改搜索选项，可以手动进行更细致的比较。
在自动跟踪中，为了避免误报，我们仅在一定程度上进行跟踪。
如果您想深入追踪，可以手动更改设置。

指定要比较的二进制大小。
当然，小一点很容易匹配。 但是，如果它太小，错误判断的可能性会更高。

尽量使用较长的比较尺寸是很重要的。

设置是否搜索ASM功能或数据。
这将用于下一个模式匹配。

在完全匹配的情况下，只会检测到完全匹配的数据，如memcmp。
在模式匹配的情况下，我们将部分使用通配符进行匹配。

模式匹配数据将随您在“内容”中设置的内容而改变。
在数据的情况下，通配符可以替换应该是指针的部分，最多为0x08000000 - 0x0A000000。
如果ROM不同，指针是不同的，所以在这里忽略并比较它可以提高匹配的可能性。


对于ASM，通配符替换LDR参考和BL调用。
根据ROM，LDR直接数据和BL调用是不同的，并且在某些情况下结构的偏移值可能不同。

所以将它们转换为通配符并匹配。

忽略指定的字节并搜索。
为了进行对齐调整，编译器嵌入NOP，并且在由prolog生成的push时推送的寄存器数取决于取决于版本。
忽略这些并搜索。

手动尝试这些搜索选项是很麻烦的，所以它通过任意调整选项自动搜索选项。

本来，我调整了手动搜索选项，从严格的考试开始，但是如果我仍然找不到它的含混比较，但是它的开发是因为它很麻烦。

通过使用它，只需按下回车键即可自动进行比较。

这是一个新增功能。
默认设置是在中等水平“忽略警告如果有参考”。
为避免不匹配，如果与原始ROM中的地址匹配太多，或者与大量零的区域匹配，则会显示警告。
是否将自动跟踪系统搜索时作为成功警告的匹配作为设定。

如果我们认为这是一场成功的比赛，那么我们不会在那之后进行搜索。

如果您想一次转换地址，手工复制它们是很麻烦的。
所以，当以tsv格式或类似的格式粘贴时，我们创建了一个自动查找函数类地址部分并获取地址的函数。
这是一批处理。

只需用tsv格式创建数据，将其复制并按下按钮即可。

080D4E34	MPlayContinue	{J}
080D4E50	MPlayFadeOut	{J}
080D4E70	m4aSoundInit	{J}
080D4EE8	m4aSoundMain	{J}
080D4EF4	m4aSongNumStart	{J}
↓↓↓↓変換結果↓↓↓↓
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}

这是一个与地址匹配无关的功能。
假设你用调试器追踪ROM，并且你的地址是0x085C5528，但你不太清楚。

这些数据究竟是什么？
有些时候我怀疑它。

每次搜索资料都很麻烦。

请在地址栏中输入您想要查看的地址，请按“地址类型”按钮。

如果它是FEBuilderGBA已知的区域，则会显示该区域的名称。

这个名称是用于调试重新调试函数的数据，因此很简单，但它是一个提示。

顺便提一句，0x085C5528，如果你问一些问题，你会得到它是MenuDef4的答案。


0x085C5528是调试菜单某些区域的地址。
它是顶部的第四个菜单，因此显示MenuDef 4。