hacking DVD firmware ?

[oz_paulb]

More proof of Flash chip being at 0x90000000:

Code:

   2fde7: fc dc 00 00  mov 0x90000000,a0 ;chip_base is 0x90000000
   2fdeb: 00 90
   2fded: fa d0 55 55  add 0x5555,a0 ;a0 now (chip_base + 0x5555)
   2fdf1: 2c aa 00     mov 0xaa,d0
   2fdf4: f0 50        movbu d0,(a0)  ;write 0xaa to (chip_base + 0x5555) (start of "Product ID entry" sequence)
   2fdf6: fc dd 00 00  mov 0x90000000,a1
   2fdfa: 00 90
   2fdfc: fa d1 aa 2a  add 0x2aaa,a1 ;a1 now (chip_base + 0x2aaa)
   2fe00: 80 55        mov 0x55,d0
   2fe02: f0 51        movbu d0,(a1)  ;write 0x55 to (chip_base + 0x2aaa)
   2fe04: 2c 90 00     mov 0x90,d0
   2fe07: f0 50        movbu d0,(a0)  ;write 0x90 to (chip_base + 0x5555) (end of "Product ID entry" sequence)
   2fe09: cb           nop
   2fe0a: cb           nop
   2fe0b: fc a8 00 00  movbu (0x90000000),d0 ;read manufacturer ID from flash chip
   2fe0f: 00 90
   2fe11: fc 82 20 10  movbu d0,(0x80001020) ;flash manufacturer ID stored here (RAM)
   2fe15: 00 80
   2fe17: fc a8 00 10  movbu (0x90001000),d0 ;hmm... reading device IDs at offset 0x1000 and 0x2000 as well??
   2fe1b: 00 90
   2fe1d: fc 82 24 10  movbu d0,(0x80001024)
   2fe21: 00 80
   2fe23: fc a8 00 20  movbu (0x90002000),d0
   2fe27: 00 90
   2fe29: fc 82 28 10  movbu d0,(0x80001028)
   2fe2d: 00 80
   2fe2f: fc a8 01 00  movbu (0x90000001),d0 ;read device ID from flash chip
   2fe33: 00 90
   2fe35: fc 82 04 10  movbu d0,(0x80001004)
   2fe39: 00 80
   2fe3b: 2c aa 00     mov 0xaa,d0  ;write 0xaa to (chip_base + 0x5555) (start of "Product ID exit" sequence)
   2fe3e: f0 50        movbu d0,(a0)
   2fe40: 80 55        mov 0x55,d0
   2fe42: f0 51        movbu d0,(a1)  ;write 0x55 to (chip_base + 0x2aaa)
   2fe44: 2c f0 00     mov 0xf0,d0
   2fe47: f0 50        movbu d0,(a0)  ;write 0xf0 to (chip_base + 0x5555) (end of "Product ID exit" sequence)
   2fe49: cb           nop
   2fe4a: cb           nop
   2fe4b: f8 fe fc     add -4,sp
   2fe4e: fc ff 47 02  calls 0x30095  ;wait for flash to be ready for reads
   2fe52: 00 00
   2fe54: f8 fe 04     add 4,sp
   2fe57: 85 1f        mov 0x1f,d1  ;1F is Atmel MFG ID
   2fe59: fc a8 20 10  movbu (0x80001020),d0 ;previously stored flash MFG ID stored here
   2fe5d: 00 80
   2fe5f: a4           cmp d1,d0
   2fe60: c9 19        bne 0x2fe79
   2fe62: fc a8 24 10  movbu (0x80001024),d0
   2fe66: 00 80
   2fe68: a4           cmp d1,d0
   2fe69: c9 10        bne 0x2fe79
   2fe6b: fc a8 28 10  movbu (0x80001028),d0
   2fe6f: 00 80
   2fe71: a4           cmp d1,d0
   2fe72: c9 07        bne 0x2fe79
   2fe74: c9 05        bne 0x2fe79
   2fe76: cc 6e 01     jmp 0x2ffe4

The above code is reading the Flash chip's manufacturer/device ID, accessing the chip starting at address 0x90000000.  In addition, it's calling the 'wait until data stops changing' function posted here previously (at offset 0x30095).

The above is just the start of the function to read the flash Identifier.  It also tries some more sequences.  It's very standard-looking Flash 'read identifier' code.

- Paulb

