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

[SirNapkin1334]

Is there a new version of this that just came out?

?
Like a release? Why were you quoting my post?

I created it to be used as an emojii for the official GodMode9 Discord Server.

 

[DaTank45]

Quote was an accident. sorry

 

[jaspern]

Hi, I'm confused by the GM9 interface - how do you create a deep/fully decrypted CIA file like it was possible in the predecessor, Decrypt9WIP? 'Decrypt file to gm9/out' only seems to do partitial decryption (much faster processing, different CRC) and there don't seem to be any options to choose from.

 

[SirNapkin1334]

Hi, I'm confused by the GM9 interface - how do you create a deep/fully decrypted CIA file like it was possible in the predecessor, Decrypt9WIP? 'Decrypt file to gm9/out' only seems to do partitial decryption (much faster processing, different CRC) and there don't seem to be any options to choose from.

As far as I can tell, "deep encrypting" is obsolete.

 

[jaspern]

As far as I can tell, "deep encrypting" is obsolete.

Hi, I meant decryption though. You know so that the app (data) partitions are decrypted along with the headers and stuff. This was possible with Decrypt9 and GM9 just skips the data partitions from what I can tell. From that you could either store them (since decrypted data can actually be compressed) or apply rom hacks/patches.

I had a look at https://github.com/ihaveamac/3DS-rom-tools/wiki but I don't really understand how to do this with any of the dev tools listed there. Well at least the D9WIP files are still up, so I guess I'll just dl and use that again

 

[ihaveahax]

Hi, I meant decryption though. You know so that the app (data) partitions are decrypted along with the headers and stuff. This was possible with Decrypt9 and GM9 just skips the data partitions from what I can tell. From that you could either store them (since decrypted data can actually be compressed) or apply rom hacks/patches.

I had a look at https://github.com/ihaveamac/3DS-rom-tools/wiki but I don't really understand how to do this with any of the dev tools listed there. Well at least the D9WIP files are still up, so I guess I'll just dl and use that again

GodMode9 can decrypt a CIA (+ contents inside), I think it was shallow decryption that was deprecated. GM9 has a different codebase that allows it to be more efficient than Decrypt9WIP.

 

[jaspern]

GodMode9 can decrypt a CIA (+ contents inside), I think it was shallow decryption that was deprecated. GM9 has a different codebase that allows it to be more efficient than Decrypt9WIP.

Oh so you are saying that the one decryption option actually does decrypt all of the data?
Guess I have to recheck with a fresh batch of files. Appreciate the help guys

 

[ihaveahax]

Oh so you are saying that the one decryption option actually does decrypt all of the data?
Guess I have to recheck with a fresh batch of files. Appreciate the help guys

if your intention to decrypt is to extract files from it, then you should know that some PC tools like ctrtool and fuse-3ds work on encrypted games now to extract data from them. neither directly decrypt CIA or other formats

 

[TurdPooCharger]

Gotta say, v1.6.2 is the best release so far. Didn't think this was possible, but it now supports 64-bit.

 

[SirNapkin1334]

Gotta say, v1.6.2 is the best release so far. Didn't think this was possible, but it now supports 64-bit.

By your wording, it seems that you may have missed out on the other themes. Did you see those? (Reboot a few times, with ~5 seconds spaced apart)

 

[TurdPooCharger]

@d0k3, I narrowed the source of that hacky-wonky bug for those nonworking CIAs injected in H&S.

With much grimace and sense of futility after many hours of cross comparing compatible & non-compatible titles, I looked into older homebrews for a possible lead. To my great surprise, something interesting turned up. Of the three well known theme managers out there, only one works with injection: Themely.

