Defeating authuld protection on CI+ devices

[smartsmurf]

true, it ends with ff07ec46

ACK.

[cyberdemon79]

Hi there,

both of you are a few steps ahead of me, I have a small
problem reading my mkey (using a different approach) and
could use some help, if you don't mind

I'm planning to patch authuld in memory, in the nameless
function which calls the AES_HMAC calculation. I'm patching
a few print_k and surrounding commands which won't hinder
the program flow and insert a loop which starts from the
pointer to mkey and calls print_k 16 times (a very crude
way but should work), outputting the next mkey byte as it goes.

My problem is to find the actual physical memory address, where
authuld is loaded, can i use /proc/pidofauthuld/maps to get it,
or can i just dlopen("authuld"), search for the exported start function
and calculate addresses base from that (difference to my address as offset) ?

If I'm to slow and authuld isn't running anymore, is the memory still
filled with the same data, or does it get wiped (as a kernel hardening
feature or something like that) ?

Thank you
cu Cyberdemon

BTW. great work finding out the mkey,
now custom exeDSP should be possible without authuld rebooting the system, correct ?

[smartsmurf]

My problem is to find the actual physical memory address, where
authuld is loaded, can i use /proc/pidofauthuld/maps to get it,
or can i just dlopen("authuld"), search for the exported start function
and calculate addresses base from that (difference to my address as offset) ?

dlopen("/bin/authuld",RTLD_NOLOAD) should do the trick. I haven't tried that.

If I'm to slow and authuld isn't running anymore, is the memory still
filled with the same data, or does it get wiped (as a kernel hardening
feature or something like that) ?

I did not have seen any key burn procedure. However, the mkey is placed on the stack so it might get recycled as soon as authuld exits.

BTW. great work finding out the mkey,
now custom exeDSP should be possible without authuld rebooting the system, correct ?

I think there will be some more steps to do this. My approach is a modification of the MacInfo_t structures in /dev/bml/3 with the structure member msgLen initialized to "4". So the /dev/bml0/6 (rootfs) and /dev/bml0/7 (boot) will allways get checked the first 4 bytes only which will be "hsqs" - regardless of the actual filesystem content.
Before I can do this, I first need to ensure that /dev/bml/3 is not checked against any other hash.

[smartsmurf]

At least I can now check integrity of my D-TV (btw, it is 2007.1 T-CHLCIPDEUC):

Code: Select all

# ./checkintegrity

Sony D-TV integrity checker V0.1
(p) SmartSmurf 2010 (smartsmurf@shared-files.de)

kernel flash type : 1000 MB

Your cmackey is: 5E C2 6E 7D C6 A3 08 DB 2B B6 6C 7F DF 9A FC F1
(cmackey is dev)
(mkey is not dev)

macUboot( msgLen=0x00330000): 03 16 53 43 B4 50 8D FC 20 57 C4 A2 CC 3D 15 F8
CI integrity checking for file /dev/bml0/6 (input size = 0x00330000)
[AES_CMAC]: total read length = 0x00330000
calculated hash: 03 16 53 43 B4 50 8D FC 20 57 C4 A2 CC 3D 15 F8
-> integrity check OK!

macFnw(   msgLen=0x000DE000): 99 94 2C 0F D7 E1 3A EC EB 57 A2 13 82 BE B3 C8
CI integrity checking for file /dev/bml0/7 (input size = 0x000DE000)
[AES_CMAC]: total read length = 0x000DE000
calculated hash: 99 94 2C 0F D7 E1 3A EC EB 57 A2 13 82 BE B3 C8
-> integrity check OK!

mtd_exe(msgLen=0x03417000): 56 7F 9A 70 39 56 F0 3F 93 B0 25 CA BD DD 40 0F
CI integrity checking for file /dev/tbml8 (input size = 0x03417000)
[AES_CMAC]: total read length = 0x03417000
calculated hash: 56 7F 9A 70 39 56 F0 3F 93 B0 25 CA BD DD 40 0F
-> integrity check OK!

mtd_appdata(msgLen=0x01CAD000): 75 B6 50 6A 22 80 F1 39 86 42 D0 B0 B6 2F 26 3A
CI integrity checking for file /dev/tbml9 (input size = 0x01CAD000)
[AES_CMAC]: total read length = 0x01CAD000
calculated hash: 75 B6 50 6A 22 80 F1 39 86 42 D0 B0 B6 2F 26 3A
-> integrity check OK!

So, next step is to brick and to unbrick the device. Whoohoo, I just own that one since 8 days now...

[cyberdemon79]

Hi,

@petergrey
could you please give me a hint, where exactly the mkey is used
within exeDSP? The MainDebug menu seems to be a good try, as
there is the same flashsize-calculation going on as in the kernel
sources and authuld, but I can't really figure out where to grab
the mkey.
Am i correct to assume, that the mkey is in the SdCP_ParamEncDec_t
structure, after the SdDecrypt right before the call to emergency.sh is
executed ?
My key dumping function should work, but I haven't found the mkey in
exeDSP memory until now

@smartsmurf
Any news, modifying the hashes ?
Have you already tried slightly modifying exeDSP, recalculated the hash
and tried if it gets accepted ?
Hope you haven't broken your TV trying that...

Thanks,
cu Cyberdemon

[smartsmurf]

@smartsmurf
Any news, modifying the hashes ?
Have you already tried slightly modifying exeDSP, recalculated the hash
and tried if it gets accepted ?
Hope you haven't broken your TV trying that...

Everything works as expected. TV had been not broken.

Btw, you cannot hash exeDSP standalone, you need to hash the complete /mtd_exe partition. At least for the length which is stated in /dev/bml/3.

Currently I am out of office enjoying my holidays at the sea. When I return next week I will continue testing.

[cyberdemon79]

Hi there,

sounds like great news from you two.
So we are even able to modify the kernel itself and upgrade to newer kernels (sounds extremely dangerous -> fun ).
I had feared, the kernelhash would be stored in the OTP.
But removing the one part you quoted isn't enough, is it ?
If I remember correctly, the kernel also reboots if it won't get a response
from authuld within a given timeframe.

After patching to kernel to ignore the authenticity of the firmware the next important
step would be to install some kind of failsafe mechanism to avoid bricking the system.
A great way to avoid trashing the firmware would be to mount mtd_exe from usb if
some condition (magic file on drive) is met. This will make development a whole lot
easier (another way could be to mount a network share like the old bootloader could do).

After something like this is established and it is harder to trash the entire system (if not done on purpose),
more people would be willing to experiment on their devices.

cu
Cyberdemon