News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Dumping Codes/GBA  (Read 1978 times)

Sup_vic

  • Jr. Member
  • **
  • Posts: 22
    • View Profile
Dumping Codes/GBA
« on: October 19, 2015, 05:24:05 pm »
Is there a way to dump code lines from a gba game? I've seen people put megaman on Castlevania HoD so I guess they coded him in it, but in the hex editor the only thing that shows up are texts. Any ideas?

FAST6191

  • Hero Member
  • *****
  • Posts: 2848
    • View Profile
Re: Dumping Codes/GBA
« Reply #1 on: October 19, 2015, 05:37:50 pm »
Code lines as in disassembly?

If so then yeah there are a few methods depending upon what you are going for. Emulators are quite useful here as their auto mode can help cut through the ARM/THUMB stuff. If you prefer a more standalone approach then I usually make do with crystaltile2 and objdump from devkitarm. There are simple techniques to finding the GBA binary (the first byte is a jump instruction which usually jumps to the end of the header, there will then be some IO and the first jump to something in the 08?????? region is the start of the binary proper). http://www.romhacking.net/utilities/818/ is crystaltile2, not sure where the current.  I have some others I use more for the DS so I am not sure how relevant they will be. Depending upon what I am doing http://www.romhacking.net/forum/index.php?topic=8413.0 is my chosen assembler, for slightly shorter things that I am not hand encoding (so more than about 3 instructions) I might go for the devkitarm/arm-eabi stuff.

That said "megaman on Castlevania HoD" is more likely tile/graphics editing that was used. Find all the movement sprites in Castlevania and all the movement in a megaman title of your choosing, line up the relevant sprites (standing to standing, attacking to attacking, movement to movement...). maybe also sort palettes and you are away. I see from your other topics you are dealing with compression, fortunately most GBA compression is so called BIOS compression as it uses algorithms from the GBA BIOS and is fairly well documented and with several tools to handle it.

Sup_vic

  • Jr. Member
  • **
  • Posts: 22
    • View Profile
Re: Dumping Codes/GBA
« Reply #2 on: October 19, 2015, 05:55:18 pm »
Thanks for the fast reply! Yes, i've been trying to hack Castlevania AoS for some time.
Right now the method I'm using to get the graphics is setting a breakpoint and getting graphics from the adressess that come up. But I started to think about the actual game code like changing how high will the character jump and things like that. In that Cv:HoD example I told you before the author of the hack made megaman be controlled by inputting an ingame code, meaning he messed a bit with the games code for that to happen. I'm really new to this stuff and I have a lot of questions but I'm trying my best to understand what you told me now.

So I use a disassembler to gather the code? How do I find the bit where the code for a jump is, for example? I would have to jump and see where the game calls it? Sorry for the possibly dumb question.

FAST6191

  • Hero Member
  • *****
  • Posts: 2848
    • View Profile
Re: Dumping Codes/GBA
« Reply #3 on: October 19, 2015, 06:56:10 pm »
If you want moon jump then the later DS Castlevania instead abused the double jump feature and rendered the check if second jump stuff useless (I can not remember the specifics offhand but I would probably look for a flag that is set and force it to no jump done at all points in time like an infinite health cheat or something).
Actual jump height changes can be a nightmare hack if you have collisions/hitboxes not tied to the animation* and can be a simple thing that you can change without so much as knowing what an opcode is after someone has found it, or even before then in some cases of external animation. If you are familiar with setting breakpoints and watching how things play out then you know most of what you might want to know already -- rather than setting it on VRAM though you have to have figure out what instead you want to look at, if the moon jump thing above is possible for this game then look at the flag that is set, it will not be the jump height but it will almost certainly lead directly back to the code responsible for the main height of the jump, if it is not the same code doing the second one), if not then you would figure out which OAM segment was handling the sprite in question and set breakpoints there. I guess you read that finding graphics with vba-sdl-h document and maybe adapted it to no$gba, either way you have effectively learned tracing and that is the backbone of most assembly work.

If megaman was there as a hidden extra (even one buried really deep and not available under any normal means) it can change how things play out. The graphics thing I mentioned... if you have ever seen a sprite sheet it will have a bunch of sprites on for each frame of the animation. It is not quite copy and paste but dangerously close.

*more common on older systems, any sensible GBA coder would have used the OAM properly. Though Konami handheld devs are not held in the highest esteem when it comes to code quality.

