Defeating authuld protection on CI+ devices

[cyberdemon79]

Hi there,

are you certain that the bootloader is on a otp (and hence not writeable) ?
exeDSP seems to have references to oneboot.bin or will it just dump it to a file ?
Do you have further insight into the booting process (oneboot -> uboot -> kernel ?) ?
Sorry for all these questions, but you seem to be quite some steps ahead and
I could sleep better a night if I understand how my TV boots to be able to
restore it in case of a brick.
One of the first things team twiizers did when hacking the Wii was to write
a custom bootloader with implemented flash dump and restore functionality
it would be great to have something similar to avoid bricking
So I think the very first thing to concentrate on is the booting-process
and they first possibility for us to intercept it (as far as I understand, most
ExLink functionality like memory writing is done through exeDSP if the
system gets bricked even ExLink won't be of much help).
After this is done, experimenting with the system will be a lot safer

cu Cyberdemon

[aquadran]

Hi!

Yes, i've tried to overwrite the bootloader. dd reports no error, but bml1 remains unchanged.
bootloader0 checks kernel (bml5), uboot (bml2) and fnw (bml4) partition and compare them with hashes stored on ubootenv partition (bml3)
The rest of the checks are done by kernel/authuld.
"U-boot" is a leftover because bootloader seems to never execute it, but aquadran suggests it's functional, so it should work if executed.

regards,
pgrey

bootloader0 checks only kernel

[cyberdemon79]

Thanks

So modifying the kernel would yield paper-weigth-mode I guess,
can the bootenv partition be changed ?

Do the kernel modules also get checked ?
If not one could recompile a module that gets automatically loaded
(on B650 the wlan module comes to mind), and insert a command
to start some known script from usb. Then autorun would be possible, right ?

cu Cyberdemon

[aquadran]

Thanks

So modifying the kernel would yield paper-weigth-mode I guess,
can the bootenv partition be changed ?

Do the kernel modules also get checked ?
If not one could recompile a module that gets automatically loaded
(on B650 the wlan module comes to mind), and insert a command
to start some known script from usb. Then autorun would be possible, right ?

cu Cyberdemon

bootenv can be changed

you can not modify boot, rootfs, exe, appdata, tlib partitions they are verified later by authld

[smartsmurf]

Yes, i've tried to overwrite the bootloader. dd reports no error, but bml1 remains unchanged.

A write operation to flash should involve an erase command first, shouldn't it? So dd might not be the tool of choice.

[smartsmurf]

Hi,

browsing through the authuld disassembly I found out that it references some key
called the "semaphore key" or "semaphore keyset", as far as I know, semaphores
are used to control concurrent hardware accesses (by blocking them if this resource
is already in use). I think it is possible that authuld somehow locks resources needed
by secure_enc and secure_dec so that only itself could calculate the correct responses.
If this is true, there are several ways around this problem
1) (the risky way) : One could patch authuld directly to dump the used mkey
(dangerous because then the check of authuld fails and we may very well get a reboot loop,
so I'm strongly against it)
2) (the long way) : We can assume that the used mkey is still in memory after authuld
terminated or (better) while it is still running, so trying to dump the whole ram should
give us the key (512*1024*1024 bytes take some time to check but would be possible)
3) patching the kernel in memory (via a module or like the ci+-serial-exlink-enable-way you
found) so that the memcmp which checks the response from authuld compares 0 bytes
instead of 16 (which would yield a positive response and keeps the tv running)
4) figuring out how the semaphorekey is created, try to mimic the commandflow to get
access to the possibly blocked resource and calculate the mkey like we tried in the
first place

2) is the easiest way but may fail due to memory access checks or maybe too time consuming
I think 3) would be the way to go but have no idea for now on how to calculate the correct
address to poke (the command there should be "mov r2, 10", which tells memcmp to check
16 bytes in length).

cu Cyberdemon

Option 4) is nice. Hint: semaphorekey is not required when authuld is no longer running.

[smartsmurf]

It's not just the authuld which uses onboard cipher. Quite a few functions from exeDSP use it.
Search for references to lldSe_ReadReg and lldSe_WriteReg

Mkey can be retrieved by examining memory of SdCP_ParamEncDec_t structure after cmackey decription

Yes, this is also a possible way. However, I did the hardware access like authuld is doing it. So I had to stop exeDSP & authuld in order to avoid a collision, because I was too lazy to add the semaphore thing. My mkey starts with 7CED26... and calculates my hashes perfectly.

Best regards,
SM