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.
The SX has a "Console Fingerprint".
Using HxD 2.0.0 aswell as Hekate, managed to find the following information:
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?} |
REAL EXAMPLE:
Format: [A-F0-9]{32}
AA-BBBBBBBB-C-DDDDD-EEEEEEEE
34-C74CAB92-0B-5234424E4A42-00011500
It could be possible to use a pre-existing licence.dat if we are able to spoof our "CF".
Since the boot.dat checks "licence.dat" to see if it is in fact matching the Console Fingerprint, then it will let you through.
It actually checks if license.dat matches the RSA-2048 public key and 65537 exponent.
Which its contents is generated from license-request.dat which is assumed to use CF.
Otherwise it tells you features will be disabled.
So if we can Spoof eMMC data (may not be easy) then we very well could spoof it to very basic values, redeem a key with it, and assumably everyone who spoofs to it and uses the same licence.dat, would be "verified".
The boot.dat seems to be encrypted with aes-128-ctr
It seems to contain 4 (payloads?)
"stage2" at 0x40020000
"arm64" at 0x80FFFE00
"fb" at 0xF0000000
"data" at 0x80000000
https://gist.github.com/nwert/9430a454c64248dd1186868c00b682c6
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.
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).
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.
Exponent = 65537 (default, most commonly used)
Public Key = E8D43CB9F1880E0A8A722F126447F0B66D86A4B4AF68A96AE93E5866A26DA2B7873EC913FD3232196705A3FB6514F38C2CD6CFF21AA7CF4EE7237BD7FCE4F6AD5F3FDF9434B0DEC008C696CB9B4F4AEEA852EC9DAE8D396B3B5FA37008645CF19C841C2125DD44C70E824C16A8FF5CE4C1E74B35CA5CDAE25632250800B9CA593D9AA1091182E1591364849EC4A87CBD2B3F5F5D01C9F5F48420D81E57CFC2DCE8F167358D599284AC3468E448FEC5BEA35DBBB0217424FA675EC66C4956BECD4485AB91C2F1ECC7BDCDFBA037C7179BEECAEBF5928A2BF701F556D4830AC42687EB890A8E7808D622603B2C1F88A76A1AE73BF0B101B2D832E99A96054CE67B
Private Key = Impossible to obtain