Homebrew Official [Release] GodMode9 - All Access File Browser for the 3DS

[Kazuma77]

@d0k3, just wanted to let you know that the issue with OldLoader on the N3DS still persists. But don't worry about it too much. I've implemented a workaround for now. I've compiled a copy of OldLoader that runs a copy of 1.3.4 with a different name. That way, if anyone uses the dual exploit feature in my recent release, they'll still have 1.3.5 when they switch to B9S. 1.3.4 still runs all of my scripts just fine, so, it's no big deal atm.

 

[d0k3]

@Kazuma77 - Can you perhaps help testing this?

I believe it's this commit that caused this:
https://github.com/d0k3/GodMode9/commit/5104deff9ec87a00aec9793df348d4c46885ba95

--------------------- MERGED ---------------------------

@d0k3 I'd love to be able to take my SD card and copy the contents to my PC and then convert to cia or citra's format given that i supply the b o o t 9 stuff from my 3ds. Is it possible for you to port that part of the godmode9 code to a standalone windows utility? the ctrtool works for decrypting cia i already have on a pc but not decrypting the SD card content and it would be a lot faster than using the 3ds to do the work. Thanks for considering and great work!

Take a look at @ihaveamac's recent development on Github.

 

[Kazuma77]

@Kazuma77 - Can you perhaps help testing this?

I believe it's this commit that caused this:
https://github.com/d0k3/GodMode9/commit/5104deff9ec87a00aec9793df348d4c46885ba95

--------------------- MERGED ---------------------------


Take a look at @ihaveamac's recent development on Github.

Just noticed your reply. I didn't get a notification for some reason. Confirmed. That commit does not work launching with OldLoader from A9LH on an N3DS. And of course, the commit right before it is the 1.3.4 stable I've been using as a workaround. I hope that helps. If there's anything more I can do, just let me know.

Also, while it wasn't directed at me, thanks for the heads-up on ihaveamac's stuff. I've been using 3dsconv for a while now, but it's been a few days since I checked their Github page.

EDIT: Since my swap card isn't my primary focus, it slipped my mind to ask before, but "unmount" would be very handy for one. No need to run a second script from the RAM drive. I could just have the script unmount the card, use the "ask" command to tell the user to swap cards, then have it copy the files right back. EDIT2: I see that's already done now. Thanks.

