[FEATURE REQUEST] Ability to Decrypt/Encrypt 3DS Game Cartridge .sav Files

[DeadSkullzJr]

Got a great idea on how to improve GodMode9? Add the ability to decrypt and encrypt raw .sav files from 3DS game cartridges.

Describe the feature you'd like GodMode9 is able to dump encrypted .sav files, but you can't decrypt the data with the current builds. I would like the ability to decrypt and encrypt the .sav files, allowing the ability to directly edit the decrypted .sav file instead of splitting it into pieces using homebrew alternatives such as JK's Save Manager or Checkpoint. Afterwards, you could then encrypt it and import that save back into the 3DS game cartridge using whatever preferred solution (unless GodMode9 gets the ability to import .sav files all on its own of course).

Describe alternatives you've considered I've used both JK's Save Manager and Checkpoint, while their purpose is solid, I prefer the ability to maintain my own .sav files as a whole and not just portions of it.

What I am NOT asking for I am not asking for something like JKSM or Checkpoint, those pieces of software don't produce any type of .sav files, instead those two produce save data in pieces (not that it's a bad thing, it's just not what I am looking for at the moment). They also tend to alter information after importing data even if the data imported was unaltered in any way, which to me doesn't make sense given if the data is unaltered, it should yield 1:1 results from a save backup, that just makes me think there are some inaccuracies or inconsistencies somewhere. I personally value my save data, I feel we need a better solution.

Side Note I tried looking into a P.C. software based solution to handle save encryption and decryption given that's faster than using the Nintendo 3DS, but stumbled on nothing viable of the sorts. I don't know 100% how save decryption works exactly with 3DS game cartridges, all I know is you can't really mix .sav files UNLESS it was already decrypted and then re-encrypted specifically for your game cartridge, which to me tells me it has something to do with unique identifiers of the game cartridge while still using the same encryption algorithm, might be something that could be brute forced one day with special software. There isn't a whole heck of a lot of research on preserving .sav integrity for the 3DS, just mostly ways to split it into pieces, then importing amalgamated Frankenstein data, which is fine and dandy, but I want that type of control at the raw .sav level.

This feature unfortunately would only benefit physical cartridge users really, JKSM and or Checkpoint is still viable for the digital side of things for dumping the necessary data for the digital based titles. Who knows maybe there is a better solution for digital users as well that could be put into work, right now I have no ideas on how to go about that, maybe give the ability to dump the save data into gm9/out decrypted inside a generated game folder, then encrypt and force it back into the original location?

[d0k3]

Save encryption on 3DS carts is somewhat complicated, and, yes, I'd very much like to have the ability to writes saves in GM9, too.

We'll look into it, but I may need your help for testing,

[d0k3]

Alright, here's some info we'll need for decrypting savegames: https://www.3dbrew.org/wiki/Savegames

I don't have any gamecarts I could test with. As this is a pretty complicated algorithm, coding blind (that means without being able to test it myself) is out of question. We will need help from a dev.

But... just so you know, savegames on gamecarts are not only encrypted, they are also signed. Without a special import tool, any edit to the savegame file would result in a non working save. Even worse: any working encryptor or signer would also need data from the gamecart, you can't do that just in software.

And that would, in essence, even with a working savegame decryptor, leave you with no more functionality than you got now. Meaning: just backup functionality, and apparently not what you want.

Guess we'll also need to discuss if this makes sense. Any opinions?

[aspargas2]

Well, as far as I know and from glancing over 3dbrew, the signing you're talking about is just an AES CMAC similar to the many CMACs which gm9 is already able to handle. Unless I'm missing something big here, there's no reason gm9 couldn't theoretically restore modified save backups to cartridges, and then fix the CMAC to make the save work again.

One thing to bring up is the wear leveling present on many cartridge savegames. I think it's a well-understood format, so it should just be another layer to unwrap, but it's good to keep in mind that it exists.

[DeadSkullzJr]

Hmmm couldn't you just make GodMode9 read into whatever this unique data is from the cartridges, then go through the process of doing either encryption or decryption? I guess when I envisioned this, I sort of envisioned a similar setup to how the Powersaves did it, just with the added ability of leaving the save decrypted so you could potentially use a save editor of sorts or something along the lines, because the save backups from that are also encrypted, you can't mix saves between cartridges obviously (unless it's theoretically left decrypted, then re-encrypted using the different card data from another cartridge) but still, it apparently decrypts the data though whenever you use their save codes (at least I think that's what it does), then re-encrypts when finished. The downside is their online servers handle that process, so it's not like you can really spot what it does for yourself. I just thought since we can already read and write to the game cartridges similar in fashion to the Powersaves, why not go all the way you know?

[DeadSkullzJr]

Well, as far as I know and from glancing over 3dbrew, the signing you're talking about is just an AES CMAC similar to the many CMACs which gm9 is already able to handle. Unless I'm missing something big here, there's no reason gm9 couldn't theoretically restore modified save backups to cartridges, and then fix the CMAC to make the save work again.

One thing to bring up is the wear leveling present on many cartridge savegames. I think it's a well-understood format, so it should just be another layer to unwrap, but it's good to keep in mind that it exists.

Wear leveling? As in actual wear on the save chip or? Kind of lost me on that a bit, if it means something else, mind elaborating or restating differently?

[aspargas2]

So yeah, it's meant to balance the amount of actual wear on the save chip. Usually stuff like this is done transparently in hardware, but for some reason Nintendo decided to have the software on the console handle it for card1 games. 3dbrew talks about this in more detail.

[profi200]

If this has not been mentioned yet: You need the gamecard unique ID to decrypt these saves from what people call "private header".

[d0k3]

Well, it's pretty much obvious, decrypting cart saves is major pita, even more so than importing (we need help with that issue, too, #589). I'd very much like both, this and the importing thing, included in GM9, but I don't see myself getting to work at that in the near future, especially with me not being all that knowledgable about cart things (for importing), and all that wear leveling stuff.

Anyways, just my two cents: Both encryption and signing could be done transparently. You'd just copy the save from the cart, you'd get a decrypted copy. You write it back, GM9 handles signature and encryption behind the scenes. This way, we'd always have the data from the cart available. We've done it in a similar way in several places (for example the whole system partitions handling, or ticket.db mounting).

[DeadSkullzJr]

Well on the bright side I put the idea out here, I guess a bit of patience and some time is all that can be provided on the table for now. Maybe one day someone with enough knowledge can come in and help with the integration process, I lack too much to do it myself, and what I know likely isn't even close to enough on what is what, I just have an idea of how this process could in theory be executed.

[aspargas2]

I can probably figure out and implement the wear leveling, crypto, and signing stuff, but I don't know anything about the hardware level of reading/writing the save to/from the physical save chip. I'll just have to work with whatever we already have for that (which iirc isn't perfect) and hope someone improves it later.