Changes

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

| 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.

| 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.

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.

| 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]]

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

| [[User:Yellows8|Yellows8]]

| [[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.

| 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.

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