Print

[Dsights]

This is a summary of my (largely unedited) notes aKlick Go there for full details

Edit (3rd April 2006): Contrary to seemingly popular belief, this page is *not*, and was never intended to be, a walk-through guide on hacking the Hitachi-LG DVD firmware to run your backup or pirated games. This page is exactly what I said in the paragraph above this one, a summary of my own findings. I made this page so that genuine hackers didn't need to read through a lot of unnecessary details to utilise the information in my notes. I did *not* write this page to provide an easy way for pirates to steal games. I was *not* involved in the firmware hack. The tools and information on this site are *not* directly applicable to the firmware hack. If you follow this page like a step by step tutorial then you will achieve *nothing* useful beyond backing up your firmware and AES key. Kindly stop emailing me about this.

Use at your own risk, this may break your 360, 360 DVD drive and/or PC if done improperly (or if I happen to have made mistakes).

Connecting the 360 drive to a PC
Getting the Hitachi-LG drive detected under Linux and Windows
Dumping the Hitachi-LG firmware from a PC
Dumping the 'forbidden RAM ranges' 0x8002EC00-0x80037300 and 0x8003A000-0x8003A300
Dumping the drive's unique encryption key from a PC
Writing to anywhere in the Hitach-LG drive's memory space from a PC
Forcing the Hitachi-LG drive to execute arbitrary code from a PC (updated 7th April 2006: I've written a much faster version of execcode)
Flashing sectors in the Hitachi-LG drive's firmware from a PC (updated 10th April 2006: NEW)




--------------------------------------------------------------------------------


Connecting the 360 drive to a PC

There are two ways to power your drive when connecting it to a PC

1) From the 360
2) From your PC power supply or external 12V mains adapter


Option 1 is easier in the short term but it's not as safe as option 2 and it gets annoying after a while. For option1 do this

1) Connect your DVD drive to your 360 using the 12 pin DVD power cable supplied with your 360.
2) Connect your DVD drive to your PC using a standard SATA cable.
3) Connect the chassis of your PC to the chassis of your 360 with a couple of croc clips
4) Turn on the 360.
5) Turn on the PC.


Step 3 isn't strictly necessary in this case, but it's a very good habit to get into.

option 2 is more difficult in the short term but is safer than option 1 and you don't have to keep powering the 360 up and down to use the drive. The following circuit will power the 360 drive from your PC power supply.

(IMG:http://www.kev.nu/360/images/dvdadap2.gif)
(IMG:http://www.kev.nu/360/images/dvdpin.gif)
It could possibly be useful to mess with the drive's state on a PC and then boot the drive in the 360 without powering the drive down and losing the state. To power the drive from a +12V (or more) external mains adapter requires an additional voltage regulator (7805) to generate the +5V supply.

Note: everything from this point on applies only to the Hitachi-LG drive, not the Toshiba-Samsung.

Getting the Hitachi-LG drive detected under Linux and Windows

This depends on how you connect the SATA signal cable to your PC. The 3 main ways are

1) PATA - SATA bridge board
2) PCI SATA adapter card
3) Native SATA controller


There is one method that I have tested on all three and so I know definitely works. Unfortunately it requires soldering and desoldering. Do this

1) Remove the case from the drive (6 screws)
2) Locate resistor R214. It's in a cluster of 6 resistors between the SATA signal connector and the MN103 MCU (the big 4 sided chip with a million pins)
3) Remove resistor R214.
4) On the DVD power cable, cut the tray_status wire. If you hold the drive horizontally with the top pointing towards the ceiling and look at the power connector on the back of the drive, then tray_status is the 2nd pin from the left on the bottom row of pins.
5) If you are powering the drive from a 360, then connect the 360's end of the tray_status wire to +3.3V (you can get +3.3V at the 3rd pin from the left on the bottom row).
6) Solder one end of a 10K resistor onto the drive's end of the tray_status wire.
7) Solder the other end of the resistor to a switch between +3.3V and GND (you can get +3.3V at the 3rd pin from the left on the bottom row. GND is available on any of the 4 right most pins on the top row)
Before powering up the drive select +3.3V for normal drive operation or select GND for a debug mode (modeB) that will allow the drive to be detected in Windows, Linux and I imagine any other OS.

Note: If powering from a 360, the eject button will behave a little strangely (probably requiring 2 presses to open/close the tray), but other than that it should work.


