Update: RPU can now unlock the eMMC.
The usual header: this will neither enable a downgrade nor running pirated porkemon [sic] on >4.5.
An anonymous source gave me the key required to generate the console specific eMMC lock/unlock password in exchange for posting his/her following statement in my initial release posts and the tool itself:
The good news: this makes it possible to unbrick even if you don't have a prior NAND backup.
The bad news: for now it has to be done in a quite roundabout way: unlock the eMMC/NAND -> dump it -> relock the eMMC/NAND -> force erase -> flash the NAND image -> unbricked.
The reason for this detour is that besides being locked, the eMMC also gets write protected (just like some people had already stated) and I wasn't able to remove said write protection yet (in this context: if anyone got any idea how on earth i could get the Pi to do CMD27 like it's supposed to work please let me know).
But said write protection gets wiped by a force erase too, thus offering a working solution for now (although I'd have preferred a single keypress unlock and will keep working on that).
I just pushed the changes to github, either do the online or offline update as described in the guide to get the new version.
As i believe not everyone to be interested in the technical details I'll put them in a spoiler:
This is another piece of evidence that the bricking doesn't happen random, as (on the most objective level) the locking occurs using a deterministic (not random) console specific password. I don't want to and will not make any claims beyond that (even though personally I do believe it happens with intent as a clone deterrent gone horribly wrong, this IMHO still isn't decisive damning evidence).
Feasibility of the unlock -> dump -> lock -> force erase -> flash approach was proven by gamesquest1 (using the unmodified 2.0b2) and Inaki (using the region patched 2.0b2). Thanks for testing dudes.
Also thanks to krisztian1997, khalaan and of course the anonymous source. Love you guys (no homo).
p.s. I'll use this opportunity to once again draw attention to step 18 of the guide *nudge nudge wink wink know what i mean*
The usual header: this will neither enable a downgrade nor running pirated porkemon [sic] on >4.5.
An anonymous source gave me the key required to generate the console specific eMMC lock/unlock password in exchange for posting his/her following statement in my initial release posts and the tool itself:
The good news: this makes it possible to unbrick even if you don't have a prior NAND backup.
The bad news: for now it has to be done in a quite roundabout way: unlock the eMMC/NAND -> dump it -> relock the eMMC/NAND -> force erase -> flash the NAND image -> unbricked.
The reason for this detour is that besides being locked, the eMMC also gets write protected (just like some people had already stated) and I wasn't able to remove said write protection yet (in this context: if anyone got any idea how on earth i could get the Pi to do CMD27 like it's supposed to work please let me know).
But said write protection gets wiped by a force erase too, thus offering a working solution for now (although I'd have preferred a single keypress unlock and will keep working on that).
I just pushed the changes to github, either do the online or offline update as described in the guide to get the new version.
As i believe not everyone to be interested in the technical details I'll put them in a spoiler:
The lock/unlock password is generated by encrypting the console specific CID (the unique serialnumber of the eMMC) with GW's master AES key (which I don't and don't want to have) using the 3DS AES engine in CTR mode. I had to look that one up as I only ever use CBC and XTS: CTR uses the block cipher to generate a keystream to be xored to the plaintext with no cleartext or cyphertext feedback whatsoever. In other words: this keystream is constant for all 3DSes, thus enabling an unlock without using a working 3DS to generate the password. To get this keystream one has just to encrypt 16 bytes of 0x00, which my source did.
Lock/Unlock mechanism (in pseudocode, those functions are named differently and have different signatures on the 3DS as well as in RPU):
Thanks GW for choosing the one AES mode which made this approach possible.
Lock/Unlock mechanism (in pseudocode, those functions are named differently and have different signatures on the 3DS as well as in RPU):
Code:
uint8_t CID_buffer[CID_length];
CID_buffer = read_CID(eMMC);
CID = AES_encrypt(CTR , GW_MASTERKEY, CID, CID_length ); //this is equivalent to CID = CID xor AES_encrypt(CTR , GW_MASTERKEY, 0x0, CID_length);
CID[0] = 5; //bit 0 and 2 set, meaning "set password" and "lock eMMC", for the unlock it's CID[0] = 2; //bit 1 set meaning "clear password" (unlock happens implicit)
CID[1] = 14; //next 14 bytes are the password
SD_command(eMMC, 42, CID, CID_length); //command 42 (lock/unlock) on the eMMC sending 16 bytes starting from &CID as data payloadThanks GW for choosing the one AES mode which made this approach possible.
This is another piece of evidence that the bricking doesn't happen random, as (on the most objective level) the locking occurs using a deterministic (not random) console specific password. I don't want to and will not make any claims beyond that (even though personally I do believe it happens with intent as a clone deterrent gone horribly wrong, this IMHO still isn't decisive damning evidence).
Feasibility of the unlock -> dump -> lock -> force erase -> flash approach was proven by gamesquest1 (using the unmodified 2.0b2) and Inaki (using the region patched 2.0b2). Thanks for testing dudes.
Also thanks to krisztian1997, khalaan and of course the anonymous source. Love you guys (no homo).
p.s. I'll use this opportunity to once again draw attention to step 18 of the guide *nudge nudge wink wink know what i mean*
