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
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
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
Hi,
hmm, via strings kann man folgendes im dump finden ftp://ftp.philips.com/pub/pce-3032/pki/crl/
CU
9000h
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
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... :-))
There seems to be other interesting files about on the FTP including some signed / unsigned images and linux kernel source.
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.
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
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
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
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.
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
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)
Hi, just got a BTvision box to play with happy to help if I can
Hi,
Sorry to drag up this fairly old topic with my first post. But I think my wuestion is relevant to this thread.
I have dumped my BTVision bootloader. It is slightly different to Mick's based on a hex file comparison, appear it may be a later version. What is the entry point for the IDA analysis? Actually the correct setting for ROM/RAM would also be useful to confirm.
I set base address of RAM as 0x93600000
Processor - mipsl
Length - I assume 1meg based on the file size of the dump.
Cheers
Chris
its mips ii iirc and i think it detects its entrypoint.
is it 7421 by chance as well ?
its mips ii iirc and i think it detects its entrypoint.
is it 7421 by chance as well ?
Hmm, I have the following options for MIPS, is there an additional proc lib to laod for mipsii?
mipsb
mipsl
mipsr
mipsrl
It is a DIT9719/05, maybe the differences are to be expected i.e. unique to each box?
Cheers
Chris
if you do a hex compare are the differences at the end of the file?
Each box has a different certificate which is at the end of the bootloader.
Mick
Yes, the differences at the end, so that would exlain it.
Can you tell me th esetting so I can analyse the file myself?
Thanks
Chris
apols cpu is mipsii but for ida purposes mipsl is used
RAM:93600000 # Processor : mipsl
RAM:93600000 # Target assembler: GNU assembler
RAM:93600000 # Byte sex : Little endian
RAM:93600000
Thanks, but with mipsl I still get the error :-
IDA Pro can't identify the entry point automatically as there is no standard if binaries.
Please move to what you think is the netry point and press C to start the auto analysis.
Do I need to add something to IDA to help with the analysis?
Chris
What you have is correct.
When you load a .bin file IDA has no way of knowing where to load the file or where the entry point is.
Tell it to load the file into RAM, and set the ram start address at 0x93600000
I also set a mapping, to get the strings to display correctly.
To do this, select Options, then analysis.
Click Processor specific options, add a mapping.
From should be set to 0x0
set TO to 0x93600000
leave size as it is already set.
RAM:93632C78 Main_Entry_Point: # Memory reference trap address low bits
Scroll down to that point, and press C.
Mick
RAM:93632C78 Main_Entry_Point: # Memory reference trap address low bits
Thanks, that's what I wanted to know! ;D
However, analysis (even on your dump) stops after a few lines?? :(
RAM:93632C78 mtc0 $0, WatchLo # Memory reference trap address low bits
RAM:93632C7C mtc0 $0, WatchHi # Memory reference trap address high bits
RAM:93632C80 mtc0 $0, Count # Timer Count
RAM:93632C84 li $t0, 0xFFFFFFFF
RAM:93632C88 mtc0 $t0, Compare # Timer Compare
RAM:93632C8C mtc0 $0, Cause # Cause of last exception
RAM:93632C90 mtc0 $0, Config # Configuration register
RAM:93632C94 li $k0, 0xA006F010
RAM:93632C9C lui $k1, 0x4800
RAM:93632CA0 sw $k0, 0x48000000
RAM:93632CA4 la $t0, unk_93650684
RAM:93632CAC lui $t1, 0xA000
RAM:93632CB0 or $t0, $t1
RAM:93632CB4 la $ra, unk_93632CC4
RAM:93632CBC jr $t0
RAM:93632CC0 nop
Error is then - RAM:93632CA0: Can't find name (hint: use manual arg)
Everything else remains as raw.
Chris