3DS System Flaws: Difference between revisions

Line 279:

| Leak of normal-key matching a key-generator key

| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.

Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.

Note the devkit key-generator was discovered to be the same as the retail key-generator.

Note that the devkit key-generator was discovered to be the same as the retail key-generator.

| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.

| pre-[[1.0.0-0|1.0.0-X]]

Line 459:

Line 458:

| [[User:Yellows8|Yellows8]]

|-

| movable.sed keyY vulnerable to brute-force

| seedminer: movable.sed keyY vulnerable to brute-force

| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.

| Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.

@@ Line 279: / Line 279: @@
 | Leak of normal-key matching a key-generator key
 | During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.
 Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.
-Note the devkit key-generator was discovered to be the same as the retail key-generator.
+Note that the devkit key-generator was discovered to be the same as the retail key-generator.
 | Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.
 | pre-[[1.0.0-0|1.0.0-X]]
@@ Line 459: / Line 458: @@
 | [[User:Yellows8|Yellows8]]
 |-
-| movable.sed keyY vulnerable to brute-force
+| seedminer: movable.sed keyY vulnerable to brute-force
 | Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.
 | Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.