Disassemblers themselves are very dumb tools, much like hex editors are very dumb tools. They only appear powerful because someone that knew what they were doing guided it to produce something useful. But yeah if you want to run a disassembler on a GBA ROM it will hopefully give you two outputs for the two instruction sets the GBA has (ARM and THUMB in case you were unaware), and will also have attempted to disassemble everything that is not game code as well much like a hex editor will try to convert everything into text regardless of how useless it may be for that file.

Also as I am not inclined to make another reply you asked about everything being decompressed at once. Yes and no as to whether that is possible. If you have a list of addresses, or an address in the ROM that contains a list of addresses (see also pointers, the GBA is quite fond of them and they are easy enough to handle on it) then you could tell one of the various command line based extraction programs to go to each address and attempt decompression. A fully automated thing will only happen if someone has done a lot of work to generate the addresses manually at first, something like the Golden Sun editors from Atrius being a good example of that.

Sup_vic

  • Jr. Member
  • **
  • Posts: 22
    • View Profile
Re: Dumping Codes/GBA
« Reply #4 on: October 20, 2015, 08:25:51 am »
I see... so I probably will have to learn what everything means before even trying that for myself.

By the way, do you have any idea if there is a way to set breakpoints in vba? I use it to grab the palettes and no$gba to set the breakpoint but something tells me that a program so full of options as vba should have something like that around.

FAST6191

  • Hero Member
  • *****
  • Posts: 2848
    • View Profile
Re: Dumping Codes/GBA
« Reply #5 on: October 20, 2015, 09:00:42 am »
I am not sure what VBA-m has these days but originally the debug version of VBA that most ROM hackers used was VBA-SDL-h, vanilla VBA does not really have much in the way of hacking support beyond the diassemblers, tile viewers and such like.
http://labmaster.bios.net.nz/vba-sdl-h/

There is a third breakpoint capable emulator in boycott advance but these days as no$gba is free you might as well go with that. If you really wanted it though http://filetrip.net/gba-downloads/emulators/download-boycottadvance-028-windows-f28912.html
I am not sure what VBA-h has here as it was more aimed at cheat making/finding and I have not played much with it.

Sup_vic

  • Jr. Member
  • **
  • Posts: 22
    • View Profile
Re: Dumping Codes/GBA
« Reply #6 on: October 20, 2015, 09:14:48 am »
Thanks, man! I'll be messing around with vba sdl h till I get something! Thanks a lot!

FAST6191

  • Hero Member
  • *****
  • Posts: 2848
    • View Profile
Re: Dumping Codes/GBA
« Reply #7 on: October 20, 2015, 09:21:57 am »
Just in case, I had mentioned it in an earlier post but if you have not read it then http://www.romhacking.net/documents/361/ covers finding graphics with VBA-SDL-h and is a pretty good step by step for it.

Sup_vic

  • Jr. Member
  • **
  • Posts: 22
    • View Profile
Re: Dumping Codes/GBA
« Reply #8 on: October 20, 2015, 10:55:05 am »
Yes! This will help a lot, man!

A different question but since you seem to know a bit about this, do you know how to find an objects palette and change it? I know it's possible I just never saw anyone talking about it.

FAST6191

  • Hero Member
  • *****
  • Posts: 2848
    • View Profile
Re: Dumping Codes/GBA
« Reply #9 on: October 20, 2015, 12:33:01 pm »
Change it so it uses one of the other palettes in memory* or change said palette that will eventually end up in memory?

*if you had a slider so you can choose the palettes in the VRAM viewer then similar idea.

For the former then yeah assuming you are not in 256 colour mode (8bpp in your tile editor) you will get to have some fun with the OAM. Or more accurately the thing that controls what ends up in the OAM. It might be the equivalent of a mapped image but it might also be buried deep in the game code.
http://problemkaputt.de/gbatek.htm#lcdobjoamattributes , specifically bits 12-15 of attribute 2.

For the latter then yeah you find it like you might find graphics in a ROM and change it. The GBA does have some dynamic palettes (the GBA, SP and GB player brightness options of Summon Night swordcraft story 2 being a good example) and palette driven animation (the rainbow blocks in Mr Driller 2 being my usual example) so you can not always get away with dumping the palette from VBA and searching for that in the ROM even if I do suggest you do that as your opening move. Though in the case of palette animations then most of it will tend to stay the same so you can try searching for a fragment.