Homebrew ClCertA

[Suiginou]

ClCertA (a CFA with titleid 0004001b00010002 all regions) contains ctr-common-1-{cert,key}.bin. ClCertA is mounted as a filesystem by the ssl module (a CXI with titleid 0004013000002f02 all regions and no RomFS).

ctr-common-1-{cert,key}.bin are both encrypted/decrypted -- in addition to the crypto inherent to CFA/NCCH -- with keyslot 0x0d as per 3dbrew: The keyslot keyX and keyY (yielding the normal-key together) is initialized somewhere during boot.

How would I go about finding out which cipher mode of operation (CBC, CTR, unlikely but possible ECB, GCM or CCM) for AES to use and which IV/CTR to work with to decrypt those two files?

 

[yifan_lu]

Look in the ssl module to see how it's decrypted. Or just extract it from the ssl module heap memory.

 

[Suiginou]

I traced the filename pointer in an objdump disassembly adjusted to the loading location according to the CXI metadata of the ssl module for a bit, but lost it somewhere around 0x103f7c (Thumb), where it's (maybe) in r1, r4 and sp+20.

Finding the call to the EncryptDecryptAes has been a failure, too; the 0x00040204 header code mentioned on 3dbrew doesn't seem to be directly encoded, instead there's some weird massive bit shifting function (0x12a7e4 shifts some registers around and passes off to 0x102f44, which does the actual shifting) whose job is unclear but is called before every sendSyncRequest, after which r0 is discarded again anyway, however.

So, as you can tell, I'm a tad bit lost. Thank you very much for your hints, however.

Extracting it from the process memory would be an option but as far as I know, there's no way I can write to ARM11 userland memory from ARM11 kernel (reached by bootstrap via spider), which is required to dump the memory of another process.