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

  • Thread starter d0k3
  • Start date
  • Views 305,355
  • Replies 1,143
  • Likes 105
D

Deleted User

Guest
Test crashing with it, maybe? Don't worry, nothing bad will happen.
nice! battery indicator
also I got the qrcode
dont have time to scan it rn
20170919_083929.jpg

Edit: scanned and it took me to an invalid googleplay app
 
Last edited by ,

Kazuma77

Well-Known Member
Member
Joined
May 11, 2008
Messages
1,035
Trophies
1
XP
888
Country
United States
So we can display QR codes for websites now. This is a cool trick. I'm not sure how useful it will be, but I like it. Somehow, seeing this conjured up a very comical (and admittedly unlikely) concept in my mind of kids showing Santa their wish list in .gm9 format this year -- "I want this, and this, and, Santa, you have to scan them with your phone or you won't know what I want!" ;)
 
Last edited by Kazuma77,
D

Deleted User

Guest
That's weird, it should display a register, stack and code dump. Works fine on my system (O3DS) + phone (XiaoMi Redmi 4X) combo
so it shoild just display the contents of the exception dumps?
I wonder why it takes me to google play
 

Wolfvak

nyaa~
Member
Joined
Oct 25, 2015
Messages
918
Trophies
1
XP
3,386
Country
Uruguay
so it shoild just display the contents of the exception dumps?
I wonder why it takes me to google play
Your phone is probably trying to make you download an app to scan the QR code properly. Try scanning any other qr code, if it takes you to the same gplay link it's an issue with your phone.
 
D

Deleted User

Guest
Your phone is probably trying to make you download an app to scan the QR code properly. Try scanning any other qr code, if it takes you to the same gplay link it's an issue with your phone.
ill try that later
still in school rn
 

d0k3

3DS Homebrew Legend
OP
Member
Joined
Dec 3, 2004
Messages
2,786
Trophies
1
XP
3,896
Country
Germany
So we can display QR codes for websites now. This is a cool trick. I'm not sure how useful it will be, but I like it. Somehow, seeing this conjured up a very comical (and admittedly unlikely) concept in my mind of kids showing Santa their wish list in .gm9 format this year -- "I want this, and this, and, Santa, you have to scan them with your phone or you won't know what I want!" ;)
Not only for websites, actually for anything. Text up to and beyound 1000 chars is supported.
 
  • Like
Reactions: Deleted User

d0k3

