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

[d0k3]

@d0k3 you have really outdone yourself this time. I am loving the new chainloading capabilities, especially useful with this new exploit. Not that the RTC feature isn't handy so I can tell when files were modified. I also thoroughly enjoyed seeing the "encrypt" and "decrypt" options added. Now I can setup a dedicated folder for removing seed encryption from CIAs by decrypting and re-encrypting them with a script. It might be nice if there was a "log" command, so I could see which ones actually had seed encryption, though.

Thanks again for all you do for the scene.

And, thanks to you, too! Useful feedback is always appreciated.

I think a "run" command would go well with this new chainloading feature. That or a configurable menu for the chainloader. I'm working on a drag-and-drop method for NTRBootHax that only requires one trip to the PC. The basic concept is already complete. Use GM9 to chainload Safe B9S Installer instead of running it directly. Then use a script to copy "boot.firm.bak" (a backup copy I'll be including with my configurations in the next version of my AIO pack) to "boot.firm" and delete the temporary installation files. It would be convenient if I could have Safe B9S Installer launch from a menu instead of having to tell people to find it on the SD card and launch it. It will still work as is, it's just that it would look more polished that way.

Though a "run" command has other possibilities as well. Renaming external firmware files for CFWs that still require them, for example. You could have a script copy "firmware90.bin" to "firmware.bin" right before launching Cakes or Corbenik/Skeith with a 9.2 EmuNAND, and have another copy "firmware114.bin" to "firmware.bin" so you could easily switch to running it with your updated SysNAND.

A 'run' or 'boot' command will be added and I'll also add a menu for quick booting of payloads.

probably still works if you build the source yourself and use the output binary. I would imagine d0k3 just didn't put it in the release archive because everyone should have moved on to b9s now. I didn't check if it actually runs on a9lh though.

Now, the A9LH compatibility. Yeah, I'll be honest, it wasn't planned to ditch it that fast, but, right now, it will not work. Don't worry though, I have something in the works that will cover this (and more) and that will be released very soon.

 

[d0k3]

Alright, didn't expect "very soon" to be this soon .

Here's a little something that will, again, allow to run GodMode9 from any entrypoint. Big thanks go to @Wolfvak for making OldLoader possible (seriously, thank him, not me). Make sure you read the release notes. Also note that I still recommend updating to B9S and running from there.

 

[lomejor18]

hey guys, i have this situation...

2 chinese flashcarts, one working normally and another broken for messing with YSmenu...
using godmode with the working flashcart, i see 2 NDS files on it and i copied those files on the SD card...
using godmode with the broken flashcart shows nothing, it's empty... i tried to copy the NDS files from the working flascart and godmode says "not allowed in virtual path"...

is there any way i can copy those files on the broken flashcart?

 

[Kazuma77]

Alright, didn't expect "very soon" to be this soon .

Here's a little something that will, again, allow to run GodMode9 from any entrypoint. Big thanks go to @Wolfvak for making OldLoader possible (seriously, thank him, not me). Make sure you read the release notes. Also note that I still recommend updating to B9S and running from there.

Just tested it from an A9LH device. It works. I was also able to chainload the latest Skeith build with it. A significant find, since the last working .bin was released on May the 3rd. As you would expect, Luma does not work. Also, the payload name is visible in a hex editor. So we can theoretically have a copy for each working payload we find (of course, patching the payload name with CBM9 is also a possibility). Oh, right, the path is at the top of main.c as well, so if you can compile the source, it's easy to make a separate copy per payload.

EDIT: Thanks for making this, @Wolfvak. I just have one question. Does the .3dsx version provide it's own access elevation, or does it have to be used with something like Safehax? If it does it's own then that would simplify guides (because this could simply be "boot.3dsx" for installation purposes -- a post-install script could easily replace it with the HB menu after B9S is installed).

