LExxB650 T2P CI+ hacking

[arris69]

...

Another thing: has someone any idea what the EDID directory is for in mtd_exe ??? encryption keys ???

Jeroen

hi edid data is simply monitor capability information:

Code: Select all

cat 1.ddc | xxd -r -p | monitor-parse-edid -
Name: SAMSUNG
EISA ID: SAM051b
Screen size: 88.0 cm x 50.0 cm (39.85 inches, aspect ratio 16/9 = 1.78)
Gamma: 2.2
Analog signal
Max video bandwidth: 150 MHz

        HorizSync 30-81
        VertRefresh 60-75

        # Monitor preferred modeline (60.0 Hz vsync, 67.5 kHz hsync, ratio 16/9, 55 dpi)
        ModeLine "1920x1080" 148.5 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync

        # Monitor preferred modeline (60.0 Hz vsync, 47.7 kHz hsync, ratio 16/9, 39 dpi)
        ModeLine "1360x768" 85.5 1360 1424 1536 1792 768 771 777 795 +hsync +vsync


[robbiesz]

Hey Guys

Let me respond to Jeroen's post as well..

- first of all, has it really been proven, that authuld is the culprit for rebooting the server ?
* I'm not sure the authuld is the culprit, but it sure seems to reboot at the stage that authuld is started complely. It starts very early in the process:

-> If that is the case, does it do it by directly communicating with the control units or does it also use MicomCtrl to do so ?
-> If it is MicomCtrl that is used to do so, one could try mask ( overlay ) that binary with a script ( mount -o bind ... ) and ignore the reboot request
* The MiComCtrl is not running anymore caused by switching of the watchdog in the service-menu??

- is authuld started by exeDSP or is it started before exeDSP ?
* It looks to me authuld is started before the exeDSP-process; the pid is lower.

- can't authuld be stopped as one of the first actions before exeDSP is started ?
* I'm not able to kill the authuld process.

- can't authuld be overlayed with something less disruptive ( e.g. mind -o bind /mtd_rwarea/my_modified_empty_authuld_script /bin/authuld ) ?
* I'm not sure; the fact that I'm not able to kill it, gives me little hope.

- one could also attempt to do some of these actions from within /mtd_boot/rc.local ( but this one is again a more risky activity, as noone has reflashed the mtd_boot partition as yet )
* Flashing the mtd_boot partition is no option... yet, cause I have no shell access on the terminal as backdoor. I can get that by killing the exeDSP-process, but that's only possible from a remote-terminal. The terminal seems not to respond on ctrl-c.

I still think the key is the authuld. We need to find out how it works, so we can control it.

Authuld is a kernel initiated userspace daemon. It is responsible for making sure that all system components are authentic and have not been modified. You cannot kill it since the kernel made it a kernel thread. It can work in two modes: Normal and Development mode. Normal mode will shut down the system in the event of any modification to partitions. The development mode won't. Unfortunately this cannot be changed (easily, more about this later on) once the thread started.
I am still debugging authuld but for now it seems that it does checks on partitions bml0/6,7,8,9,10 and 11. And also the kernel checks for a genuine copy of authuld just before it executes it.
Authuld does not use MicomCtrl! It doesn't need to as all MicomCtrl does is open the serial line ttyS0 and send packets (commands) to <well, I'm not really sure to what. It looks as there's another arm powered circuitry in the TV which controls the main CPU and other peripherals of the TV>
Authuld sends the commands to ttyS1 to shut the TV down.. Simple as that.
There are two files that the kernel and authuld use to communicate with each other.. They are /dtv/.ku and /dtv/.uk . You can guess these are for the two-way communication (KERNEL-USERSPACE and vice versa). Why it was done this way is beyond me... Understandably.. I'm just a arm kernel enthusiast with a samsung tv..

Question for Jeroen: Does your TV work at the moment? Or it keeps restarting every two minutes or more often?
Did you put the old exe.img back to bml0/8?

robbiesz

[dynamic1969]

Hi robbiesz,

did you discover any information as to what authuld is checking these partitions against ( I assume there is some sort of checksum or fingerprint stored per partition somewhere ? )
As during a normal FW Upgrade only mtd_app and mtd_exe are updated, one could assume that the checksums / fingerprints are:
- either calculated on the file during the upgrade and then stored or
- already embedded in a file in the respective partition

Regards
dynamic

[erdem_ua]

If the key created while update process, than we alter the update process with uploading modified exe.img file without .sec extension.

I check the root file (bml6) and found a little script at /usr/sbin directory, that updates firmware of TV from exe.img directly!
So we don't needed encrypted file for update partition I think.
At least, worth to try

