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

c4388354 · Sep 15, 2017

small bug report?
M:\nand_cid.mem is actually the sd_cid.
and
M:\sd_cid.mem is actually the nand_cid, (the 'sd-cid' file is the same the 'nand_cid' file in the 'S:\essentials.exefs')

edit: Decrypt9 shows the NAND_CID when you do a 'system info', which is the same
as the contents of 'M:\sd_cid.mem' so the 'M drive' files are most likely reversed.

---

https://github.com/d0k3/GodMode9/blob/master/source/virtual/vmem.c#L85

Code:

    { "sd_cid.mem"       , VMEM_CALLBACK_FLASH_CID    , 0x00000010, 0x01, VFLAG_CALLBACK | VFLAG_READONLY },
    { "nand_cid.mem"     , VMEM_CALLBACK_FLASH_CID    , 0x00000010, 0x00, VFLAG_CALLBACK | VFLAG_READONLY }

https://github.com/d0k3/GodMode9/blob/master/source/virtual/vmem.c#L148

Code:

// Read NAND / SD CID.
int ReadVMemFlashCID(const VirtualFile* vfile, void* buffer, u64 offset, u64 count) {
    // NAND CID if keyslot field != 0.
    bool is_nand = (bool)vfile->keyslot;
    
    u32 cid[4]; // CID is 16 byte in size
    sdmmc_get_cid(is_nand, (u32*) cid);
    memcpy(buffer, ((u8*) cid) + offset, count);
    return 0;
}

https://github.com/d0k3/GodMode9/blob/master/source/virtual/vmem.c#L151

Code:

bool is_nand = (bool)vfile->keyslot;

at line 85, the 'nand_cid.mem' sets 'keyslot' to 0x00
when 'vfile / keyslot' is 0x00, then this sets is_nand to 0 (False).

at line 86, the 'sd_cid.mem' sets 'keyslot' to 0x01
when 'vfile / keyslot' is 0x01, then this sets is_nand to 1 (True).

so at line 85, switch the filenames OR switch the values of 'keyslot'

---

another small one:

in S: SYSNAND Virtual, the 'agbsave.bin' file needs its size changed from 0x00030000 (~192kb) to 0x00040400 (~257kb) to support the 1mbit savesize of GBA games, same for the X: NAND XORPADs drive as well. (agbsave.bin.xorpad)

https://www.reddit.com/r/3dshacks/comments/6znqqg/

TL;DR: 1Mbit games work with no patches at all, all they need is support from GBA injectors, specifically a
savefile size of 0x00040400 vs 0x00030000 in the exheader and TMD of the game (savefile size is specified at 0x1C0 in
the exheader), other than a 1Mbit save flag in the ROM footer (documented on the 3dbrew link above).

d0k3 · Sep 16, 2017

Kazuma77 said:
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).

I'd use 'verify' before restoring, this is actually more important than the .SHA check. Also, unsure if it's a good idea to have a full NAND restore in there cause noobs. Also, an optional SHA check does not make much sense, cause even on a failed check, the script would continue.

c4388354 said:
small bug report?
M:\nand_cid.mem is actually the sd_cid.
and
M:\sd_cid.mem is actually the nand_cid, (the 'sd-cid' file is the same the 'nand_cid' file in the 'S:\essentials.exefs')

Thanks! That one slipped through. Also, good catch!

c4388354 said:
in S: SYSNAND Virtual, the 'agbsave.bin' file needs its size changed from 0x00030000 (~192kb) to 0x00040400 (~257kb) to support the 1mbit savesize of GBA games, same for the X: NAND XORPADs drive as well. (agbsave.bin.xorpad)

https://www.reddit.com/r/3dshacks/comments/6znqqg/

192kB is the size of the AGBSAVE partition, there's no way to make this bigger (or smaller). You'd actually have to repartition your NAND to accomplish that goal.

Kazuma77 · Sep 16, 2017

d0k3 said:
I'd use 'verify' before restoring, this is actually more important than the .SHA check. Also, unsure if it's a good idea to have a full NAND restore in there cause noobs. Also, an optional SHA check does not make much sense, cause even on a failed check, the script would continue.

A NAND backup with A9LH would fail to verify though, wouldn't it? That's why I only verify firm1.bin (except for the safe restore, since it isn't copying over the firms). The scripts ask the user if they want to proceed after the SHA check, so they can back out (or not) if it fails. Though I guess that's not great if you want to set it, walk away, and come back in 10 minutes. Maybe I just shouldn't bother doing one with the EmuNAND and Safe SysNAND options, since they can't actually brick a device anyway. Then lock the "full" one down with a verify. Then make a "forced full" with a mandatory SHA check and a strong warning, so that an A9LH NAND can be restored if desired. As for the noobs, I'm thinking the worst that can happen is they end up on retail (presumably an exploitable version, otherwise they wouldn't have a backup). If they can't figure out what "full" means, they'll know after redoing their exploit.

EDIT: These are the ones I think I'm going with. Whether you want to use them or not, that's your call. And feel free to change them to suit your needs.