I did some hex splicing between Anemone3DS_v1.0.0 (early stable build) and Themely_v1.3.1-i1 (last obtainable release in @ihaveamac's repo).

Because the two are surprisingly (or not surprisingly) similar in terms of system and access control calls within their extended header, I did a quick and dirty swap from Themely's latter 3/4th extheader.bin over to Anemone3DS.

Amazingly, hacky-Anemone3DS managed to launch, splash, and boot to theme selection menu!

I haven't tried using the injection as-is and don't plan to as there is some instability with ARM11 crashes. While a patch to fix this bug still might not be practical or possible, it is at least good to know where and maybe why most SD titles don't or can't work on NAND.

Edit - Managed to inject Snes9x_3DS v1.30 into Face Raider and played F-ZERO. Tried injecting Pokemon Yellow VC into Face Raider with semi-success. It boots but gives a save data error.

 

[TurdPooCharger]

I got a little good news but mostly bad news.

The good news is I've finally found the mysterious bug that plagues certain CIA injections.

Spoiler: Cause of Hacky-Wonky Bug

It is partially patchable by hex editing.

The bad news is that many injections will still fail. Apparently, the 4 offset addresses from 0x1C0 to 0x1C3 are part of something called "Stack size", referred from here: https://3dbrew.org/wiki/NCCH/Extended_Header

I don't know enough what this stack size is, but my hunch tells me it has something to do with specifying either how much RAM or drive space the title requests from the 3DS system.

• All Virtual Console games (SNES, GBC, GBA, NES) will launch but fail with a save data error or boot up blank.
  
• Some homebrew and game titles may launch, work for a bit, and then crash later.
• The file size of the CIA has no strong correlation whether or not the injection will work. Graphic intensive or "complex" games seem to be the factor.
  
• Other injections appear stable. I believe these titles RAM/storage usage fall well under the requested stack size.
• When it is not 00, that wonky hex offset can be anything else. Common values are 02, 03, and 08.

Official games that failed for one reason or another:

• The Legend of Dark Witch 1 (131 MB)
  
• Legend of Zelda - A Link to the Past (SNES VC) (5.77 MB)
  
• Pokemon Yellow (GBC VC) (9.83 MB)
  
• Gradius (NES VC) (5.92 MB)
  
• F-Zero Maximum Velocity (GBA VC) (4.87 MB)

Official games found to work:

• 3D Streets of Rage (13.8 MB)
  
• Shovel Knight - Treasure Trove (135 MB)

Homebrew that works then crashes after exiting:

• Anemone3DS (v1.3.0) (824 KB)

Homebrew that works with good stability:

• Snes9x_3DS (v1.30) (1.21 MB)
• Virtuanes_3DS (v1.02) (1.11 MB)
• Zelda ROTH (v1.0.2) (51.1 MB)

The other half of wonky is that Nintendo probably put some sort of safety for Sys Apps where there's probably no way of increasing stack size. At that point, we probably shouldn't be pushing our luck messing with SysNAND.

Edit - Nvm. I got the offsets wrong stack size is located at 0x1C , not 0x1C0. That wonky hex number is actually part of something called SystemInfo.

 

[redunka]

That "wonky hex" (8 bytes after 0x1C0) is SaveData size, so it shouldn't be a surprise that VC games throw save data errors when saving is disabled in exheader.

 

[TurdPooCharger]

That "wonky hex" (8 bytes after 0x1C0) is SaveData size, so it shouldn't be a surprise that VC games throw save data errors when saving is disabled in exheader.

Yah, I did some more 3dbrew.org reading after my last posts on what that exact hex traces back to and did more testing in trying to get other SD games to work on NAND.

Most official SD titles differ in where they make their save data compared to system titles. The few SD titles like 3D Streets of Rage and Shovel Knight can work fine without their specified SavaData size because they create the save files outside the typical 0:/Nintendo3DS/<ID0>/<ID1>/title/00040000/<TitleID>/data directory.

In the case of 3D Streets of Rage, saves are made directly on the root of the SD card.

System titles make their saves at 1:/data/<ID0>/sysdata/<SaveID-Low>/<SaveID-High>.

Injecting Pokemon Yellow (GBC VC) and Gradius (NES VC) into Face Raider (because it's a NAND game most similar to SD games), I've tried dabbling with something called the Storage Info within the extheader.bin. This handles save locations for system titles. I have no luck tricking my 3DS system into making SD titles do their saves on NAND at that specified 1:/ directory. I'll probably mess around with this a little more if I have any new ideas to test out, but at this point I'm starting to think you can't convert typical SD titles into functional NAND titles without a serious rewrite if they do saves at the mentioned 0:/ directory.

At the end of the day, this bug finding exercise won't mean much to 99% of 3DS users because ... *drum roll*
.
.
.
Most users, (aka: "normal people"), will install their CIA games and titles on the SD card as was intended. Why mess with the puny 1 GB NAND if you have no reason to? The bright side to this is that I'm glad there's a fix for many homebrew titles that haven't worked before when installed with H&S-related injections.

Btw, "wonky" is a term @d0k3 coined for this bug in previous GM9 GitHub issues regarding H&S injection. It is super technical word, yes lol.

I didn't report this finding at his GitHub as I'm not sure if it was worth exploring further or (fully) fixable in the first place. Also, I thought he would like to know from something he wrote back in another thread:

Additional note, though (yes, one more): There is some kind of size limitation in place. You won't be able to replace H&S with a commercial game title because that's much larger (although I'd love to be proven wrong by you guys).

 

[d0k3]

Yah, I did some more 3dbrew.org reading after my last posts on what that exact hex traces back to and did more testing in trying to get other SD games to work on NAND.

Most official SD titles differ in where they make their save data compared to system titles. The few SD titles like 3D Streets of Rage and Shovel Knight can work fine without their specified SavaData size because they create the save files outside the typical 0:/Nintendo3DS/<ID0>/<ID1>/title/00040000/<TitleID>/data directory.

In the case of 3D Streets of Rage, saves are made directly on the root of the SD card.

System titles make their saves at 1:/data/<ID0>/sysdata/<SaveID-Low>/<SaveID-High>.

Injecting Pokemon Yellow (GBC VC) and Gradius (NES VC) into Face Raider (because it's a NAND game most similar to SD games), I've tried dabbling with something called the Storage Info within the extheader.bin. This handles save locations for system titles. I have no luck tricking my 3DS system into making SD titles do their saves on NAND at that specified 1:/ directory. I'll probably mess around with this a little more if I have any new ideas to test out, but at this point I'm starting to think you can't convert typical SD titles into functional NAND titles without a serious rewrite if they do saves at the mentioned 0:/ directory.

At the end of the day, this bug finding exercise won't mean much to 99% of 3DS users because ... *drum roll*
.
.
.
Most users, (aka: "normal people"), will install their CIA games and titles on the SD card as was intended. Why mess with the puny 1 GB NAND if you have no reason to? The bright side to this is that I'm glad there's a fix for many homebrew titles that haven't worked before when installed with H&S-related injections.

Btw, "wonky" is a term @d0k3 coined for this bug in previous GM9 GitHub issues regarding H&S injection. It is super technical word, yes lol.

I didn't report this finding at his GitHub as I'm not sure if it was worth exploring further or (fully) fixable in the first place. Also, I thought he would like to know from something he wrote back in another thread:

Yup, you proved me wrong .

Now, my guess on this... I think that homebrew and games using the 3DS native save system simply don't work, because, as you wrote, that works in a different way on NAND and SD. Your earlier fix, just setting the save size to zero, effectively disabled the savegame function for these homebrew / games. This, of course, can have unforeseen consequences. Software like FBI doesn't use the native save system, but rather has it's own implementation of a save system.

Question is, how to handle this? I can disable injection for all titles that have a save size > 0, and that may be the smartest choice here. NAND saves do work different from SD saves, and it's unsure if stuff works at all if we force it (ie. setting the save size to zero).

Btw, @TurdPooCharger - documenting your findings on 3dbrew may make sense.

 

[TurdPooCharger]

@d0k3, i'm on the fence on what to do with this hex in terms of the script I've been working on. I don't know how you'll tackle it on your end for built-in GM9 H&S injector.

Since saves are different between most SD and NAND titles, one approach is to block off injection like what you mentioned. However, many homebrew titles with savedata hex that isn't 00 will work just fine when it is disabled.

I can't think of a better way of differentiating official vs homebrew titles other than the NCCH header. There's a maker code section that has a bit set to Nintendo or "01" somewhere. I haven't checked if 3rd party game publishers have their maker code set different than Nintendo's.

Another method is to use a white list for titles known to work with changed 00 savedata, but this is cumbersome to test and include for every title. On top of that, the list would get outdated as time goes by.

The last approach would be to warn the user his or her selected title that's getting injecting may not work with disabled save. Give them a choice if they want to proceed by their own choosing.

Edit - As for documentation of this finding on 3dbrew, that's a great idea. Once I get wiki editing privileges, some time, more familiarity using proper technical terms, I'll see to it. Just not now as I'll like to be on hiatus. lol

 

[d0k3]

Since saves are different between most SD and NAND titles, one approach is to block off injection like what you mentioned. However, many homebrew titles with savedata hex that isn't 00 will work just fine when it is disabled.

I honestly don't think we should put in too much effort into H&S injection. It's a one trick feature, honestly, and the only thing on there that makes really sense to inject is FBI. I'm all for experimentation, though. Can you give me a list of such titles (a short one is okay, doesn't need to be complete)?

I think the two options we have here is either just set it to zero and leave testing to the user, or block it.

 

[TurdPooCharger]

I honestly don't think we should put in too much effort into H&S injection. It's a one trick feature, honestly, and the only thing on there that makes really sense to inject is FBI. I'm all for experimentation, though. Can you give me a list of such titles (a short one is okay, doesn't need to be complete)?

I think the two options we have here is either just set it to zero and leave testing to the user, or block it.

Ergrhgm. Can you clarify what kind of list you're looking for?

List of...

(A) homebrew titles
-or-
(B) official titles

discovered so far known to work when SaveData is disabled?

My current approach for the next update on injection script is to use the TitleIDs on TitleDB.com to white list all the known homebrews, automatically inject disabling SaveData (I have yet to find one homebrew that utilizes SaveData), and then warn users injection incompatibility with Nintendo/3rd party titles -> with choice to inject at their own risk.

Edit - That approach is probably ill suited for GodMode9 making it grossly bulky and hassle to keep updated. You could do without the list and warn users injection will disable SaveData, strongly recommend only injecting homebrews, yada yada might not work for official games, and do you wish to continue?

Edit 2 - Checked the Maker Code in NCCH0 header if it's always

• 30 for homebrew
• 31 for Nintendo
• 50 for SEGA

Nope, 30 also appears on retail 3rd party.

Edit 3 - I'm almost certain all homebrew titles, at least those having an equivalent .3dsx version, do not need nonzero SaveData. Because they make saves in 3ds folder or where ever else that's not in the Nintendo 3DS folder, that SaveData value has no impact in their functioning.

In the earlier case of Anemone3DS crashing, I found out it was due to taxing the app loading over 700 themes. Crashes happen for .3dsx and .cia versions as well. Lower theme count to something like 100 keeps it stable.

 

[d0k3]

Ergrhgm. Can you clarify what kind of list you're looking for?

List of...

(A) homebrew titles
-or-
(B) official titles

discovered so far known to work when SaveData is disabled?

I'd be happy if you could name 5 in each category, but, we're looking for titles that have a nonzero save size from the beginning, of course . And, just so I understand that correctly... Does that even do anything for homebrew? Ie. don't homebrew always work (or not work), based on your findings?

I'm leaning towards just setting savedata to zero, just so you know. The end result will not be worse than what we got now, and GM9 allows to revert to standard H&S easily.

 

[TurdPooCharger]

I'd be happy if you could name 5 in each category, but, we're looking for titles that have a nonzero save size from the beginning, of course . And, just so I understand that correctly... Does that even do anything for homebrew? Ie. don't homebrew always work (or not work), based on your findings?

I'm leaning towards just setting savedata to zero, just so you know. The end result will not be worse than what we got now, and GM9 allows to revert to standard H&S easily.

OooO, okay gotcha!

For retail games, I'll need to find more example titles. I found three so far due to pulling them out of my game collection for titles less than 400 MB. The three found are digital downloadable only??? I'll try to find a small enough cartridge based title with nonzero SaveData for working injection. I'll produce the list of 5 retail games with Name, Title ID, Region, and Product ID, so you know exact which to look for and test against.

For homebrew titles with nonzero SaveData, all (4) of @bubble2k16's emulators, @Rinnegatamante CHMM2 theme manager, and @nop90's ported games (still testing his numerous library). These didn't work with injection until flipping them to 00.

Edit - And yes, my currently held belief and observation is that disabled SaveData has no impact on homebrew titles. They don't seem to make save files like official titles, so they appear to ignore using it.

Edit 2 - I'll stop scripting for 'fget' and 'fset' command testing until I find and present those 5 official titles.