11 March 2016 - Forum Rules

Main Menu

What could be a useful tool?

Started by Mewster, December 04, 2013, 12:36:53 PM

Previous topic - Next topic


Hiya all. I have a question regarding romhacking tools, or better the moltitude of them.

I know that each game has its own way to be handled, but is there something that could be generalized, a tool a romhacker could possibly use during his/her work independent from the game and that still doesn't exist?

Possibly hacking with translation purpose, but every idea is accepted

(I'm going to graduate this year in IT, and since i always loved this world I was thinking about a final thesis' theme rh-related)


I had a similar idea a while back ( ) and various people have tried similar things over the years.

The trouble comes in things are so different between games that such things almost inevitably turn towards making your own, possibly quite limited and maybe not even Turing complete, programming language or bringing in an existing language (typically in the python/perl/lua side of things) and calling it a plugin for an existing program. Similarly as games tend to be programmed in either assembly or something in the C family it tends to look a lot like structs anyway (go around some of the hacking forums that deal with formats and watch how many people will define them as they might in C).
It is arguably what happened to the text insertion/dumpers in things like Atlas and Cartographer
ROMulan went down a similar path

I had thought about doing a few things for the DS as they follow common formats a lot of the time but the use of such a thing would be limited.

About the only thing I could reasonably suggest would be to consider making or improving the debugging emulators, some have considered a reference standard frontend for debugging emulators in the past (debugging if you are not on a NES, SNES and a slightly lesser extent GBA or DS is very limited compared and varies a bit between them all too, mainly as features that exist on one console may be seriously downplayed on another) but that is probably less final year project and more PhD or at the very least a good masters. The more cynical side of me wants to say think long and hard about doing a final thesis on a subject you really enjoy, I doubt you will be limited in scope like some others might be when they pick a hobby but you might have a hard time putting it together in a form that could work for a thesis.


Thanks for the reply.

I know what you mean about doing a final thesis on a subject I enjoy, but if there is no interest there is no gain :P

Anyway thanks for the ideas; I'll think about them.


radare2 + capstone-plugins might be interresting for you. The problem is, that it has to much  features for total newbies. the following video-consoles are supported at the moment:
Gameboy: disassembler and analysis just open r2 and then type aa for analysis and pd for disassembly
SNES: disassembler, open r2 -a snes file.smc
N64: disassembler and analysis. you need capstone-plugins for this --> open r2 -a mips.cs file.n64 and then type e asm.cpu = n64
GBA: should work basically but you need to find the entrypoint yourself like for snes. open r2 -a arm file.gba

more is on its way
go r2, use debug. .... White hand was fainted


If you have ARM7TDMI disassembly capabilities then GBA entry points, assuming you do not mean hook points, are easy to find. The very first bytes in the ROM are a jump, usually to the end of the header, and then some IO setup with the first reference to anything in the 08XXXXXX region being the first actual instruction. There are very few ROMs that deviate here ( and maybe some of the scene trainers/intros, naturally homebrew could vary but usually does not) so you might want to include a force instruction for the read.

If you have GBA disassembly then you basically have DS (give or take binary compression and 5 rarely used instructions) which you just read the relevant values for from the header.