Hacking Discussion Missing eMMC recovery without a backup

[Ignas]

Hello everyone,

For the last few days, I've been working on a missing eMMC Switch.

I was able to recover HWI, SBK, TSEC KEY with biskeydump
I was able to recover BIS keys with sdsetup/biskeygen
I was able to recover BOOT0 encrypted_keyblob_00 to encrypted_keyblob_05 with linkle keygen -k prod.keys
I was able to recover Device ID with fuse_get_device_id() and small RCM payload I wrote

Rebuilt the filesystem with ChoiDujour
Now the Switch boots to NINTENDO SWITCH logo and hangs

What I am missing is a correct PRODINFO EccB233DeviceCertificate (0x0480)
Which is completely identical to 3DS "CTCert" or even Nintendo Wii "IOSC::GetDeviceCertificate()"

Very interesting piece of code was "convert_otp_to_device_cert" from SciresM/otptool
It copies the signature directly from OTP, meaning I wont be able to create it and any modification to an existing certificate is impossible

A solution might be to make a patch for Hekate or Atmosphere
The only reference to where the patch might be required is this line:

NIM checks if this item matches the set:cal DeviceId with byte7 cleared. If they don't match, a panic is thrown.

Where should I look into?
Ghidra is ready.

Spoiler: Required prod.keys for linkle

keyblob_00 = ...
keyblob_01 = ...
keyblob_02 = ...
keyblob_03 = ...
keyblob_04 = ...
keyblob_05 = ...
keyblob_key_source_00 = ...
keyblob_key_source_01 = ...
keyblob_key_source_02 = ...
keyblob_key_source_03 = ...
keyblob_key_source_04 = ...
keyblob_key_source_05 = ...
keyblob_mac_key_source = ...
secure_boot_key = ...
tsec_key = ...

Spoiler: BOOT0 keyblob locations

encrypted_keyblob_00 @ 0x180000
encrypted_keyblob_01 @ 0x180200
encrypted_keyblob_02 @ 0x180400
encrypted_keyblob_03 @ 0x180600
encrypted_keyblob_04 @ 0x180800
encrypted_keyblob_05 @ 0x180A00

 

[Draxzelex]

Hello everyone,

For the last few days, I've been working on a missing eMMC Switch.

I was able to recover HWI, SBK, TSEC KEY with biskeydump
I was able to recover BIS keys with sdsetup/biskeygen
I was able to recover BOOT0 encrypted_keyblob_00 to encrypted_keyblob_05 with linkle keygen -k prod.keys
I was able to recover Device ID with fuse_get_device_id() and small RCM payload I wrote

Rebuilt the filesystem with ChoiDujour
Now the Switch boots to NINTENDO SWITCH logo and hangs

What I am missing is a correct PRODINFO EccB233DeviceCertificate (0x0480)
Which is completely identical to 3DS "CTCert" or even Nintendo Wii "IOSC::GetDeviceCertificate()"

Very interesting piece of code was "convert_otp_to_device_cert" from SciresM/otptool
It copies the signature directly from OTP, meaning I wont be able to create it and any modification to an existing certificate is impossible

A solution might be to make a patch for Hekate or Atmosphere
The only reference to where the patch might be required is this line:


Where should I look into?
Ghidra is ready.

Spoiler: Required prod.keys for linkle

keyblob_00 = ...
keyblob_01 = ...
keyblob_02 = ...
keyblob_03 = ...
keyblob_04 = ...
keyblob_05 = ...
keyblob_key_source_00 = ...
keyblob_key_source_01 = ...
keyblob_key_source_02 = ...
keyblob_key_source_03 = ...
keyblob_key_source_04 = ...
keyblob_key_source_05 = ...
keyblob_mac_key_source = ...
secure_boot_key = ...
tsec_key = ...

Spoiler: BOOT0 keyblob locations

encrypted_keyblob_00 @ 0x180000
encrypted_keyblob_01 @ 0x180200
encrypted_keyblob_02 @ 0x180400
encrypted_keyblob_03 @ 0x180600
encrypted_keyblob_04 @ 0x180800
encrypted_keyblob_05 @ 0x180A00

