SX OS Crack Status

[LightningMods]

SX OS's Requests for Licence Validation

Let's make something clear. SX OS payload/boot.dat does NOT make ANY requests
It ONLY does a request on the Licence Code Redeem section.
The Payload for RCM itself does not do any external website requests for validation. NONE.
Everything is handled by the boot.dat file.
This is to allow offline usage.

Console Fingerprint

The SX has a "Console Fingerprint".
Using HxD 2.0.0 aswell as Hekate, managed to find the following information:
Show entries
Search:
Section Value (From eMMC Info on Hekate)
AA Extended Card Spec -> Spec Version (in regular old ASCII -> HEX)
BBBBBBBB Card ID -> S/N in Big Endian (e.x.: AABBCCDD in eMMC Info should be: DDCCBBAA)
C Prd Rev with 0 added to start, (e.x. "Prd Rev: B" -> "0B")
DDDDD Card ID -> Model (in regular old ASCII -> HEX)
EEEEEEEE {Card ID -> OEM ID}{Card ID -> Card/BGA (add 0 to start)}{Card ID -> Vendor ID}{00 for padding?}
Showing 1 to 5 of 5 entries
https://gist.github.com/nwert/9430a454c64248dd1186868c00b682c6

boot.dat

Headers: (0x0->0XF0)

Sections Layout:

1. headers (0x0->0xF0)
2. Stage 2
3. data
4. fb
5. arm64
6. rest unencrypted from boot.dat starting @ 0x571E20 -> end of boot.dat

The SHA256 of Data Bin in Stage 2 can be found @ 0x5EA0
The Public Key inside Data can be found @ 9FE0(0C) -> A0E0(0B)
(These are encrypt with AES-CTR-128 so you cant just paste new values)

fb_x.bin

fb.bin is just a framebuffer for the Splashscreen.
Instead of using a data resource like a png they use an 8bit framebuffer so that its smaller in size (kind of) and faster to execute.
The entire contents (when decrypted and manually rotated) is:
Raw Image 1280x768
license.dat

Encrypted with RSA-2048
This is in fact encrypted using license-request.dat as the "message".
The signature/modulus/public key encrypted with is @ offset 0x00040A0 (from 0C onwards) with a size of 0x100.
This is the rsa public key. The modulus is the default 65537.
We CANNOT encrypt license.dat files as we don't know the Private Key (stored serveriside on the website - that api link)
Thats why SX asks us to send our licence-request.dat (which you can see more of below) to that API so that it signs it using probably CF, Redeem Code and random entropy.

license-request.dat

Not encrypted (as far as I can tell)
Seems to just be some kind of Console Fingerprint with 32 bytes of 00 padding at the end.
This is likely so they dont have to pad it themselves for whatever hash function they using (possibly aes-ctr-256 or 128)
This file gets encrypted with a exponent (65537 confirmed), and a public and private key.
We know the exponent and public key but not the private key (as already explained, its server-side unable to be gotten unless their FTP was hacked).

payload.bin

As far as I know, this is either encrypted very well, or not encrypted at all
If it's not encrypted, then it doesn't do any hash checks as far as we can tell.
None are found and I can confirm it does not hash check boot.dat, see for yourself, pad 32bytes of 00 at the end, and it will still boot.
This seems to simply be a way to open a boot.dat, it seems to be NOTHING more.

License Verification OFFICIAL RSA Keys

Exponent = 65537 (default, most commonly used)
Public Key = E8D43CB9F1880E0A8A722F126447F0B66D86A4B4AF68A96AE93E5866A26DA2B7873EC913FD3232196705A3FB6514F38C2CD6CFF21AA7CF4EE7237BD7FCE4F6AD5F3FDF9434B0DEC008C696CB9B4F4AEEA852EC9DAE8D396B3B5FA37008645CF19C841C2125DD44C70E824C16A8FF5CE4C1E74B35CA5CDAE25632250800B9CA593D9AA1091182E1591364849EC4A87CBD2B3F5F5D01C9F5F48420D81E57CFC2DCE8F167358D599284AC3468E448FEC5BEA35DBBB0217424FA675EC66C4956BECD4485AB91C2F1ECC7BDCDFBA037C7179BEECAEBF5928A2BF701F556D4830AC42687EB890A8E7808D622603B2C1F88A76A1AE73BF0B101B2D832E99A96054CE67B
Private Key = Impossible to obtain

How to Crack TX's SX OS (what we know so far)


Current State

• As of RIGHT NOW, doing the following steps, we found out it will LOAD but will freeze on the splash screen/loading screen
• This only happens on boots after the first boot. For some reason, some users on first boot get through. I never do.
• Possibly saving a save file or something somewhere to nand
• Confirmed BOOT0 is unaffected as I disabled autorcm, recovered my first ever boot0 before doing anything, and got it to freeze, and boot0 was the same. (Or perhaps we need it to get boot0 to BE edited?)
• Confirmed SD Card and SD Card partitions is unaffected
• Confirmed doing a full reset including saves did nothing
• What does this mean? This means, this crack walkthrough isn't complete, we still need to find out more information.