EDIT2: I just saw the "Payloads" menu in the commits and decided to build it and try it. Very nice. I especially like how that and the "Scripts" menu are on the first page of the home menu now. I can see GM9 becoming the centerpiece for all future guides and tutorials. My "new system" configuration works great now. I copy one of my pre-made configurations over to the SD card, then copy that over and it's all ready to go. I can backup SysNAND, run Safe B9S Installer, reboot, run my post-install script, and the system boots with BootCTR9 (or CBM9 or Luma) as the chainloader (and all the temporary files are already deleted). Perfect! I almost feel sorry for the next person that watches me setup their 3DS. Because this will make their head spin. Thanks again, @d0k3. Now, all that's left is to do a *hax variant of this setup configuration and it will be ready to release (hopefully). Not that I'm trying to compete with the guide. Just seeing how much of it I can automate.

EDIT3: Please tell me "installfirm" and "extractfirm" are going to be script commands soon. Then we can have a single script install B9S (or even A9LH), copy Luma to CTRNAND, and delete all the temporary files. Also, can we get that safe restore option as a command? I thing a "Transfer EmuNAND to SysNAND.gm9" might help avoid errors. Actually, nvm, figured that one out. Backup the firm partitions and secret sector, then just restore them afterward.

 

[windows_server_2003]

Why do we have to keep secret about the URL of the aeskeydb.bin?

 

[Asia81]

https://d0k3.secretalgorithm.com/
What's "GodMode9TD " ?

 

[d0k3]

https://d0k3.secretalgorithm.com/
What's "GodMode9TD " ?

GM9 with top and bottom screens switched. If you like it better that way.

EDIT: Thanks for making this, @Wolfvak. I just have one question. Does the .3dsx version provide it's own access elevation, or does it have to be used with something like Safehax? If it does it's own then that would simplify guides (because this could simply be "boot.3dsx" for installation purposes -- a post-install script could easily replace it with the HB menu after B9S is installed).

I missed your edits earlier. Yes, this is based on my Brahma Loader and already contains the access elevation. The 3DSX does only work on 9.0...9.2 (afaik), though.

EDIT2: I just saw the "Payloads" menu in the commits and decided to build it and try it. Very nice. I especially like how that and the "Scripts" menu are on the first page of the home menu now. I can see GM9 becoming the centerpiece for all future guides and tutorials. My "new system" configuration works great now. I copy one of my pre-made configurations over to the SD card, then copy that over and it's all ready to go. I can backup SysNAND, run Safe B9S Installer, reboot, run my post-install script, and the system boots with BootCTR9 (or CBM9 or Luma) as the chainloader (and all the temporary files are already deleted). Perfect! I almost feel sorry for the next person that watches me setup their 3DS. Because this will make their head spin. Thanks again, @d0k3. Now, all that's left is to do a *hax variant of this setup configuration and it will be ready to release (hopefully). Not that I'm trying to compete with the guide. Just seeing how much of it I can automate.

And thanks for trying this cutting edge stuff . You can actually already automate more, see below.

EDIT3: Please tell me "installfirm" and "extractfirm" are going to be script commands soon. Then we can have a single script install B9S (or even A9LH), copy Luma to CTRNAND, and delete all the temporary files. Also, can we get that safe restore option as a command? I thing a "Transfer EmuNAND to SysNAND.gm9" might help avoid errors. Actually, nvm, figured that one out. Backup the firm partitions and secret sector, then just restore them afterward.

You don't need these commands. Installing a FIRM is simply copying it to S:/firm0.bin / S:/firm1.bin. I strongly recommend not forgetting safety when scripting this (sha checks / verification of FIRM, maybe sha check of sector0x96.bin). Extracting stuff from a FIRM works via mounting it, then copy what you need. If you meant doing a backup of the FIRM0, then just copy it out of S:/firm0.bin / S:/firm1.bin. And, the safe restore - I'd go about this differently. Mount the backup image, then copy I:/ctrnand_full.bin, I:/twln.bin, I:/twpl.bin to their respective locations on the SD card, done. It's the same as a safe restore (won't work if the current NCSD has a different partitioning than the current, but when is that ever the case?).

 

[urherenow]

Why do we have to keep secret about the URL of the aeskeydb.bin?

So the owners of this site can't be held liable. Keys are copyrighted.

 

[Kazuma77]

GM9 with top and bottom screens switched. If you like it better that way.


I missed your edits earlier. Yes, this is based on my Brahma Loader and already contains the access elevation. The 3DSX does only work on 9.0...9.2 (afaik), though.