3DS Homebrew Legend
OP
Member
Joined
Dec 3, 2004
Messages
2,786
Trophies
1
XP
3,896
Country
Germany
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).
Do you want to make the commit yourself, @Kazuma77 ? I'd just make a few minor changes to those scripts after the pull request. I'm also a little unsure if I want to keep full restore script for SysNAND, and I still have some concerns cause a 'safe' restore can actually brick for an unhaxed console (and you don't check hax here).
 

Kazuma77

Well-Known Member
Member
Joined
May 11, 2008
Messages
1,035
Trophies
1
XP
888
Country
United States
Do you want to make the commit yourself, @Kazuma77 ? I'd just make a few minor changes to those scripts after the pull request. I'm also a little unsure if I want to keep full restore script for SysNAND, and I still have some concerns cause a 'safe' restore can actually brick for an unhaxed console (and you don't check hax here).

I am not sure if I could if I wanted to. I don't think I have a github account. I clone a lot of stuff from it, but I guess I never bothered to register, having so many names to remember already. Besides, I don't consider myself a coder. I just recently started compiling stuff out of necessity. Like needing Luma Legacy to use a different folder, wanting keys in my GM9, or needing OldLoader to run something other than boot.firm.

Anyway, it had not crossed my mind someone would do a safe restore on retail (they have no exploit to protect, it's completely irrational). A verify would probably not save someone that would do that, either. The NAND itself is most likely valid, after all. It's just using a different version. Maybe it should do a partial SHA check for hax. But without branching, that would mean creating separate scrips for at least B9S 1.2, 1.3, and the last version of A9LH. I could have it install B9S, but, it has to be present, and that seems kind-of deceptive. I'll let you decide how/if you want to implement them. It's your app. It's just that having "backup" without "restore" seems like half of a solution.

EDIT: The more I think about it, the less of an issue this seems to be. You just got into GM9 via Soundhax, and the first thing you're going to do is safe restore a NAND backup? I'd think it would be install an exploit unless you just love those birds in Sound Player ;) And only a Menuhax or MSET user would have a NAND backup without a proper hack installed. I've already gone SSR with my install method ("Classic" will be removed next release I think). Aside from removing two steps, it should also keep people from screwing around in GM9 without an exploit installed. Most of the people that would try it are probably running GM9 from NTRBootHax anyway. Regardless, there's only so much you can do without sacrificing utility. Consider noob-friendly Linux distros. They try hard to keep you safe, but some fool will inevitably end up figuring out how to delete the root folder. I've changed the warning messages one last time. If people won't read, as far as I'm concerned, it's on them. So, this is what's going in my release I think. Feel free to change or remove anything you're uncomfortable with in the official GM9 version.
 

Attachments

  • NAND Backup & Restore Scripts.7z
    1.2 KB · Views: 189
Last edited by Kazuma77,

d0k3

3DS Homebrew Legend
OP
Member
Joined
Dec 3, 2004
Messages
2,786
Trophies
1
XP
3,896
Country
Germany
@Kazuma77 - the new chk command should be pretty helpful in making your restore scripts a little safer. If you add the respective checks, I'll add the scripts to GM9.
 

Kazuma77

Well-Known Member
Member
Joined
May 11, 2008
Messages
1,035
Trophies
1
XP
888
Country
United States
@Kazuma77 - the new chk command should be pretty helpful in making your restore scripts a little safer. If you add the respective checks, I'll add the scripts to GM9.

OK, that will definitely help to make sure there's an appropriate exploit when doing a safe restore. Now if there was just a way to look for NF mismatch when a NAND image is retail (and preferably automatically fix it -- updating a GW EmuNAND's firms should not have any negative effects). Or even just a way to check for retail (I could say "use the retail script" on the error and have that one extract the CTRNAND copy). If such things as 9.2 EmuNANDs with 4.5 firm partitions could be removed from the equation, the full restore process would be completely safe.

I could make the full one only run when "ntrboot" is found as a compromise, but it's too restrictive for my own standards.

The hardware type one's a nice addition as well. I'm already performing a find on NF to get the hardware type in most of my scripts that need to make such checks. But it's nice having a shorter command for future use.

I'm a bit unsure on how to effectively use RDTYPE. I don't have access to a devkit model for testing purposes. So if there's anything I need to add in that respect, let me know. Though I guess a noob wouldn't have one either.

EDIT: OK, I've made the modifications. They should be sufficiently safe now. Though detecting/fixing bad retail images (or just detecting retail images at all) would be a godsend if it's not too much trouble to implement.
 

Attachments

  • NAND Backup & Restore Scripts.7z
    1.3 KB · Views: 204
Last edited by Kazuma77,

d0k3

3DS Homebrew Legend
OP
Member
Joined
Dec 3, 2004
Messages
2,786
Trophies
1
XP
3,896
Country
Germany
OK, that will definitely help to make sure there's an appropriate exploit when doing a safe restore. Now if there was just a way to look for NF mismatch when a NAND image is retail (and preferably automatically fix it -- updating a GW EmuNAND's firms should not have any negative effects). Or even just a way to check for retail (I could say "use the retail script" on the error and have that one extract the CTRNAND copy). If such things as 9.2 EmuNANDs with 4.5 firm partitions could be removed from the equation, the full restore process would be completely safe.

For the console running from, you can just do chk $[RDTYPE] "retail". For NAND backups - no proper way, but you honestly shouldn't care. If you try to restore a retail backup on a devkit or vice versa, the verification will fail anyways, cause the NAND backup will be not from the same console :).
 

Kazuma77

Well-Known Member
Member
Joined
May 11, 2008
Messages
1,035
Trophies
1
XP
888
Country
United States
For the console running from, you can just do chk $[RDTYPE] "retail". For NAND backups - no proper way, but you honestly shouldn't care. If you try to restore a retail backup on a devkit or vice versa, the verification will fail anyways, cause the NAND backup will be not from the same console :).

So the RDTYPE would be more for, say, double checking when installing an exploit like B9S. Well, I highly doubt anyone with a dev kit is going to be using my AIO pack anyway.

