search

hacks-guide / Guide_3DS

A complete guide to 3DS custom firmware, from stock to boot9strap.
https://3ds.hacks.guide/
MIT License
1.57k stars 315 forks source link

Potential process to bypass System Transfer to utilize DSiWare downgrades - untested - theory only #623

Closed Onoitsu2 closed 8 years ago

Onoitsu2 commented 8 years ago

I have been tinkering with some things, such as the saving of a title and importing on the other device, using DSiWare, and have an idea, that probably won't pan out, but I would need a system with a hard mod to test this so that it could be tested "stock."

If there is some way to have an emunand (or just use sysnand if brave) and fool the eshop into reading the serial number of the other console (stock) you could sign into their same NNID (much like you can on an emunand that is simply unlinked from the sysnand, by signing into the same NNID in Settings that shows for sysnand)

I wonder how DSiWare exports are saved to SD, if said encryption scheme could be found, you could then install it from the destination's NNID on the source system (meaning the destination keeps its original NNID!), inject the save, and simply move that over SD to the destination system, no system transfer needed. I did something similar when I had done my transfer (2x N3DS XLs) and it failed, and the game did not move over, I installed it on the destination system (having already purchased it on that newly moved NNID, restored the NAND on the source system, exported the DSiWare to SD on destination, to find where it should be copied into, and on the source too. I replaced it with the copy from the source system, and imported it on destination, it bringing in the altered save from the source system)

Perhaps we can seek to spoof the SecureInfo_A on the source system (sysnand or emunand) to get it to encrypt the exported DSiWare save the same way. Just a thought on side-stepping the week delay on the system transfers. I don't have a system currently to test this theory on, or else I would. But it was something that just came to me as a logical result of my tinkering to resolve a failed system transfer, was not about to wait 2 weeks to finish, nor buying the game again (fieldrunners)

This is just my thoughts on something, totally untested as I don't have a stock system to test it with (definitely want hardmod on it), if it can even be done, and I am not able to use my kids systems that I have finally got set up just right for them, that would be just mean.

Onoitsu2 commented 8 years ago

Also have a Reddit thread on the official page open about this, so might check that for our 3DS overlords like yourself Plailect, posting there too. https://www.reddit.com/r/3dshacks/comments/58b9nj/potential_process_to_bypass_system_transfer_to/

Plailect commented 8 years ago

All SD data is encrypted with console unique keys, and cannot be modified unless you have the console's moveable.sed file, which you could only get with arm9 access (the exact thing you're trying to get with the process).

Onoitsu2 commented 8 years ago

Then how was I able to backup the save on my source system, after restoring the NAND from the backup, and the destination system able to decrypt the .bin file that I replaced? It has to be something with the NNID then, not the console Serial Number because that would not have carried across from the System Transfer, only NNID would. And if you can get the CFW system signed into the same NNID as the destination, then it stands to reason it should encrypt it the same way, as that is the only logical assumption, since I have done something like this when I had a failed System Transfer where the game was nowhere to be found on the destination.

To test this, have the DSiWare game on source, with hacked save, backup NAND, system transfer and allow titles to be moved. Then simply delete it from the destination, like it failed to receive it. Then you restore your NAND on source, and export the DSiWare to SD, move the exported #####.bin from the 'Nintendo DSiWare' folder that is 2 folders deep within the 'Nintendo 3DS' folder to the destination system's SD card, and then attempt to import, if successful you can then have said hacked save on the still stock system. This is how I had to start my process of my DSiWare Downgrade because sure it moved the NNID, but not much else, due to its failure. Still don't know how it failed having both on a charger, and less than 3 inches from each other, no matter it worked after this process.

Plailect commented 8 years ago

Then how was I able to backup the save on my source system, after restoring the NAND from the backup, and the destination system able to decrypt the .bin file that I replaced?

Because the system transfer moves your current moveable.sed from the source device to the destination device. If you restore the sources device from a backup, they will then use the same moveable.sed file and can share SD card data, but this only works because you have a copy of the moveable.sed file that the target device is using. This file would be impossible to have access to without system transferring unless you already had arm9 access.

Onoitsu2 commented 8 years ago

Thank you for clarifying this for me, makes sense, perhaps one that is skilled in homebrew could develop an app that could be a very small exploit to backup that movable.sed to the SD card so that it can imported to the CFW system. Simply anything to avoid the current 7-day period for doing any system transfers is the thing I was trying to logically tackle. Thank you Plailect, as you always show, you are a master of the 3DS!