Hacking Question About PRODINFO corruption...

[machine69_420]

So I have this question about switch's cert...

If only my PRODINFO gets corrupted how does Horizon actually check if the console specific certificate and all that stuff is valid or not?

Also you should be able to load something like Lakka onto your switch even when your PRODINFO is corrupted, am I right?

 

[Kubas_inko]

When prodinfo is corrupted, your switch simply won't boot past nintendo logo. And yes, any payload and that stuff still works.

 

[machine69_420]

When prodinfo is corrupted, your switch simply won't boot past nintendo logo. And yes, any payload and that stuff still works.

I understand that, but I am asking why? How does it "realize" it is corrupted?

I wanna know the technical stuff if there is any information out there.

 

[aerios169]

if you already actived your license, is stored on your sd, so you can run the payload via USB.

 

[mologie]

I understand that, but I am asking why? How does it "realize" it is corrupted?

The PRODINFOF partition contains a FAT12 filesystem [1]. A corrupted PRODINFOF partition means that standard FAT12 structures can no longer be parsed of files on it cannot be found. Basic sanity checks in whatever reads PRODINFOF should detect this. (Note: I have not checked what exactly fails here, but any well-written FAT filesystem driver will error out when encountering a broken partition, so it's most likely that.)

Even if the partition layout is still valid there's data in there that is most likely checked against known-good values, such as the device ID (for details check [1].)

EDIT: The above also applies to the PRODINFO partition (it contains static headers and a checksum.)

[1] http://switchbrew.org/index.php?title=Flash_Filesystem#User_Partitions

 

[garyopa]

PRODINFOF is easy to fix, as pointed out above its a FAT12 partiition, with mainly 'log' files, those can be replaced with blank ones.

The problem is the section just above PRODINFO that is setup during factory, it contains alot of 'console unique' info that bootloader checks, some could be re-caled, but hashing and checksums need to pass the bootloader tests.

Calibration

During factory setup, the Switch goes through calibration and the generated data from this process is written to two NAND user partitions (PRODINFO and PRODINFOF).

PRODINFOF is a FAT12 compliant filesystem and it's structure can be found here. It's mainly used to keep calibration logs and other assorted files.

PRODINFO is a raw binary blob containing the main calibration data, which ranges from hardware IDs to system keys.

CAL0
This is the raw data stored under the PRODINFO partition.

Offset Size Field Description
0x0000 0x04 magic "CAL0" header magic.
0x0004 0x04 unk Always 0x07.
0x0008 0x04 calib_data_size Total size of calibration data minus 0x40 bytes (header + calib_data_sha256).
0x000C 0x02 version Always 0x01.
0x000E 0x02 revision Increases each time calibration data is installed.
0x0020 0x20 calib_data_sha256 SHA256 hash calculated over calibration data.
0x0040 0x1D config_id1 Configuration ID string.
0x0060 0x20 reserved Empty.
0x0080 0x04 wlan_country_codes_num Number of elements in the wlan_country_codes array.
0x0084 0x04 wlan_country_codes_last_idx Index of the last element in the wlan_country_codes array.
0x0088 0x180 wlan_country_codes Array of WLAN country code strings. Each element is 3 bytes (code + NULL terminator).
0x0210 0x06 wlan_mac_addr
0x0220 0x06 bd_addr
0x0230 0x06 accelerometer_offset
0x0238 0x06 accelerometer_scale
0x0240 0x06 gyroscope_offset
0x0248 0x06 gyroscope_scale
0x0250 0x18 serial_number
0x0270 0x30 device_key_ecc_p256 Device key (ECC-P256 version; empty and unused).
0x02B0 0x180 device_cert_ecc_p256 Device certificate (ECC-P256 version; empty and unused).
0x0440 0x30 device_key_ecc_b233 Device key (ECC-B233 version; empty and unused).
0x0480 0x180 device_cert_ecc_b233 Device certificate (ECC-B233 version; active).
0x0610 0x30 eticket_key_ecc_p256 ETicket key (ECC-P256 version; empty and unused).
0x0650 0x180 eticket_cert_ecc_p256 ETicket certificate (ECC-P256 version; empty and unused).
0x07E0 0x30 eticket_key_ecc_b233 ETicket key (ECC-B233 version; empty and unused).
0x0820 0x180 eticket_cert_ecc_b233 ETicket certificate (ECC-B233 version; empty and unused).
0x09B0 0x110 ssl_key SSL key (empty and unused).
0x0AD0 0x04 ssl_cert_size Total size of the SSL certificate.
0x0AE0 0x800 ssl_cert SSL certificate. Only ssl_cert_size bytes are used.
0x12E0 0x20 ssl_cert_sha256 SHA256 over the SSL certificate.
0x1300 0x1000 random_number Random generated data.
0x2300 0x20 random_number_sha256 SHA256 over the random data block.
0x2320 0x110 gamecard_key GameCard key (empty and unused).
0x2440 0x400 gamecard_cert GameCard certificate.
0x2840 0x20 gamecard_cert_sha256 SHA256 over the GameCard certificate.
0x2860 0x220 eticket_key_rsa ETicket key (RSA-2048 version; empty and unused).
0x2A90 0x240 eticket_cert_rsa ETicket certificate (RSA-2048 version; active).
0x2CE0 0x18 battery_lot Battery lot string ID.
0x2D00 0x800 speaker_calib_value Speaker calibration values. Only 0x5A bytes are used.
0x3510 0x04 region_code
0x3520 0x50 amiibo_key Amiibo key (ECQV and ECDSA versions).
0x3580 0x14 amiibo_cert_ecqv Amiibo certificate (ECQV version).
0x35A0 0x70 amiibo_cert_ecdsa Amiibo certificate (ECDSA version).
0x3620 0x40 amiibo_key_ecqv_bls Amiibo key (ECQV-BLS version).
0x3670 0x20 amiibo_cert_ecqv_bls Amiibo certificate (ECQV-BLS version).
0x36A0 0x90 amiibo_root_cert_ecqv_bls Amiibo root certificate (ECQV-BLS version).
0x3740 0x04 product_model
0x3750 0x06 color_variation
0x3760 0x0C lcd_backlight_brightness_mapping
0x3770 0x50 device_ext_key_ecc_b233 Extended device key (ECC-B233 version; active).
0x37D0 0x50 eticket_ext_key_ecc_p256 Extended ETicket key (ECC-P256 version; empty and unused).
0x3830 0x50 eticket_ext_key_ecc_b233 Extended ETicket key (ECC-B233 version; empty and unused).
0x3890 0x240 eticket_ext_key_rsa Extended ETicket key (RSA-2048 version; active).
0x3AE0 0x130 ssl_ext_key Extended SSL key (active).
0x3C20 0x130 gamecard_ext_key Extended GameCard key (active).
0x3D60 0x04 lcd_vendor_id
0x3D70 0x240 [5.0.0+] unk_key0
0x3FC0 0x240 [5.0.0+] unk_key1
0x4210 0x04 [5.0.0+] unk_id
Error detection
Each block of raw calibration data (with the exception of blocks with SHA256 hashes) is padded to 16 bytes, being the last 2 bytes a CRC-16 over said block.

XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
00 00 00 00 00 00 00 00 00 00 00 00 00 00 YY YY

XX == data
00 == padding
YY == crc

The CRC-16 is generated as follows:

unsigned int crc_16_table[16] = {
0x0000, 0xCC01, 0xD801, 0x1400, 0xF001, 0x3C00, 0x2800, 0xE401,
0xA001, 0x6C00, 0x7800, 0xB401, 0x5000, 0x9C01, 0x8801, 0x4400 };

unsigned short int get_crc_16 (char *p, int n) {
unsigned short int crc = 0x55AA;
int r;

while (n-- > 0) {
r = crc_16_table[crc & 0xF];
crc = (crc >> 4) & 0x0FFF;
crc = crc ^ r ^ crc_16_table[*p & 0xF];

r = crc_16_table[crc & 0xF];
crc = (crc >> 4) & 0x0FFF;
crc = crc ^ r ^ crc_16_table[(*p >> 4) & 0xF];

p++;
}

return(crc);

Source: http://switchbrew.org/index.php?title=Calibration

 

[machine69_420]

So if the FAT12 file system gets corrupted you're kinda screwed. I get that.

This is probably stupid but I was wandering if you could replace the console unique values and also the hashes and checksums corresponding to the new values.

Sure, you would probably run into other problems but it would probably boot.

Or do we not know to overwrite these hashes and checksums?

 

[mologie]

This is probably stupid but I was wandering if you could replace the console unique values and also the hashes and checksums corresponding to the new values.

Unfortunately you cannot, because you have no option to recompute the values for your console once its gone. (Writing any valid value is not a problem, writing the correct value that makes your specific console work is the problem.)

These two things break stuff here:

1. Your console-unique certificate/ticket. You could use another console's certificate, but that would most likely lead to it being banned because of inconsistent data being sent to Nintendo. Thus, there's no practical way to replace the certificate. (It's signed, so you can't make one up.)

2. Calibration data. Nintendo most likely has special machines on their end that assist in the calibration process. Each piece of hardware is a bit different and needs calibration to work properly. Without the calibration tool and Nintendo's calibration machines you can't generate calibration data that make your console work.

To be brief: You're right that you can probably patch the PRODINFO data up and bypass some signature checks using a custom RCM payload to make Horizon boot, but it would be so utterly broken/limited that there is no point in doing that.

 

[superxoi]

sorry for digging this topic. i have an oled which boot not pass the nintendo logo. i used nxnandmanager to check and see that it showed my device serial number. so i want to ask if the nxnandmanager can identify my oled serial does it mean that my prodinfo is intact or not. if not i will use donor prodinfo to revive it then. thank in advance. in CAL0 info i still can see the serial number of the console.
edit: for more informations , this device had a bluescreen when i bought it. i took the emmc off then reballed it back and the console showed nintendo logo then shut off.