[Pec]

Have no success connecting the sata -> pata >sata adapters so far.   Either the xbox won't boot, or an error E64 occurs.... Hmm, go to sleep now....

[Nayr]

PaulB has convinced me.  I would like to change my vote.  flash at 0x90000000.

[Nayr]

I would also like to point out this link:

http://www.dextrose.com/_forum/showthread.php?s=&threadid=10437

Its about a gamecube hack. 

If you ignore all the BS, they talk about uploading firmware code into ram with debug commands.  Then they overwrite an interupt vector to point to the new code.  Pretty interesting.

[darkfly]

Okay I got my adapters in today. Bummer the Addonics card has a dual SATA data/power plug so you cant plug it directly into the dvd, had to make my own cable.

Shows in BIOS as "TSSTcorpDVD-ROM TS-H953A ms25"

Booted into linux with drive attached, get this on console repeating endlessly.

hdb: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdb: packet command error: error=0x54
ide: failed opcode was 100

ATAPI device hdb:
Error: Illegal request -- (Sense key=0x05)
(vendor specific error) -- (asc=0x81, ascq=0x00)
The failed "Prevent/Allow Medium Removal" packet command was:
"1e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"

If someone has linux running, try to start without the drive attached, run "tail -n1 -f /var/log/messages >> output.txt", then attach the drive and wait some time (it was assumed, that the drive shuts itself down after a period of "not a specific command received", so wait a few minutes) and then detach the drive again. You can hit CTRL+c to stop the above process. A file named output.txt should have been created with the system log, please post that here.
I guess this is the way you get the maximum information from the drive with a pc doing nothing special (IE unlocking or something like that).

If you start without the drive attached it wont be detected by BIOS. Nothing will show in the log apart from normal system messages.

[darkfly]

Just tried the DOS mtkflash utility, not sure if I need to set some specific command line parameters but it reported unknown flash type and the dump is 65536 bytes.

Also just noticed the Mini ITX board im working with has a SST 39SF020A in a PLCC socket, I assume for the BIOS. Perhaps I could do a hot swap and use uniflash.

[darkfly]

Well forgot about the multiple banks earlier, attempted to dump using the mtkflash again.

Reported unknown flash type, ended up with 512KB file, contents seem to be all f0

 

[anita999]

darkfly, seems you may need the hot swap trick, it shall work. But before that, please make sure you can detach the PLCC chip without damaging the PCB first.

[NghtShd]

A slightly offtopic question -> Is there anyway to make this "bank switched" debugging in IDA any easier ? I would love to get IDA to change the conditional jump adresses for a certain section (like adding $10000 to all conditional jump adresses in some bank). Is something like that possible with IDA ?

And another question about IDA : is it possible in IDA to label memory adresses ? For example: $0472 holds the drive's state. When I see in IDA:
mov A, #$0472, I'd like to see:
mov A, *variable name here* instead (for all occurences of this variable).

For x86 if you have something like:

mov     eax, dword_404700

you can click on 'dword_404700' and press 'N' or right-click and choose Rename. But in a case where you have an immediate value I don't know.

[jig]

since there seems to be a difference between via and intel motherboard chipsets, could there be anything usefull gained by hooking it up to a G5 based system running OSX?

if i remember correctly, the early dev stations were dual G5s...

i suppose as long as the bios recognizes something is there, then that's all that's really needed... so maybe nothing spectacular could be achieved. (chalk it up to a poor via implementation of some standard protocol).

[smo]

Booted into linux with drive attached, get this on console repeating endlessly.
hdb: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdb: packet command error: error=0x54
ide: failed opcode was 100

If you get this endlessly and you have a fairly recent distro, it's probably haldaemon probing the disc (just say "service haldaemon stop").

[Geremia]

Just tried the DOS mtkflash utility, not sure if I need to set some specific command line parameters but it reported unknown flash type and the dump is 65536 bytes.

Also just noticed the Mini ITX board im working with has a SST 39SF020A in a PLCC socket, I assume for the BIOS. Perhaps I could do a hot swap and use uniflash.

What mtkflash version did you tried? here are a lot of version, try the most recent http://dhc014.rpc1.org/howto.htm#mtkflash
If you have an intel chipset motherboard, look in the bios setup and  remap the sata controller to something of primary/secondary master/slave, because mtkflash can access only primary and secondary channels.
mtkflash can also work if the drive is not recognized, if you specify where the drive is attached it sends commands anyway.