Another method that I suspect will work for any type of SATA connection is a firmware patch. I have not tested this, but I know of at least one hacker who has had it working with native SATA. I strongly suspect it will work with PATA - SATA and PCI SATA too. Obviously this requires that you are able to reprogram your drive's flash chip. You need to patch the following code within the Inquiry command handler.

ROM:00024F6D                 movbu   (word_5BD), D0   ; D0 = packet[5]
ROM:00024F70                 mov     0xC0, D1 ! '+'
ROM:00024F73                 and     D1, D0           ; clear all bits except for (vendor-specific) bits 6 and 7
ROM:00024F75                 cmp     D1, D0           ; are both bits set?
ROM:00024F76                 beq     loc_24F80        ; yes, so continue
ROM:00024F78                 mov     0xD, D0          : no, so fail

I'd patch the conditional "beq loc_24F80" instruction at offset 0x24F76 with an unconditional "bra loc_24F80" instruction. These offsets are taken from the 0047 revision firmware, these may differ in the 0046 code but the priciple is identical.

If these two aren't an option for you, then the following options are available. You'll have much more of a chance using a PATA - SATA board.

1) If you're using a PATA - SATA board, then I found that simply ejecting and closing the tray during boot was enough to get Linux to detect the drive.
2) If you're using a PATA - SATA board or have a legacy mode on your Native/PCI SATA controller, then you can use the following program to initiate the same debug mode (modeB) that I mentioned above. This should get it detected in Windows after a restart (make sure the drive doesn't power down) or maybe running a "Find new hardware" instead of a restart (untested).


download source
download binary


3) If your drive is detected in Linux but not windows, then you can boot into Linux and run the following program. Then reboot the PC into Windows (make sure the drive doesn't power down). Windows should then pick it up.

modeb.c


4) Linux users should keep an eye on Protobus excellent efforts with the drive in Linux.


Windows users, during some of my tests with native SATA I sometimes found that windows (XP in my case) would detect the drive and it would appear in device manager, but no drive letter would be assigned. To assign one I had to do "device manager > DVD/CDROM drives > right click on HL-DT-ST DVD-ROM GDR3120L SCSI CdRom Device > Properties > Volumes tab > Populate > OK" (screen shot).

Dumping the Hitachi-LG firmware from a PC

There is a Hitachi debug command that allows you to dump memory from the drive. There are security measures in place to prevent the software dumping of the firmware but these measures are a complete failure (see my full notes for info). The following program will dump your firmware.

memdump.c - hex memdump source for Linux
memdump_win.zip - hex memdump binary for Win2000/XP
memdump_win_src.zip - hex memdump source for Win2000/XP

Linux example:
$ ./memdump /dev/hdc 12200 8 8000 ./firmware.bin

Windows example:
C:\> memdump_win e 12200 8 8000 firmware.bin

Simple as that.

Dumping the 'forbidden RAM ranges' 0x8002EC00-0x80037300 and 0x8003A000-0x8003A300

It turns out that these ranges contain very interesting information (IMG:style_emoticons/default/smile.gif) Again, the security measures to prevent software dumping of these ranges were a total failure. Use the following commnds to dump the entire contents of RAM, the 'forbidden' regions are at offsets 0x2EC00-0x37300 and 0x3A000-0x3A300 in the final dump.

Linux example:
$ ./memdump /dev/hdc 10200 8 8000 ./ram.bin

Windows example:
C:\> memdump_win e 10200 8 8000 ram.bin

Dumping the drive's unique encryption key from a PC

This key is used to de/encrypt some of the ATAPI transfer during disc authentication.

Linux example:
$ ./memdump /dev/hdc 91004F0 1 10 ./key.bin

Windows example:
C:\> memdump_win e 91004F0 1 10 key.bin

Writing to anywhere in the Hitach-LG drive's memory space from a PC

A combination of Mode Select(10) and Hitachi debug commands allows you to write to anywhere in the drive's address space. The following program allows you to peek/poke single bytes. The same principle can be applied to any amount of data, not just single bytes (see my full notes for info)

pp.c - peek/poke source for Linux
pp_win.zip - peek/poke binary for Win2000/XP
pp_win_src.zip - peek/poke source for Win2000/XP


Linux examples:
$ ./pp /dev/hdc 40000000 peek
$ ./pp /dev/hdc D98D poke 30