Steps

1. Decrypt boot.dat (look below for a script).
2. In data.bin, Swap out the public key @ 0x00040A0 (0C) (size: 0x100) with the custom RSA key (A57F99B3E8BA0C714864800C23605ADAA1467AACF80728F282E95D5D7946EB42FB7E396DEF81130AB4E4541B8CC286E2CFCB52D9B3B6455E9250ACEBD3BAF7215040BB29CA5FC5BD49DD3F895CCBBB0CD00E286F1A71F329A18E80842976E6CF8D13256803A6019BC21815B39FAEC70CADEF125C5FD08E4EC1BC49AF08BC1BE3BA08C1C9FAFBCF6AC70202EF62F768C03CE8EF49F1DADCF13B678860450BEB011C3506631BEE5E12B2E712FF793E763C8BD02106F27566F6CACEDB221447579F0DD006D8D02F1344BA6E86937A1CF17F20BA7C76BAC29C3F827E62CC652C92718631C683FDF3F5FC1CEE227D880B377156ED557FB1563A554BF4322ACBC77879). Simply a random generated RSA public key that we know the private key to.
3. In stage2.bin, it does a hash check of data.bin, we need to patch this out. Was pretty easy, search for the original sha256 hash of data before editing and replace it with edited versions SHA256.
   We now have data and stage2 edited. Data now has our own custom key, and Stage2 is simply edited to think its unedited.
4. Rebuild boot.dat with arm64.bin, fb.bin, data.bin, stage2.bin aswell as the original boot.dat (look below for a script).
   Now boot.dat is custom edited with with the hash check for stage2 patched aswell as some header data before 0x110 is SHA hash patched.
5. Generate a license.dat based on license-request.dat's contents using the public key we edited in, and its private key (not official private key, our own). (look below for a script)
   We now have a license.dat with contents of license-request.dat encrypted with RSA-2048 using our own keys. Normally, this wouldnt be usable by SX OS, but since we swapped out its public key, and encrypted the license.dat with said public key and private key, it will be usable by our modified boot.dat as we swapped out its public key, so all boot.dat knows, is to use that key.
6. Put the modified boot.dat in your SD Card root. Use regular old payload.bin with RCMSmasher and it will run the modified boot.dat resulting in it using the modified public key for all licence.dat checks!
   Now obviously the public key matches with the licence.dat contents, so it thinks its a valid licence!
   SX OS Boots free of charge.

Tools

boot.dat Unpacker (by nwert)

https://gist.github.com/nwert/9430a454c64248dd1186868c00b682c6

boot.dat Repacker (by PRAGMA)

https://gist.github.com/imPRAGMA/b135f59df43728b64662f466874836f4

license.dat Generater (by PRAGMA) v0.9 (probably final)

https://transfer.sh/cHQQP/licenceDatGeneratorByPRAGMA.zip
This generates a license.dat file using licence-request.dat as contents and uses custom RSA Keys.
So again, this wont work on the official boot.dat, but if we can finalize the custom boot.dat and fix the freeze, it will work for that.
The boot.dat gets edited to use the custom RSA Public Key thats in this script. Which then allows it to basically verify for our needs.
Create a licence.dat using the same text, but different keys will result in a different licence.dat than the official. This is normal, thats the point.

Source: https://gbatemp.net/threads/sx-os-crack-thread.507934/

 

[Jolafrite]

http://jeux-linker.com/20-pour-nintendo-switch

 

[Gymo]

Now that's what I call interesting!

 

[deadhunt49]

aaaaand it's not happening

 

[DorianX]

at this point is SX OS even worth hacking ? I mean it looks pretty but thats it
atmosphere has always been ahead with support. Team X has put the switch on the back burner when it comes to support

 

[Pitbull]

its still working?

 

[mrdude]

Here you go, thanks to reacher17, this is for SXOS 3.10 (use firmware 11.0.0 - doesn't work on 11.0.1)

Place SXOS boot.dat in the same folder as the script, run the python script and put the generated license.dat and patched boot.dat into the root of your sd card, use SXOS payload (find this yourself) to boot into SXOS.

 

[DorianX]

Here you go, thanks to reacher17, this is for SXOS 3.10 (use firmware 11.0.0 - doesn't work on 11.0.1)

Place SXOS boot.dat in the same folder as the script, run the python script and put the generated license.dat and patched boot.dat into the root of your sd card, use SXOS payload (find this yourself) to boot into SXOS.

have you tested this ?
is there any proof of it working ?
how do we know it wont brick your nintendo switch like sx os has previously done in the past????
i am asking because there is always that one dude that messes up and wants to try and use what is now an obsolete payload. just like rainX and sx os is now.

 

[mrdude]

Yes, of course I have tested it, It works great.

See here for an updated script:

https://gbatemp.net/threads/hack-sxos.582831/page-31#post-9427915