EDIT2: Just saw the new option to disable the preview recently. It's a good thing I have batch files helping me update my AIO. This could be an all day job

. Not that I mind it so much on regular scripts, but I think SSRs will look more professional with it off.

DarkIrata · Sep 16, 2017

Heyho!
Having a bricked o3ds (bluescreen, nand restore failed.. wuubs) and thanks to ntrhax i though to maybe reflash my backup with gm9.
Version 1.4.0 is the only thing i got to work with the o3ds. Buut it stucks at loading when booting into gm9 by ntrhax. Any ideas?

Kazuma77 · Sep 17, 2017

DarkIrata said:
Heyho!
Having a bricked o3ds (bluescreen, nand restore failed.. wuubs) and thanks to ntrhax i though to maybe reflash my backup with gm9.
Version 1.4.0 is the only thing i got to work with the o3ds. Buut it stucks at loading when booting into gm9 by ntrhax. Any ideas?

Hmm, I've never had a problem with it getting stuck in NTRBoothax. Can you run CBM9? If so, maybe you could launch GM9 from that. It shouldn't be necessary, but it may work. I could make my NAND restore script into a standalone script runner, which you could then try to launch from the CBM9 menu or directly. I have the latest commit built, so, you could see if that makes a difference.

EDIT: I made the SSR. I named it "SysNAND9"

. Hope it helps. Anyone else reading this, keep in mind this is ONLY for performing a full restore. If it protected your exploit, it couldn't restore a bricked device. Use at your own risk.

nitrozz · Sep 17, 2017

noob question:
how to upgrade godmod9 from 1.3 to 1.4

windows_server_2003 · Sep 17, 2017

nitrozz said:
noob question:
how to upgrade godmod9 from 1.3 to 1.4

Download from the link below and extract. Then copy and overwrite "Godmode9.firm" to /luma/payload/Godmode9.firm (or same path as previous version's one). Launch it by the same way you were doing before updating.
https://github.com/d0k3/GodMode9/releases

DarkIrata · Sep 17, 2017

Kazuma77 said:
Hmm, I've never had a problem with it getting stuck in NTRBoothax. Can you run CBM9? If so, maybe you could launch GM9 from that. It shouldn't be necessary, but it may work. I could make my NAND restore script into a standalone script runner, which you could then try to launch from the CBM9 menu or directly. I have the latest commit built, so, you could see if that makes a difference.

EDIT: I made the SSR. I named it "SysNAND9" . Hope it helps. Anyone else reading this, keep in mind this is ONLY for performing a full restore. If it protected your exploit, it couldn't restore a bricked device. Use at your own risk.

Mhmm does CBM9 has a NTRBoot version?
Got the same behaviour with your attched files.

Kazuma77 · Sep 17, 2017

DarkIrata said:
Mhmm does CBM9 has a NTRBoot version?
Got the same behaviour with your attched files.

So you're using the NTRBoot versions straight from the cart? Hmm, something could be broken in the NTRBoot build. Try just using B9S on the cart, and use regular "Godmode9.firm" as "boot.firm" instead. That should work. If not, try using CBM9 as the "boot.firm" and make sure Godmode9 is an entry in the "a9lh.cfg" configuration file.

DarkIrata · Sep 17, 2017

Kazuma77 said:
So you're using the NTRBoot versions straight from the cart? Hmm, something could be broken in the NTRBoot build. Try just using B9S on the cart, and use regular "Godmode9.firm" as "boot.firm" instead. That should work. If not, try using CBM9 as the "boot.firm" and make sure Godmode9 is an entry in the "a9lh.cfg" configuration file.

B9S gives me just a black screen.
Wil ltry it later, ty

Kazuma77 · Sep 17, 2017

DarkIrata said:
B9S gives me just a black screen.
Wil ltry it later, ty

Hmm, I don't know then. I can't replicate your problem. B9S boots me straight into GM9. Maybe it's just failing to activate? It happens to me sometimes. I'll have the magnet perfectly placed and everything, and it just doesn't go for some reason and I have to retry. Though my AK2i is still on 1.2 (since there doesn't seem to be much of a reason to update it to 1.3).

Maybe an older version would work. If the NTRBoot build is broken, I'm sure it would help d0k3 knowing where. You might try these.

AwesomeSaucemGuy · Sep 18, 2017

Noob question: GodMode9 1.4.0 asks me to set the RTC date and time since it's wrong. What do I say?

d0k3 · Sep 18, 2017

AwesomeSaucemGuy said:
Noob question: GodMode9 1.4.0 asks me to set the RTC date and time since it's wrong. What do I say?

That goes at least in the top 10 of questions that you guys should already know the answer for -_-. Maybe, try, you know, the current date and time?

