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

[nl255]

Would it be possible to make it so that firm0/firm1 write permissions are separate from the normal sysnand/emunand write permission? That would make it somewhat safer for a9lh users since firm0/firm1 would remain read only (unless separately overridden) even when the rest of the system is writable.

 

[pikatsu]

Occasional failed boots on HBL are normal, as the Brahma entrypoint is not perfectly stable.


Sure there is! With A9LH installed, you have access to Select9 and CTR Boot Manager9. Without A9LH, you still have CTR Boot Manager (which you'd have to use as a HBL replacement). In general, Homebrew Launcher is a better entrypoint than MSET and A9LH > HBL > MSET.

Thanks for the explaining. Is Ctr bootmanager9 this or there is another one? https://github.com/Cpasjuste/CtrBootManager
and an other one question: does boot.3dsx files have slow boot rate?

 

[democracy]

Would it be possible to make it so that firm0/firm1 write permissions are separate from the normal sysnand/emunand write permission? That would make it somewhat safer for a9lh users since firm0/firm1 would remain read only (unless separately overridden) even when the rest of the system is writable.

If it were a Linux system perhaps, don't know about 3ds though

 

[d0k3]

Would it be possible to make it so that firm0/firm1 write permissions are separate from the normal sysnand/emunand write permission? That would make it somewhat safer for a9lh users since firm0/firm1 would remain read only (unless separately overridden) even when the rest of the system is writable.

If it were a Linux system perhaps, don't know about 3ds though

It would, but it would only serve to make things more complicated. All you have to do to keep FIRM unchanged is not write to the FIRM0.bin / FIRM1.bin and NAND.bin virtual files. If you want a A9LH preserving restore option, use D9WIP.

Thanks for the explaining. Is Ctr bootmanager9 this or there is another one? https://github.com/Cpasjuste/CtrBootManager
and an other one question: does boot.3dsx files have slow boot rate?

Yes. And no, boot.3dsx has a perfect boot rate.

 

[Kazuma77]

Occasional failed boots on HBL are normal, as the Brahma entrypoint is not perfectly stable.


Sure there is! With A9LH installed, you have access to Select9 and CTR Boot Manager9. Without A9LH, you still have CTR Boot Manager (which you'd have to use as a HBL replacement). In general, Homebrew Launcher is a better entrypoint than MSET and A9LH > HBL > MSET.

Don't forget BootCTR and BootCTR9. Another hotkey option, but with a configuration file. With the former, you can have hotkeys in MenuHax. I used to run CTR Boot Manager myself before switching to A9LH. I should probably explain at this time that I used the "Cakes" option because it's actually a "BootCTR9" option that sets Cakes up as one of the choices. However, I've actually got AuReiNAND as the default for several reasons. I just don't use it's chain loader because it seems to have a slight delay booting tools like D9, whereas BootCTR9 doesn't seem to slow AuReiNAND down noticeably at all. Since that was part of the tutorial, I wasn't aware there was a CBM9 at first, but I think I've decided I like the hotkeys more. Though I have downloaded CBM9 to try it out.

Interestingly, the regular BootCTR .3dsx has the name of the .ini file in plain text. You can easily change it with a hex editor so that you can run both on the same system. Very useful if you have a Gateway while we wait for the GW A9LH payload to hit. I've setup MenuHax to L on my 9.2 EmuNAND (because AuReiNAND uses L to boot EmuNAND using NATIVE_FIRM 9.0), and I've set the BootCTR default to Gateway (and I put the HBL menu to B just for a faster way to launch it). With that setup, I can just hold L to boot GW (I want it to stop at the menu anyway, so I can pick SysNAND mode).

Oh yeah, I noticed something weird on my EUR N3DS XL. For some odd reason, GodMode9 gives me "Warning: slot0x05 crypto fail! Could not set up slot0x05keyY. Continue?" when it starts up. It's only doing it on the EUR (Australian) device. Creating "aeskeydb.bin" in Decrypt9 caused the message to go away, so, it's not even a problem now. Still, I thought you (and anyone else with an AUS unit) might want to know.

 

[3xkrazy]

Oh yeah, I noticed something weird on my EUR N3DS XL. For some odd reason, GodMode9 gives me "Warning: slot0x05 crypto fail! Could not set up slot0x05keyY. Continue?" when it starts up. It's only doing it on the EUR (Australian) device. Creating "aeskeydb.bin" in Decrypt9 caused the message to go away, so, it's not even a problem now. Still, I thought you (and anyone else with an AUS unit) might want to know.

@d0k3

I'm getting the same with the latest github commit.

 

[d0k3]

Oh yeah, I noticed something weird on my EUR N3DS XL. For some odd reason, GodMode9 gives me "Warning: slot0x05 crypto fail! Could not set up slot0x05keyY. Continue?" when it starts up. It's only doing it on the EUR (Australian) device. Creating "aeskeydb.bin" in Decrypt9 caused the message to go away, so, it's not even a problem now. Still, I thought you (and anyone else with an AUS unit) might want to know.

@d0k3I'm getting the same with the latest github commit.

Are both of your N3DSes (these are N3DSes, right?) AUS units? Running from A9LH? Do the CTRNAND partitions show up in GodMode9? And, did you have the slot0x05keyY.bin file before you got that message?

Background to this: That message only comes up if GodMode9 can't verify slot 0x05 crypto. In theory, that happens in two cases.. (1) on A9LH, if you don't have the slot0x05keyY.bin or aeskeydb.bin file, (2) if you have a corrupt slot0x05keyY.bin or aeskeydb.bin file. In that case, on N3DS (not on O3DS) we would not have access to the CTRNAND partition.

I also already have a suspicion what may cause this, and if one of you (or both!) could dump the first 16 byte of their decrypted CTRNAND_fat.bin, I could verify.

 

[3xkrazy]

Are both of your N3DSes (these are N3DSes, right?) AUS units? Running from A9LH? Do the CTRNAND partitions show up in GodMode9? And, did you have the slot0x05keyY.bin file before you got that message?

Background to this: That message only comes up if GodMode9 can't verify slot 0x05 crypto. In theory, that happens in two cases.. (1) on A9LH, if you don't have the slot0x05keyY.bin or aeskeydb.bin file, (2) if you have a corrupt slot0x05keyY.bin or aeskeydb.bin file. In that case, on N3DS (not on O3DS) we would not have access to the CTRNAND partition.

I also already have a suspicion what may cause this, and if one of you (or both!) could dump the first 16 byte of their decrypted CTRNAND_fat.bin, I could verify.

JP n3ds w/ a9lh. After generating aeskeydb.bin with Decrypt9, GodMode9 stops displaying the error message. I've been using the same slot0x05KeyY.bin since the beginning.

 

[d0k3]

JP n3ds w/ a9lh. After generating aeskeydb.bin with Decrypt9, GodMode9 stops displaying the error message. I've been using the same slot0x05KeyY.bin since the beginning.

Okay, that helps! That aeskeydb.bin file... is it in the Decrypt9/ folder or in the SD root now? What happens if you move it?

 

[3xkrazy]

Okay, that helps! That aeskeydb.bin file... is it in the Decrypt9/ folder or in the SD root now? What happens if you move it?

I never made a Decrypt9/ folder

 

[driverdis]

i'm pretty sure any cfw other than aureinand will let you access recovery to cancel an update. I was also under the impression doing this will not brick, only if you choose to proceed with recovery action while on a9lh may it brick or uninstall a9lh.

Anyone else know the answer to this? Anyways, if I were still using emunand at this point I'd also have an updated sysnand too, perhaps you must have gateway I guess?

Even accessing recovery on a A9LH New 3DS will brick it. However, it does not brick Old 3DS.

 

[Kazuma77]

Are both of your N3DSes (these are N3DSes, right?) AUS units? Running from A9LH? Do the CTRNAND partitions show up in GodMode9? And, did you have the slot0x05keyY.bin file before you got that message?

Background to this: That message only comes up if GodMode9 can't verify slot 0x05 crypto. In theory, that happens in two cases.. (1) on A9LH, if you don't have the slot0x05keyY.bin or aeskeydb.bin file, (2) if you have a corrupt slot0x05keyY.bin or aeskeydb.bin file. In that case, on N3DS (not on O3DS) we would not have access to the CTRNAND partition.

I also already have a suspicion what may cause this, and if one of you (or both!) could dump the first 16 byte of their decrypted CTRNAND_fat.bin, I could verify.

Well, I've had the slot0x05KeyY.bin file on the device the entire time. So it can't be case 1. And Decrypt9 used the file to build a working aeskeydb.bin, so it can't be case 2 either. Actually, I've just confirmed my USA N3DS XL does the same. It's just that I had already created aeskeydb.bin before updating from v0.20 so I hadn't noticed. I delete it and it had the same issue. Rebuilt aeskeydb.bin and it and it went away again. The functionality of aeskeydb.bin does not seem to matter whether I leave it in the Decrypt9 folder or move it to the root (well, technically, copy it to the root and delete it from Decrypt9, since there is no "move" function yet). CTRNAND is indeed not an option when it gives this error, as you would expect. With the aeskeydb.bin in place, the first 16 bytes on that .bin file are E9 00 00 43 54 52 20 20 20 20 20 00 02 40 01 00 on the EUR and USA devices (I'm using "SYSNAND VIRTUAL" and the hex viewer to get that, if that matters -- makes little sense copying 1 GB of data to get 16 bytes after all).

Now, I used the files from the data_input.zip provided by the A9LH tutorial. Is it possible that part of the problem is that I should have dumped my own firm0, firm1, and secret sector files? I was under the impression that they must be all the same if a distributed copy can work in the first place, but I can extract them from EmuNAND (being it's a copy of my pre-A9LH SysNAND) and reinstall A9LH if it matters.

 

[d0k3]

Well, I've had the slot0x05KeyY.bin file on the device the entire time. So it can't be case 1. And Decrypt9 used the file to build a working aeskeydb.bin, so it can't be case 2 either. Actually, I've just confirmed my USA N3DS XL does the same. It's just that I had already created aeskeydb.bin before updating from v0.20 so I hadn't noticed. I delete it and it had the same issue. Rebuilt aeskeydb.bin and it and it went away again. The functionality of aeskeydb.bin does not seem to matter whether I leave it in the Decrypt9 folder or move it to the root (well, technically, copy it to the root and delete it from Decrypt9, since there is no "move" function yet). CTRNAND is indeed not an option when it gives this error, as you would expect. With the aeskeydb.bin in place, the first 16 bytes on that .bin file are E9 00 00 43 54 52 20 20 20 20 20 00 02 40 01 00 on the EUR and USA devices (I'm using "SYSNAND VIRTUAL" and the hex viewer to get that, if that matters -- makes little sense copying 1 GB of data to get 16 bytes after all).

Now, I used the files from the data_input.zip provided by the A9LH tutorial. Is it possible that part of the problem is that I should have dumped my own firm0, firm1, and secret sector files? I was under the impression that they must be all the same if a distributed copy can work in the first place, but I can extract them from EmuNAND (being it's a copy of my pre-A9LH SysNAND) and reinstall A9LH if it matters.

Well, actually I messed up loading from slot0x05keyY.bin and I think that is the cause. With the latest commit, could you compile fresh and try without the aeskeydb.bin (but with slot0x05keyY.bin, obviously)? It should work now.

 

[d0k3]

Here's a new major, stable release. This is new:

• You can now mount NAND and FAT images and use them as additional drive(s)
• Hexviewer for files from any locations
• Virtual Memory drive added (allows you to view and dump certain memory regions)
• Dual pane handling added, switch with R + (Right / Left)
• Vastly improved button react times on O3DS (thanks @AuroraWright)
• More useful info displayed in directory view
• Fixed filename input dialogue (this would fail on rare occasions)
• Fixed case sensitive renaming
• Some minor bugfixes

Also, to those of you who are not using this tool because you are too scared of it's possibilities... See that colored bar on top? As long as that is green, you have write permissions only for the SD card, meaning nothing bad can happen. Giving extended write permissions requries entering a button sequence. Even if the bar is yellow or red (for EmuNAND / SysNAND writing permissions), it is still in your hands, this tool won't do anything funny on it's own. If you can't handle this responsibility, keep away from this tool, otherwise there is nothing to be scared of.

 

[Kazuma77]

Well, actually I messed up loading from slot0x05keyY.bin and I think that is the cause. With the latest commit, could you compile fresh and try without the aeskeydb.bin (but with slot0x05keyY.bin, obviously)? It should work now.

I don't think I have the 3DS dev kit installed, just the PS3 one (even that's not updated -- the last time I used it was to help someone that was creating a Cinavia patch tool). Call me lazy I guess. It's probably not a good time to install it now either. I'm about to switch from an ATI card to an Nvidia. So I'm probably looking at a fresh Windows install (oh well, haven't been doing those as often as I should anyway). Besides, I've got someone wanting their PC looked at (typical malware infestation), so, not going to have much time today. If it's not too much trouble, can you upload another pre-compiled file?

Here's a new major, stable release. This is new:

• You can now mount NAND and FAT images and use them as additional drive(s)
• Hexviewer for files from any locations
• Virtual Memory drive added (allows you to view and dump certain memory regions)
• Dual pane handling added, switch with R + (Right / Left)
• Vastly improved button react times on O3DS (thanks @AuroraWright)
• More useful info displayed in directory view
• Fixed filename input dialogue (this would fail on rare occasions)
• Fixed case sensitive renaming
• Some minor bugfixes

View attachment 45547 View attachment 45548 View attachment 45549 View attachment 45555

Also, to those of you who are not using this tool because you are too scared of it's possibilities... See that colored bar on top? As long as that is green, you have write permissions only for the SD card, meaning nothing bad can happen. Giving extended write permissions requries entering a button sequence. Even if the bar is yellow or red (for EmuNAND / SysNAND writing permissions), it is still in your hands, this tool won't do anything funny on it's own. If you can't handle this responsibility, keep away from this tool, otherwise there is nothing to be scared of.

Damn, that was fast

 

[d0k3]

I don't think I have the 3DS dev kit installed, just the PS3 one (even that's not updated -- the last time I used it was to help someone that was creating a Cinavia patch tool). Call me lazy I guess. It's probably not a good time to install it now either. I'm about to switch from an ATI card to an Nvidia. So I'm probably looking at a fresh Windows install (oh well, haven't been doing those as often as I should anyway). Besides, I've got someone wanting their PC looked at (typical malware infestation), so, not going to have much time today. If it's not too much trouble, can you upload another pre-compiled file?

See above . It is already fixed, but you may try with the newest release.

 

[3xkrazy]

@d0k3

Offtopic: Any chance of bringing https://github.com/d0k3/uncart up to date with a9lh compatibility?

@Shadowtrance uploaded a binary with nice purple font way back, but never provided the sources.

 

[Shadowtrance]

@d0k3

Offtopic: Any chance of bringing https://github.com/d0k3/uncart up to date with a9lh compatibility?

@Shadowtrance uploaded a binary with nice purple font way back, but never provided the sources.

No one asked for the source. (hint, it's on my github and not much needs changing to work on a9lh).

 

[3xkrazy]

No one asked for the source. (hint, it's on my github and not much needs changing to work on a9lh).

Yea, I was looking at the change log and the last commit was in August, 2015. I'll compile it to see if it's the same. Thanks.

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

Yea, I was looking at the change log and the last commit was in August, 2015. I'll compile it to see if it's the same. Thanks.

Spoiler: error

arm-none-eabi-gcc -MMD -MP -MF /home/hle/src/uncart/brahma_loader/build/main.d -g -Wall -O3 -mword-relocations -fomit-frame-pointer -ffast-math -march=armv6k -mtune=mpcore -mfloat-abi=hard -I/home/hle/src/uncart/brahma_loader/include -I/home/hle/.bin/devkitPro/libctru/include -I/home/hle/src/uncart/brahma_loader/build -DPAYLOAD=\"Uncart.bin\" -DARM11 -D_3DS -DARM_ARCH -w -c /home/hle/src/uncart/brahma_loader/source/main.c -o main.o
/home/hle/src/uncart/brahma_loader/source/main.c: In function 'main':
/home/hle/src/uncart/brahma_loader/source/main.c:9:5: error: too many arguments to function 'hidInit'
     hidInit(NULL);

I'm not sure if this has anything to do with libctru, but is it updated for the latest libctru?

 

[internetakias]

Occasional failed boots on HBL are normal, as the Brahma entrypoint is not perfectly stable.


Sure there is! With A9LH installed, you have access to Select9 and CTR Boot Manager9. Without A9LH, you still have CTR Boot Manager (which you'd have to use as a HBL replacement). In general, Homebrew Launcher is a better entrypoint than MSET and A9LH > HBL > MSET.

Speaking of CTRBM9, trying to load GodMod9 with it doesn't work. AuReiNand's payload chainloader works, though.