You cannot rebuild or fake PRODINFO.

 

[PabloZaiden]

Hello everyone,

For the last few days, I've been working on a missing eMMC Switch.

I was able to recover HWI, SBK, TSEC KEY with biskeydump
I was able to recover BIS keys with sdsetup/biskeygen
I was able to recover BOOT0 encrypted_keyblob_00 to encrypted_keyblob_05 with linkle keygen -k prod.keys
I was able to recover Device ID with fuse_get_device_id() and small RCM payload I wrote

Rebuilt the filesystem with ChoiDujour
Now the Switch boots to NINTENDO SWITCH logo and hangs

What I am missing is a correct PRODINFO EccB233DeviceCertificate (0x0480)
Which is completely identical to 3DS "CTCert" or even Nintendo Wii "IOSC::GetDeviceCertificate()"

Very interesting piece of code was "convert_otp_to_device_cert" from SciresM/otptool
It copies the signature directly from OTP, meaning I wont be able to create it and any modification to an existing certificate is impossible

A solution might be to make a patch for Hekate or Atmosphere
The only reference to where the patch might be required is this line:


Where should I look into?
Ghidra is ready.

Spoiler: Required prod.keys for linkle

keyblob_00 = ...
keyblob_01 = ...
keyblob_02 = ...
keyblob_03 = ...
keyblob_04 = ...
keyblob_05 = ...
keyblob_key_source_00 = ...
keyblob_key_source_01 = ...
keyblob_key_source_02 = ...
keyblob_key_source_03 = ...
keyblob_key_source_04 = ...
keyblob_key_source_05 = ...
keyblob_mac_key_source = ...
secure_boot_key = ...
tsec_key = ...

Spoiler: BOOT0 keyblob locations

encrypted_keyblob_00 @ 0x180000
encrypted_keyblob_01 @ 0x180200
encrypted_keyblob_02 @ 0x180400
encrypted_keyblob_03 @ 0x180600
encrypted_keyblob_04 @ 0x180800
encrypted_keyblob_05 @ 0x180A00

I’m on a similar situation, with a Switch that got the nand nuked before I got it. Right now, no viable prodinfo.

I’m trying to reconstruct a minimal viable prodinfo using a blanked donor from my other switch, but no luck so far. It still doesn’t boot past the Nintendo switch logo. Did you have any insights on this? At least something to know which part of the boot process is hanging?

 

[LIY2012]

Can I ask how you were able to recover Device ID with fuse_get_device_id()

 

[Ignas]

Good to hear I am not alone in this.

My previous assumption about:

0x0480 0x180 EccB233DeviceCertificate Device certificate

was wrong, it appears that it can be any value, as long as the CRC of the field is correct - switch boots.
CRC calculation is described in switchbrew.org/wiki/Calibration

Before putting this away for a while my research led me to this one CAL0 field:

0x3770 0x50 ExtendedEccB233DeviceKey

I am not 100% sure, but seems to be the only thing I could not take from another console or generate it.
It probably contains an asymmetric digital signature which we can not fake, the only possibility is to apply a patch.

There is not much information about Horizon debugging and seems to require a devkit. Can someone shed some light on this?
One thing I might attempt to do, is to add some UART debug information to emuMMC or Atmosphere's "blank_prodinfo" to see which module is accessing the ExtendedEccB233DeviceKey.


Regarding the "Device ID" (NX0000000000000000-0), I will upload the RCM payload to github, it's a few lines of code. fuse_get_device_id() generates it from the CPU fuse bits, so it is chip dependent.

 

[PabloZaiden]

Saved me some time. I was about to start clearing out item by item from a working prodinfo until it stopped booting.
I’ve tried asking in discord With no luck. You can contact me there and compare notes.

 

[LIY2012]

Regarding the "Device ID" (NX0000000000000000-0), I will upload the RCM payload to github, it's a few lines of code. fuse_get_device_id() generates it from the CPU fuse bits, so it is chip dependent.

