Hacking Discussion Cracked SX OS recovery

[V-Temp]

if u don't know to download from a verified source (like the TX website for SX OS) you probably shouldn't even think about modifying your system.

I agree but things like Rei are extremely fluid and all over the place right now. It can easily slip in and the fake build is obviously trying to.

 

[Kioku]

I agree but things like Rei are extremely fluid and all over the place right now. It can easily slip in and the fake build is obviously trying to.

One of the worst things about ReiNX is this. You're pretty much on your own, however there are places to find valid builds.

 

[jellybeangreen2]

Doesn't backing up the whole raw nand on switch take like 90 minutes?
Also, the topic of this thread shouldn't specifically refer to a cracked SX os, but the name of the piece of shit itself - PozzNX - since it was as well distributed as other stuff. If you Google for it, you also find it referenced to as a version of ReiNX.

Maybe if you have a slow SD. SDXC U3 take 15 minutes, not where near 90 minutes.. whoever said that, must have been using a poor class 4/6 SD card. I managed to do 3 backups within an hour easy..

 

[DeoNaught]

For future reference, Always make ATLEAST ONE BACKUP, with 3ds i'd make one every couple of months.
After you are done with your Backup, Put it in a safe place on your computer, on a usb, and on an online storage, like google drive, or One drive, or drop box, OR, all of them, to be extra safe.

Because using hacks is always risky, and not having atleast one backup is just silly, so when you buy a new switch, when you get hektate, make a backup, and make multiple copies, and save em.

 

[jimmyj]

One of the worst things about ReiNX is this. You're pretty much on your own, however there are places to find valid builds.

ye,infact pozzNX was being beta tested by people that had no idea iy was pozzNX and not reiNX,infact I even tested one of the betas because they were on the reiswitched discord masked as reiNX sig patch beta build.

 

[V-Temp]

ye,infact pozzNX was being beta tested by people that had no idea iy was pozzNX and not reiNX,infact I even tested one of the betas because they were on the reiswitched discord masked as reiNX sig patch beta build.

Oh I'm sure there's bricks from this we haven't heard about. Just naive kids suddenly with switches that don't turn on.

 

[jimmyj]

Oh I'm sure there's bricks from this we haven't heard about. Just naive kids suddenly with switches that don't turn on.

ye I'm sure too,thankfully I tested a version that wasn't (yet) harmful.

 

[CarefulCrysis]

my nand dump took about 25mins lol god knows why it would take 90 wtf

 

[wurstpistole]

For this thread, it's actually completely irrelevant how long a NAND dump takes.
Actually everything is irrelevant, since the answer was already posted. Unsubscribing now before it goes down the drain again

 

[Indominusda1e]

Remember that this is not the discussion about what has happened or shouldn't happen or whatever went to the closing of the old thread, but a thread to speak about how to fix it, and the how to was posted right in the first reply and a bunch of other times as well... So, yeah. This thread is now resolved and can be closed, if only to prevent the deservers from rushing all over this again.

It's not sorted yet people are still asking questions so please pipe down in the cheap seats

 

[wurstpistole]

It's not sorted yet people are still asking questions so please pipe down in the cheap seats

How is this not sorted? You can not recover without a full raw NAND dump. Question answered. There is no other fix.
Also, if you had showed any interest in the other, yet for good reasons locked thread, you would have seen massive participation from me, since I am also one who got bricked by this. So get back in your cheap seat, please.
You were even one of those slagging the bricked people, and now you open a thread to "help" them. You did that just to continue with it, didn't you.

 

[garyopa]

If this topic going to really be about 'recover', lets discuss what is PRODINFO and why its so important to have your OWN UNIQUE BACKUP:

Partition name Offset Size Bis Partition ID Encrypted Description
PRODINFO 0x00004400 0x003FBC00 27 Yes (Bis key 0) "CAL0" raw partition containing set:cal data. The official name for this partition is "CalibrationBinary".
PRODINFOF 0x00400000 0x00400000 28 Yes (Bis key 0) FAT12 filesystem, additional calibration. The official name for this partition is "CalibrationFile".

PRODINFOF
├── Certifications
│   └── WirelessCertification.png
└── ptd
   ├── DeviceIdWithEmsBit.dat
   ├── Ecid.dat
   ├── prodCode.dat
   └── log
       ├── Process_asm1.log
       ├── Process_board1.log
       ├── TestFlagLine.log
       ├── TestFlagQc.log
       ├── AGING
       │   └── Sequence.log
       ├── BOARD_TEST
       │   └── Sequence.log
       ├── BOARD_WIRELESS
       │   └── Sequence.log
       ├── FINAL_CHECK
       │   └── Sequence.log
       ├── LCD_AND_KEY
       │   └── Sequence.log
       └── USB_AND_HP
           └── Sequence.log

DeviceIdWithEmsBit.dat
Contains a 0x10-byte uppercase hex string, identical to the DeviceId in the DeviceCert.

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

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

 

[Indominusda1e]

If this topic going to really be about 'recover', lets discuss what is PRODINFO and why its so important to have your OWN UNIQUE BACKUP:

Partition name Offset Size Bis Partition ID Encrypted Description
PRODINFO 0x00004400 0x003FBC00 27 Yes (Bis key 0) "CAL0" raw partition containing set:cal data. The official name for this partition is "CalibrationBinary".
PRODINFOF 0x00400000 0x00400000 28 Yes (Bis key 0) FAT12 filesystem, additional calibration. The official name for this partition is "CalibrationFile".

