Pages: 1
Posted on 02-23-12, 12:47 am
Banned for being a complete idiot.

Karma: 529
Posts: 719/987
Since: 07-09-11
Hey I have two questions about Overlays:
1. Is the Overlay header 0x10402DE9? Because every Overlay I open has that as the first four bytes for whatever ROM region I open so far.
2. How are you suppose to tell where some stuff you're looking for is? Some Overlays are big, and is difficult to try to find what you want. Do you just modify random bytes in the Overlay and see what you get is what you want?
Posted on 02-23-12, 09:46 am


Karma: 3752
Posts: 948/2112
Since: 06-28-11
The second Point is also interesting for me. I had aleady an idea how to do it, but it does not work well.
Posted on 02-23-12, 12:22 pm
Super Mario
( ͡° ͜ʖ ͡°)

Karma: 9979
Posts: 1504/4456
Since: 06-08-11
Nope, overlays have no header. They're just a mix of code and data. The only way to understand the data is to look at the code in IDA Pro or another disassembler and have a look. And even then, it's not easy
Posted on 02-23-12, 03:44 pm
Banned for being a complete idiot.

Karma: 529
Posts: 720/987
Since: 07-09-11
Posted by Dirbaio
Nope, overlays have no header.

Then why does the overlays start with 0x10402DE9?

Posted by Dirbaio
The only way to understand the data is to look at the code in IDA Pro or another disassembler and have a look. And even then, it's not easy

...
I guess that means we have to be really determined in order to find what we want then.
Posted on 02-23-12, 09:12 pm
Fuzzy
Full mod

Karma: 1183
Posts: 389/785
Since: 06-28-11
You could try modifying random bytes (AKA corruption), but this won't usually work because there is data and code. Likely if you modify some random bytes of code, then the ROM will crash.

Finding data in the overlays is just like finding data in older gen consoles that don't have a filesystem. You could try some of the techniques used on those, such as tracing RAM address reads or writes.
Posted on 02-25-12, 06:28 pm
Super Mario
( ͡° ͜ʖ ͡°)

Karma: 9979
Posts: 1505/4456
Since: 06-08-11
0x10402DE9 is just an ASM instruction. If all overlays start with that, it's just coincidence.
And it's in fact 0xE92D4010 because the DS is little-endian.

A good way of telling whether a bunch of data is code or not is to look at the first nybble. It's usually E because that's the condition field of the instruction, and most instructinons have the condition field "Always" which is 0xE

See http://nsmbhd.net/docs/gbatek.htm#armconditionfield.
Posted on 02-25-12, 07:07 pm
☭ coffee and cream


Karma: 10398
Posts: 205/2766
Since: 06-26-11
0xE92D4010 must be a STMDB instruction. Those are found at the beginning of (almost) every function in ARM assembly.

As for finding data in overlays, well... you can't just take an overlay and look for stuff in it. And more importantly, when you find something, you can't even be sure that its offset will be the same in all ROMs. Different versions of a ROM may have slight code changes in that overlay, and your data will be at another location. Generally not too far away, but you still need to take it into account. I experienced this with the first versions of SM64DSe. After having found the level headers, I extracted the level header address table from the ROM, subtracted the overlays's base RAM address from each address, and put that in the editor's code. It worked fine for the ROM version I was using (EUR), but it caused problems with other ROM versions, namely, trying to open some levels would cause an exception or give really weird results.

As an example, while we're talking about SM64DS, I shall explain how I found the level headers. Being the unprofessional fuck I am, I used a dev+ version of desmume that I'd modify to log what I wanted. If you don't know C++, you'll probably prefer using the NO$GBA debugger (if you have it, that is).
I first thought that a way to find the level headers (or atleast interesting pieces of level data) was to trace accesses to a certain model file as the level using it was being loaded. I wanted to find out what told the game to use that specific file ID for this level. Eventually I found that the ID was taken from a table that maps another kind of ID to the file ID. I modified my desmume to log accesses to that table entry, which led me to the code that was using the table (said code is in overlay 0, as well as a list of filenames that is used to build the table). I then attempted to trace calls to the function that was accessing the table, in order to find out where the internal ID used came from. The code was reading an address from a table, using the level ID as an index. Bingo, that table contains the addresses of the level headers. There's another table that maps level IDs to overlay IDs, but those are just assigned linearly, as in overlayid=levelid+8. All that remains to be done is extract the table and subtract the base RAM address of the level overlay region from each address, and there are the overlay offsets to the level headers.
This explanation may be inaccurate though, I don't remember the details well, but this is generally how you find stuff in overlays: first, you look for code that accesses and uses the data you're looking for.


So basically, in order to do things correctly, you need some debugging sessions (breakpoints and/or RAM traces) to find your data, and you need to do it for each and every ROM version existing. Though, you can probably omit rare versions noone has, like kiosk/demo versions (or that second JAP version of SM64DS someone talked me about).
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij
Pages: 1