Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - joepub
1
J23 looks like the jumper to switch between parallel/serial flash, and I wouldn't mind betting that U33 near J23 is the footprint for the parallel flash, but there looks to be some resistors missing from that area too. J22 could be a serial port, check the pins with an oscilloscope if you have one. There appears to be a lot more unpopulated headers on the DP-600 board than the 1600, I would first see if you can determine if any of them are JTAG ports, that will make life much easier.
2
Nope, if you could upload a photo of the board I could see if it's the same as the Kiss 1600
3
Just anything really would be nice as I haven't found any sites with information about hacking DP-600 or Kiss 1600. How to get access to filesystem for instance.
Well as far as I could work out with the stock firmware you cannot get shell access, they disabled the key sequence during the 1st stage boot loader also so no joy sending extra kernel parameters to enable it yourself. So that leaves flashing it with your own firmware and since the JTAG port on the EM8622 is not accessible on the Kiss 1600 board that rules out flashing it via JTAG so your only other option is to use the SPI flash mode of the chip to do it. The EM8622 support loading flash from a serial flash interface or parallel flash, parallel flash is what the Kiss 1600 does but you should be able to see footprints for the SPI flash on the board near the EM8622 core, it's labelled U12, you also need to solder a 10k SMT resistor on R88 near the SPI pad and 3 pin jumper on J18, the purpose of the jumper is to select between SPI and parallel flash, once you have done this you will be able to flash your own serial flash (has to be the ST25 types) a boot off that instead.
4
What exactly do you want to achieve, I have done extensive reversing of the Kiss 1600 and without a hardware mod you cannot update the firmware with your own. They sign the Linux kernel with a public/private key so creating your own is a no go without the private key.
I do plan on blogging about it shortly.
5
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.
6
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
7
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?
8
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?
9
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