Kazuma77 said:
A NAND backup with A9LH would fail to verify though, wouldn't it? That's why I only verify firm1.bin (except for the safe restore, since it isn't copying over the firms). The scripts ask the user if they want to proceed after the SHA check, so they can back out (or not) if it fails. Though I guess that's not great if you want to set it, walk away, and come back in 10 minutes. Maybe I just shouldn't bother doing one with the EmuNAND and Safe SysNAND options, since they can't actually brick a device anyway. Then lock the "full" one down with a verify. Then make a "forced full" with a mandatory SHA check and a strong warning, so that an A9LH NAND can be restored if desired. As for the noobs, I'm thinking the worst that can happen is they end up on retail (presumably an exploitable version, otherwise they wouldn't have a backup). If they can't figure out what "full" means, they'll know after redoing their exploit.

I'll see about including those scripts, if you have newer versions, please upload. Also, the verify - the only condition for a NAND backup to be recognized as valid is *one* valid FIRM partition, so, no, it won't fail.

Kazuma77 · Sep 18, 2017

d0k3 said:
That goes at least in the top 10 of questions that you guys should already know the answer for -_-. Maybe, try, you know, the current date and time?

I'll see about including those scripts, if you have newer versions, please upload. Also, the verify - the only condition for a NAND backup to be recognized as valid is *one* valid FIRM partition, so, no, it won't fail.

I see. Since it won't fail, I'll redo them and upload new versions.

EDIT: OK, here they are. I left the verify line commented out in the regular EmuNAND and Safe SysNAND varitants, and include my reasons in the comments. In the case of EmuNAND, it is neither vital to the system nor does it even use it's firm partitions. In the case of a safe SysNAND restore, the firm partitions are not being touched, so, it hurts nothing to let someone try restoring a bricked NAND. Maybe it's just the firm partitions that are bad, after all. If it doesn't work, they can try again with a good backup. The full one remains pretty much the same, though I changed the warning to mention not using EmuNAND images (because it just recently hit me, those will verify even if their firm partitions contain an outdated NF that doesn't match CTRNAND's, but any attempt to prevent this makes it not a full restore), and the forced full one is gone, since the full one already did what I intended to enable (I just didn't know it). I did disable the preview on them all, and all of my scripts for that matter. I think it's great for troubleshooting things I'm still working on, but might be TMI for end users. Feel free to make any changes you like (if you even decide to use them).

Deleted User · Sep 18, 2017

EDIT:

d0k3 · Sep 19, 2017

Eix said:
lol
playing with gm9s nds mounting

Exception: Data Abort (4)
2017-08-19 22:50:44

R00: 00000000 | R01: C156F01D
R02: C156F10D | R03: 20520000
R04: 0000C0EC | R05: 20520000
R06: 0000C0EC | R07: 23EFF490
R08: 20000000 | R09: 23EFF440
R10: 00000020 | R11: 23EFF500
R12: 2051F400 | R13: 23EFF3C0
R14: 23F11C5D | R15: 23F13400
CPSR: 800000FF

Press POWER to turn off

I beat gm9!
EDIT:

Well played

. Can you give me some more info? What image was that, is it reproducable, and can we have the full exception dump (from 0:/gm9/out)?

Deleted User · Sep 19, 2017

d0k3 said:
Well played . Can you give me some more info? What image was that, is it reproducable, and can we have the full exception dump (from 0:/gm9/out)?

I get that error whenever I open the data folder in a certain rom
I havent tested this on other systems but im pretty sure it still happens ill upload the rom and dump to something like google drive in a little bit
Edit:
took abit longer than I thought because google was being useless as always

the file that caused the crashes and 3 dumps are in the zip file

d0k3 · Sep 19, 2017

Eix said:
I get that error whenever I open the data folder in a certain rom
I havent tested this on other systems but im pretty sure it still happens ill upload the rom and dump to something like google drive in a little bit
Edit:
took abit longer than I thought because google was being useless as always
[ --- snip ---]
the file that caused the crashes and 3 dumps are in the zip file

Thanks! Doesn't happen with anything else, right? Also, better to remove that link now.

EDIT: Oh, that's an AR dump?

Deleted User · Sep 19, 2017

d0k3 said:
Thanks! Doesn't happen with anything else, right? Also, better to remove that link now.

EDIT: Oh, that's an AR dump?

havent tryed with anything else because I only have 1 system on me rn
yeah its a ar dump
Edit: 1 b9s system

d0k3 · Sep 19, 2017

Eix said:
havent tryed with anything else because I only have 1 system on me rn
yeah its a ar dump
Edit: 1 b9s system

Looking into it. Btw, if you like crashing GM9, I have something for you. Will require a good smartphone camera, though.
https://transfer.sh/iGKTg/GodMode9.firm

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

Well-Known Member

3DS Homebrew Legend

Well-Known Member

Attachments

Well-Known Member

Well-Known Member

Attachments

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Attachments

Well-Known Member

3DS Homebrew Legend

Well-Known Member

Attachments

Deleted User

Guest

3DS Homebrew Legend

Deleted User

Guest

3DS Homebrew Legend

Deleted User

Guest

3DS Homebrew Legend

Similar threads

Popular threads in this forum