[Geremia]

Code:

   2fde7: fc dc 00 00  mov 0x90000000,a0 ;chip_base is 0x90000000
   2fdeb: 00 90
   2fded: fa d0 55 55  add 0x5555,a0 ;a0 now (chip_base + 0x5555)
   2fdf1: 2c aa 00     mov 0xaa,d0
   2fdf4: f0 50        movbu d0,(a0)  ;write 0xaa to (chip_base + 0x5555) (start of "Product ID entry" sequence)
   2fdf6: fc dd 00 00  mov 0x90000000,a1
   2fdfa: 00 90
   2fdfc: fa d1 aa 2a  add 0x2aaa,a1 ;a1 now (chip_base + 0x2aaa)
   2fe00: 80 55        mov 0x55,d0
   2fe02: f0 51        movbu d0,(a1)  ;write 0x55 to (chip_base + 0x2aaa)
   2fe04: 2c 90 00     mov 0x90,d0
   2fe07: f0 50        movbu d0,(a0)  ;write 0x90 to (chip_base + 0x5555) (end of "Product ID entry" sequence)

   

Good finding paul_b, this should also prove that probably no data/address pin swapping is done in hardware, right? otherwise there will be no standard flash commands.
Reading manufacturer ID at an higher address...maybe some king of check to see if for mistake the real 0x0 adrress was readed instead of manufacturer ID, to see if the falsh accept write commands

[oz_paulb]

Code:

   2fde7: fc dc 00 00  mov 0x90000000,a0 ;chip_base is 0x90000000
   2fdeb: 00 90
   2fded: fa d0 55 55  add 0x5555,a0 ;a0 now (chip_base + 0x5555)
   2fdf1: 2c aa 00     mov 0xaa,d0
   2fdf4: f0 50        movbu d0,(a0)  ;write 0xaa to (chip_base + 0x5555) (start of "Product ID entry" sequence)
   2fdf6: fc dd 00 00  mov 0x90000000,a1
   2fdfa: 00 90
   2fdfc: fa d1 aa 2a  add 0x2aaa,a1 ;a1 now (chip_base + 0x2aaa)
   2fe00: 80 55        mov 0x55,d0
   2fe02: f0 51        movbu d0,(a1)  ;write 0x55 to (chip_base + 0x2aaa)
   2fe04: 2c 90 00     mov 0x90,d0
   2fe07: f0 50        movbu d0,(a0)  ;write 0x90 to (chip_base + 0x5555) (end of "Product ID entry" sequence)

   

Good finding paul_b, this should also prove that probably no data/address pin swapping is done in hardware, right? otherwise there will be no standard flash commands.
Reading manufacturer ID at an higher address...maybe some king of check to see if for mistake the real 0x0 adrress was readed instead of manufacturer ID, to see if the falsh accept write commands

Very good point about the address/data lines not being swapped in hardware (because the standard flash addresses/commands used in the above function are 'normal' ones).  But, that doesn't make sense to me: we know that the data stored in flash has the bits swapped around in every 32-bit dword (people have de-soldered their flash chips/dumped them directly).

Maybe 8-bit accesses to the flash region are un-swapped, but 32-bit accesses get swapped?

I'm just waking up after little sleep - so maybe I'm not thinking this through enough.  After some coffee, I'll think about it some more/re-read the flash code to see if it makes more sense (I've also identified some other flash code in the image - I'll look at it too).

- Paulb

[MacDennis]

Very good point about the address/data lines not being swapped in hardware (because the standard flash addresses/commands used in the above function are 'normal' ones).  But, that doesn't make sense to me: we know that the data stored in flash has the bits swapped around in every 32-bit dword (people have de-soldered their flash chips/dumped them directly).

Maybe 8-bit accesses to the flash region are un-swapped, but 32-bit accesses get swapped?

See the following thread:
http://forums.xbox-scene.com/index.php?showtopic=325005&st=690

To my knowledge the firmware is scrambled... after decryption you have a plain image and you can correctly disassemble it using (for example) objdump from Linux or any other mn103 disassembler...

The dld file is composed by an header a scrambled rom image and plain flashing code.

