mgbdis VS pwndbg

Game Boy disassembler: https://github.com/mattcurrie/mgbdis

You can compile the ROM's back with rgbds: https://github.com/gbdev/rgbds

Here you can see how bank switching works.

You can get images out of it. Find the image locations in the ROM with a tool like YY-CHR, then annotate that location in the disassembler (like https://github.com/mattcurrie/mgbdis).

By a search on Google, I found this link: https://github.com/mattcurrie/mgbdis

I didn't use Ghidra, I only used mgbdis to create a disassembly. Patched it and then reassemble it.

You make it sound like there's a machine you can put a Game Boy ROM into and get out a disassembly, which is kinda true (https://github.com/mattcurrie/mgbdis) but it doesn't automatically split out data blocks or anything like that - it just tries to crawl the ROM and disassemble any code it can find. It's certainly not "effectively no additional work" than making targeted alterations to the binary and documenting your work.

And that's before you get to platforms where most if not all games are written in C - I question whether a mere disassembly of a game like Pokemon Emerald would even be useful to anyone, whereas the pokeemerald decompilation (https://github.com/pret/pokeemerald) is clearly useful but was a heck of a lot more work to produce.

> That's a hurdle, but not an insurmountable one... unless the system didn't even support banking. (Are there any systems that didn't?)

Depends what you mean by "support". I don't think any system has a built-in mapper - they just assign a chunk of memory space to the cartridge bus, and if your game is larger than that chunk of memory space you include a mapper on the cartridge. Nintendo provided standard mappers for machines like the NES and Game Boy because it's very hard to include a substantial game in the wedge of memory space you get on the processors in those machines, whereas only one game on the Genesis/Megadrive needed one.

By far the best debugger for C is gdb+pwndbg (https://github.com/pwndbg/pwndbg)

There are a lot of these types of tools already in the reverse engineering community (in order of lowest chance of breaking when you throw really weird stuff at it):

GEF: https://gef.readthedocs.io/en/master/

PWNDBG: https://github.com/pwndbg/pwndbg

PEDA: https://github.com/longld/peda

They also come with a slew of different features to aid in RE/exploit dev, but many of them are also useful for debugging really weird issues.

GDB is great. I definitely recommend checking out watchpoints as well, a very useful tool for monitoring how a variable changes over time.

GDB also has many good plugins - pwndbg has tons of features and UI improvements over stock GDB.

https://github.com/pwndbg/pwndbg

I've recently started a new semester for my Master's program, and the first project for the semester involves using the GDB tool (GNU Debugger) to analyze a stack on a simple C program that contains a buffer overflow vulnerability. A couple of semesters ago, I had been given a VM pre-loaded with a more featured debugger tool called pwndbg. Pwndbg was excellent because it was easy to use and easily allowed accessed to information such as current assembly code being executed and a view of the program registers. So, going back to using GDB felt a little like stepping back into the stone age.

Pwndbg - A GDB plugin that provides a suite of utilities to hack around GDB easily.

i have peda installed on my gdb and now i am trying to install pwndbg with git clone https://github.com/pwndbg/pwndbg cd pwndbg ./setup.sh