News:

11 March 2016 - Forum Rules

Main Menu

GBA data after function offsets

Started by Madsiur, March 21, 2017, 09:08:21 PM

Previous topic - Next topic

Madsiur

I'm working on a FF6A disassembly using IDA Pro. There's an unknown 4 bytes data after a lot of routines (but not all), usually 0x00000020. I tried to find the use of it online but my searches gave nothing and I'm a bit new to GBA code structure. Typical code structure is as follow:

function A code
0x0000 (Align instruction?)
0x02XXXXXX (one or multiple RAM offset referenced in function A, can be ROM offset too)
0x00000020 (this is what I'm trying to find the meaning. Not referenced in code, sometimes 0x00000021 also).
function B code

Kea

The 0000 bytes are most likely to word-align the following data - the LDR rd, [pc,#] instructions used to load large local variables can only index to 4-aligned offsets to maximize range.

The 0x00000020s and 0x21s I would imagine are artifacts of the specific compiler that TOSE used for FF6A. I'm not certain that's the case, but I've looked at code from their earlier FF ports and those don't have these 20/21s at the end of functions. Possibly they changed compilers somewhere along the road. Is there any pattern to which functions have these words tacked on?

As an aside, I've never heard about IDA Pro before; looking at their website it seems to have a pretty solid feature set. What's been your experience using it? Would you recommend it over, say, No$GBA?

Madsiur

#2
Quote from: Kea on March 21, 2017, 09:31:26 PM
Is there any pattern to which functions have these words tacked on?

I've tried to find a pattern but so far I noticed none.

Quote from: Kea on March 21, 2017, 09:31:26 PM
As an aside, I've never heard about IDA Pro before; looking at their website it seems to have a pretty solid feature set. What's been your experience using it? Would you recommend it over, say, No$GBA?

IDA Pro is a solid all-purpose reverse engineering tool. Strictly speaking of ARMv4T, it's accurate for Thumb and normal instructions and auto-analyze can disassemble a lot of the ROM with one click. However, you need to continue manually at instructions such as BX r1. It also does not recognize jump table but you can disassemble those (and function referenced) with a single manual switch input (with correct parameters). For FF6A, it disassembled around 1700 function with auto-analysis but I still have a lot to do manually. IDA also has a powerful labeling system. I'm still exploring the software but it seems it is quite complete.

The downside is licenses start at 589 USD. There are freeware versions but not all architectures and supported and it has limited features. If you strictly want to disassemble GBA code, no$GBA is the best free tool. I have little experience disassembling with no$GBA so I can't compare both feature-wise but IDA is not GBA specific so it lack the palette viewer, VRAM viewer, etc. I would say also that IDA auto-analysis, if set properly, does save a lot of time.

henke37

You might be seeing the constant pools. They are simply chunks of data that can be referenced with smaller offsets interspersed in the executable. And possibly some alignment padding too.

tvtoon

At first, padding too but be careful for stack ending routines.