Again, a theory ..
The firmware consists of various parts / sections. A header, vendor specifc header, vendor specifc image, standard flashing code, standard routines etc etc. Some are scrambled, some are not. In theory, each part could use a different XOR / bitswapping routine. Compare it to a filesystem. Firmware images which are (partly) scrambled are common for normal DVD-ROM players as you might already know. The flashing code receives a firmware image from the host which *already* contains scrambled parts. It simply writes the data 1:1 to the flash, no need for scrambling / descrambling at this stage.

Ofcourse the CPU won't be able to run the scrambled part this way. This is why the boot ROM *or* the firmware should contain (not scrambled) code which does the descrambling and places the descrambled part in RAM and run it from there. If this code in RAM detects a firmware flashing command from the host the it simply calls the standard (not scrambled) flashing code in the flash rom and returns when it's ready. Note that the flashing code can also be run from RAM if absolute addressing is used to write to the flash memory, which it seems to do judging from the previous posts.

Anyone with a LA and a 8163B DVD-ROM can verify if the flashing code is run from RAM or flash memory. Update the firmware and log all access to the firmware at the same time. I would have done this if I had the time, unfortunately still busy with the Philips XBOX1 drive.  My vote is for RAM with a base address of 0x80000000.

I believe that different revisions of the MN103S CPU which is being used as a DVD controller use different XOR values and/or bitswapping routines in it's internal boot ROM to handle vendor specific flash images. As a reminder, see this post by Geremia: http://www.xboxhacker.net/forums/index.php?topic=76.msg868#msg868

[oz_paulb]

I've done a bit more analysis of the flash programming code in the image (I believe I'm looking at a decoded "GDR-3120L_0047DH.BIN" right now - I'm not 100% sure).

There are two basic 'chunks' of flash code.  One from 0x9002f8b7 to 0x9002fd27, the other from 0x9002fd29 to 0x900300f5.

