Sorry for the extended absence, been meaning to post an update on things but some personal issues came up, haven't had all that much free time unfortunately.
Did try upgrading my unit in a VM but sadly the client didn't seem to detect it...
I'm hoping to try r/wing the nand with my rPi soon (as soon as I get around to soldering the wires on.. or paying someone to do it for me since I'm awful at soldering)
It's probably best that I get a dump before upgrading anyway seeing as this OS version seems to be rare.
@Wack0 Nice to see you here! Very interesting info about the SKSA, I noticed things were similar to Wii but didn't think the similarity went that deep. Gives me even more hope the signing bug might be in here.
To that end I tried looking into how the signatures work, managed to write some code (
https://pastebin.com/qg4jDVyY) that works to verify the signatures inside SKSA (the signature only covers the ETICKET_SIG struct/TICKET struct, there's probably a hash of the actual data in there somewhere)
Basically 0x0 - 0xAC of that struct is hashed with SHA1, and checked against signature at 0xAC - 0x1AC with the public key specified by cert_name (which should be in the cert chain area of SKSA)
Oddly enough the same ETICKET_SIG struct inside ticket.sys tickets fails to verify. Comparing tickets between units it seems most of the struct matches (even including the signature) except for a 0x10 byte area (the unkHash289C in ETICKET_SIG / unk_94 in your TICKET struct) which differs between devices.
My guess is this is an encrypted title-key of sorts, except instead of being encrypted with a common key like Wii/WiiU it uses a per-device one instead, I'd guess it decrypts that 0x10 area using the device-key and then the signature is checked with that decrypted 0x10 area in-place.
Only explanation I can think of for that area being different between units while signature remains static.
(also no luck with the ETICKET_XS_SIG struct signature neither, I'm guessing it probably has something similar)
I think it's funny the SKSA signature verified fine though - I guess the 0x10 area in that is already decrypted (or uses a common key to decrypt instead?)
Anyway seeing as we can calculate the signature hash for it we should be able to fake-sign SKSAs now... but that's kind of useless unless we figure out the SKSA crypto/hashing.
(I was really hoping to get ticket.sys fake-signing to work since that would have been pretty simple to test out, but seems we can't go anywhere with that until we get that title-key business sorted
)
Also what console-unique parts have you seen in the NAND? From the single dump I've had to look at the SKSA area seemed to match up with the one from the cache (except for some spots where I think the NAND wasn't dumped properly)
AFAIK the only console-unique parts are the apps themselves, and a few config-related files (there's files like id.sys & depot.sys which contain the BBID of the device, I'd guess it refuses to boot if those don't match the BBID in the CPU)
I'd really like to look at other dumps to be sure though, I still have my ique_diag extension mod here that should be able to dump over USB, which sadly hasn't been actually tried out yet ;_;
(If anybody has iQue@Home setup and working with their device, and wouldn't mind trying it out, please PM me!)
