TDMX block on em8622/smp8634

[joepub]

Hi,

Can someone explain how the transport demux block on the em86xx/smp86xx works.  I am trying to figure out what encryption methodology the Kiss 1600 player is using to encrypt it's boot firmware so that we can overwrite one with our own.

So far after disassembling kiss's firmware on the 1600 player I noticed they are loading the TDMX block with some ucode and some data into it's data memory within the TDMX block.  I believe this ucode is responsible for doing the decryption of their firmware.

What instruction set/disassembler can you use for their TDMX ucode?

I have managed to port u-boot to the Kiss 1600 player so hopefully once I can figure out the encryption they are using for their firmware I can write a Kiss-1600 boot CD that will flash their boot loader with u-boot and the Kiss-1600 should be DRM free to use Linux as we please.

Thanks

[Hoernchen]

The tdmx block and its cpu is completely custom, so there is no way to disassemble the ucodes
But I doubt that linksys/kiss are actually using the tdmx block to decrypt anything, no sigma customer had access to the ucode stuff so far, so the only way to do it would be to supply the bootloader as a scrambled mpeg-ts stream in order to decrypt it with the tdmx block.

[joepub]

Ah I see, so most likely they are just loading the ucode given to them by Sigma TDMX into the demux PMEM? 

Well they seem to be using AES, so if they have no control over the ucode I guess the keys must be embedded within the firmware and the TDMX block is informed of the keys before decryption begins.

How much do you know about how the TDMX block works?  I have managed to dump some part of the encrypted firmware in unencrypted form by starting the demux CPU in a similar fashion as their original firmware, but there is one write to a register I am trying to figure out how it works.

They are writing to the demux_MISC_interrupt register with value 0x101, as soon as this happens the decryption starts, but then the PC jumps elsewhere once it's finished (I guess from some interrupt), so what I have done currently is try to stop the demux CPU before that interrupt fires and then dump the unencrypted memory.  Do you know if there is a way for the demux CPU to start then finish it's tasks without firing an interrupt?

[Hoernchen]

The em8622 is an ARM based device and it has no XPU, so you should be able to decompile the irqhandler which is responsible for handling the demux interrupts. Unfortunately there is no register description or documentation available, and the irq handler for smp86xx devices is encrypted, so I never had the the opportunity to explore this any further.
As for the ucode loading.. another mystery, I've never understood why, but they seem to load their ucode by putting it into the dmem instead of the pmem.

[joepub]

so you should be able to decompile the irqhandler which is responsible for handling the demux interrupts

Funny thing is I have control of the interrupt vectors, as I have already set them up as u-boot does but they don't appear to fire within the IRQ interrupt (well actually none of them as far as I can see, it's like the u-code has remapped them somewhere else)

Would it be possible for the TDMX RISC CPU change them, or does the TDMX RICS CPU have direct control over the PC register?

[Hoernchen]

Theoretically any part of the chip could do anything, but I somehow doubt that the demux block would manipulate the instruction pointer...
Did you check the FIQ stuff, too ?

[joepub]

Theoretically any part of the chip could do anything, but I somehow doubt that the demux block would manipulate the instruction pointer...
Did you check the FIQ stuff, too ?

Well as far as I can see the FIQ as well as every other vector ends up within the same function within u-boot which is a default exception handler that prints out the CPU registers and resets.  Well I take another look to see, but at the moment I'm really confused

[joepub]

Well I'm getting somewhere.  I have managed to find out where the key is, they store it in the LR_KEY_ZONE in local ram within the CPU block which eventually gets copied into the aes key area within the demux engine.  I also think they store the IV within a header inside the image.bin file which is the encrypted linux kernel that the decrypt and expand during boot.

At the moment though using the key/iv externally with a normal open source AES implementation doest decrypt to the correct plain text, so I'm wondering if the have changes the AES implementation, perhaps different sbox and rsbox tables for AES.  Not quite sure yet.