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

[Kazuma77]

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.


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.

OK, I see your point. Maybe we should call it exploit-protecting restore? I'm somewhat of the "if they've got the tools to fix it, let them make the mistake and learn from it" mindset, but I have no objections to the scripts in their current form.

I was less concerned about verifying that a NAND image had a working exploit (this is something I'd imagine the user would probably already know, having performed the install) so much as verifying it was OFW (I was blindsided by the fact GW didn't update the firm partitions -- what everyone was saying at the time was that EmuNAND was a 1:1 NAND copy, so I thought it would work, but I got a lovely black screen). Then again, FIRM protection has been removed from GW since before 11.x came out. The chances of an EmuNAND with mismatched firms existing in the wild (especially in GM9 naming format) are probably between slim and none.

Yeah, I include your scripts for returning to retail in my AIO already. Actually, I probably would have pulled the lines for the "full retail" script straight from them, and added a comment crediting you for that part of it (no reason to reinvent the wheel) if it was possible. I made a second version of the N3DS one. It automatically replaces the secret sector with "secret_sector.bin" on the card (after checking it's SHA) instead of checking the one on SysNAND. I also slightly modified the original to say "run the other script" if it fails at the part where it checks the secret sector on SysNAND. Also, your originals specifically referenced Sighax, but they work just fine for returning to retail from A9LH as well, so I changed the language a bit to reflect this. I can upload a copy if you'd like to take a look. They've been very useful for restoring test systems to retail for testing my install scripts. I can literally just use SysUpdater to put the system on any version I want to test with, then run those to make it legit retail on that version. A real time saver. I also have them delete the temporary copy of NF (having to hit A to overwrite got old fast).

 

[d0k3]

OK, I see your point. Maybe we should call it exploit-protecting restore? I'm somewhat of the "if they've got the tools to fix it, let them make the mistake and learn from it" mindset, but I have no objections to you using the scripts you uploaded in their current form.

That's already almost too complicated (the name).... also keep in mind, the standard UI allows full and safe restores as well.

I was less concerned about verifying that a NAND image had a working exploit (this is something I'd imagine the user would probably already know, having performed the install) so much as verifying it was OFW (I was blindsided by the fact GW didn't update the firm partitions -- what everyone said was that EmuNAND was a 1:1 NAND copy, so I thought it would work, but I got a lovely black screen).

Compare the SHA of the first 0x200 bytes from the firm installed in FIRM0 to that (fist 0x200 byte!) of the firm in the NCCH to check this,

Yeah, I include your scripts for returning to retail in my AIO already. Actually, I probably would have pulled the lines for the "full retail" script straight from them, and added a comment crediting you for that part of it (no reason to reinvent the wheel) if it was possible.

Of course you can always take stuff from GM9, it's open source ! Crediting is nice, ofc.

Scripts I'll have a look at later.

Now, for something entirely different... That N3DS screeninit bug when coming from OldLoader A9LH - is that a GM9 bug or a OldLoader bug. Meaning: Will that bug also happen for ntrboot flasher or SafeB9SInstaller? Also, @Wolfvak - you may be interested in the reply.

 

[Kazuma77]

Compare the SHA of the first 0x200 bytes from the firm in installed in FIRM0 to that of the firm in the NCCH to check this,

I figured I could do something like that. But then if it has an exploit installed, it gets rejected too. I was interested in a way to give the non-OFW ones a free pass.

Of course you can always take stuff from GM9, it's open source ! Crediting is nice, ofc.

I try to always credit the people who made it when I use their stuff. Though I often don't bother crediting my own stuff because it's too much work. Besides, you can check the release date and see who was first.

Now, for something entirely different... That N3DS screeninit bug when coming from OldLoader A9LH - is that a GM9 bug or a OldLoader bug. Meaning: Will that bug also happen for ntrboot flasher or SafeB9SInstaller? Also, @Wolfvak - you may be interested in the reply.

Well, I had no reason to check Safe B9S Installer, since there's an A9LH version. But I've "backported" both the latest Skeith (the .bin is broken) and NTRBoot Flasher in my A9LH configurations. I recompiled OldLoader to change the names to "SkeithLoader" and "NTRBFLoader" respectively (I did the same with GM9 and called it "GodLoader" for that matter), and changed the path so that they look in the "b9s/payloads" folder for the appropriate payload instead of launching "boot.firm" and they both seem to work just fine. I can test Safe B9S Installer if you like. I expect it will work.

This has only been an issue with GM9 so far (and only with versions higher than 1.3.4). And the thing is, the app still works. The start key reboots, and R+start powers down as it should. You just can't see what you're doing in it because of the messed up display, which basically looks like it's trying to display everything on the bottom screen (you can almost make out what looks like text, but it's really tiny). It also flickers a bit, much like what happens when you try to run a PC monitor at a resolution it doesn't support. However, I guess I can't completely rule out the possibility it could have something to do with how OldLoader launches it that just doesn't affect the other apps.