PRODINFOF
├── Certifications
│   └── WirelessCertification.png
└── ptd
   ├── DeviceIdWithEmsBit.dat
   ├── Ecid.dat
   ├── prodCode.dat
   └── log
       ├── Process_asm1.log
       ├── Process_board1.log
       ├── TestFlagLine.log
       ├── TestFlagQc.log
       ├── AGING
       │   └── Sequence.log
       ├── BOARD_TEST
       │   └── Sequence.log
       ├── BOARD_WIRELESS
       │   └── Sequence.log
       ├── FINAL_CHECK
       │   └── Sequence.log
       ├── LCD_AND_KEY
       │   └── Sequence.log
       └── USB_AND_HP
           └── Sequence.log

DeviceIdWithEmsBit.dat
Contains a 0x10-byte uppercase hex string, identical to the DeviceId in the DeviceCert.

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

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

Good shout

 

[Sgt. Lulz]

Just so the same mistake doesn't get repeated twice in the future, Hekate can dump all partitions without dumping USER, which massively cuts down the time required to make a backup.
The absolute minimum you should have backed up in multiple places is PRODINFO, PRODINFOF, and the Repair BCPKG2 partitions. Everything else can be reflashed from a generic firmware package, e.g. the packages generated by ChoiDujour.
That said, running random payloads on a system with SoC-controlled voltages is still an incredibly dangerous idea.

 

[garyopa]

What we need is leak, dump of the 'factory setup' launcher:

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

Setup Process
At the factory, a minimal version of the Switch OS is installed. A modified version of the boot2 title (boot2.manuBoot) is installed that launches an additional "Manu" sysmodule, and the system config title specifies to launch "Test Application Launcher" instead of qlaunch.

Test Application Launcher is used to launch a number of tests, "CAL0" calibration data is written to NAND, and retail firmware is installed.

Titles
Overview
Factory firmware contains a stripped down version of the Switch's OS with unnecessary titles removed, and a number of additional debug titles installed. The version of the OS installed at the factory is receiving updates as new switches are manufactured. At least four revisions of factory firmware are known to have been used in production.

[IMG]http://switchbrew.org/images/thumb/0/0f/TestApplicationLauncher.jpg/400px-TestApplicationLauncher.jpg[/IMG]
TestApplicationLauncher running on a console.
Removed Titles
[LIST]
[*]The following system data archive titles are present in retail firmware, but not installed at the factory: 0100000000000801, 0100000000000803, 0100000000000804, 0100000000000805, 0100000000000808, 010000000000080A, 010000000000080B, 010000000000080C, 010000000000080D, 010000000000081A, 010000000000081B, 010000000000081E.
[/LIST]
[LIST]
[*]Every System Applet "10XX" title is not installed.
[/LIST]
[LIST]
[*]01008BB00013C000 ("flog") is not installed.
[/LIST]
Factory-Only Titles
Title ID Name Description
0100000000002000 BoardFunction Board testing.
0100000000002001 A3Wireless Wireless testing.
0100000000002002 C1LcdAndKey LCD/Keyboard testing.
0100000000002003 C2UsbHpmic USB testing.
0100000000002004 C3Aging Graphics/Framerate testing.
0100000000002005 C4SixAxis Sixaxis (controller peripheral) testing.
0100000000002006 C5Wireless Wireless testing.
0100000000002007 "FinalCheck" 
0100000000002044 "HB-TBIntegrationTest" 
010000000000204E A4BoardCalWriti Writes calibration data to NAND.
010000000000209C TestApplication "Test Application Launcher", factory qlaunch replacement. Used to launch other tests.
010000000000B14A Manu Manufacturing sysmodule.
1000000000000001 SystemInitializ Strings internally refer to this as "SystemInitializer". See here.
1000000000000004 CalWriterManu  ?
1000000000000007 "ApplicationLauncer"

This app, products the 'prodinfo' section, so if we could find this app, maybe we could make a payload that generates new nand setup?

 

[fragged]

Is there a checksum of the SX OS bricking file so we can check order files against it? Or would renaming it not check correctly, could they change it so it wouldn't match?

 

[wurstpistole]

Is there a checksum of the SX OS bricking file so we can check order files against it? Or would renaming it not check correctly, could they change it so it wouldn't match?

Just do a little commit to anything and build a new payload - checksum gone.

 

[fragged]

Just do a little commit to anything and build a new payload - checksum gone.

Guess we just need to be very vigilant now then.

 

[sarkwalvein]

Just so the same mistake doesn't get repeated twice in the future, Hekate can dump all partitions without dumping USER, which massively cuts down the time required to make a backup.
The absolute minimum you should have backed up in multiple places is PRODINFO, PRODINFOF, and the Repair BCPKG2 partitions. Everything else can be reflashed from a generic firmware package, e.g. the packages generated by ChoiDujour.
That said, running random payloads on a system with SoC-controlled voltages is still an incredibly dangerous idea.

I think the first post in this thread should explain this.
State the only measure that can be taken is preventive.
Link to a valid release of Hekate, and explain the whole process for backup and restore with detailed pictures and a video if needed.
Also, perhaps with some big text like:

The only measure that can be taken is preventive:

Perform a NAND Backup with Hekate ASAP!
Links and tutorial below.

 

[PT333]

Just do a little commit to anything and build a new payload - checksum gone.

Even without editing anything in code at all, binaries compiled from the same code can (and often do) have a different checksums. But I think that if you compile PozzNX yourself, you can then compare it to some shady payload you find disguised as, let's say "ReiNX XCI loader 100% real no fake" in software like IDA, you could determine whether it's real or not. But I'm not sure about that.