Re: Defeating authuld protection on CI+ devices
Posted: Wed Jun 30, 2010 1:11 pm
ACK.petergrey wrote: true, it ends with ff07ec46
SamyGO
Samsung TV Firmware on the GO
http://forum.samygo.tv/
Defeating authuld protection on CI+ devices
Page 3 of 9
Re: Defeating authuld protection on CI+ devices
Posted: Thu Jul 01, 2010 12:55 pm
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 ?
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 ?
Re: Defeating authuld protection on CI+ devices
Posted: Thu Jul 01, 2010 1:50 pm
dlopen("/bin/authuld",RTLD_NOLOAD) should do the trick. I haven't tried that.cyberdemon79 wrote: 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) ?
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.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 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.BTW. great work finding out the mkey,
now custom exeDSP should be possible without authuld rebooting the system, correct ?
Before I can do this, I first need to ensure that /dev/bml/3 is not checked against any other hash.
Re: Defeating authuld protection on CI+ devices
Posted: Thu Jul 01, 2010 8:33 pm
At least I can now check integrity of my D-TV (btw, it is 2007.1 T-CHLCIPDEUC):
So, next step is to brick and to unbrick the device. Whoohoo, I just own that one since 8 days now... 
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!
Re: Defeating authuld protection on CI+ devices
Posted: Mon Jul 05, 2010 11:22 am
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
@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
Re: Defeating authuld protection on CI+ devices
Posted: Sun Jul 11, 2010 10:44 am
Everything works as expected. TV had been not broken.cyberdemon79 wrote: @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...
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.
Re: Defeating authuld protection on CI+ devices
Posted: Wed Jul 21, 2010 1:14 pm
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
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