And thanks for trying this cutting edge stuff . You can actually already automate more, see below.


You don't need these commands. Installing a FIRM is simply copying it to S:/firm0.bin / S:/firm1.bin. I strongly recommend not forgetting safety when scripting this (sha checks / verification of FIRM, maybe sha check of sector0x96.bin). Extracting stuff from a FIRM works via mounting it, then copy what you need. If you meant doing a backup of the FIRM0, then just copy it out of S:/firm0.bin / S:/firm1.bin. And, the safe restore - I'd go about this differently. Mount the backup image, then copy I:/ctrnand_full.bin, I:/twln.bin, I:/twpl.bin to their respective locations on the SD card, done. It's the same as a safe restore (won't work if the current NCSD has a different partitioning than the current, but when is that ever the case?).

Sounds about right. OldLoader's .3dsx worked great with 9.2, but not 11.2 or 11.3. That's OK. The udsploit and safehax combo gets the .bin up and running on newer firmwares. I've actually compiled my own copies for launching Godmode9 and Skeith in A9LH so I can launch them from my preferred "b9s/payloads" folder. I named them "GodLoader" and "SkeithLoader" respectively. Anyone still using my A9LH packs should love it.

So, you're saying that a "cp 0:/boot9strap/boot9strap.firm S:/firm0.bin" would work for installing B9S to the first partition, for example? Interesting. The "Install FIRM" feature seems to not like B9S for some reason, btw. As for the extracting thing, never mind. I was thinking of extracting a .firm file from an A9LH install that could be installed directly using that new "Install FIRM" option. Then it hit me later. A9LH uses console-specific info and could not be made a universal .firm file of anyway (then again, I guess "otp.bin" could be injected straight from M:/). Well, at least when you get that boot command added, my script that dumps OTP can run the installer at the end, reducing it to two steps. Not that I see myself getting that many requests going forward.

I have made some use of firm backups from the S: drive. I have scripts that can switch between A9LH and B9S now. I reused your script for the A9LH one, since the Safe B9S Installer conveniently provides the backups and everything, and just added commands to move payloads around, swap configuration files, etc. so that it has something to run upon completion. But I used the decrypted copies from S: to go back to B9S successfully.

Thanks for telling me how to do a proper safe restore. I'll be sure to put it to good use. And I'll be sure to include those checks when/if I go public with it. I have a hard mod and NTRBootHax, so worries here, but the last thing I would want is someone to brick using something I released.

 

[Asia81]

Is there a thread with a list of godmode9 scripts?

 

[Kazuma77]

Is there a thread with a list of godmode9 scripts?

Considering they're like bash scripts for the 3DS, that seems unlikely. But if you wait for my next AIO release, it's going to do most of what is possible with them

 

[d0k3]

So, you're saying that a "cp 0:/boot9strap/boot9strap.firm S:/firm0.bin" would work for installing B9S to the first partition, for example? Interesting. The "Install FIRM" feature seems to not like B9S for some reason, btw. As for the extracting thing, never mind. I was thinking of extracting a .firm file from an A9LH install that could be installed directly using that new "Install FIRM" option. Then it hit me later. A9LH uses console-specific info and could not be made a universal .firm file of anyway (then again, I guess "otp.bin" could be injected straight from M:/). Well, at least when you get that boot command added, my script that dumps OTP can run the installer at the end, reducing it to two steps. Not that I see myself getting that many requests going forward.

Make sure you don't forget about sector0x96 when actually doing an A9LH install. Also, re installing FIRMs by just copying - in that case you need to make absolutely sure you've got the correct sighax sig, otehrwise brick. Especially if you go public. I may change the sha command so it allows just checking part of a file (in that case, 0x100...0x200). Also, don't hesitate to ask if you need more functionality in scripting (additional commands, f.e.). Can't promise anything, but normally I add everything that has a plausible use case.

 

[DocKlokMan]

Make sure you don't forget about sector0x96 when actually doing an A9LH install. Also, re installing FIRMs by just copying - in that case you need to make absolutely sure you've got the correct sighax sig, otehrwise brick. Especially if you go public. I may change the sha command so it allows just checking part of a file (in that case, 0x100...0x200). Also, don't hesitate to ask if you need more functionality in scripting (additional commands, f.e.). Can't promise anything, but normally I add everything that has a plausible use case.