That Skeith works is probably the most revealing, since it's probably the only other one that has screen init code. Not that screen init code seems to works under OldLoader. My script that makes Skeith the chainloader has to copy "SkeithLoader.bin" to "arm9loaderhax_si.bin" or I get a black screen. The same happens with working versions of GM9 -- you'll get a black screen if you copy "GodLoader.bin" to the root and rename it "arm9loaderhax.bin" without the "_si" tacked on. With the "_si" part GM9 works correctly (though only up to 1.3.4 on the N3DS, as I said).

For the record, the clone of the OldLoader repo I'm using is from 8/14, and from what I can tell, there have been no commits since then. My devkitpro, libctru, citro3d, etc. are all up to date (the latest Luma compiles without errors).

If you guys can get this fixed by the end of the year, that would be great. I'll probably have to drop A9LH support by the start of next year. It's so much work updating the configurations. And there's so few people using them.

 

[d0k3]

@Kazuma77 thanks for the explanation! Are you on IRC perhaps or Telegram? A more direct form of communication would help sorting this out more quickly.

 

[adrifcastr]

That's already almost too complicated (the name).... also keep in mind, the standard UI allows full and safe restores as well.

"keep-exploit restore"

 

[Kazuma77]

@Kazuma77 thanks for the explanation! Are you on IRC perhaps or Telegram? A more direct form of communication would help sorting this out more quickly.

As I said, it's been a few years since I messed with IRC, but I have been meaning to check out Whonix's client all the same.

@d0k3, it just hit me what the issue could be. Both of my N3DS units have Toshiba NANDs. They have a timing difference that has caused a display issue one other time. You remember those multi-stage A9LH methods that came out for launching Gateway before they released an "arm9loaderhax.bin" for us to use? When they first came out, they worked fine for Samsung devices but everyone with a Toshiba got a black screen. The fix turned out to be simply adding a slight delay. I had forgotten about that. It was over a year ago, and so much has happened since then. I would test this theory, but I don't have an O3DS with a Toshiba NAND. The only problem with this theory is that you can launch it with something like CBM9 several seconds after the system has booted and it still happens. So, OldLoader would have to be re-initializing the display or something.

 

[PikaFan123]

can a mod please delete this post?

 

[astronautlevel]

@retrobug and me made a little tool based on a batch script.
It needs firmtool installed.
When you start it you can decide if you want to compile GodMode9 or SafeMode9.
Then the tool packs the compiled files in a release like zip.

Spoiler: So it has these Files and directorys

gm9
ntrboot
GodMode9.firm (or SafeMode9.firm if compiling SafeMode9)
HelloScript.gm9
README.md

It automatically names the page like a release package

Spoiler

(Safe or God)Mode9-v(commit)-(Year)(Month)(Date)(Hour)(Minute)(Second) so if you compile GodMode9 with the commit 5d9ed65 at the 24th September of 2017 at 23:19 and 07 Seconds it names it GodMode9-v5d9ed65-20170924231907.zip

It takes the name of the commit of the folder its located in.
After completing the zipping you can choose if you want to delete the sourcecode and the tool itself.
I did put the Tool on Github here https://github.com/PikaFan123/GodMode9CompilingTool/releases

Edit: Forgot to give @retrobug credit

Not to be rude, but there's already a tool like this called "GNU Make," and godmode9 already uses Makefiles...

 

[PikaFan123]

Not to be rude, but there's already a tool like this called "GNU Make," and godmode9 already uses Makefiles...

Didnt knew i just wanted to post it

 

[The Catboy]

I've actually been playing around with the GM9 bootloader all night and quite honestly it's the best damn bootloader I've used. I think the ability to use both GM9 scripts and B9S payloads has to be my favorite feature.

 

[ihaveahax]

Didnt knew i just wanted to post it

the Makefile already builds and packs into a release archive with "make release".

 

[PikaFan123]

the Makefile already builds and packs into a release archive with "make release".

well sorry. ill ask a mod to delete my post.

 