EDIT3: While the recent change to the "find" command is great for, say, restoring the last NAND or FIRM partition backups performed, it breaks attempts to do things like extract the DSP firmware, where the lowest numbered file is the correct one. Maybe you could add a "findlow" command for such tasks? Or maybe an optional parameter like "-m" for match, i.e. "-m 1" returns the first match, "-m 2" returns the second one, etc. This would allow for some very specific file targeting while keeping a script compatible with multiple firmware versions (since Nintendo's naming scheme rarely changes between versions).

EDIT4: I've been thinking, would it be possible to add one that searches a file for a hex string and returns the offset as a variable? This could be useful for finding the right part of a file to patch/extract if the physical address varies with region/hardware/version.

BTW, "switchsd" seems to be working flawlessly. I've actually performed my dual exploit method on my swap card. Which, long story short, requires two trips. While there's not many practical reasons to keep A9LH around, much less have an option to switch between that and B9S at will, it was fun to watch as it asked me to switch cards 3 times while it automatically transferred everything back and forth.

 

[d0k3]

Just noticed your reply. I didn't get a notification for some reason. Confirmed. That commit does not work launching with OldLoader from A9LH on an N3DS. And of course, the commit right before it is the 1.3.4 stable I've been using as a workaround. I hope that helps. If there's anything more I can do, just let me know.

Also, while it wasn't directed at me, thanks for the heads-up on ihaveamac's stuff. I've been using 3dsconv for a while now, but it's been a few days since I checked their Github page.

EDIT: Since my swap card isn't my primary focus, it slipped my mind to ask before, but "unmount" would be very handy for one. No need to run a second script from the RAM drive. I could just have the script unmount the card, use the "ask" command to tell the user to swap cards, then have it copy the files right back. EDIT2: I see that's already done now. Thanks.

EDIT3: While the recent change to the "find" command is great for, say, restoring the last NAND or FIRM partition backups performed, it breaks attempts to do things like extract the DSP firmware, where the lowest numbered file is the correct one. Maybe you could add a "findlow" command for such tasks? Or maybe an optional parameter like "-m" for match, i.e. "-m 1" returns the first match, "-m 2" returns the second one, etc. This would allow for some very specific file targeting while keeping a script compatible with multiple firmware versions (since Nintendo's naming scheme rarely changes between versions).

EDIT4: I've been thinking, would it be possible to add one that searches a file for a hex string and returns the offset as a variable? This could be useful for finding the right part of a file to patch/extract if the physical address varies with region/hardware/version.

BTW, "switchsd" seems to be working flawlessly. I've actually performed my dual exploit method on my swap card. Which, long story short, requires two trips. While there's not many practical reasons to keep A9LH around, much less have an option to switch between that and B9S at will, it was fun to watch as it asked me to switch cards 3 times while it automatically transferred everything back and forth.

I'll think about adding flags to the find command, alright? I'll most likely just add a flag that allows to find the first, not last.

As for EDIT4 - could you give me an actual real world example? Not impossible to do, it's just a little complicated.

Also, take a look at the most recent commit in GM9, I'm sure you'll like it. Or, even better, try this test build:
https://transfer.sh/EwjP3/GodMode9-v1.3.6-20170905225038.zip
(it may fix that issue with OldLoader on that N3DS)

 

[nl255]

@d0k3 Since if statements are going to be added would it be possible to add a function to detect if gm9 was booted via ntrboot (apparently Luma can detect the ntrboot environment) so that sufficiently dangerous scripts could either refuse to run or give their own extra warning unless they are being run via ntrboot? Also, would it be possible to create aeskeydb.bin without needing other keyfiles or anything other than gm9 itself (plus the right script) now that we have b9s?

 

[d0k3]

@d0k3 Since if statements are going to be added would it be possible to add a function to detect if gm9 was booted via ntrboot (apparently Luma can detect the ntrboot environment) so that sufficiently dangerous scripts could either refuse to run or give their own extra warning unless they are being run via ntrboot? Also, would it be possible to create aeskeydb.bin without needing other keyfiles or anything other than gm9 itself (plus the right script) now that we have b9s?

Sufficiently dangerous scripts... you know, anything that touches something critical already has the write protection sequence? I'll look into that ntrboot detection thingy, though. And, no, aeskeydb.bin is specifically needed (on entrypoints other than B9S and for some very special stuff) because it contains the keys that are *not available in the system*.

 

[The Catboy]

@d0k3 Follow up to previous research

So what happened?
I am nuked my old thread because there's just no way to clean up some of the confusion I may have caused. All research is going private and will be turned into it's own separate thread if I can find anything. Few reasons why:
1: The Ak2i doesn't have a 1GB NAND, it looks like there may have been some mix up in the documents that we found.
2: It seems the ROMs dumped had some skewed results
3: I feel like I am getting people's hopes up when in reality, I am no expert here. Everything I am doing is pure speculation and it shouldn't be treated like fact. There's facts in there, but a lot of speculations on my end. I can't allow the public to be mislead by someone like me. You guys trust me and I can't abuse that trust.
Well my previous thread had a lot of misinformation that made sense when you considered how we got the results, but it turns out everything was wrong and I was in too deep to keep the thread going.
A little history, early on in my research another dev and I theorized that the Ak2i simply used small ROMs containing no real game data. Basically they only had enough information to fool the system into thinking it was a game. This was the previously believed method of how DSi carts worked. The issue came up when we tried dumped the ROM with GodMode9 and it came up with full ROMs with each dump. Which basically didn't make sense so we kept digging until we believed we found the answer. Which was the NAND onboard answer. It made sense and explain a lot the previously unexamplable. Thus I posted this information and no one corrected me, so it seemed we were onto something.
Well it turns out another dev and I actually figured out why the cart dumps to a full ROM. It actually turns out when dumper is looking at the header, the header basically says, "Hey! These files/folders are suppose to be here at this size!" To which the dumper basically goes, ""¯\_(ツ)_/¯ k" and creates a bunch of files with zeros. Basically the dumper fills in the blanks for the header. So the files are the right size, but basically there's only enough information to make the game launchable and the rest are just junk files.
It seems some of my results were skewed due to some mix up in my files as well. Looking through my files, it seems I compressed the ROM file as well.
Either way, it turns out our early research was right. They simply found games that they could map out the memory to work with with their exploit, then only used enough game data to make it work. I even proved that by making my own launchable exploit file that was only 1.1MB (updater is 1.2MB.)
So what does this mean for my research? It means that I have a lot to learn and also means that I need to do detailed reports before bringing them to the public. I am deeply sorry that I accidentally spread misinformation. Even if it's information that made sense, it was still wrong information and that's why I am nuked my previous thread to prevent it from spreading and made this one to correct it.

 

[d0k3]

@d0k3 Follow up to previous research

Don't worry, Lilith, that's how research works . And yes, GM9 actually uses the size info from the header (like everything else), and tries to dump everything. I don't even know how to get the raw card size.

@Kazuma77 - the most recent commit has something for you. WOudl be nice if you could test and check if it works as expected. EDIT: But also test the test build I uploaded in my last post.

 

[Kazuma77]

Don't worry, Lilith, that's how research works . And yes, GM9 actually uses the size info from the header (like everything else), and tries to dump everything. I don't even know how to get the raw card size.

@Kazuma77 - the most recent commit has something for you. WOudl be nice if you could test and check if it works as expected. EDIT: But also test the test build I uploaded in my last post.

Thanks, I'll check them out shortly. I have the latest commit building right now. I actually asked about the "find" thing on behalf of @TheCyberQuake because he said the change broke his script for dumping "dspfirm.cdc" by causing it to pick the wrong file from MSET. But I'll check it all the same. I've had a look at doing something similar myself, but having looked at multiple firmware versions, well, the lower one isn't always the right one in all cases, so, I'm thinking it's probably best to stick with the Home Menu, since it only has one .app file. However, it seems like either approach would be version-specific without a way to search for the byte pattern. I'm not even sure I want to release my project here given how much I would have to remove from it, and I just include the file in my current full release, but, I'm still interested from a technical aspect. Though that's probably just scratching the surface of what search and replace would make possible. Still, don't worry about it if it's too much work. It's not like there's anything I actually need it for at this time.

Also, I think what nl255 meant was a way to generate the key file from B9S, which could then be used with other devices you're looking to mod via other entry points like Safehax (if you don't have access to NTRBootHax).

EDIT1: The uploaded 1.3.6 file unfortunately did not fix the screen init issue with OldLoader. I'll have the results for the "find" modifications soon.

EDIT2: Well, "find -f" always gives an error with the latest commit for some reason. Though I do like how it's showing the lines now, so that you can see exactly which one it's failing at in red. That makes troubleshooting easier.

@d0k3 Since if statements are going to be added would it be possible to add a function to detect if gm9 was booted via ntrboot (apparently Luma can detect the ntrboot environment) so that sufficiently dangerous scripts could either refuse to run or give their own extra warning unless they are being run via ntrboot? Also, would it be possible to create aeskeydb.bin without needing other keyfiles or anything other than gm9 itself (plus the right script) now that we have b9s?

I don't see why this is needed, considering there are already warnings. Furthermore, the NTRBoot environment isn't specifically required for any script to function properly. As long as it can find the keys, GM9 can even install A9LH from regular *hax exploits like Safehax. Disabling scripts from running in other environments would be limiting people's options needlessly. There's no reason to force someone on 11.3 or lower to buy a DS flash cart. I get the whole added brick insurance thing, but should that not be a reason to decrease the warnings if it's detected? If the screen turning red isn't enough to convince people to read it first, I don't know what is.

Also, most of us are careful enough to add checks for things like sufficient keys being present to perform a task. For example, installing A9LH or restoring an N3DS to retail both need access to a decrypted secret sector. A "find S:/sector0x96.bin NULL" will shut down a script immediately if the keys needed to decrypt it aren't present. And if you don't at least have the keys to decrypt the firms, nothing can happen anyway. So as long as people using other exploits download from someone that includes safety checks and tests thoroughly before releasing, they won't have a problem. Not that many people support other exploits, but my single card installer tries to be all-inclusive.

And most of the "dangerous" ones should not be something you're looking at every day. Any same card install script worth running is going to use it's last line to delete itself. And any swap card script should be using a separate folder for the files to be transferred to the target card (you copy it back to 0:/ to transfer it's contents to the root), and therefore never even get transferred to the RAM drive, much less the target card.

 

[d0k3]

EDIT1: The uploaded 1.3.6 file unfortunately did not fix the screen init issue with OldLoader. I'll have the results for the "find" modifications soon.

Looking into this further, no idea yet,

EDIT2: Well, "find -f" always gives an error with the latest commit for some reason. Though I do like how it's showing the lines now, so that you can see exactly which one it's failing at in red. That makes troubleshooting easier.

I derped. You can just compile again (most recent master), or try this test build:
https://transfer.sh/idikF/GodMode9-v1.3.6-1-g6d276c6b-20170906110249.zip

 

[Kazuma77]

Looking into this further, no idea yet,


I derped. You can just compile again (most recent master), or try this test build:
https://transfer.sh/idikF/GodMode9-v1.3.6-1-g6d276c6b-20170906110249.zip

It happens to everyone. I had to make several changes to those installer scripts I uploaded for you to check out. I just tried it. The command gave no error and it found the right file, so, it's working good now. Thanks again.

 

[Giodude]

Have you made a pull of the latest b9s 1.3? Or is 1.3 already compatible with loading godmode9 from the home menu.

 

[d0k3]

Have you made a pull of the latest b9s 1.3? Or is 1.3 already compatible with loading godmode9 from the home menu.

There should be no problems at all with this and loading GodMode9. I've tried with the nightlies.

 

[Selver]

Just tried setting GodMode9.firm as boot.firm, and booting directly to GodMode9.firm via NtrBoot on an N3DS. The goal is to have a flashcart + SD that can trivially boot to GM9.

GM9 mostly works, except that the bottom screen does not appear to get initialized. This makes it really hard to do anything, unless you happened to have memorized all the screens and key combos of interest.

Three related questions:

1. Is this setup expected to work?
2. If it's expected to work, is this a known issue?
3. If expected to work and not a known issue,

 

[The Catboy]

There should be no problems at all with this and loading GodMode9. I've tried with the nightlies.

I think he's referring to this project
http://gbatemp.net/threads/release-gm9link-run-gm9-from-the-comfort-of-your-homemenu.479944/

 

[Kazuma77]

Just tried setting GodMode9.firm as boot.firm, and booting directly to GodMode9.firm via NtrBoot on an N3DS. The goal is to have a flashcart + SD that can trivially boot to GM9.

GM9 mostly works, except that the bottom screen does not appear to get initialized. This makes it really hard to do anything, unless you happened to have memorized all the screens and key combos of interest.

Three related questions:

1. Is this setup expected to work?
2. If it's expected to work, is this a known issue?
3. If expected to work and not a known issue,

That's odd. I've had no such issues. Actually, I may have seen this issue a few commits ago, around when 1.3.2 came out, but no recent build has done this on me. The only issue I'm having is related to OldLoader. I've just built the latest commit and tested it with both an O3DS and N3DS. I experienced no such issues. Here's a copy so you can try it for yourself.

EDIT: I just got messing with the standalone script runners option. Nice. And it's something I didn't even know I wanted. Now my same card installer is easier to use than ever. It boots to CBM9, you just pick which exploit you want to install from the list, and it runs an SSR. I think I'll leave the swap card booting GM9 though. I'd update my "A9LH to B9S" option with an SSR as well, but there's that issue with OldLoader on the N3DS.

EDIT2: File selection... another game changer. This reminds me of an old DOS classic actually -- Batch Select. I think my first test will be simplifying Cakes Launcher. If all goes well I'll move on to a "setup your hotkeys" one (for "BootCTR9 (Select Mode)" for now, I can do one for Luma too but I have to be careful not to break my workarounds, so, GW and Cakes probably have to stay where they are). I updated the compiled file for those who want to check it out.

EDIT3: OK, this hidden bootloader thing has me concerned. Especially with it using "left" for something. That's what I hotkey GM9 to. @d0k3, is this going to mess up my configuration?

 

[gugussefring]

Ok so I have an issue with the save injection/restoration feature for gba games. I'm following the instructions in the guide and I can export my savefile without a problem but I can't reinject a savefile, the game just loads the previous savefile. Is there a fix?

 

[d0k3]

Alright, first of all, everyone, a new release (v1.4.0) is out.

Just tried setting GodMode9.firm as boot.firm, and booting directly to GodMode9.firm via NtrBoot on an N3DS. The goal is to have a flashcart + SD that can trivially boot to GM9.

GM9 mostly works, except that the bottom screen does not appear to get initialized. This makes it really hard to do anything, unless you happened to have memorized all the screens and key combos of interest.

Three related questions:

1. Is this setup expected to work?
2. If it's expected to work, is this a known issue?
3. If expected to work and not a known issue,

Try with the new version, then post the results.

EDIT: I just got messing with the standalone script runners option. Nice. And it's something I didn't even know I wanted. Now my same card installer is easier to use than ever. It boots to CBM9, you just pick which exploit you want to install from the list, and it runs an SSR. I think I'll leave the swap card booting GM9 though. I'd update my "A9LH to B9S" option with an SSR as well, but there's that issue with OldLoader on the N3DS.]

Yeah, that super annoying issue. We're working on a fix.

EDIT2: File selection... another game changer. This reminds me of an old DOS classic actually -- Batch Select. I think my first test will be simplifying Cakes Launcher. If all goes well I'll move on to a "setup your hotkeys" one (for "BootCTR9 (Select Mode)" for now, I can do one for Luma too but I have to be careful not to break my workarounds, so, GW and Cakes probably have to stay where they are). I updated the compiled file for those who want to check it out.

I'm glad that already gets put to use .

EDIT3: OK, this hidden bootloader thing has me concerned. Especially with it using "left" for something. That's what I hotkey GM9 to. @d0k3, is this going to mess up my configuration?

Don't worry. The bootloader can only ever go into effect when sighax but no b9s is detected. Right now, the only way for this to be the case is if GM9 is installed to FIRM0 - on any other setup a bootloader does not make any sense. Btw, even with it being hidden and undocumented, it works rather nicely, and via a compile with "make AL3X10MODE=1" you can make it work even more b9s like. It may be useful for devs and GM9 powerusers, for all others, stay with boot9strap.

 

[Billy Acuña]

Alright, first of all, everyone, a new release (v1.4.0) is out.

This release looks so sexy.
Thanks @d0k3

 

[Kazuma77]

Alright, first of all, everyone, a new release (v1.4.0) is out.


Yeah, that super annoying issue. We're working on a fix.


I'm glad that already gets put to use .


Don't worry. The bootloader can only ever go into effect when sighax but no b9s is detected. Right now, the only way for this to be the case is if GM9 is installed to FIRM0 - on any other setup a bootloader does not make any sense. Btw, even with it being hidden and undocumented, it works rather nicely, and via a compile with "make AL3X10MODE=1" you can make it work even more b9s like. It may be useful for devs and GM9 powerusers, for all others, stay with boot9strap.

It's good to see a new official release. It's also good to hear you haven't given up on finding a fix for OldLoader (it wasn't a big deal, but now that I'm using "filesel" more and more, it's starting to become an issue).

It was always one of my main goals with InScripted to have scripts be able to fully configure the chainloader one day. To that end I had already made a BootCTR9 configuration that runs key-named payloads (x.firm, y.firm, etc.) and called it "Select Mode" because it made it seem more like using Arm9Select. When you added "filesel" I immediately knew that day was here. I released R5 yesterday with the ability to copy any payload to any hotkey in both BootCTR9 (in Select Mode) and Luma (not recommended since converted payloads won't work). Select Mode also uses it for the default payload option. It finally does everything I had hoped for, and more. And the simplified Cakes Launcher works great also. I've decided to build it into an SSR for the next update.

Actually, I've come up with some scripts that use "filesel" for restoring SysNAND and EmuNAND backups that you might want to include in future releases (since you provide the ones for backing them up, after all). I'll attach them to this post. Have a look at them, and see what you think (I've included your original backup scripts for the sake of having it all in one folder).

So, the bootloader is only for when it's being run as a firm. Well, that makes sense. Thanks for confirming it won't mess with my hotkey configuration.

Thanks again for all of these great new features.

EDIT: Made some minor changes. Added an SHA check. I was on the fence about this since it takes an O3DS 3 minutes just to get one for a NAND image. So I made it optional. You can cancel it and still do the restore.

EDIT2: Removed. New versions in a newer post.