My desire to check for whether a NAND is retail (maybe I should say OFW) has nothing to do with that though. I would ultimately like the "full" script to become a "full exploit" script and have a "full retail" script alongside it. I basically want the former to reject any OFW NAND dump, so that I can have people run the latter, which will use the NF in CTRNAND and completely ignore the FIRM partitions. This would prevent an EmuNAND updated with old versions of Gateway (which used to protect EmuNAND's firm partitions) from bricking a device. For example, I once bricked a device by restoring an EmuNAND dump that had 9.2 on CTRNAND (but it had 4.5 on the FIRM partitions, so I ended up having to dig out the soldering iron).

But if that just isn't possible/feasible, then it is as safe as it can get, I think.
 
Last edited by Kazuma77,

d0k3

3DS Homebrew Legend
OP
Member
Joined
Dec 3, 2004
Messages
2,786
Trophies
1
XP
3,896
Country
Germany
the date and time from Godmode9 is not match with my 3ds system..How do I set up the time ?
HOME button -> more -> set RTC clock
So the RDTYPE would be more for, say, double checking when installing an exploit like B9S. Well, I highly doubt anyone with a dev kit is going to be using my AIO pack anyway.

My desire to check for whether a NAND is retail (maybe I should say OFW) has nothing to do with that though. I would ultimately like the "full" script to become a "full exploit" script and have a "full retail" script alongside it. I basically want the former to reject any OFW NAND dump, so that I can have people run the latter, which will use the NF in CTRNAND and completely ignore the FIRM partitions. This would prevent an EmuNAND updated with old versions of Gateway (which used to protect EmuNAND's firm partitions) from bricking a device. For example, I once bricked a device by restoring an EmuNAND dump that had 9.2 on CTRNAND (but it had 4.5 on the FIRM partitions, so I ended up having to dig out the soldering iron).

But if that just isn't possible/feasible, then it is as safe as it can get, I think.
Oh, now I understand what you want to do. Not a bad idea! You can just pull the NATIVE_FIRM out of the NCCH. Mount the NCCH, then copy it, also see here.

I would ultimately like the "full" script to become a "full exploit" script and have a "full retail" script alongside it. I basically want the former to reject any OFW NAND dump, so that I can have people run the latter, which will use the NF in CTRNAND and completely ignore the FIRM partitions.

Or, do I? Unsure :). What would these two script do different?
 

d0k3

3DS Homebrew Legend
OP
Member
Joined
Dec 3, 2004
Messages
2,786
Trophies
1
XP
3,896
Country
Germany
Okay, @Kazuma77 - I looked over your restore scripts and changed a few things. My changes are mainly to reduce strings sizes (I want to keep compatibility with the legacy font) and to improve the formatting (more empty lines). I also reenabled the scripting preview cause processing speed should not be a concern here and I want a unified look to these scripts.

Now, as for the relevant stuff:
  • Safe restore (SysNAND): Disabled on ntrboot now (cause no defined state of the system). I also changed it so that 'allow' and 'find' is called for the three relevant partitions.
  • Full restore (SysNAND): I toned down on the warnings a bit. This only runs from ntrboot now, so that should be okay.
  • Full restore (both): I used 'inject' instead of 'cp'. Why? Because there may be cases where a NAND is totally borked, and in those the 'nand_minisize.bin' file is not available. 'nand.bin', on the other hand, is always available. So, this makes this scripts work in more use cases.
Can you review my changes and tell me what you think? If you're okay with them, we can add those scripts to GM9. Also, I don't have my console available for testing rn. I did pay attention in my edits, but, can you maybe do a test run on each?
 

Attachments

  • scripts.zip
    2 KB · Views: 175
Last edited by d0k3,

Kazuma77

Well-Known Member
Member
Joined
May 11, 2008
Messages
1,035
Trophies
1
XP
888
Country
United States
HOME button -> more -> set RTC clock

Oh, now I understand what you want to do. Not a bad idea! You can just pull the NATIVE_FIRM out of the NCCH. Mount the NCCH, then copy it, also see here.



Or, do I? Unsure :). What would these two script do different?

Basically the "full with exploit" would be the true full restore because the NAND image has an exploit installed. And the "full with retail" (or "full with OFW") one would pull the NF from the NCCH, as you said, to bypass the aforementioned problem with some GW EmuNAND backups.

Okay, @Kazuma77 - I looked over your restore scripts and changed a few things. My changes are mainly to reduce strings sizes (I want to keep compatibility with the legacy font) and to improve the formatting (more empty lines). I also reenabled the scripting preview cause processing speed should not be a concern here and I want a unified look to these scripts.

