ROM Hack GBA ARM instructions, disassembler and debugger (IDA Pro / mGBA)

[Madsiur]

Hi,

I got a few points / questions I'd like to cover.

I'm trying to disassemble FF6 Advance with IDA Pro 6.5. I have the few first dozen functions done by just doing a first auto disassembling. I runned a loader file to map memory. Now mainly two things slow me down:

1) I'm looking for a list of ARM instruction with what they do and also ASM tutorials on how it works on GBA. I can do SNES assembly so I'm hoping the lurning curve won't be too big. I'd like to have a basic understanding of what is disassembled so far in FF6.

Edit: I found this, http://problemkaputt.de/gbatek.htm
If you have any other tutorial recommendation, feel free to give them to me.

2) Second I'd like to get mGBA's GDB server work with IDA Pro. I tried multiple things but from what I'm understanding mGBA keeps refusing the connection from IDA Pro. If I understand correctly the GDB server would allow me to use mGBA as an external debugger working in IDA Pro? I'd like to have this working if possible because of IDA disassembling capabilities, but I guess worst case I could resolve myself to use no$gba as debugger.

Last thing I'd like an assembler recommendation. I read devKitPro is a good one, should I go with that? I'm basically looking for something as simple as xkas for the 65816.

Thanks!

 

[FAST6191]

gbatek is a good thing and it looks like you found that.

Other links worth having
http://imrannazar.com/ARM-Opcode-Map
http://www.coranac.com/tonc/text/asm.htm
http://blog.quirk.es/2008/12/things-you-never-wanted-to-know-about.html
https://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm
I will link http://drunkencoders.com/2013/03/some-memory-benchmarks/ because why not.
Same as above http://www.dwedit.org/dwedit_board/viewtopic.php?id=480
ARM themselves put out a very nice reference manual http://www.atmel.com/images/ddi0029g_7tdmi_r3_trm.pdf
http://www.romhacking.net/documents/361/ and https://web.archive.org/web/20150428020823/http://labmaster.bios.net.nz/vba-sdl-h/ for what others might have used over time.
I will link my own ponderings as well, though there is not so much on the assembly front for someone like you (mainly getting people used to thinking in a way rather than arm for those that already know) http://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/

Afraid nobody has written a "so you are coming from the SNES" document for ARM assembly. I imagine you would have seen the ARM/THUMB mode thing already and if you have clicked on the links above you will likely have seen most things. From what I know of the SNES stuff (and a quick scan of http://wiki.superfamicom.org/snes/show/65816+Reference to refresh my memory) then it is not going to be too traumatic -- you have many general purpose registers rather than 2 plus accumulator, a few more branch/jump methods, some slightly different names for things and shifts are very much in. The many more registers thing means it would be absurd to label all the instructions like the NES/SNES with the register as part of the instructon name, but nobody I met really thinks of SNES assembly that way anyway. You do have a proper multiply and even a divide if you count the BIOS function for it ( http://problemkaputt.de/gbatek.htm#biosfunctions ). Oh yeah BIOS functions have good stuff in, most hackers are concerned with the BIOS aka SWI decompression routines but the others are by no means to be ignored and even basic debugging emulators will log SWI calls.

You probably encountered the basic GBA binary finding technique (first instruction is a jump to the end of the header*, you then get some IO and the first jump to something in the 08XXXXXX region is your binary). This works for most games but http://doc.kodewerx.org/hacking_gba.html#nonstandard has some more on the deviations from form.
*some intros/trainers may change this, it should then branch back at some point, though it is not impossible that one handles the IO for the ROM as well. Some intros were slightly obfuscated to prevent the basic intro removal techniques.


Assemblers. Between no$gba, something using devkitpro/devkitarm's/gcc's stuff (usually for the DS) or simple hand encoding I get many things I want. That said ARMIPS is going from strength to strength these days and is probably where I would look long term/for big projects http://www.romhacking.net/forum/index.php?topic=8413.0
There are two others of note, three if you want to go into some of the really old homebrew.
Goldroad. Buggy as you like but for a long time the main arm assembler used by hackers. Offhand I can not remember the syntax differences (not that they were major)
ARMSDT, mainly a problem for homebrew users but it has reared its head in the hacking world before. It is ARM's software development toolchain and its assembler was better in some ways (register relative writes and a few more abstractions/shorthand* if memory serves)

*not exactly this but think that you can not mov a full 32 bit immediate in a 32 bit instruction (or worse 16 bit for THUMB) for the most part** but your assembler will handle it for you. Most assemblers will handle the simple mov but the ARM SDT had quite a bit of stuff like this, as well as a marginally different syntax that could probably be sorted with find and replace.

**things like mvn (mov negate aka invert) to get all the high bits you can't touch in one instruction to be high or simply not needing it as it is (0000 00FF is as good as 00 00FF after all).

Whatever was being used in the old AGB toolchains. Some early GBA homebrew was developed using Nintendo's gear (it leaked prior to the GBA's release, which also meant GBA emulation of reasonable quality on day 1) and other things like visualham.


