Changes

Jump to navigation Jump to search
812 bytes added ,  17:08, 26 February 2018
Add information about "impossible" consoles with uninitialized movable.sed files. See github issue for context.
Line 29: Line 29:  
Movable.sed always exists on retail and development units(written to NAND at the factory), however if reading this file fails(svcBreak would be executed if the [[Filesystem_services_PXI|file-read]] code-path return value is 0xC8804464) the system will fall-back to using a console-unique keyY already in [[PSPXI:GetLocalFriendCodeSeed|memory]], with the last 8-bytes being loaded from the 8-bytes following that u64. On development units the code-path handling movable.sed would execute [[SVC|svcBreak]] if file-reading(regardless of error-code) or verifying the RSA signature fails(this would brick the 3DS), RSA verification failure on a retail unit here would also cause a brick.
 
Movable.sed always exists on retail and development units(written to NAND at the factory), however if reading this file fails(svcBreak would be executed if the [[Filesystem_services_PXI|file-read]] code-path return value is 0xC8804464) the system will fall-back to using a console-unique keyY already in [[PSPXI:GetLocalFriendCodeSeed|memory]], with the last 8-bytes being loaded from the 8-bytes following that u64. On development units the code-path handling movable.sed would execute [[SVC|svcBreak]] if file-reading(regardless of error-code) or verifying the RSA signature fails(this would brick the 3DS), RSA verification failure on a retail unit here would also cause a brick.
   −
The keyY is hashed with SHA256, the first 0x10-bytes from the hash is used with the below snprintf for ID0 in [[SD Filesystem|sdmc/Nintendo 3DS/<ID0>/<ID1>]] and [[Flash Filesystem|nand/data/<ID0>]]. ID0 is generated by: snprintf(outdirname, maxlen, "%08x%08x%08x%08x", hashword[0], hashword[1], hashword[2], hashword[3]).
+
The keyY is hashed with SHA256, the first 0x10-bytes from the hash is used with the below snprintf for ID0 in [[SD Filesystem|sdmc/Nintendo 3DS/<ID0>/<ID1>]] and [[Flash Filesystem|nand/data/<ID0>]]. ID0 is generated by: snprintf(outdirname, maxlen, "%08x%08x%08x%08x", hashword[0], hashword[1], hashword[2], hashword[3]). Thus, ID0 is the first half of the SHA-256 of movable.sed bytes 0x110-0x11F inclusive, with the four u32s of the half-SHA-256 byte-flipped.
 +
 
 +
'''Note:''' It has been observed at least 2 times that the 0x120+ part has been left uninitialized, yet the 3DS is still working without any form of modfication, behaving just as if it was initialized and working just fine with Custom Firmware installed.
 +
It is currently unknown why this is the case, but the following information holds true for both systems:
 +
* They are Old 3DS Retail Consoles from Europe
 +
* They were shipped with Firmware version 1.0.0-0E
 +
* Their Serial Number starts with CEM10, differ from there on
 +
* SoC manufacturing date of 2010
 +
* They have not been formatted, ever
 +
More details [https://github.com/d0k3/GodMode9/issues/318 on this Github Issue]
1

edit

Navigation menu