using GHIDRA to debug 3ds games?

Are you talking about the reverse-engineering suite, Ghidra?

Or something completely different?

 

Yeah, that's the reverse-engineering suite Ghidra.

It is NOT a debugger.

 

You might be asking the wrong question, or have been slightly misled by the reply you mention.

Afraid I am not particularly up on my 3ds ROM hacking/emulation/debugging but have done enough of it on older systems that I can give a general overview, and some notes on where the 3ds might change up from older stuff that most spend their time contemplating.

Traditionally most people use emulators when they can get them for the device they care about to find cheats.
https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial is my usual suggestion for a link on basic cheat finding, albeit for the GBA. The 3ds (and basically everything else) does work in much the same way, however with the 3ds being a bit newer then there are a few quirks with memory arrangements and the way the code works means it might not be in the same place between runs (see pointers).
If emulators are not yet a thing for your device then some kind of hardware access is needed, with such things being known as a debugger (though it is not the only sort, even if technically it has much of the same abilities). These will allow you to fiddle with memory on hardware (including dump it to compare), and some abilities to mess with the code as it is running too though what ones you get might vary.

You can do an awful lot with basic memory manipulation (it is well within reason to have infinite consumables for a game, moon jump, max stats, all unlocks, walk on water maybe, walk though walls is a possibility, inventory cheats, cheats to do things like if this then do that), however a debugger will allow you to play with the code as it runs rather than just the memory. This opens a lot more doors.
Memory is just memory really, it holds data the game uses. Play with a debugger and you can change how the whole game operates from the ground up -- rather than just infinite health you never get hit (no knockback, stun...), can change what percentages something will happen or force outcomes to decisions the game makes and much much more.
The trouble comes in that rather than memory which you can generally understand pretty easily and quickly for most things (it is usually a value or a flag and that is pretty much the end of it. There are some things like understanding why double jump flags are good for moon jump, or why you might want to look at various stats if the game does not have it, or why you would want to first get infinite basic potions or something you can buy in the shop before you move sideways in memory and make it so you can have infinite end game sword only available as a rare drop in a 20 hour sidequest) you instead have assembly.
Assembly is what the CPU itself runs with. It is a selection of short (in the case of ARM, which is what the 3ds runs, mathematical/electrical/programming operations and sometimes less complicated (which is not necessarily a good thing) than a PC.
Afraid I don't really have a good learning ARM assembly, much less the 3ds type.
I usually link https://www.plantation-productions.com/Webster/ and https://stuff.pypt.lt/ggt80x86a/asm1.htm for the PC and that gives people a reasonable grounding.
I have stuff for some ARM processors like the GBA http://www.coranac.com/tonc/text/asm.htm and the staple of GBA and DS hacking http://problemkaputt.de/gbatek.htm#3dsreference is starting to get some 3ds info, https://www.3dbrew.org/wiki/Main_Page has a bunch of info.

There will be three main classes of debugger, maybe four if you count some aspects of homebrew and commercial development which you likely will not have here (that being debug flags enabled).

1) The in hardware stuff we spoke of earlier. Here you will probably have either a hardware device attached to the machine, or as the 3ds is a modern device with a firmware running at all times and wifi you can get stuff done there.

2) A specialist emulator with debugging functionality. Not all emulators will have this, and sometimes you might have to run an extra program (if you see GDB mentioned then this is one such things -- guess what the db in that name stands for?) on top of things.
Afraid I have not really kept up on 3ds emulation.

3) A standalone debugger that will be able to do static analysis, though you might be able to give it a boost with some data grabbed from an emulator or real hardware.
Ghidra is one such example, most know it more for the PC but there should be some ARM stuff/modules somewhere out there (ARM is also used in phones and tablets a lot so would be hackers are quite interested in it).
IDA is another such one.
Radare2 is one more.
If you want to go more basic then a basic disassembler (which is a key feature of any debugger really) should be available for the 3ds' particular CPU.


Most ROM hackers and cheat makers will spend their time with 2) if it is available and reasonably good as it is the quickest and easiest way to do most things cheat making cares about -- 1) is just tedious to use but has the bonus of being on hardware rather than inaccurate emulation and 3) is good for massive understanding of things but lacks info from hardware.


