Separate names with a comma.
Discussion in '3DS - Flashcards & Custom Firmwares' started by SolidSnail55, Mar 18, 2015.
Australia is the same as Europe.
oh I will have to correct that lol
I guess we could go ahead and arrange preliminary trades for N3DS fat16s as well for when region swapping becomes possible?
If someone's interested in swapping their US N3DS partition for my PAL N3DS's when that happens, let me know!
it is possible right now, and yes, I will swap my US fat16 for your EUR fat16
For the New 3DS? I was told that it couldn't be done because the xorpads aren't obtainable.
oops I read that wrong, and I do not have a New 3ds, so I don't know if its possible
New 3ds are not available yet for this method i think.. because of encryption.
Anyone have EUR NAND, and would like to dump it?
(I've got a JP but not sure original user is up for me to trade it away)
FYI, you won't be able to trade over fat16 partitions unless you delete the movable.sed file. Currently the movable.sed will brick emunand/sysnand if you transfer them over unmodified. Part of the KeyY string stored in the file has to be updated to match the new console (which is normally done by the System Transfer application during a system transfer). But the string is hashed and manually editing it is not possible right now. Unless someone comes out with a tool that does this for you, it won't be happening anytime soon. So you can't transfer over installed SD content or NNIDs to another console in this way. You will need to remove the movable.sed file from both before swapping them. (this will result in them being reset to factory default).
Of coarse you can transfer the movable.sed and the associated content that depends on it from different emunand images on the same console. (for example you want to move your emunand stuff over to sysnand without updating sysnand). But things break the moment you try putting it on a new console without using system transfer.
The end result is you need to have both the donor system and the target system unlinked from NNID otherwise you'll never be able to relink your NNID to it. (this also results in eShop never letting you access it)
Also you might have to create a new NNID for the region you have your 3DS at if you don't have an NNID for that region. I think NNIDs are region locked.
According to http://3dbrew.org/wiki/Nand/private/movable.sed it should be as simple as using the aes engine to encrypt the hash over the first 0x120 bytes.
That would be great. Maybe someone can write some homebrew that does this? I have been trying forever to restore my old SD card content and friend code from a bricked 3DS (which I sold to someone and is no longer bricked. But I don't have physical access to it anymore). I have since transferred my NNID to my current console by calling Nintendo, so in theory I should be able to do this. But the movable.sed is the current roadblock.
I think you need to re-encrypt everything that's been encrypted with per-console keys (that's not specified by movable.sed). I think that includes the dbs on NAND.
There's a few things out there that do a little of this. Like the title key dumper/decrypter (as that's stored in the dbs folder). Maybe the dev behind rxTools can do something like this. He's already got a lot of other things like decrypting/encrypting entire fat16 partition on the 3DS without the use of xorpads among other things. So this sounds like something best suited for that. I can only hope.
From quick inspection (may missed something/a lot) but in order to do a manual system transfer + region swap:
1) N3DS: Change region with https://gist.github.com/yellows8/f15be7a51c38cea14f2c
2) O3DS: Get movable.sed and decrypt the MAC
3) N3DS: Encrypt movable.sed from O3DS
4) O3DS: Decrypt dbs/ticket.db and dbs/title.db
5) N3DS: Re-encrypt files from 4 and then merge with N3DS's ticket.db/title.db (not sure if needed, but I think this way the system apps/firm will still have tickets)
6) N3DS: Copy merged ticket.db/title.db as well as movable.sed over. Also copy over "data" to get all your saves.
I think an alternative to merging title.db is to replace title.db and then immediately do a system update (in the same boot cycle). Hopefully that will write the new tickets. I'm not even sure tickets are required for the system apps and stuff, but it's in there, so idk.
So the data folder doesn't have to be messed with? Just the stuff in the dbs folder? That makes things a bit easier then.
I don't know what any of this means but if it's progress I like it
i'll sell TWN KOR and CHN secureinfo_a files for $70 each
first come first serve
(i'm joking but if anyone is desperate enough... then it's a deal)
Wait, a manual system transfer is possible!? Meaning the systems don't have to be on latest firmware for this manual system transfer?