[Kazuma77]

@d0k3: I have performed some additional tests. I compiled a copy of OldLoader to run the B9S version of CBM9. So, then I tried running Godmode9 from that. Same problem. So then I setup CBM9 to run BootCTR9 and used the patching feature to have it run a custom "boot_gm9.ini" file which simply has Godmode9 as the default. That didn't get it to run properly either. The issue persists even when going through 2 additional chainloaders. So, now it seems even less likely to be OldLoader.

 

[d0k3]

well sorry. ill ask a mod to delete my post.

No need to be sorry, @justaMew - you just didn't notice earlier. Now, no need to give up on this. As you know by now, everything is in the Makefile, but not everything may be obvious. You can compile GM9 as SafeMode9, with screens switched, with a different font. You can hardcode keys, you can compile it as a standalone script runner and soon you can even piggyback a data image to the FIRM. Also, any and all thinkable combination of the aforementioned stuff. Basically "roll your own GodMode9".

So, as a suggestion - why not take what you have developed so far and extend it? Best would be some simple GUI, maybe even some additional tool that would create the image for you (ctrtool, f.e. can create a RomFS image).

@d0k3: I have performed some additional tests. I compiled a copy of OldLoader to run the B9S version of CBM9. So, then I tried running Godmode9 from that. Same problem. So then I setup CBM9 to run BootCTR9 and used the patching feature to have it run a custom "boot_gm9.ini" file which simply has Godmode9 as the default. That didn't get it to run properly either. The issue persists even when going through 2 additional chainloaders. So, now it seems even less likely to be OldLoader.

Thanks! Can you maybe try the test build attached to this post?

 

[Kazuma77]

Thanks! Can you maybe try the test build attached to this post?

I tried it. No major change. The top screen is black with what looks like a scanlines trick in use, and the corners are darkened. On the bottom, I see what looks like the start and home hotkey descriptions really tiny. Under that, a green line that goes maybe 2/3 across the screen. Then blank space. Then a red line at mid screen (same length). Then about 3 tiny lines of text that change when I hit up and down so they must be the folders. Then at the bottom what looks like the layout of the instructions. It's all too small to read (not enough pixels to make out anything). Hotkeys like start and R+start work as usual.

 

[Wolfvak]

I tried it. No major change. The top screen is black with what looks like a scanlines trick in use, and the corners are darkened. On the bottom, I see what looks like the start and home hotkey descriptions really tiny. Under that, a green line that goes maybe 2/3 across the screen. Then blank space. Then a red line at mid screen (same length). Then about 3 tiny lines of text that change when I hit up and down so they must be the folders. Then at the bottom what looks like the layout of the instructions. It's all too small to read (not enough pixels to make out anything). Hotkeys like start and R+start work as usual.

Would you mind posting a picture of what it looks like?

 

[Kazuma77]

Would you mind posting a picture of what it looks like?

Unfortunately, I've tried that. But it doesn't work. The snapshot feature shows what I SHOULD be seeing. If what is in the snapshot actually showed up on the screen, I wouldn't have a problem. I guess I could use my phone or something. Not used to having to resort to such tactics.

 

[Wolfvak]

Unfortunately, I've tried that. But it doesn't work. The snapshot feature shows what I SHOULD be seeing. If what is in the snapshot actually showed up on the screen, I wouldn't have a problem. I guess I could use my phone or something. Not used to having to resort to such tactics.

Yeah, I actually meant using your phone camera. I don't care if it's low res, I just need to have an idea of what's going on.
As a general rule, if your phone is good enough to process the exception QR, then it's good enough to take a pic of a 3DS.

 

[Kazuma77]

Yeah, I actually meant using your phone camera. I don't care if it's low res, I just need to have an idea of what's going on.
As a general rule, if your phone is good enough to process the exception QR, then it's good enough to take a pic of a 3DS.

OK. I've got it. Sorry for taking so long, but, I went to snap the picture and got the battery critical warning. So I had to let it charge, got watching something, dozed off, etc. I made them archives so they wouldn't clutter the page.

 

[Billy Acuña]

@d0k3
I just wanted to thank you for the new bootloader mode, looks so professional and works pretty smooth, I don't think I will ever return ti B9S
Btw I also wanted to ask you for 2 new features (only if you want to add them):

1.- Add script's folder sorting to get scripts organized by categories.
2.- Add a fuction to gm9 scripts to prompt the list of titles installed, just to get the rid of the TID on scripts.