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

[windows_server_2003]

@d0k3
Thank you for cleaning it and adding a lot of stuff !
I learned some basic coding rules.

Btw I MCU bricked mine(it's the actual brick, I can't even power it on), and at least I can't use one in this year. I may buy a new one next year(and a magnet and ...)
I already tested 'ssplit' and I'll make a PR.

 

[Kazuma77]

So, if Luma is installed to a FIRM partition, then you could use it like GM9? I didn't know that. Also, is .firm the format that the 3DS uses for firmwares, or is it just what sighax uses?
Also, please tell me what SSR means.

It will run. It has no special bootloader mode that pops up like GM9 does, though. On the positive side, it won't need boot.firm. On the negative side, you'll be at the mercy of Luma's chainloader regarding what you can run (granted, nothing you can't resolve with BootCTR9, and if you use CBM9 to launch it, you can even make it work in GUI mode), and every Luma update would have to be installed to the firm partitions. Sighax Updater will do it, but, fair warning, if you use any default or anticipated payload names aside from B9S and GM9 it will (and not very politely) refuse So if you're going to go there, name it something weird. And don't forget to setup a ".config" folder if you want payloads (any existing "luma/payloads" or "legacy/payloads" folder does get wiped to prevent undesired hotkey chaining).

Ugh, new tools, new trouble. Try removing the extension from the app files. Also have [number].tmd / [number].cetk

@Kazuma77
Actually, here's a nicer way of doing spaghetti code:

# Spaghetti Code sample

goto chooser

@choices_Preview_off
set PREVIEW_MODE off
goto chooser

@choices_Preview_quick
set PREVIEW_MODE quick
goto chooser

@choices_Preview_full
set PREVIEW_MODE full
goto chooser

@choices_Preview_PCX
set PREVIEW_MODE V:/GodMode9_splash.pcx
goto chooser

@choices_Preview_custom
set PREVIEW_MODE "Your text can be here"
input "Enter anything:" PREVIEW_MODE
goto chooser

@choices_Leave_script
goto outside

@chooser
labelsel -o "Choose preview mode" choices_*
goto chooser

@outside

So, it has labelsel, elif, and the new preview options. Nice. Looks like I have a lot of new things to test. Though I need to evaluate ssplit first.

Btw I MCU bricked mine(it's the actual brick, I can't even power it on), and at least I can't use one in this year. I may buy a new one next year(and a magnet and ...)
I already tested 'ssplit' and I'll make a PR.

Sorry to read that. Half of me wants to ask how, and the other half isn't sure they want to know. If you come up with any great ideas in the meantime, I would be more than willing to test them for you.

 

[windows_server_2003]

Sorry to read that. Half of me wants to ask how, and the other half isn't sure they want to know. If you come up with any great ideas in the meantime, I would be more than willing to test them for you.

Probably, I messed up the MCU register while trying to disable the LED via the i2c.
And I made a simple and important mistake in my code.

> testing
thank you, but I think it will be difficult. If I find nice idea, I may ask you helps.

 

[d0k3]

Probably, I messed up the MCU register while trying to disable the LED via the i2c.
And I made a simple and important mistake in my code.

> testing
thank you, but I think it will be difficult. If I find nice idea, I may ask you helps.

Okay, that's pretty bad. We're always warned about messing with the MCU registers, but rarely something bad happens. In fact @al3x_10m has messed with the MCU for weeks using a special version of GM9 and hasn't bricked so far. From what I know this far, actually changing the LED registers should not be too dangerous (although everyone and their momma believes so), but the "danger zone" (registers 0x05...0x07) is actually very critical (see here).

So.... can you perhaps explain the brick in a little more detail, for science? The bricking code would be great. I may actually know of someone who can fix this, but with no guarantees and you'd have to ship it internationally. You'd in essence have to donate it, and with some luck you'd get a working system back.

 

[d0k3]

So, it has labelsel, elif, and the new preview options. Nice. Looks like I have a lot of new things to test. Though I need to evaluate ssplit first.

I'll merge 'ssplit' into master today, though I may find a different name for the command. Also, think 'endif' would be a better fit than 'end'? Also, take note that the PCX thing will not slow down things. It will simply load the graphics file once, and that's it.

 

[SirNapkin1334]

Okay, that's pretty bad. We're always warned about messing with the MCU registers, but rarely something bad happens. In fact @al3x_10m has messed with the MCU for weeks using a special version of GM9 and hasn't bricked so far. From what I know this far, actually changing the LED registers should not be too dangerous (although everyone and their momma believes so), but the "danger zone" (registers 0x05...0x07) is actually very critical (see here).

So.... can you perhaps explain the brick in a little more detail, for science? The bricking code would be great. I may actually know of someone who can fix this, but with no guarantees and you'd have to ship it internationally. You'd in essence have to donate it, and with some luck you'd get a working system back.

