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

[Kazuma77]

Okay, @Kazuma77 - the latest commit should fix most, if not all of the annoyances you just pointed out.

Yes, I think you fixed all of my problems. I did still get the error message for there being nothing to archive, but it builds GM9 with the ''data" folder empty, and that's all that matters. And I was able to build an SSR with the flavor changed (I just created a zero byte file for the splash file, since I'm not concerned about being flashy with my "apps"), and it did not include the "README.md" file (and the point was not that the file could not be displayed, so much as that your average autorun script is not going to use it). Problems solved. I hope you'll get these added to your new "ifelse" branch soon.

Just one tiny thing. In the "README.md" file, you listed drive V: as X: Not that this affects me one bit, but I thought you might like to know.

I have a request. An undo combo. You should be able to undo actions, probably up to about 5 actions ago. I could especially use it after I accidentally deleted my title folder in SysNand SD. I'd be fine if the action undo cache is cleared on reboot, as long as you can undo. Preferably also a redo.

Also, a question. Where does GM9 get the System Info (in Home...More...System Info) from?

You already got your answer from d0k3, so I'm inclined to say "Use the backup script, Luke" (or the "Nand Manager" app when I put out R10 of my AIO). However, while a recycle bin is clearly out of the question, an undelete function that works similar to the way Photorec does might be handy to have (after all, you never know what condition a 3DS you find, or have brought to you, is going to be in).

 

[SirNapkin1334]

Yes, I think you fixed all of my problems. I did still get the error message for there being nothing to archive, but it builds GM9 with the ''data" folder empty, and that's all that matters. And I was able to build an SSR with the flavor changed (I just created a zero byte file for the splash file, since I'm not concerned about being flashy with my "apps"), and it did not include the "README.md" file (and the point was not that the file could not be displayed, so much as that your average autorun script is not going to use it). Problems solved. I hope you'll get these added to your new "ifelse" branch soon.

Just one tiny thing. In the "README.md" file, you listed drive V: as X: Not that this affects me one bit, but I thought you might like to know.



You already got your answer from d0k3, so I'm inclined to say "Use the backup script, Luke" (or the "Nand Manager" app when I put out R10 of my AIO). However, while a recycle bin is clearly out of the question, an undelete function that works similar to the way Photorec does might be handy to have (after all, you never know what condition a 3DS you find, or have brought to you, is going to be in).

How can I hardcode the aeskeydb.bin file? Also, does SaltMode9 still take a moment to boot, but without the splash, or does it completely skip the splash screen and "Booting.." Dialogue?
Also, you should make the other screen flash red/black on the unlock prompt for the Red perm level to scare noobs away.
How do I change the combo to enter the bootloader menu?

 

[Kazuma77]

How can I hardcode the aeskeydb.bin file? Also, does SaltMode9 still take a moment to boot, but without the splash, or does it completely skip the splash screen and "Booting.." Dialogue?
Also, you should make the other screen flash red/black on the unlock prompt for the Red perm level to scare noobs away.
How do I change the combo to enter the bootloader menu?

Just put "aeskeydb.bin" in the "data" folder when compiling. SALTMODE is completely no-splash and it boots instantly from what I can tell (pretty quickly anyway, if there is a delay, I've not noticed it). The hotkey combos are on lines 42 or 48 in "arm9/source/godmode9.c" depending on whether you're going to make the regular or SALTMODE version (respectively).

 

[d0k3]

@SirNapkin1334 - If you look at the current nightly, I implemented random key sequences. I even decided to make longer ones for the real dangerous stuff.

 

[d0k3]

@Kazuma77 / @windows_server_2003 - something that I want to put up for wider discussion, originated from here:
https://github.com/d0k3/GodMode9/pull/261

Do we really need if nesting? I do get the appeal of the else keyword, if nesting, on the other hand, especially with a large number of nested ifs, will only make stuff confusing on both sides - for the script writer, who may mess up at some point, and for the writer of the GM9 parser, cause the code gets more complex and unexpected stuff is bound to happen. It will only get worse once we have support for 'for', when we can nest 'if' inside 'for' inside 'if' inside 'for' - in short: clusterfuck. A goto inside a nested if may make it even worse.

So, tl;dr - @Kazuma77, you're one of the most active script writers out there. Will nested ifs make things easier for you, or would you rather not need them?

 

[Kazuma77]

@Kazuma77 / @windows_server_2003 - something that I want to put up for wider discussion, originated from here:
https://github.com/d0k3/GodMode9/pull/261

Do we really need if nesting? I do get the appeal of the else keyword, if nesting, on the other hand, especially with a large number of nested ifs, will only make stuff confusing on both sides - for the script writer, who may mess up at some point, and for the writer of the GM9 parser, cause the code gets more complex and unexpected stuff is bound to happen. It will only get worse once we have support for 'for', when we can nest 'if' inside 'for' inside 'if' inside 'for' - in short: clusterfuck. A goto inside a nested if may make it even worse.

So, tl;dr - @Kazuma77, you're one of the most active script writers out there. Will nested ifs make things easier for you, or would you rather not need them?

I've already made extensive use of it. Removing the nesting would require much more use of the "goto'' command (not to mention massive changes to nearly every script I've written this month). Since the way the "goto" command works is by skipping lines until it finds the label it's looking for, I think it best to keep most subroutines inline for the sake of efficiency.

