Hacking How to add additional assembly instructions?

[AnonymousWaddleDee]

Hello,

This seems like a pretty basic question, but I haven't been able to find an answer for it: editing assembly, like changing one hardcoded value to another, is easy, but how do you add additional assembly instructions like more advanced romhacks do? It seems like this would mess up all the offsets and pointers and completely ruin the code. My instinct is that you would change one instruction to a branch to unused space, add the additional code there, and then branch back, but am I off? Is there any type of program to help with this, or am I missing something simple?

Thanks for your help.

 

[FriendlyPolygon]

Since there's no space in file where these hardcoded values are, you'd have to make a pointer to some free space where you could do your work. Usually it's straight to the end of the ROM, some emulators don't like that (nds version of GBARunner2 for example)

Post automatically merged: Aug 12, 2023

Oh? You're talking about NDS romhacks? There won't be a problem then

 

[FAST6191]

You were correct. Jump/branch somewhere else, do what you need and jump back. That or optimise code to gain those few instructions.

In DS games with wifi (most of them I imagine) then I have generally noted the wifi error codes are sitting there in the main ARM9 binary (do a text strings search). This includes all the various bizarre codes that I would have to actively try to create and I doubt ever happened in the wild while it was active or could happen under the replacements.

Commercial games also use overlays (sections of memory set aside for this sort of thing) to swap things in and out. Usually one big section but can have multiple sections within it.

Programs to help. I don't think we have a trace logging option worth speaking of (some emulators for older systems will note what areas are executed in a given run or three), not to mention with most things being compiled (by a fairly well optimising compiler* too) it is less useful than older stuff where there might be commented out functions. There was a build of desmume that tried to be a free space finder (later versions of which would ignore the binary area) but the areas the binaries get loaded to are noted in the ROM headers such that various tools can read it).
Some will take a bit more active approach and find something they don't care about (bonus mode, credits, multiplayer... dealer's choice here) and both use the space and possibly fix any issues or prevent it from ever being called.

*it is noted that if the base game does not use the STRM format (one of the sub types/parts of the SDAT audio format) that the compiler will lose support for it.

 

[AnonymousWaddleDee]

Thanks for your response, and to FriendlyPolygon as well.

My game, Apollo Justice: Ace Attorney, unfortunately doesn't have any Wi-Fi functionality, and it doesn't use built-in overlays either (no y9.bin file, at least). To clarify, is it possible to write assembly code in RAM, or does it have to be in ROM? I've found a spot in the 0x2000000 range that seems to be empty and unused, anyway, so I'll try that and see how it goes.

Edit: So it looks like the empty space I branched to, which I thought was unused, is written with zeroes every frame. I don't want to mess with it, so I'll have to find another empty space, which is why I'm wondering if I'm restricted to the 0x2000000 ROM range. And also to clarify, do any games that don't use Wi-Fi have Wi-Fi warnings built in anyway?

 

[FAST6191]

No overlays on a late stage Capcom game? Colour me shocked.

On the GBA some of the super fast code could be stuffed into the small section of RAM the CPU has but that is not really what was asked, not to mention management of that would probably be a nightmare. Likewise there is scope to run some things from the GBA slot (potentially 32 megs of space, more likely 16 or 12) https://gbatemp.net/threads/vanilla-conquer-nintendo-dsi-port.603701/ .

If you can stuff code into the RAM somewhere you can branch to it -- no DEP or contemplations of Harvard architecture needed in this. This could include fetching it from the ROM at some point yourself using a modified binary (your code plus fixing whatever you broke to add your code in there, assuming you did not find space somewhere to do that). If you wanted to get really heretical to modern coding sensibilities you could dip a toe into the self modifying code aspect and find part of the binary only used for rare events (loading the credits maybe) and overwrite that and overwrite back afterwards.

On the DS most make a distinction between the ARM9 and ARM7 with the ARM7 often being tapped to make cheats (in case you were unaware it is mostly kicked to being a library* in commercial games, homebrew is potentially different with some even using it as a main processor and kicking the ARM9 to being a number cruncher).

Running code from the ROM is not really a thing here -- the ROM is not memory mapped like it was on the GBA and also rather slower than is ideal (one reason GBA emulation on the DS is never going to go anywhere beyond proof of concept).

*similar enough between games you can swap between games of a similar vintage or one up-one down in most cases without ill effect, some even doing it as a form of anti piracy dodging.

 

