Philips DIT9719 (BT Vision) bootloader dumped :)

Started by is0-mick, 21. Apr 2008, 22:36

previous topic - next topic
Go Down

is0-mick

Hi All,

I can confirm that the jtag points in my previous post are correct.

I tried a different pc, with the C program and dumped the bootloader.

The data seems valid as I had a look in a hex editor and can see plain strings.

I have uploaded it here:

http://www.megaupload.com/?d=34BB7N97


Cheers
Mick

mce2222

very nice... that looks very similar to the x300t bootloader.
but I guess the signature check location is slightly different ... i havent checked with IDA pro yet

is0-mick

Thanks for the reply :)

I was going to drop it into IDA last night, but it was getting too late.
I may try later on this evening.

Do you have part of the disassembly of your signature check, so I can see what it looks like?

I guess it all boils down to a JZ or JNZ or a CMP :) (not sure on the exact commands on mips).

Mick

9000h

Hi,

hmm, via strings kann man folgendes im dump finden ftp://ftp.philips.com/pub/pce-3032/pki/crl/

CU
9000h

is0-mick

This looks like it could be the right place?

RAM:93633EC8                 la      $v0, aNk_bin     # "nk.bin"
RAM:93633ECC                 addiu   $a2, $fp, 0xA0+var_4C
RAM:93633ED0                 sw      $s4, 0xA0+var_50($fp)
RAM:93633ED4
RAM:93633ED4 loc_93633ED4:                            # CODE XREF: sub_93633BC8+31Cj
RAM:93633ED4                 addu    $t8, $v1, $v0
RAM:93633ED8                 lhu     $a3, 0($t8)
RAM:93633EDC                 addu    $t9, $v1, $a2
RAM:93633EE0                 sh      $a3, 0($t9)
RAM:93633EE4                 bnez    $a3, loc_93633ED4
RAM:93633EE8                 addiu   $v1, 2
RAM:93633EEC                 sw      $s4, 0xA0+var_30($fp)
RAM:93633EF0                 lw      $v0, 0xA0+var_50($fp)
RAM:93633EF4                 lui     $v1, 0x9380
RAM:93633EF8                 sw      $v0, 0x938056F0
RAM:93633EFC                 andi    $v0, 1
RAM:93633F00                 beqz    $v0, loc_93633F34
RAM:93633F04                 nop
RAM:93633F08                 jal     sub_936349F0
RAM:93633F0C                 nop
RAM:93633F10                 li      $a3, 0
RAM:93633F14                 li      $a2, 0
RAM:93633F18                 li      $a1, 0
RAM:93633F1C                 li      $a0, 0
RAM:93633F20                 sw      $0, 0xA0+var_88($sp)
RAM:93633F24                 sw      $0, 0xA0+var_8C($sp)
RAM:93633F28                 jal     sub_9364D73C

Mick

redband


Hi,

hmm, via strings kann man folgendes im dump finden ftp://ftp.philips.com/pub/pce-3032/pki/crl/

CU
9000h


When the bootstrap.asmx is called the x-tv2-auth-ticketReq contains a cert which contains the following single entry in it's chain.
ftp://ftp.philips.com/pub/pce-3032/pki/certs/ProductionSTBSubCA007.cer  which is issued by "Microsoft IPTVe CA"

ftp://ftp.philips.com/pub/pce3032/pki/crl/ProductionSTBSubCA007.crl
is probably just a dummy/placeholder value in the cert, doesn't seem to return a CRL

Interesting news on the JTAG... :-))

is0-mick

There seems to be other interesting files about on the FTP including some signed / unsigned images and linux kernel source.


redband

#7
22. Apr 2008, 20:02 Last Edit: 22. Apr 2008, 20:28 by redband
ftp://ftp.philips.com/pub/pce-3032/pki/cps/Philips_STB_MSTV_Production_CA_CPS.pdf
is particularly interesting...

"STB  Private  Keys  are  generated  by  the Manufacturer  Authority  and  are  provided  to
PHILIPS STB together with the corresponding STB certificates.
The  two pairs of certificate and  related private key are burnt  together  in  the STB  (and
then cannot be removed or overwritten).
The  serial  number  part  of  subject  name  of  the  two  certificates  burnt  in  each STB  is
identical and will be used as the MAC address of the STB. "


...

NB: STB certificate validity period must not be checked.

is0-mick

I have modified the booter.ce in the NK.bin and a few other files.

Does anyone have a copy of your bootloader so I can compare how yours is patched, and patch ours.
or has anyone looked at our bootloader to see what needs patched. I think I have the right area, but not sure what all the other subroutines do...