Anyway an example of why it might be good vs other things.
So you want to do a moon jump cheat. OK you might be a half bright cheat maker that knows about double jump flags (if you have a double jump it will have to note if a double jump has been done, find where it stores this "jump done", which if you can't always add and subtract things like you might boring potions and only have the one chance each jump is not necessarily that easy), or maybe you reckon that a gravity stat somewhere in the game, or a speed stat might influence jump height...
Rather than mess around with that the would be debugger/assembly versed hacker would instead likely note that jumping influences the position on screen and such things tend to have a dedicated hardware location (if 2d graphics see OAM, for 3d graphics then might be more of a virtual location, though 2d virtual location is also a thing some games have). Set the debugger to tell you when this location data is changed, jump at your leisure and it will flash up saying something changed it. While you don't necessarily care about the position the sound, the animations, the hitbox... all will be being changed within the same section of code that just changed the location. No messing around with savestates or hard to track down flags, you are right there watching the game make the decisions.
Or maybe they will note that jumping happens after you press A so they wait and see what reads the control state and follow that down.
Some debugging emulators, though usually for older systems (here is one for a NES emulator, http://fceux.com/web/help/TraceLogger.html though know that FCEUX usually represents the gold standard for non PC debuggers and most things struggle to live up to it), will also have an elimination function. Here you get to a point in the game, start a elimination session and do everything but jump (idle, walk around, open menu...), say wait for a new function and now jump. As the game will have seen clock happen, idle animations, walk animations and whatever else then the new thing it has not seen will likely be the jump aspect.
Anyway now you can do many things to the jump command as you found it, including making it say normally jump double the height and still leave the double jump intact rather than abuse it (or potentially suffer the negatives of such things like hard to control).
I already mentioned detecting hits itself, and not just forcing things in inventory but understanding how things work, https://www.dragonflycave.com/mechanics/gen-i-capturing is the sort of thing you might be able to write if you get a handle on assembly level fiddling, you can make it play different songs in the game, if it is one of those annoying games with anti cheat then you can see how it works in action rather than having to bash your head against memory dumps until you see the method it uses, you can figure out how save games are checked and work around it, and... actually now we are heading into ROM hacking proper. https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ if you are interested in that sort of thing.

 

Sorry, didn't think it ended up that long and some of it was extra fluff.

Basic assembly hacking is not so bad. If you can find a memory cheat and understand the basics then it is usually not so bad to watch for the thing editing the memory and then either changing the number it adds/subtracts, telling it to not do it (see NOP, short for no-operation), or telling it to always take a given path (in programming you see a construction along the lines of IF ELSE, this being things like IF this location = this value then do this, ELSE carry on with the game (or maybe go to the "player died" routine) and changing that to never die, never question why the save game does not match what it should or similar then you can do good stuff). If you happen to understand cycle timings and what they are useful for, or what the three major destinations for an opcode might be and which ones are lacking on the 3ds compared to PC, then so much the better but you can get some seriously impressive stuff done with just a basic understanding.

Anyway had a quick scan. There are basically three 3ds emulators worth paying any attention to it seems and none of them make any great discussion of their debugging options. All have some mention by people pulling things apart on emulation forums though.

Citra is the main one

vvctre is a fork of it aimed at running some games where citra might have troubles
https://github.com/vvanelslande/vvctre/releases

Corgi3ds. Seems to be its own thing.
https://github.com/PSI-Rockin/Corgi3DS

no$gba might be joining them at some point in the future. If fceux is the gold medal standard for console debuggers (PC tends to blow anything we see in consoles out of the water) then the no$ series of debuggers are the silver medal that is nipping at its heels. Its DSi and 3ds emulation support right now is minimal though.
http://problemkaputt.de/

It should be noted that while having things run in real time without graphical issues is a goal of the game player the ROM hacker/cheat maker can deal with slowdowns and graphical issues.

Anyway it is 5am as I write this and the 3ds is one of the most boring consoles ever released as far as I am concerned so I have no great desire to go exploring emulation of it.

 

Does seem to be a new edition out with it, and there were some bridge options before it.

https://wrongbaud.github.io/posts/ghidra-debugger/ appeared in a search as well which covers connecting it to a GBA emulator (might have to share that wider actually, could be interesting to have). You would have to figure out what settings for the 3ds and if any of the emulators there have GDB options, however the link serves as proof of concept for having it Ghidra speak to GDB based setups and debug a non PC system (ARM one at that) so 3ds seems well within reason if there is an emulator with it or a hardware plugin offering similar functionality.

 

Says failed to find suitable JDK (that would be Java development kit) and points you at the installation manual for Ghidra.

Personally I dislike Java and avoid having it installed unless absolutely necessary but if you absolutely must use ghidra rather than the other options out there then I guess you might be following along with the install guide.

 

Did you try the msi installer of the JDK? (Assuming you are using Windows)
This should probably setup all the required varibles so ghidra can find it
https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.10+9/OpenJDK11U-jdk_x64_windows_hotspot_11.0.10_9.msi

 

Just to rule it out. You have installed the 64-bit version of the JDK?

btw. the JDK (Java Development Kit) includes the JRE (Java Runtime Enviroment)