Could you potentially fix it by flashing a backup of the MCU FW?
Also, thanks for clearing up the brick misconception. I had also thought it was caused by a bad LED state, but I guess it's just from writing to the wrong place? Why wouldn't they make the unlock sequence read-only?

 

[Deleted User]

@d0k3 @SirNapkin1334 was asking me to make my mod autoboot into itself if no payload is found so i did this
works perfectly and has no build errors or warnings
ive gone and tested it entirely and it doesnt cause any problems
do you think its somewhat worthy of being in GodMode9?

         if (IsBootableFirm(firm_in_mem, FIRM_MAX_SIZE)) BootFirm(firm_in_mem, "sdmc:/bootonce.firm");
         for (u32 i = 0; i < sizeof(bootfirm_paths) / sizeof(char*); i++) {
             BootFirmHandler(bootfirm_paths[i], false, (BOOTFIRM_TEMPS >> i) & 0x1);
        if (bootloader) {//Megumin is the best girl!
            godmode9 = true;//~Eix
        }

https://github.com/eiiiiix/EixMode9...20#diff-4cade01509e33489192816bc32e95712R1951

 

[windows_server_2003]

I'll merge 'ssplit' into master today, though I may find a different name for the command. Also, think 'endif' would be a better fit than 'end'? Also, take note that the PCX thing will not slow down things. It will simply load the graphics file once, and that's it.

For the command names, I leave it to you.
I know PCX won't slow down. but while Luma uses raw image as splash screen and don't PCX, most people will use raw format. so supporting it would be good.

 

[Kazuma77]

I'll merge 'ssplit' into master today, though I may find a different name for the command. Also, think 'endif' would be a better fit than 'end'? Also, take note that the PCX thing will not slow down things. It will simply load the graphics file once, and that's it.

OK, I'll wait for you to decide on what would be a good name then, so I won't have to change it twice. Maybe "fsplit" would be good. Then again, that kind of implies splitting the file. So, maybe "nsplit" since it's the name that's getting split, or "vsplit" since it's a variable being split. As far as "endif" is concerned, well, do we have other conditionals that need a termination command? I could see doing this to clarify if we need to "end" more than one thing. If it's just going to be "if" though, it seems like a lot of unnecessary changes. I can use Notepad++ to search and replace, but I would have to double check all text in the scripts for things like "process has endifed" for example. If you're not going to be able to let it go, though, better off changing it now than in 6 months.

 

[Larsenv]

Ugh, new tools, new trouble. Try removing the extension from the app files. Also have [number].tmd / [number].cetk[/CODE]

I removed the .app extension, and now the CIA builds fine so I can actually have it decrypted.

 

[windows_server_2003]

@d0k3
Arithmetic in GM9 scripts is great with control flow commands.
Why not just use standard c library(stdlib.h strtod()) to convert string to double and calculate them ?

 

[zoogie]

Surprised nobody has mentioned this yet
https://github.com/d0k3/GodMode9/releases/tag/v1.5.0

I really like the TAD mount feature.
However, I do tend to be partial to dsiware things.
check the thanks section

 

[Eddypikachu]

Hey I dumped my puyo puyo chronicles game as a cia and I tried decrypting it so I can get the romfs and exefs folders to edit stuff but when I go to cia image options and try to decrypt it says its not encrypted and I choosing the right option to get the romfs folder or is there another way to get it?

 

[SirNapkin1334]

Hey I dumped my puyo puyo chronicles game as a cia and I tried decrypting it so I can get the romfs and exefs folders to edit stuff but when I go to cia image options and try to decrypt it says its not encrypted and I choosing the right option to get the romfs folder or is there another way to get it?

CIA IMAGE OPTIONS->Mount Image To Drive, go into folder, there should be exefs and romfs.

 

[TurdPooCharger]

Hey, I signed up for gbatemp so I could post about finding a bug on GodMode9 v1.5.0. I tried signing up at GitHub to file an issue there, but my account got instant banned for trying to use a disposable e-mail. Whoops, lol.

I was following the guide.3ds instructions to do a fresh install of Luma3DS v9.0, boot9strap v1.3, etc. on a New 3DS (original). Using the latest GodMode9 under emuNAND, all the .3ds files converted and built into .cia format causes the file sizes to double to the nearest 256 MB size.

After some 12 hours of conversion and then hopping over to FBI v2.4.14, none of the .cia batch files would install. I originally thought the problem was due to needing to update my title keys (I’m still fuzzing about this subject) after using TIKDevil, freeshop, Decrypt9WIP, but this problem still persisted.

The problem was recreate-able on a second, older CFWed N3DSXL that I own when it was updated to the latest GodMode9/Luma 3DS/boot9strap. When I reinstalled GodMode9 v1.4.3, CIA test building several .3ds files went back to outputting the correct trim sized .cia files that are installable on FBI.

Not to wish that there is a bug in your program because GodMode9 is damn mighty awesome and perfect in pretty much every conceivable aspect at this point user-friendly and programming wise, but I do hope I get my name added in your shout out.

 

[SirNapkin1334]

Hey, I signed up for gbatemp so I could post about finding a bug on GodMode9 v1.5.0. I tried signing up at GitHub to file an issue there, but my account got instant banned for trying to use a disposable e-mail. Whoops, lol.

I was following the guide.3ds instructions to do a fresh install of Luma3DS v9.0, boot9strap v1.3, etc. on a New 3DS (original). Using the latest GodMode9 under emuNAND, all the .3ds files converted and built into .cia format causes the file sizes to double to the nearest 256 MB size.

After some 12 hours of conversion and then hopping over to FBI v2.4.14, none of the .cia batch files would install. I originally thought the problem was due to needing to update my title keys (I’m still fuzzing about this subject) after using TIKDevil, freeshop, Decrypt9WIP, but this problem still persisted.

The problem was recreate-able on a second, older CFWed N3DSXL that I own when it was updated to the latest GodMode9/Luma 3DS/boot9strap. When I reinstalled GodMode9 v1.4.3, CIA test building several .3ds files went back to outputting the correct trim sized .cia files that are installable on FBI.

Not to wish that there is a bug in your program because GodMode9 is damn mighty awesome and perfect in pretty much every conceivable aspect at this point user-friendly and programming wise, but I do hope I get my name added in your shout out.

Actually, this is not in 5.0.0. A few days ago, having built from the (then) latest commit, just before 5.0.0, I could not dump my MK7 cart. I verified the cart's .3ds and .trim.3ds, they passed, but the trim.cia I built didn't work, verification failed and FBI did not accept it.

 

[TurdPooCharger]

Actually, this is not in 5.0.0. A few days ago, having built from the (then) latest commit, just before 5.0.0, I could not dump my MK7 cart. I verified the cart's .3ds and .trim.3ds, they passed, but the trim.cia I built didn't work, verification failed and FBI did not accept it.

So you are having problems with the CIA build function as well, and it's not just me? Can you clarify what you mean in 5.0.0? I think you meant v1.5.0 for GodMode9 as that's what the GitHub states it as, or are you referring to another app?

Edit: Oh, you have an issue with mounting an CIA file, correct? I wonder what broke the code lol.

 

[SirNapkin1334]

So you are having problems with the CIA build function as well, and it's not just me? Can you clarify what you mean in 5.0.0? I think you meant v1.5.0 for GodMode9 as that's what the GitHub states it as, or are you referring to another app?

Edit: Oh, you have an issue with mounting an CIA file, correct? I wonder what broke the code lol.

Ooops, I mean 1.5.0. No I meant building them. I was trying to dump my cart to .trim.cia, but there was some problem, FBI was rejecting it halfway through and it also failed the Verification Check (whatever that does...)

 

[TurdPooCharger]

Ooops, I mean 1.5.0. No I meant building them. I was trying to dump my cart to .trim.cia, but there was some problem, FBI was rejecting it halfway through and it also failed the Verification Check (whatever that does...)

Something in the latest build is causing the converted files not to properly trim, and that makes FBI not happy because the hash sum check doesn't match what it's expecting it to be. Try using v1.4.3 for the time being as that worked when I was converting .3ds files to .cia. I have no physical game cart to help verify if this root problem goes back to the older version.

 

[TurdPooCharger]

Hey I dumped my puyo puyo chronicles game as a cia and I tried decrypting it so I can get the romfs and exefs folders to edit stuff but when I go to cia image options and try to decrypt it says its not encrypted and I choosing the right option to get the romfs folder or is there another way to get it?

I dunno if GodMode9 can extract a decrypted .cia into their romfs and exefs components. There is a program called ctrtool you run on desktop that can produce those folders @ github ... /profi200/Project_CTR/releases

Here's the instruction on how to use it:

@ github ... /ihaveamac/3DS-rom-tools/wiki/Extract-a-game-or-application-in-.cia-format

Edit : @Eddypikachu Nevermind! I figured out how you extract the files in a decrypted CIA.

- In GodMode9, hover over your .cia file and press A.
- Select CIA image options...
- Select Mount image to drive and press <A> yes. You should now be in [G:] CIA GAME IMAGE which list all the files within the mounted CIA.
- Hold the L-shoulder button and scroll down to highlight everything in yellow.
- Press A on one of the '.bin' or '.app' items you've selected. The first one/two items listed with a bunch of numbers and zeros are directories.
- You should now see on the bottom screen the option Copy to 0:/gm9/out . Select <A> yes.
- In the gm9/out folder, you should find all the extracted files from your CIA which you can now copy over to your computer to edit and rebuild.