Windows examples:
C:\> pp_win e ABF peek
C:\> pp_win e 804A4B4C poke F2

Forcing the Hitachi-LG drive to execute arbitrary code from a PC

Update 7th April 2006: New version of execcode. This version uploads the code using a new bulk upload procedure obtained by reverse engineering an offical LG flasher .exe for a very similar drive (see full notes for technical details). It's much, much faster. It also allows you to execute code with a disc in the drive, which the old one didn't (see this xbh.net thread for details)

execcode2.c - new execcode source for Linux
execcode2_win.zip - new execcode binary for Win2000/XP
execcode2_win_src.zip - new execcode source for Win2000/XP

I'm leaving the old versions up, just in case. Note: This version can take a while to upload the a lot of code.

execcode.c - old execcode source for Linux
execcode_win.zip - old execcode binary for Win2000/XP
execcode_win_src.zip - old execcode source for Win2000/XP

Linux examples:
$ ./execcode /dev/hdc ./code.bin

Windows examples:
C:\> execcode_win e code.bin

Flashing sectors in the Hitachi-LG drive's firmware from a PC

This app will flash single sectors in the Hitachi-LG firmware using flash erase/program routines that exist in the 3120L firmware.

Warning: This app is an interim solution intended *only* for hackers who know what they are doing. It is very easy to kill your drive with this program. I wrote it and I still knackered my drive to the point where I needed to physically remove the flash and reprogram it using a hardware programmer. If you fail to update the firmware checksum before you power down the drive, you *will* break your drive. If you overwrite any of the upload and execution command handlers with broken code, you *will* break your drive. If you overwrite your flash entry point code, you *will* break your drive. If you overwrite the sector containing your AES key without backing up your key first, you *will* break your drive and will not be able to rapair it for a very long time (possibly never). If you do not understand *everything* that I just said, then this app isn't for you. Wait for a safer more user friendly one (I'm working on a proper flasher, I know others are too, it shouldn't be too long).

I'm also working on a flasher that will work in the Hitachi-LG's recover mode. So if you do brick your drive, don't panic. unless of course you killed your recovery code or AES key, then you can panic.

flashsec.c - flashsec source for Linux
flashsec_win.zip - flashsec binary for Win2000/XP
flashsec_win_src.zip - flashsec source for Win2000/XP

In the following examples encrypted_fw.bin is a *full* firmware dump. It *must* be encrypted. Encrypt it after you make your changes and before you run the flasher. You can use Loser's FirmCrypt app to de/encrypt firmware images. So, encrypted_fw.bin would be created like so (in Windows),

C:\> memdump_win e 12200 8 8000 firmware.bin
(then modify your target sector within firmware.bin)
C:\> FirmCrypt e firmware.bin encrypted_fw.bin
(then flash the modified sector as per the examples below)

You will almost certainly break your drive if you do not encrypt the firmware image before flashing.

The next argument is the address of the target sector in the MN103's address space in hexadecimal. Just add 0x90000000 to the sector's offset into the firmware dump to get this value. The final argument is the sector size. The 3120L erase/program routines support a few devices, some appear to have 8KB sectors (0x2000 bytes), others 4KB sectors (0x1000 bytes). My drive has a SST39SF020A flash device (with 4KB sectors). I'm not sure if any Hitachi-LG drives exist with a different chip, but my app supports them just in case. Make sure you specifiy the sector size in hexadecimal.

Please. Don't use this app if you don't understand all of the above.

Linux examples:
$ ./flashsec /dev/hdc ./encrypted_fw.bin 9003F000 1000

Windows examples:
C:\> flashsec_win e encrypted_fw.bin 9003F000 1000

Note that the drive does not restart after each sector flash, nor does it need to be restarted. So you can change multiple sectors in one sitting. For example, a typical session might look like this (in Windows)

C:\> flashsec_win e encrypted_fw.bin 90006000 1000
done
C:\> flashsec_win e encrypted_fw.bin 90010000 1000
done
C:\> flashsec_win e encrypted_fw.bin 90027000 1000
done
C:\> flashsec_win e encrypted_fw.bin 9003E000 1000
done

This example shows 3 sector changes followed by a final sector change to update the firmware with a new correct checksum value. This final checksum update flash *must* always be performed unless you actually want the checksum to fail the next time your drive powers up (which will leave you stranded in recovery mode, not a great place to be).

This post has been edited by Dsights: Apr 15 2006, 01:24 PM