And I saw some info at script at bml7 rc.local. this file is highly related with SW update process...

Code: Select all

if [ "$usb_upgrade" = "true" ]; then         
#   $BOOT_MOUNT/usb
#   CI+ could not run in emergency mode for hacking... Set will be shutdown
        echo "Wait time: 1-30 sec."

Are they talking to us?

[jeroenvoc]

robbiesz

Thanks for the indepth information on authuld.

Yeh, my TV works at the moment. I had to remove the PartitionSwitch_0_0 file and create a PartitionSwitch_1_0 file to make it boot from the bml0/10 parttion.
When I boot from my hacked exe, I got about 10 seconds before the TV shuts down. That's enought to do the above.

I know I have to put the old exe.img back, but I leave my hacked one in for now; Living on the edge . I'm not finished testing yet....
I'll try to boot again from the hacked exe, and I will see if I can monitor the .ku and .uk files... just curious what message the authuld will be sending to the kernel... If the authuld-signal to shutdown the set will go through these files, maybe intercepting / altering these messages is an opening....

erdem
I've spotted that script too. No sure what I can do with it.

Jeroen

[robbiesz]

Hi Jeroen

Communication between Authuld and the kernel is binary... I havent cracked the authuld->kernel way but the kernel only sends 4 bytes (only once) to authuld which seem to be a simple number (unsigned int) from a timer interface..
The kernel will shut the set down if
- authuld does not respond within a predefined amount of time
- the message is corrupted or does not conform to the protocol..

On boot-up the authuld has 5 minutes to authenticate all modules, by default the kernel has a 2 minute timeout value for the response from authuld..
All crypting is done by the kernel..

robbiesz

[erdem_ua]

Hi Jeroen

Communication between Authuld and the kernel is binary... I havent cracked the authuld->kernel way but the kernel only sends 4 bytes (only once) to authuld which seem to be a simple number (unsigned int) from a timer interface..
The kernel will shut the set down if
- authuld does not respond within a predefined amount of time
- the message is corrupted or does not conform to the protocol..

On boot-up the authuld has 5 minutes to authenticate all modules, by default the kernel has a 2 minute timeout value for the response from authuld..
All crypting is done by the kernel..

robbiesz

I don't understand "modules" word. Do you mean kernel modules?
Is it checks kernel modules + exeDSP only?
Are we sure about that authuld checks files/modules instead of partitions?
If answer is yes, checking every file alone comes weird to me.
Implementing this might possible by 2 way
1)Including secret hash index of files in the authuld or anywhere that authuld reads.
2)Hashes included each kernel file, like CRC.
Second approach is more difficult and could be problematic at implementation for Sammy. Like needing every module modified by hand( or program )
By comparing modules at encrypted version and normal version could make visible that hash rounder byte(s).

[jockyw2001]

Some questions to begin with:
- is it possible to boot a B650 of a USB stick? (with my A750 where this is possible after dumping flash to stick and changing bootcmd)
- is this authuld process running on the same cpu or is there a 2nd ARM where it is running on? (just like on several mobile phones where "radio" runs on an ARM9 and the OS on another ARM11)

I just received my 58" B859 plasma. I guess I will not only use it for watching telly. Could become a huge brick if something goes wrong ..

[robbiesz]

I'm sorry Jeroen, I didnt mean kernel modules at all. I meant system components. They are the bootloader, fnw (onenand updater), uboot, kernel image, mtd_exe partitions (both!), appdata partitions (both!), mlib partition...

Have a look at the files in linux-b650t2p/init folder... The encryption used is cmac-eas where the cmac ciphering is done by the processor.. I've managed to compile the CI+ kernel so I can run some tests myself. Yeah, you can run CI+ kernel on a CI set... Of course my build has a bit (a lot) more debugging info..
I've also been working on a kernel module which will do the HW ciphering. It seems to be working on my set but will need a CI+ tester soon.. Jeroen, how would you feel about doing some testing for me?

robbiesz

[robbiesz]

Some questions to begin with:
- is it possible to boot a B650 of a USB stick? (with my A750 where this is possible after dumping flash to stick and changing bootcmd)
- is this authuld process running on the same cpu or is there a 2nd ARM where it is running on? (just like on several mobile phones where "radio" runs on an ARM9 and the OS on another ARM11)

I just received my 58" B859 plasma. I guess I will not only use it for watching telly. Could become a huge brick if something goes wrong ..

I hope I'm not mistaken but are you THAT jockyw2001? from xda-developers? I owe you my kaiser phone! You got some serious talent, man! The TV does seem to have two arm cores... One ARM9 and one ARM11 where the OS runs..

and don't worry, you'll be watching your hacked telly for a looong time..

robbiesz