The first 'chunk' represents all of the code necessary to erase a flash sector.  This code is NOT executed directly from the flash chip (since, while programming/erasing flash, you can't do opcode fetches from the chip).  The code at 0x9002f46f-0x9002f4c9 copies this 'chunk' of flash code to RAM (starting at 0x80000000), then calls the code at 0x80000000.

The second 'chunk' of flash code represents the code necessary to program a byte (or bytes) of flash.  Again, this chunk of code isn't executed directly from flash.  The code at 0x9002f4cc-0x9002f535 copies this chunk of code to RAM (at 0x80000000) and calls the code there.

Each of these chunks of code that gets copied to RAM starts/ends with similar sequences.  For example, the first chunk starts out like:

Code:

9002f8b7: cf 08        movm [other],(sp)
9002f8b9: cf 20        movm [a2],(sp)
9002f8bb: f8 fe fc     add 0xfffffffc,sp
9002f8be: fc ff 29 04  calls 0x9002fce7
9002f8c2: 00 00
9002f8c4: f8 fe 04     add 0x4,sp
9002f8c7: 34 a8 d9     movbu (0xd9a8),d0
9002f8ca: 85 01        mov 0x1,d1
9002f8cc: f2 14        or d1,d0
9002f8ce: 02 a8 d9     movbu d0,(0xd9a8)

The sequence above calls a function at 0x9002fce7 (see that func below), then "or's" a bit (D0) into what appears to be a hardware register.  Here's the function that gets called from above:

Code:

9002fce7: 34 04 d9     movbu (0xd904),d0
9002fcea: f8 e0 80     and 0x80,d0
9002fced: c9 fa        bne 0x9002fce7
9002fcef: cb           nop
9002fcf0: cb           nop
9002fcf1: 80 01        mov 0x1,d0
9002fcf3: 02 00 df     movbu d0,(0xdf00)
9002fcf6: cb           nop
9002fcf7: cb           nop
9002fcf8: 80 00        mov 0x0,d0
9002fcfa: 02 01 df     movbu d0,(0xdf01)
9002fcfd: cb           nop
9002fcfe: cb           nop
9002fcff: 2c 9a 00     mov 0x9a,d0
9002fd02: 02 28 df     movbu d0,(0xdf28)
9002fd05: f0 fc        rets

The above function seems to wait until a bit (in a hardware register?) goes to zero, then writes to three more hardware registers.


Similar code is seen at the end of the 'chunk' of flash code:

Code:

9002f92d: 34 a8 d9     movbu (0xd9a8),d0
9002f930: 2d fe 00     mov 0xfe,d1
9002f933: f2 04        and d1,d0
9002f935: 02 a8 d9     movbu d0,(0xd9a8)
9002f938: f8 fe fc     add 0xfffffffc,sp
9002f93b: fc ff cc 03  calls 0x9002fd07
9002f93f: 00 00
9002f941: f8 fe 04     add 0x4,sp
9002f944: ce 20        movm (sp),[a2]
9002f946: ce 08        movm (sp),[other]
9002f948: f0 fc        rets

This time, it clears the same D0 bit in the same hardware register that was set at start, and calls another function that looks similar to what was called at the start of the 'chunk' (except that it does different register writes):

Code:

9002fd07: 34 04 d9     movbu (0xd904),d0
9002fd0a: f8 e0 80     and 0x80,d0
9002fd0d: c9 fa        bne 0x9002fd07
9002fd0f: cb           nop
9002fd10: cb           nop
9002fd11: 80 00        mov 0x0,d0
9002fd13: 02 00 df     movbu d0,(0xdf00)
9002fd16: cb           nop
9002fd17: cb           nop
9002fd18: 80 00        mov 0x0,d0
9002fd1a: 02 01 df     movbu d0,(0xdf01)
9002fd1d: cb           nop
9002fd1e: cb           nop
9002fd1f: 2c 9a 00     mov 0x9a,d0
9002fd22: 02 28 df     movbu d0,(0xdf28)
9002fd25: f0 fc        rets

I suspect that the 'entry sequence' to these flash functions temporarily disables address-line remapping, and that the 'exit sequence' re-enables the mapping.  This allows the standard flash functions to just work without worrying about bit-swapping.

I've looked at several places which call these 'erase sector' and 'byte program' functions.  So far, they all look like they are related to things like DVD region setting.  They operate on data at offset 0x4f00 and 0x4f80 in the flash image (which I had previously suspected contained the drive/Xbox serial numbers).  I haven't looked closely enough at the code - maybe these regions contain both the "DVD region" info and the drive/Xbox serial numbers.  I'll study it more later and see if I can figure that out.

Of course, I could be way-off here - feel free to correct me in any of my assumptions/guesses.

- Paulb

[anita999]

Sorry for an offline question. When I use objdump, the output result isn't in hex format when it interprets a immediate value. But the disasm from Paulb's post can do it. example:
 
Paulb's result:

2fded: fa d0 55 55  add 0x5555,a0 ;a0 now (chip_base + 0x5555)

My result:
2fded:   fa d0 55 55    add   21845,a0

I know there must be a option switch controls this. But I couldn't find it. I am using  a recompiled version for win32. Can anyone help me out here?

[Takires]

The flashing routines can reprogram devices from 5 different vendors. The manufacturer IDs are
1F, 37, 92, BF (this is SST) and CF. Someone might look up which manufacturer belong to the
other four.

WRITE BUFFER reads 90004000-90004003, 90004F00-90004F0F and 90004F80-90004FFF,
writes the data in the last chunk and is scrambling the data before it starts to reprogram
that sector of the flash.

And I came to the same conclusion like Paulb about the hardware registers. One of them will
change the WE# line and the other one will turn off the descrambling.

[oz_paulb]

Sorry for an offline question. When I use objdump, the output result isn't in hex format when it interprets a immediate value. But the disasm from Paulb's post can do it. example:
 
Paulb's result:

2fded: fa d0 55 55  add 0x5555,a0 ;a0 now (chip_base + 0x5555)

My result:
2fded:   fa d0 55 55    add   21845,a0

I know there must be a option switch controls this. But I couldn't find it. I am using  a recompiled version for win32. Can anyone help me out here?

I couldn't find an option to control this.  I have the source, and modified it/re-built for Linux (sorry, I can't seem to get a win32 build to compile - I use 'mingw' for my Unix-like environment under Windows).

If you have the source/can re-build, the file to change (in 'binutils') is "opcodes/m10300-dis.c".  Look for the fprintf_func call with "%ld" (near the end of the file), and change it to use "0x%lx".

- Paulb

[DaveX]

If you have the source/can re-build, the file to change (in 'binutils') is "opcodes/m10300-dis.c".  Look for the fprintf_func call with "%ld" (near the end of the file), and change it to use "0x%lx".

For those lazy as I am, just patch the objdump.exe that was given in this thread at offset 21F60 from "4C 3B" to "9F 09".
That will do the trick