Now, as for the relevant stuff:
  • Safe restore (SysNAND): Disabled on ntrboot now (cause no defined state of the system). I also changed it so that 'allow' and 'find' is called for the three relevant partitions.
  • Full restore (SysNAND): I toned down on the warnings a bit. This only runs from ntrboot now, so that should be okay.
  • Full restore (both): I used 'inject' instead of 'cp'. Why? Because there may be cases where a NAND is totally borked, and in those the 'nand_minisize.bin' file is not available. 'nand.bin', on the other hand, is always available. So, this makes this scripts work in more use cases.
Can you review my changes and tell me what you think? If you're okay with them, we can add those scripts to GM9. Also, I don't have my console available for testing rn. I did pay attention in my edits, but, can you maybe do a test run on each?

I'm fine with most of the changes. However, I'm confused as to why you would disable safe restore with "ntrboot" though. It's true that you don't know the state of the system. Still, if they're using NTRBootHax, well, if they brick it, they can fix it, right? So there's no need for such concern.
 

d0k3

3DS Homebrew Legend
OP
Member
Joined
Dec 3, 2004
Messages
2,786
Trophies
1
XP
3,896
Country
Germany
Basically the "full with exploit" would be the true full restore because the NAND image has an exploit installed. And the "full with retail" (or "full with OFW") one would pull the NF from the NCCH, as you said, to bypass the aforementioned problem with some GW EmuNAND backups.
There's not really a way to ensure a NAND backup has a (working!) exploit installed. I personally think it would be better to have a separate exploit uninstaller, anyways. There's a script for exploit uninstallation written by me somewhere on the web (can't even find it myself right now). Additionally to fixing the NATIVE_FIRM, you'd have to fix the secret sector.

I'm fine with most of the changes. However, I'm confused as to why you would disable safe restore with "ntrboot" though. It's true that you don't know the state of the system. Still, if they're using NTRBootHax, well, if they brick it, they can fix it, right? So there's no need for such concern.
It's about the target audience for these scripts. Someone who knows their way around the 3DS and GM9 will have an easy time fixing anything from ntrboot. Someone who has not... will perhaps run this script (cause, who doesn't want "safe"?) and be surprised by the results.
 
  • Like
Reactions: GilgameshArcher

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
  • Veho @ Veho:
    Mkay.
  • Veho @ Veho:
    I just ordered another package from China just to spite you.
  • SylverReZ @ SylverReZ:
    Communism lol
  • SylverReZ @ SylverReZ:
    OUR products
  • The Real Jdbye @ The Real Jdbye:
    @LeoTCK actually good quality products are dying out because they can't compete with dropshipped chinese crap
    +2
  • BakerMan @ BakerMan:
    @LeoTCK is your partner the sascrotch or smth?
  • Xdqwerty @ Xdqwerty:
    Good morning
  • Xdqwerty @ Xdqwerty:
    Out of nowhere I got several scars on my forearm and part of my arm and it really itches.
  • AdRoz78 @ AdRoz78:
    Hey, I bought a modchip today and it says "New 2040plus" in the top left corner. Is this a legit chip or was I scammed?
  • Veho @ Veho:
    @AdRoz78 start a thread and post a photo of the chip.
    +2
  • Xdqwerty @ Xdqwerty:
    Yawn
  • S @ salazarcosplay:
    and good morning everyone
    +1
  • K3Nv2 @ K3Nv2:
    @BakerMan, his partner is Luke
  • Sicklyboy @ Sicklyboy:
    Sup nerds
    +1
  • Flame @ Flame:
    oh hi, Sickly
  • K3Nv2 @ K3Nv2:
    Oh hi flame
  • S @ salazarcosplay:
    @K3Nv2 what was your ps4 situation
  • S @ salazarcosplay:
    did you always have a ps4 you never updated
  • S @ salazarcosplay:
    or were you able to get new ps4 tracking it \
    as soon as the hack was announced
  • S @ salazarcosplay:
    or did you have to find a used one with the lower firm ware that was not updated
  • K3Nv2 @ K3Nv2:
    I got this ps4 at launch and never updated since 9.0
  • K3Nv2 @ K3Nv2:
    You got a good chance of buying a used one and asking the seller how often they used or even ask for a Pic of fw and telling them not to update
    K3Nv2 @ K3Nv2: You got a good chance of buying a used one and asking the seller how often they used or even ask...