Automatic pointer calculation function ROM analysis using FEBuilderGBA (for hacker)

FEBuilderGBA is a tool to easily modify GBAFE,
It can also help those who want to analyze the code seriously.

This time, we will introduce the pointer automatic calculation function which can automatically convert function address of FE8 to function address of FE6.

FEBuilderGBA has function and data address porting function.
By using this function, the function address of FE6 can be obtained from the function address of FE8J.

For example, let's look for a function that decompresses LZ77 compressed data.
Through analysis of the predecessors, we know that the location of this function is the following.
Let's let FEBuiderGBA do it automatically.

FE8
08013008	AutoCopyOrDecompressImageToVRAM	void	r0:Compressed data.	r1:Decompression place.	{J}
08012f50	AutoCopyOrDecompressImageToVRAM	void	r0:Compressed data.	r1:Decompression place.	{U}

FE7
08013688	AutoCopyOrDecompressImageToVRAM	void	r0:Compressed data.	r1:Decompression place.	{J}
08013168	AutoCopyOrDecompressImageToVRAM	void	r0:Compressed data.	r1:Decompression place.	{U}

FE6
08013ca4	AutoCopyOrDecompressImageToVRAM	void	r0:Compressed data.	r1:Decompression place.	{J}

First of all, let's find out the LZ77 decompression function of FE8U from the LZ77 decompression function 08013008 of FE8J.

First, open the ROM of FE8J.

Select Tools → Pointer Calculator from the menu.

The pointer calculation tool is started.

Insert the LZ77 decompression function 08013008 of FE8J into the address.

Next, click “Read another ROM” button to open the ROM of FE8U.

Then, the comparison is done automatically …

The number 08012F50 was displayed.
This number is the same as the value of LZ77 decompression function 08012F50 of FE8U.

How exactly is it realized?
This is realized by performing a binary comparison.
It is made from the hypothesis that processing similar to that function should have similar assembly code.

Of course, there are times when I make mistakes, but I will tell you the correct answer with considerable accuracy.
(MAP files are not used for binary comparison. It detects only by binary comparison.)

If you want to search again, please press the enter key in the address field.

Let's find a similar function of FE6 this time.

Press the “Read another ROM” button to read the ROM of FE6.
Then, the comparison is done automatically …

umm, this time it did not work.
0xFFFFFFFF is displayed. It seems I could not find it.


In such a case, you can raise the level of the automatic tracking system.
By default, accuracy is emphasized.
If it is of the same generation ROM as FE8J → FE8U, this is fine, but if it exceeds generations like FE8J → FE6, the binary is somewhat different.
Therefore, you need to raise the auto tracking level at the expense of some accuracy.
Increasing the auto tracking level will make it match, even if somewhat ambiguous.

Let's do it right away.
Let's set the maximum tracking level 7 this time.



After changing tracking level, please press enter in the address text box to re-search.

When you press the enter key in the address text box, analysis starts.
This time, I increased tracking level, so it will take some time to compare.

This time, the number 08013CA4 was displayed.

This number is consistent with the number of LZ77 decompression function of FE6.
Yeah!. Automatically, from the function of FE8J, the address of the function of FE6 could be found.

It was found that ROM data can be tracked automatically.
So what about RAM data?

FE8
0202BCEC	Area of the stage.	{J}
0202BCF0	Area of the stage.	{U}

Until now it was not tracking, but the search function was newly implemented from the reference value.
Let's do it at once.

Let's search the stage area of FE8U from the area 0202BCEC of the stage of FE8J.

In the address text box, enter 0202BCEC.
Read “ROM of FE8U” with “Read another ROM”.

Then, the search is done automatically ・ ・ ・

A number of 0202BCF0 was displayed.
This is consistent with the figures in the area of the stage of FE8U.
I could also search the RAM area.

This is a technique using LDR reference.
The algorithm is as follows.

1. Find the part of LDR referencing the number specified in the original ROM.
↓
2. It goes back to the function prologue there.(To increase the room to search).
↓
3. Record the number of bytes that go back ..
↓
4. It checks whether or not the function exists in the target ROM.
↓
5. If there is a function in the partner ROM, address is added to that address by the number of bytes backwards.
↓
6. See if the added location is an LDR reference.
↓
7. In case of LDR reference, adopt its value ..

Again this is an algorithm derived from the hypothesis that the source code will be similar if the processing is similar.
Since the RAM pointer, it can not be searched,
but, Since the code calling it is ROM data, we can search.

And the code is mostly similar if the process is the same.

Changing the search options allows you to make more detailed comparisons manually.
In automatic tracking, we will only track to some extent in order to avoid false positives.
If you want to track at a deeper level, you can change the setting manually.

Specify the binary size to compare.
Naturally, the smaller one is easy to match.
However, if it is too small, the possibility of erroneous judgment will be higher.
It is important to use comparison sizes as long as possible.

Set whether you want to find ASM function or data.
This is used for the next pattern match.

In case of exact match, only completely matched data like memcmp will be detected.
In case of pattern matching, we will perform a match using “?” Wild card in part.

Pattern match data will change depending on what you set in “Contents”.
In the case of data, wildcards can replace parts that are supposed to be pointers up to 0x08000000 - 0x0A000000.
Pointers are different if ROMs are different, so ignore this and compare them to increase the possibility of matching.

For ASM, wildcards replace LDR and BL calls.
Depending on the ROM, the LDR direct data and the BL call are different, and some structures may have different offset values.
Therefore, convert them to wildcards and match.

Ignore the specified byte and search.
For alignment adjustment, the compiler embeds NOPs, and the number of registers pushed in push generated by prolog depends on version depending on version.
Ignore these and search.

It is troublesome to try these search options manually by hand, so it automatically searches by adjusting the options.
Originally I adjusted the search options manually, started from a strict examination, but still had a vague comparison unless I found it, but it was developed because it was troublesome.
By using this, we will automatically compare by just pressing the enter key.

It is a newly added function.
The default is to “ignore warnings if reference” at the middle level.
To avoid an incorrect match, a warning is displayed if it matches a different address than the original ROM too much, or if it matches an area with a lot of zeros.
This is a setting as to whether to regard the match that warned as success when searching by the automatic tracking system.
If we regard it as a successful match, we will not search after that.

If you want to convert addresses at once, it is troublesome to copy them by hand.
It's fine if you have ten, but it's a tough job to look up 100 addresses to make a wide range of matches.

Therefore, when pasted in tsv format or the like, we created a function that automatically finds function address-like parts and obtains addresses.
This is a batch processing batch.

Make data with tsv format or the like, copy it and press the button.

080D4E34	MPlayContinue	{J}
080D4E50	MPlayFadeOut	{J}
080D4E70	m4aSoundInit	{J}
080D4EE8	m4aSoundMain	{J}
080D4EF4	m4aSongNumStart	{J}
↓↓↓↓Conversion result.↓↓↓↓
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}

It is a function not related to address match.
Suppose you are chasing the ROM with a debugger and you are at an address such as 0x085C5528 which you do not know well.
What on earth is this address?
There are times when I doubt.

It is troublesome to search for materials each time.

In the address column, enter the address you want to check, and press the “Type of address type” button.
If it is an area known by FEBuilderGBA, the name of that area will be displayed.

Since the name displayed is for debugging the function for repoint, it is a simple one, but it is a hint.
Incidentally, 0x085C5528, if you ask something, you get the answer that it is “MenuDef4”.



0x085C5528 was the address of some area of the debug menu on FE8J.
It is the fourth menu from the top so MenuDef 4 is displayed.