As for getting IDA to speak to GDB I have no idea and I have not really used mGBA (though the shrek stuff and the classic nes writeups I read the other week was good reading http://gbatemp.net/threads/undumped-gba-shrek-videos-analysed.404837/ ) and my use of IDA is mainly for X86. I just found http://matsstuff.blogspot.co.uk/2013/01/an-assembly-intro.html so I will link it, it reckon's no$gba gdb stub should speak to it. I should also say some are looking radare2 http://www.radare.org/r/ so you might want to be aware of that too.

Anyway it appears I started to waffle so I will leave it there.

 

[Madsiur]

Thanks for the reply! I see you have the same behavior here than on RHDN: making comprehensive and complete posts!

I'll look at all that stuff later today and comeback in this thread if I have more questions but you basically covered up everything.

The many more registers thing means it would be absurd to label all the instructions like the NES/SNES with the register as part of the instructon name, but nobody I met really thinks of SNES assembly that way anyway

Well if you're talking about thinking ASM instructions as hex values, some people do code 65816 ASM in hex, though I don't really understand why. It's lot less tedious to use only the instruction names in an assebler and the method is also time saving. I can't imagine however how someone could actually code ARM in hex aside of being a long term memorization exercise

You probably encountered the basic GBA binary finding technique (first instruction is a jump to the end of the header*, you then get some IO and the first jump to something in the 08XXXXXX region is your binary).

Yes, IDA did not recognized the first 4 bytes (the jump) as an entry point and I wonder why since it is a ARM instruction. I had to manually disassemble it and saw it jumped at 0x80000C0.

Edit: Also IDA does not recognize jump tables (2 bytes pointers table for functions in same bank) in a SNES ROM but seems to recognize jump table in the GBA ROM. There is however something preventing it of disassembling all the code at once, maybe it loads garbage at some point or there is a similar issue to the SNES jump table one I described.

On a unrelated note, I got your 2012 hacking document and know you're still working on the 2016 (or 2015?) edition. I'd like to host on ff6hacking.com the most complete version with your approval, even if it's still WIP. If you accept, could you provide a link?

Thanks again for the different links!

 

[FAST6191]

If you are going to post, try to make the internet a better place, even if only fractionally. Works well enough for me.

On the instructions where the snes has ldx lda and ldy then nobody would have ldr1 ldr2... ldr16 as it would be ridiculous and instead it is all instruction destination source (or source, destination depending upon architectures and chosen assemblers). The hex/binary would reflect this and you could possibly think of things like that but nobody does, occasionally you might be able to fiddle it or copy something but anything longer than about 4 instructions is definitely time for an assembler for me. Choice link http://www.catb.org/jargon/html/story-of-mel.html

Oh and another link for various ARM related stuff
http://www.heyrick.co.uk/assembler/

By all means host a copy of documents if you like (the first post there says by all means rehost in part or full), I might even remember to tell you when I update it. I do keep the first post in that thread updated and filetrip will always have the latest version available. http://filetrip.net/nds-downloads/u...-rom-hacking-guide-2016-preview-1-f33419.html is the latest one, however I have since found a few more broken links (not least of all that vba-sdl-h faq/user manual I linked in the earlier post) so I might have another quick link update version to come before too long.

I am not sure why IDA might have stopped disassembling. The GBA does not really have a terribly defined file system/end of cpu binary marker that it could have read up to, to say nothing of the THUMB stuff.

 

[Madsiur]

I do keep the first post in that thread updated and filetrip will always have the latest version available

I'll check periodically your hacking document thread in any case. I think I asked you the same hosting question on RHDN a few years ago, though I can't remember. I had the 2012 version on ff6hacking.com for a few months but for some reason it was removed from the technical resources section. I'm now rebuilding the technical page to have a more complete GBA section and your document is a "must have" IMO.

The GBA FF6 version definitely needs more love now that it is know that the FF6 Steam version has in its files system a JAP GBA ROM use for almost every data excluding graphics and music related stuff. I want to check if the exe makes use of some of the ROM ARM code. I'm also getting back on my FF6AE editor so I need to see how some graphics are handled compared to FF3us.