Got a question for you @d0k3, feel like your understanding of B9S would be able to answer his pretty easily.

I took a copy of S:/firm0.bin from a n2DS XL and another from an o3DS XL. Their SHAs were different but when I copied the firm0.bin from the n2DS XL to S:/firm0.bin & S:/firm1.bin of the o3DS XL, it still booted.

Question is, why were the SHAs different if the same firm file worked on both models?

 

[d0k3]

Got a question for you @d0k3, feel like your understanding of B9S would be able to answer his pretty easily.

I took a copy of S:/firm0.bin from a n2DS XL and another from an o3DS XL. Their SHAs were different but when I copied the firm0.bin from the n2DS XL to S:/firm0.bin & S:/firm1.bin of the o3DS XL, it still booted.

Question is, why were the SHAs different if the same firm file worked on both models?

Padding is the answer. The firm0.bin / firm1.bin files are each 4MB (on a standard NCSD partitioning), and we don't know what happens beyound the end of the actual FIRM payload. Compare these files, and you will see changes start onl later in teh file.

 

[DocKlokMan]

Padding is the answer. The firm0.bin / firm1.bin files are each 4MB (on a standard NCSD partitioning), and we don't know what happens beyound the end of the actual FIRM payload. Compare these files, and you will see changes start onl later in teh file.

Gotcha, thank you!

 

[windows_server_2003]

So the owners of this site can't be held liable. Keys are copyrighted.

OK.

 

[windows_server_2003]

@d0k3
Would you add a WARNING message when trying to run "firmware.bin" as firm image? I heard it will uninstall the B9S!
I'm sorry if it is already added.

 

[d0k3]

@d0k3
Would you add a WARNING message when trying to run "firmware.bin" as firm image? I heard it will uninstall the B9S!
I'm sorry if it is already added.

Umm... that's a mysterious filename, and you already get a warning message + button sequence everytime you tr to boot a firm.

 

[c4388354]

Would it be possible to add support to use the 'gateway red card' as a second 'sd card' slot so I can copy files to/from the gateway micro-sd card to/from the 3DS SD card?
(Mainly so I can dump a NAND backup to the 'Gateway Card', then I can easily transfer the backup to my computer instead of having to take the microSD out of my New3DS-XL)

I saw that someone managed to do it with decrypt9 with this 'gwcard' source code they wrote here: https://github.com/shinyquagsire23/gwcard

This repository contains source files for initializing and utilizing protocol in Gateway 3DS cartridges, and by derivation, Supercard DSTWO+ and possibly other clones.

A few quotes from the topic: https://www.reddit.com/r/3dshacks/c...an_old_gateway_use_the_blue_card_for/d6drcjl/

The red card is a pretty dank second SD slot if you integrate https://github.com/shinyquagsire23/gwcard with fatfs

All 3DS cards have to go through NTR mode before shifting to CTR mode, the Gateway red card just has extra steps.
Not a lot of developers apparently kept their cards though, and uncart is missing FIFO write, but it can read and write the raw SD sectors so it can work for FAT and file transfers.

The only thing the project does is provide a way to initialize the Gateway Card, and from there, execute commands with the card.
The regular CTRCARD read command just reads straight from the SD card, and the CARD2 commands (used to write non-locked NAND
on Pokemon games) can write to the SD card. You also have fun commands like the RGB LED, changing the card ID, etc.
With read/write you could just use it as a secondary SD card for things like Decrypt9.

You have to interface it with fatfs. For an additional fatfs device all it needs is an initialization function, a function to read one sector, a function
to write a sector, and a deinit. For the SD card it would use the sdmmc init, and then the sdmmc read/write function drivers. If you had some funky kind
of NAND, you would interface those drivers. So you just plug in all the required functions for the device and it can read/write the Gateway Card FAT.

I don't really know much programming, but this feature would be really nice to have (maybe have it as a 'G' drive?)

 

[The Catboy]

GM9 with top and bottom screens

So top down, bottom up?