Thanks

Mick

mce2222


RAM:93641BAC loc_93641BAC:                            # CODE XREF: VerifyBLFilesImage+54Cj
RAM:93641BAC                 lw      $a2, 0x9A8+var_97C($sp)
RAM:93641BB0                 addiu   $a1, $sp, 0x9A8+filename
RAM:93641BB4                 jal     sub_9363CCD0
RAM:93641BB8                 addiu   $a0, $sp, 0x9A8+var_960
RAM:93641BBC                 beqz    $v0, loc_93641BD8
RAM:93641BC0                 nop
RAM:93641BC4                 lui     $v0, 0x9360
RAM:93641BC8                 jal     nullsub_1
RAM:93641BCC                 addiu   $a0, $v0, 0x5E9C  # "\r\n****** ERROR: hash does not match expected value ******\r\n"
RAM:93641BD0                 b       loc_93641BE8
RAM:93641BD4                 nop
RAM:93641BD8  # ---------------------------------------------------------------------------
RAM:93641BD8
RAM:93641BD8 loc_93641BD8:                            # CODE XREF: VerifyBLFilesImage+598j


if you change it like this, then the hash check of the bootable files is always true.

RAM:93641BBC                 b   loc_93641BD8

please note that the filesize is checked some lines above, but usually it is not needed to fix this, unless you are generating a complete new nk.bin

is0-mick

#10
23. Apr 2008, 12:54 Last Edit: 23. Apr 2008, 14:06 by is0-mick
Thanks for that..

I have found the same routine here:

RAM:93640F1C
RAM:93640F1C loc_93640F1C:                            # CODE XREF: sub_93640994+54Cj
RAM:93640F1C                 lw      $a2, 0x9A8+var_97C($sp)
RAM:93640F20                 addiu   $a1, $sp, 0x9A8+var_948
RAM:93640F24                 jal     sub_9363C41C
RAM:93640F28                 addiu   $a0, $sp, 0x9A8+var_960
RAM:93640F2C                 beqz    $v0, loc_93640F48
RAM:93640F30                 nop
RAM:93640F34                 lui     $v0, 0x9360
RAM:93640F38                 jal     nullsub_1
RAM:93640F3C                 addiu   $a0, $v0, 0x6208
RAM:93640F40                 b       loc_93640F58
RAM:93640F44                 nop


so I would need to change to
RAM:93640F2C                 b       loc_93640F48

so in the patcher
ejtag_write(0x93640F2C, 0x06000010);   // beqz    $v0, loc_93640F48  -->  b loc_93640F48

should do it.



Mick

mce2222

a word on the patch...

the bootloader will start to load the NK.BIN to do the signature check. while it is loading you have about 5 seconds to start the jtag patcher so that
the outcome of the hashing will be always correct.

if you wait too long, the hash will be false, and a desaster recovery is triggered.

is0-mick

I found the routine that checks the size also:

RAM:93640DDC loc_93640DDC:                            # CODE XREF: VerifyBLFilesImage+43Cj
RAM:93640DDC                 lw      $fp, 0x18($sp)
RAM:93640DE0                 beq     $s7, $fp, loc_93640E10
RAM:93640DE4                 nop
RAM:93640DE8                 lui     $v0, 0x9360
RAM:93640DEC                 jal     nullsub_1
RAM:93640DF0                 addiu   $a0, $v0, aErrorBootableF  # "\r\n****** ERROR: BOOTABLE file of incorr"...
RAM:93640DF4                 lui     $v0, 0x9360
RAM:93640DF8                 move    $a2, $s7
RAM:93640DFC                 move    $a1, $fp
RAM:93640E00                 jal     nullsub_1
RAM:93640E04                 addiu   $a0, $v0, 0x630C

so
RAM:93640DE0                 b    loc_93640E10
should do the trick on that one...


In your code you seemed to have another patch?
   // signature skip flag
   addr1 = 0x937E1728;
   ejtag_write(addr1, 0x01000000);

Could you explain that one please?

Thanks
Mick




mce2222

yeah. there is a nice boolean flag in the boot method, that completely skips the validation of the boot.sig file.
the problem is that you have a very tiny time interval to apply this, because the skip is at the beginning.
in the x300t, you can use a nice trick, by unpluggin the network cable. then it will wait in a loop to the reconnection of
the cable, so you have all the time you want to apply the patch.

thats why it mentions to "press OK" to continue booting.

if your box does not behave like that, then there is a flag in the boot.prv file missing (wait_for_network)

Chiliblue

Hi, just got a BTvision box to play with happy to help if I can

Go Up