Since you have concerns about memory use, I will tip my hand a bit. Allow me to present the 28K centerpiece of InScripted R10. This will replace most of the scripts I include with my my configurations. It sets the default payload. It configures the hotkeys. It switches chainloaders. It allows you to change the "boot.firm" to any payload if GM9 is installed to your FIRM partitions (and if not, it even offers to update your FIRM partitions on the spot). Everything except the NAND management scripts and the option to update Luma on SysNAND (which will all be in the relatively small "NAND Manager" SSR) is here. I call it "Settings". If this behemoth of a script, at 787 lines, does not run the system out of memory, then I don't see it being an issue.

I would encourage anyone that is using InScripted R9 to check it out. It will replace "Defaults" on R (you can still restore the default hotkeys as one of the options, so you'll lose nothing). Though you might want to use a spare card, since the "NAND Manager" and "Options" SSRs planned for the final release aren't included. "Settings" is also not hotkeyed for regular BootCTR9 nor listed for CBM9 yet. So, if you switch to one of those, you will have to access "Settings" from GM9's "Payloads" menu for now.

Though you will notice I did use "goto" sections for switching chainloaders and switching the "boot.firm" file, since the routines don't depend on which chainloader is in use. Never mind that, with the routines being rather lengthy, it just made no sense replicating them 6 times. The default payload and hotkey routines are best staying inline because no two are the same, and they get processed faster by not having to use "goto" to skip to a separate routine.

Even if running the system out of memory is a potential issue, the way I see it, the burden of not doing that lies with the script author. A good script writer tests their work. If someone writes a script, and in testing it runs out of memory, they will need to move some subroutines into goto sections. I think it can largely be avoided by exercising good judgement. It's also fair to assume that script writers represent a more advanced user base. There's no reason to pull out the kid gloves and say "because you could screw up, we're just not going there." If you want a kid to learn how to ride a bike, you have to be willing to take the training wheels off and let them crash a few times until they get the hang of stabilizing it themselves. IMHO, the usefulness of inline subroutines warrants the risk.

P.S. Fair warning, if you enable the preview mode on this one, you're in for a slow ride. It's 787 lines after all.

 

[SirNapkin1334]

[Feature Request for Kazuma]
Add toggle able SD data backups.
By this, I mean in the NAND backup script make it so it also backs up SD data into a ZIP.
This could be toggle able, or even a separate script, but it'd be helpful (in case somebody else deletes their title folder). Also, is the data in the Sys & EmuNand SD drive decrypted, or just directly read from SD:/Nintendo 3DS/[Sys/EmuNand ID]/[ID 2]/?

 

[Kazuma77]

[Feature Request for Kazuma]
Add toggle able SD data backups.
By this, I mean in the NAND backup script make it so it also backs up SD data into a ZIP.
This could be toggle able, or even a separate script, but it'd be helpful (in case somebody else deletes their title folder). Also, is the data in the Sys & EmuNand SD drive decrypted, or just directly read from SD:/Nintendo 3DS/[Sys/EmuNand ID]/[ID 2]/?

The purpose of A: and B: is to provide on-the-fly decryption/encryption of the data when copying from/to them. Also, for what you're suggesting to even work, your SD card would have to be less than half full. Otherwise, there just isn't going to be enough space. Never mind backing up, say, 30 GB worth of content from a 64 GB Card to the same card would take hours. I can't see it being practical. A Photorec-like undelete utility is what you need. Though for what it's worth, I did expand my ticket synchronizing scripts -- I call it "Ticket Master" now, and it has the ability to backup and restore ticket files, not just copy them between SysNAND and EmuNAND.

 

[SirNapkin1334]

The purpose of A: and B: is to provide on-the-fly decryption/encryption of the data when copying from/to them. Also, for what you're suggesting to even work, your SD card would have to be less than half full. Otherwise, there just isn't going to be enough space. Never mind backing up, say, 30 GB worth of content from a 64 GB Card to the same card would take hours. I can't see it being practical. A Photorec-like undelete utility is what you need. Though for what it's worth, I did expand my ticket synchronizing scripts -- I call it "Ticket Master" now, and it has the ability to backup and restore ticket files, not just copy them between SysNAND and EmuNAND.

Oh, yes, I had forgotten that the SD data is bigger than the NAND. My bad. But you didn't answer my question, at least in the context I was looking for–are A: and B: encrypted or decrypted?

 

[Kazuma77]

Oh, yes, I had forgotten that the SD data is bigger than the NAND. My bad. But you didn't answer my question, at least in the context I was looking for–are A: and B: encrypted or decrypted?

I did, you just didn't quite get what I meant by it, I guess. Keep in mind, these are virtual drives. Which is why I said they "provide on-the-fly decryption/encryption" instead of saying that they're decrypted (because technically they don't even exist). If you're looking at data on A: it will appear decrypted. If you copy files from A: they will be decrypted. If you copy files to A: they will be encrypted (they will appear to be decrypted if you view them on A: but go look at them on 0: and you will see that they are not). You could, for example, backup a save and copy it to another device. I think you would then have to fix the CMAC on the target device though (correct me if I'm wrong, I still don't quite understand what they do). And before you even ask, I'd need the "for" command (with a recurse flag) to backup all saves that way (or a recurse flag and wildcards added to "cp").

 

[d0k3]

Alright then @Kazuma77, we'll need if nesting. The memory thing wasn't actually about the scripts themselves (there is an actual limit for them, 1MB), it was about grabbing too much memory from the stack, inside the GM9 code. This can have unexpected consequences, thus it's better to be careful there.

As for the goto thing, I already suggested moving the search for a label to a separate function, which will in fact even be faster, as no full parsing is required.

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

... You could, for example, backup a save and copy it to another device. I think you would then have to fix the CMAC on the target device though (correct me if I'm wrong, I still don't quite understand what they do). And before you even ask, I'd need the "for" command (with a recurse flag) to backup all saves that way (or a recurse flag and wildcards added to "cp").

CMAC is similar to a signature in that it authenticates that (A) the file is valid and (B) it originates from your console. CMAC is the only thing stopping you from transferring your files to different console, as it has to be recalculated with a different console.

EDIT: Maybe just think about the CMAC as an encryted hash? Cause that's what it basically is. We need to be able to properly decrypt it (using console unique keys), and it has to match the data. If one of the two doesn't work, CMAC authentication fails.

 

[Kazuma77]

Alright then @Kazuma77, we'll need if nesting. The memory thing wasn't actually about the scripts themselves (there is an actual limit for them, 1MB), it was about grabbing too much memory from the stack, inside the GM9 code. This can have unexpected consequences, thus it's better to be careful there.

As for the goto thing, I already suggested moving the search for a label to a separate function, which will in fact even be faster, as no full parsing is required.

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



CMAC is similar to a signature in that it authenticates that (A) the file is valid and (B) it originates from your console. CMAC is the only thing stopping you from transferring your files to different console, as it has to be recalculated with a different console.

Well, "Settings" probably has the most nested "if" commands of anything I'm working on. "Options" is going to make heavy use of "goto" (and make some very unconventional use of labels) to string a bunch of individual scripts together (it's being created in a way that will make it easy to add/remove features). So, that would especially benefit from making the label search a separate function.

And thanks for the clarification on CMACs.

 

[SirNapkin1334]

If I want to update my FIRM Partition-installed GM9 all I have to do is extract the newest GM9 to my SD card and install the firm?
Also, does GM9 have to be boot.firm for the installation to work correctly?

 

[SirNapkin1334]

@d0k3 Help! I'm building SaltMode9 from source so I can hardcode an aeskeydb.bin, but it always gives me an error. I have firmtool installed. Running macOS Sierra 14.1 or 11.4 or something.

Spoiler: Terminal Image

 

[d0k3]

@d0k3 Help! I'm building SaltMode9 from source so I can hardcode an aeskeydb.bin, but it always gives me an error. I have firmtool installed. Running macOS Sierra 14.1 or 11.4 or something.

Spoiler: Terminal Image

View attachment 106659

Fuck. This is not your fault. Try the attached Makefile instead of the one that comes with GM9.

 

[SirNapkin1334]

Fuck. This is not your fault. Try the attached Makefile instead of the one that comes with GM9.

Same problem, except now it says:

tar: Option --xform=s/^.*\/// is not supported

Also, whenever I run make in any form it gives me:

fatal: Not a git repository (or any of the parent directories): .git

It only happens at the beginning and the make process keeps going.
It also happens when I run make clean

 

[d0k3]

Same problem, except now it says:

tar: Option --xform=s/^.*\/// is not supported

Also, whenever I run make in any form it gives me:

fatal: Not a git repository (or any of the parent directories): .git

Okay, can you give me the output of tar --help from your terminal? tar --help >tarhelp.txt should write it all to a file.

 

[SirNapkin1334]

Okay, @d0k3 here it is.
Also, thanks for the write to file trick.

 

[d0k3]

Okay, @d0k3 here it is.
Also, thanks for the write to file trick.

Okay, could you try, in terminal:

brew install gnu-tar --with-default-names

... then try to make again?

https://apple.stackexchange.com/que...ce-mac-os-x-utilities-with-gnu-core-utilities

 

[SirNapkin1334]

Okay, could you try, in terminal:

brew install gnu-tar --with-default-names

... then try to make again?

https://apple.stackexchange.com/que...ce-mac-os-x-utilities-with-gnu-core-utilities

It worked! I have yet to actually run the firm, but it made it successfully.