Hacking [Info] eMMChax/bootloaderhax

[DSoryu]

So, acording to some resources and reads I was taking last nights, I came into this posibility, but I need to know what can be done atm.

The 3DS unique console key is based on a hardware chip known as the eMMc, and acording to this there is a posibility to do something interesting with that information.

Correct me if I'm wrong.

 

[yifan_lu]

Where did you get that crazy idea?

 

[DSoryu]

Where did you get that crazy idea?

Well, I was reading something on the XDA forums that had to do with that article linked, a little flaw the Bootloader has on some devices.

I know I'm wrong, so... I only want answers.

 

[shinji257]

That won't work since the architecture is quite a bit different on a 3DS than on a cell phone...

 

[yifan_lu]

The IV is generated from the CID (potentially changeable with that hack). The key is the same across all 3ds.

In THEORY this MIGHT be possible: take a hacked 3DS and get an encrypted dump and the CID. Flash the CID onto an unhackable 3DS. Then flash the encrypted NAND dump. You might have just duplicated the original 3DS with a vulnerable fw. Maybe.

I've talked about this theory before--I haven't tested and someone more knowledgable may chime in about why it might not work. Right now every 3DS on latest FW is downgradable and hackable so it's pretty pointless. However, this might become interesting when nintendo fixes the exploits in a newer fw. However, this "hack" would require soldering and maybe hardware (like a RPI).

EDIT: An orthogonal hack: if we ever dump bootrom9 and the KeyX for the various nand partitions, then we may be able to do this even without a CID write hack.

 

[solsolis]

If I'm not mistaken the samdunk thing affects bootloaders that are stored on the eMMC, where as the 3ds has the bootloader stored in silicon. Also the mentioned vulnerability abuses mechanisms in Samsung's bootloader implementation (which I think is a modification of little kernel?). In summary it's not useful.

 

[DSoryu]

The IV is generated from the CID (potentially changeable with that hack). The key is the same across all 3ds.

In THEORY this MIGHT be possible: take a hacked 3DS and get an encrypted dump and the CID. Flash the CID onto an unhackable 3DS. Then flash the encrypted NAND dump. You might have just duplicated the original 3DS with a vulnerable fw. Maybe.

As always, thank you, this was the type of answer I was expecting, specially from you.

This could lead to, maaaybe, unbrick dead 3DS's.
..
The main problem seems to be on how to dump the CID, on the article I linked above they used tools already provided by Samsung itself by mistake, the only way I can think of is the risky hardware method...

Yet, is not really known if that'll work.

 

[yifan_lu]

As always, thank you, this was the type of answer I was expecting, specially from you.

This could lead to, maaaybe, unbrick dead 3DS's.
..
The main problem seems to be on how to dump the CID, on the article I linked above they used tools already provided by Samsung itself by mistake, the only way I can think of is the risky hardware method...

Yet, is not really known if that'll work.

That's all easy to do. Just connect the eMMC pinouts to a raspberry pi and you can read the CID and run those vendor commands and stuff.

 

[solsolis]

The IV is generated from the CID (potentially changeable with that hack). The key is the same across all 3ds.

In THEORY this MIGHT be possible: take a hacked 3DS and get an encrypted dump and the CID. Flash the CID onto an unhackable 3DS. Then flash the encrypted NAND dump. You might have just duplicated the original 3DS with a vulnerable fw. Maybe.

I've talked about this theory before--I haven't tested and someone more knowledgable may chime in about why it might not work. Right now every 3DS on latest FW is downgradable and hackable so it's pretty pointless. However, this might become interesting when nintendo fixes the exploits in a newer fw. However, this "hack" would require soldering and maybe hardware (like a RPI).

EDIT: An orthogonal hack: if we ever dump bootrom9 and the KeyX for the various nand partitions, then we may be able to do this even without a CID write hack.

That actually seems like a much more practical idea than what I was getting from the OPs question.

 

[yifan_lu]

Okay so I thought of some limitations:
1) Sector 0x96 (the keystore) cannot be transferred--even if encrypted since the key comes from the OTP and not the eMMC CID. So you need to replace the encrypted sector 0x96 with your original one.
2) More importantly, there might be keys used later in the boot process (such as the tickets.db MAC key) that /might/ depend on keys generated from the OTP. That means the console may not boot. However, there might be a way around this...

EDIT: Okay we can shut this down. yellows8 tells me that the CID is used in the IV but KeyX is also console-unique (and not based on the CID). So in short, it won't work.

 

[SonyUSA]

Locked~