[AnonymousWaddleDee]

Thanks for that information, it's really helpful. I managed to find some empty space that was actually unused and got my code working successfully in there, but having that space-finding DeSmuME build sounds helpful for the future ---- the only version I could find seems to have been deleted, though.

A slightly unrelated question about something that happened while testing the code: Apollo Justice has four episodes that can be accessed from the menu, and also an unused fifth episode that can be accessed from the menu by changing a value.

On no$gba, DeSmuME, and an actual DS, selecting that unused episode loads the first episode, as it should, but on melonDS, the emulator just freezes. It seems to be a problem with melonDS, and I can't check what the problem is, either, since there's no debugger. I was hoping to use the unused episode to add in extra content, but it looks like because of this my romhack won't work on melonDS. Do differences between emulators like this happen often? I guess I can only hope I accidentally fix whatever issue melonDS is having as I go along.

 

[FriendlyPolygon]

but on melonDS, the emulator just freezes

Not all emulators are hardware-accurate. This is far not the only case where it happens. Romhack creators just make it compatible with real DS hardware and if some emulators refuse to work thats their problem

 

[FAST6191]

Yeah emulator only ROM hacks are an ancient SNES hacks thing, certain texture replacements (PS2 seems to have risen up lately but mostly was N64 and some gamecube. Various gameboy colourisations I guess also being this technically) and whatever is done in Lua scripts. Target hardware then being the goal and possibly mantra of most ROM hackers. There can be some blurry lines but ultimately it saves aggravation when the world changes (phones being the primary computing platform for one) so yeah.

MelonDS is the new kid on the block so has some teething issues at times. It is still actively worked on though (desmume did see a very fairly recently and no$gba gets one every year or so but neither are as active as they once were).
I would also question if it is anti piracy protection (that is fairly classic fault behaviour, if a bit obvious for that point in life).

desmume free space finder I will have to see if I have on an old hard drive as I think there was a later version after
https://web.archive.org/web/2014070...smume-build-unused-memory-finder-tool.349332/
yields
http://www.mediafire.com/file/siavuq6jmt870ls/DeSmuMe-custom-memaccessview-r3.rar
attached here for the time being.

 

[plasturion]

When something freeze not on every emulation, or not on every hardware (different type of r4 flashcards) you can have some possibility that some pointers in pointers table, let's say even unused during gameplay wasn't set right, or isn't NULL value and contain random vaule pointing things out of usable RAM address or just throw "forced exception". Maybe melonDS is more unpleasent in this matter sepcially to catch potential bugs and errors. Perhaps. Sometimes pointers table is not so obvious and not all of them are "visible", in that case data block can tell more about all the pointers (additional unpointed string/values or even zeros). I met once with that construct. Make sure then you don't erased anything important at the end of file in data / string block.

 

[AnonymousWaddleDee]

Thanks for all of your replies. I'll just make sure it works on original hardware then. But to clarify, MelonDS freezes even on the original ROM when I try to access the unused episode, so it's not anything I messed up by adding my assembly code.

 

[Coto]

On prebuilt binaries (make sure they're uncompressed first) you'll definitely want to embed a hook which does what you want to do through assembly code in some unused RAM section

edit (the following goes for retail NTR/TWL games):

1) GBA is a single binary. Since you're dealing with a NTR SDK binary (because Apollo Justice is NOT a TWL game), it'll have 2 payloads: ARM7 and ARM9. Since retail NTR/TWL games didn't have access to ARM7(i) payloads, you'll be always dealing with the ARM9 payload.

2)
Read the NTR header to figure out where is the ARM9 payload. It's guaranteed to be scrambled (RSA 2048bit), thus you need to descramble it. You can use DSLazy to descramble both ARM7 and ARM9 payloads. Then you can hack around ARM9 payload, save changes, then scramble again both ARM7 and ARM9 payloads back into a bootable NTR binary.

edit2;
You could also try the same on a NTR homebrew instead because it's simpler. TGDS-unittest allows to extract both ARM7 and ARM9 sections and write a .txt file describing where each one goes in memory at runtime, along their respective entrypoint.
NDSTool allows to take both ARM7 and ARM9 payloads added the .txt information, to build a 1:1 NTR executable, identical to the original NTR executable these sections were extracted with in first place.