Well, this is over my head. I checked out the fuse_get_device_id() function is fuse.c and fuse.h I found on the Atmosphere github. I can see where it's doing it's thing, but I can't quite understand what it's doing, or how I can make it work for me. Any help you could give would be appreciated.

 

[PabloZaiden]

Hey!
I've been doing some tests with mixed results. If I clear (all 0s, with proper CRC16):

Range {Start = 0x0480, Length = 0x180}, //device cert (if missing, atmosphere shows error 2105-0584)
Range {Start = 0x2440, Length = 0x400}, //gamecart cert (if missing, atmosphere shows error 2011-0301)
Range {Start = 0x3770, Length = 0x50}, //extended device key (if missing, breaks. stuck on nintendo switch logo at boot)
Range {Start = 0x3890, Length = 0x240}, //extended eticket key (if missing, breaks. stuck on nintendo switch logo at boot)
Range {Start = 0x3C20, Length = 0x130}, //extended gamecart key (boots, but crashed when inserting gamecart. Not that important anyway)

In the ReSwitched discord, user shchmume said:

the modulii and keypairs that need importing do not get checked for their own validity at sysmodule init. i gcm encrypted zeroes so it would pass ghash validity testing and fuse device id check
[11:51 PM]
zeroes
[11:51 PM]
for gc
[11:51 PM]
straight zeroes

Do you know which keys should I have to use for the gcm encryption, and how to obtain them from the device (fuses, I'm guessing?)

 

[PabloZaiden]

Update here:

The device keys are gcm encrypted with a kek generated by an es kek source, and the encrypted payload should have the device id at 0x18 bytes before the end of the buffer, with the ghash being the last 0x10 bytes).

By shchmume comments, using zeros as the key, (or reencrypting a donor device keys maybe?) and gcm-reencrypting with proper keys and deviceid for the console should make it boot.

 

[Ignas]

That is very useful information.

It appears Atmosphere already has a function for this: gcm_encrypt_key(...) (in Atmosphere/exosphere/src/gcm.c)
This already handles adding the Device ID,

However I still have no idea how to derive the keys.

 

[PabloZaiden]

From my conversation with shchmume:


```c
GenerateAesKek(&tempkek, kek_source, generation, generation == 0 ? 0x20 : 0x21); //kek_source = 7F5B...
DecryptRsaPrivateKey(&outkey, ExtendedECCB233DeviceKey, &tempkek, kekek_source); // prod kekek_source = AF44...```

all the required keys for these are in es rodata


didn’t have more time to keep searching for the prod kekek_source, but as he said, it should be retrievable dumping the sysmodule and finding it in rodata

 

[Ignas]

This is sure moving forward thanks to your help!

I extracted the es sysmodule and got the sources:

hactool -k keys.dat --plaintext=output.bin 0100000000000033.nca

Now we need to compile shchmue's Lockpick to quickly validate this
HINT: splCryptoGenerateAesKek();

I tried to compile it and due to libnx version being too new there are errors, so beware.

 

[PabloZaiden]

If you share a repo we can both contribute to a tool or procedure generate a prodinfo from scratch or from a donor.

 

[PabloZaiden]

I was thinking more on a tool to run on the local computer with the keys already dumped, rather than something to run on the switch.

 

[PabloZaiden]

I have successfully decrypted the content with a small python script and, indeed, my deviceid is there. Now, to try changing that, reencrypting for the other console and see what happens!

 

[Tamalulu]

Hi guys,
I'm interested and willing to help. Could you share me the code/payload you used to get your device id?

 

[AKASGamingYT]

Was this ever finished? Did it work? If so, is there a repo or tutorial I can follow somewhere? I have a switch from eBay that's missing an emmc entirely.

 

[punderino]

Was this ever finished? Did it work? If so, is there a repo or tutorial I can follow somewhere? I have a switch from eBay that's missing an emmc entirely.

https://github.com/PabloZaiden/deviceid-exosphere-builder