hacking DVD firmware ?

[djhuevo]

Svenhag,
what I understood from djhuevo post is that, if you change anything you can set the checksum to 0x00000000 it always return as a valid not that the position 0x00000000 is a checksum.

yeah reise is correct, the checksum is a s32 at 0x3E800, is a simple sum from *(s32)0x6000-0x3E7FC substracted from 0x100000000
if you put the *value* 0x00000000 @ 0x3E800 checksum test will always pass

Code:

      9b: fc dc 00 60 mov -1879023616,a0  // a0 = 0x90006000
      9f: 00 90
      a1: fc dd 00 e8 mov -1878792192,a1  // a1 = 0x9003E800
      a5: 03 90
      a7: 85 00        mov 0,d1   // d1 = 0
      a9: 70          mov (a0),d0  // d0 = *(u32 *)a0;
      aa: e1          add d0,d1  // d1+=d0
      ab: 50          inc4 a0      // a0+=4
      ac: b4          cmp a1,a0  //
      ad: c4 fc        bcs 0xa9  // if(a0!=a1) goto _0xa9
      af: a5 00        cmp 0,d1  //
      b1: c8 0b        beq 0xbc  //  if (d1==0) goto _j_boot_checksum_ok
      b3: fa fd 00 0f or 3840,psw
      b7: cb          nop
      b8: cb          nop
      b9: cc 47 0f    jmp 0x1000 // goto  _boot_checksum_fail (flashing led or semething???)
_j_boot_checksum_ok:
      bc: fa fd 00 0f or 3840,psw
      c0: cb          nop
      c1: cb          nop
      c2: cc 7e 5f    jmp 0x6040  // goto _boot_checksum_ok

for me the first 256bit dont look like a sha1 (in base to his entropy), I can't see another visible checksum like the 8050L and 8163B that have checksums @0x3fff8 and @0x41be4

Hrm yea when I re-read djhuevos' post what you're saying seems to make sense <: .

hehe, sorry my english

[svenhag]

for me the first 256bit dont look like a sha1 (in base to his entropy), I can't see another visible checksum like the 8050L and 8163B that have checksums @0x40000 and @0x41be4

I hope you're right since it wouldn't be nice if the whole fw was protected by a sha256.

[svenhag]

if you put the *value* 0x00000000 @ 0x3E800 checksum test will always pass

Hrm actually I don't see how this can be true.

First, the "checksum" is at 0x3e7fc and the value there must always be the 2's complement to the sum of everything from 0x6000-0x3e7f8. That way the sum of everything from 0x6000-0x3e7fc will always be 0 (which is what we want it to be).

Code:

#include <sys/mman.h>

#include <stdio.h>
#include <fcntl.h>
#include <string.h>
#include <errno.h>

#define CS_START 0x6000
#define CS_END 0x3e800
#define SIZE CS_END-CS_START

int
main(int argc, char *argv[])
{
int fd, sum = 0;
int *ptr;
void *start, *end;


if (argc != 2)
printf("Usage: %s file\n", argv[0]), exit(-1);

if ((fd = open(argv[1], O_RDONLY)) < 0)
printf("fopen failed: %s\n", strerror(errno)), exit(-1);

if ((start = mmap(NULL, SIZE, PROT_READ, MAP_SHARED,
fd, CS_START)) == MAP_FAILED)
printf("mmap failed: %s\n", strerror(errno)), exit(-1);

for (ptr = start, end = start + SIZE; ptr != end-4; ++ptr)
sum += *ptr;

printf("Sum before adding value at 0x3e7fc: %x\n", sum);
printf("Sum after adding value at 0x3e7fc: %x\n", sum+ *ptr);
printf("Value at 0x3e7fc: %x\n", *ptr);


munmap(start, SIZE);
close (fd);

return (0);
}

When I run this I get

Sum before adding value at 0x3e7fc: cc97e34a
Sum after adding value at 0x3e7fc: 0
Value at 0x3e7fc: 33681cb6

And 0x33681cb6 is the 2's complement of 0xcc97e34a.

[svenhag]

The code above is for the GDR-3120L.

[svenhag]

Ah okay heh I found why 0x00000000 will always work now (I posted that piece of code myself a couple of pages ago )

Code:

//
// branch to 0x400000bc (jmp to 0x40006040) if (0x9003e7fc) == 0
//
40000090: fc dc fc e7 mov -1878792196,a0 // 0x9003e7fc
40000094: 03 90
40000096: 70          mov (a0),d0
40000097: a0 00        cmp 0,d0
40000099: c8 23        beq 0x400000bc

That's why <:

Okay then nevermind my previous posts.

[MacDennis]

I just made high res scans of the front and the back of the mainboard of this DVD drive if anyone is interested.

Ofcourse could you upload them somewhere and post a link ? Thanks.

Here you go ..
http://rapidshare.de/files/10267902/Philips_DVD-ROM.rar.html

[Nayr]

It is possible to convert from sata to pata and then back from pata to sata.

The 360 appears to use a very similiar unlocking protocol as the xbox1.

This list of packet commands after a disc insertion is probably not entirely correct:
...
00
03
00
55
5a
5a
ad
55
5a
55
5a
55
5a
55
5a
55
5a
55
5a
28
28 ...

[TheSpecialist]

It is possible to convert from sata to pata and then back from pata to sata.

The 360 appears to use a very similiar unlocking protocol as the xbox1.

This list of packet commands after a disc insertion is probably not entirely correct:
...
00
03
00
55
5a
5a
ad
55
5a
55
5a
55
5a
55
5a
55
5a
55
5a
28
28 ...

