SamyGO

erdem_ua wrote:How could we decipher exe.img encryption on PC?
If we find technique and correct keys, than we build modifications on the computer and plug&flash option for safe process.

@Jeroen could you get all bml devices image and compress them with 7z?
Resulting file is nearly ~200-250 Mb but full image is better at some cases.

Is there anyone that understands cryptology here:?:

kernel source code tells exactly where keys are and how to decrypt.
however i'm not familiar with decryption in general.

Kernel? I am suspecting that if kernel is responsible for decrypting for flashing firmware. Codes at kernel could be related with CI+ broadcast signal itself.
Could you indicate file and lines of source code where is the that encoding stuff?
Also inspecting on root.img will give as hints of decryption technique of firmware update process.
I think there is no image of root, right? I prefer to inspect full bml device table. from 0 to 20..

erdem_ua wrote:Kernel? I am suspecting that if kernel is responsible for decrypting for flashing firmware. Codes at kernel could be related with CI+ broadcast signal itself.
Could you indicate file and lines of source code where is the that encoding stuff?
Also inspecting on root.img will give as hints of decryption technique of firmware update process.
I think there is no image of root, right? I prefer to inspect full bml device table. from 0 to 20..

true, it may not be responsible for firmare decryption as whole thing. but at least decryption executables, that authuld daemon stuff.
all related authuld code is in "linux-r011/init" kernel CI+ kernel sources.

jeroenvoc wrote:Do you think it's possible to stop authuld from running?
Patching the exe-image is possible, the TV runs it, but the authuld deamon shuts down the tv. If we can stop authuld from loading, we can do whatever we want.

Does anyone knows where the authuld is started from?

Jeroen

authuld daemon is bulting into linux kernel. only replace kernel with disabled daemon which is possible by flashing from telnet (also flashing bootloader from non CI+). however it's unknown how it affect to rest stuff in rootfs. It's quite risky.

Hi jeroenvoc,

you should in any case get your original flash bml0/8 also in order ... otherwise you may rung into trouble in case your backup flash gets corrupted as well during one of your tests ( you look like to be an interested, curious & active user )
Remember bml0/10 is your backup flash and not the original flash!

Also if I understand you correctly, you got the EERID issue resolved by fixing your rc.local script, right ?

Regarding authuld, maybe a little brainstorming & challenging questions do help:
- first of all, has it really been proven, that authuld is the culprit for rebooting the server ?
-> 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
- is authuld started by exeDSP or is it started before exeDSP ?
- can't authuld be stopped as one of the first actions before exeDSP is started ?
- can't authuld be overlayed with something less disruptive ( e.g. mind -o bind /mtd_rwarea/my_modified_empty_authuld_script /bin/authuld ) ?
- 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 )

Regards
dynamic