Nice Nayr, I love these 5a, 55 and AD combo's, hehe, seems that the authentication/unlocking is pretty much unchanged. Could you post the complete logs ?

[Nayr]

Nice Nayr, I love these 5a, 55 and AD combo's, hehe, seems that the authentication/unlocking is pretty much unchanged. Could you post the complete logs ?

A little work needs to be done.

[MacDennis]

It is possible to convert from sata to pata and then back from pata to sata.

The 360 appears to use a very similiar unlocking protocol as the xbox1.

This list of packet commands after a disc insertion is probably not entirely correct:

Fantastic news!
Could you mention which adapters you used? Brand? Model? Url?
And yes, those commands ring a bell ..

[Nayr]

http://www.addonics.com/products/io/ide_sata.asp
http://www.addonics.com/products/io/adsaide.asp

However the adapters are meant to plug directly into a drive, so you will have to modify them to work with cables.
There might be other brands that you don't have to solder on.

[Pec]

Ok, finally i got my 360. unfortunately, they got only a sata->ide connector, so thoses tests have to wait a bit. Surprisingly, my 360 has a Toshiba TS-H943 DVD Drive with a MT1359SE Chipset. Furthermore, there's an evil looking sticker on it... With a token "ITM ms**". Whatever..... The Version is: X800473-015, TS-H943A/MCAH Ver. A H/W:004 September 2005. Its an european Xbox, 26-11-2005. They have glued the SST 39SF020, so it'll be very hard to desolder it. Have to try ist tomorrow...

[darkfly]

Picked up a new 360 this afternoon.

Toshiba / Samsung TS-H943 DVD Drive
FW: ms25 (Sticker covering old print "ms22")
Part: X800473-016 (Sticker covering old print "-011")
HW: 005
Ver: A
Manuf: October 2005

Also glue all over the SST, have not attempted to remove.

[Tiros]

The old sammys used MT1329E. Sweet old 8051.
Wonder if the old 605 fw flasher/reader will work on it....

[dmozk]

Benq(Acer) are in a optical drive joint beture with phillips

http://www.benq.com/InfoPage/index.cfm?id=50

[anita999]

Wonderful, Nayr. We're doing almost the same thing. I got my 360 yesterday. And all converters have been waiting for weeks. Unfortunately I couldn't borrow the LA within these days. It might take me another week to get the LA. Btw, what LA are you using now? How do you set it up?

So things are getting close to our initial expectation. Once we have the raw data log, then it will be possible to emulate the process in 360. Now I believe that TheSpecialist will have lots of fun. me, too.

[smo]

I believe the 'code' at $B185 to be part of this routine, BUT there's no code at that location -> this location is part of a block, filled with stringdata "COPYRIGHT ACER PERIPHERALS, INC.  632ACOPYRIGHT ACER PERIPHERALSINC.  632A' etc...

Maybe this part of the code is stored somewhere else than on the flash chip, maybe in the chip's own memory (if it has some.. comparable to Xbox1's "secret code in MCPX, rest in flash" way)? Maybe you could create your own ATAPI command to dump the code as it is in memory (not an easy feat though).

[anita999]

I believe the 'code' at $B185 to be part of this routine, BUT there's no code at that location -> this location is part of a block, filled with stringdata "COPYRIGHT ACER PERIPHERALS, INC.  632ACOPYRIGHT ACER PERIPHERALSINC.  632A' etc... I don't have any idea what this could be, as far as I know there's not even any Acer hardware used in the Philips drive.... Why would Philips put this string into their FW anyway ? Maybe this is part of some 'firmware protection scheme' that was developed by Acer ?

Anyone any ideas on this ?

Maybe the bank switching issue. Are you sure the code at $B185 is in the same bank of the code calls it? The philips controller is a 80C51 core, which has 64K address space only. So memory bank switching is necessary to access code in different bank.

[Stealth]

One of my 360's is a Toshiba Sammy as well though mine part number sticker ends in -015.  Glued SST of course, though the tops of the legs are not glued, so could probably solder on wires to do the flash dump. Unfortunately I have no useful means to do any flash dumping so I can't be the one to test it.  Would be nice to have 8051 code to work on instead of the am33 stuff, if that is what type of processor the M1359SE is.  

[MacDennis]

I believe the 'code' at $B185 to be part of this routine, BUT there's no code at that location -> this location is part of a block, filled with stringdata "COPYRIGHT ACER PERIPHERALS, INC.  632ACOPYRIGHT ACER PERIPHERALSINC.  632A' etc... I don't have any idea what this could be, as far as I know there's not even any Acer hardware used in the Philips drive.... Why would Philips put this string into their FW anyway ? Maybe this is part of some 'firmware protection scheme' that was developed by Acer ?

Anyone any ideas on this ?

Acer has a 632A CD-ROM drive ..

And about address $B185, is this an offset in the firmware file or is this an (internal) memory address? I noticed that memory locations $600 to $BF00 are mapped to the external DRAM.

Not sure ofcourse if it is used but if you look at the CPU datasheet then you will notice that it also has "program upload support" and 1.5kbytes of ROM memory.
http://www.semiconductors.philips.com/acrobat_download/datasheets/SAA7817HL_1.pdf

And about the glue, my Philips XBOX1 drive also has it's PLCC, flash chip glued to the mainboard. Only 2 sides of the chip though. I have been able trace the other pins on the mainboard. Plan to do some logging.