Getting XBOX drives to work in windows

[SeventhSon]

Hey guys, love your work so far.

I accidentally stumbled on a way to use the Hitachi-LG drive in Linux/Windows without using any form of SATA swap trick.

For the past week or so I have been trying to gain a complete understanding of the situation before posting, but I will not have much time to work on it for a few weeks, so I'm posting what I have now.

I haven't been following any of the "hacking DVD firmware" spin off theads and I see that you guys have already discovered most of what I have, I imagine the only interesting thing for you guys will be the using the drive in linux/windows without a swap trick part.

http://www.kev.nu/360/dvd.html

Anyway hope it helps. If somebody could confirm that it works for drives besides mine it would be nice :-)

-Kev

[Tiros]

Read your link, I too had some problem with this.
I think the solution is a little simpler than what you describe.
I used no circuit, it is only important to tie eject low for power up, I use a jumper. When the jumper is removed (float) the drawer opens, replace it (ground) and it closes and init's the disk. The other pin requires no connection.
Leaving eject floating during power up causes the drive to get confused, grounding it at that point will cause the drawer to open with no way to close it. Also the disk will not spin up, and commands are ignored.
My drive works fine in windows, once I grounded this pin at power up!

Edit:
I use PATA to SATA too, it seems like peeps using that adaptor have better luck than native SATA.

[SeventhSon]

I think the solution is a little simpler than what you describe.

Indeed! I'm glad that I posted this stuff to the hacker community before investing any more time in my own theory.

Live and learn.

[MacDennis]

I think the solution is a little simpler than what you describe.

Indeed! I'm glad that I posted this stuff to the hacker community before investing any more time in my own theory.

Live and learn.

Just wanted to say, very very nice analysis Seventhson. The information about getting the drive to work in Windows was new to me and as far as I know not published before.

In your document you ask what's so special about the 0x8002EC00 - 0x80037300 range. Well, it seems to hold the raw (security) sectors FD0210 - FD021F including the headers. You can check this by dumping the range. The sector header will hold the sector number amongst other things.

Keep up the good work!

[SeventhSon]

I think the solution is a little simpler than what you describe.

Indeed! I'm glad that I posted this stuff to the hacker community before investing any more time in my own theory.

Live and learn.

At the time I posted the above comment I had forgotten that I had removed the pull up resistor that holds tray_status high. So when I tied eject to ground and the drive was immediately visible in windows I assumed that I had reproduced Tiros' results. Now that I have replaced the pull up resistor (restoring the drive to it's out-of-the-box state), things aren't so simple.

My drive works fine in windows, once I grounded this pin at power up!

I can't get this grounded eject technique to work. I'm probably doing something wrong. Are you simply connecting eject to GND, powering up the drive, turning on the PC and then leaving eject grounded as windows loads? Or is there more to it than that?

Edit:
I use PATA to SATA too, it seems like peeps using that adaptor have better luck than native SATA.

Using the 'modeB' technique (pulling tray_status low during boot) that I posted about yesterday, I managed to get the drive working in an XP machine using native SATA. Native SATA required an extra step. Once windows had booted I had to go through "device manager > DVD/CDROM drives > right click on HL-DT-ST DVD-ROM GDR3120L SCSI CdRom Device > Properties > Volumes tab > Populate > OK". Perhaps anyone having problems with native SATA using the SATA swap trick or Tiros' grounded eject technique should try this (if you haven't already).

More details (not a lot) for anyone who is interested in an update to the page I linked yesterday.

In your document you ask what's so special about the 0x8002EC00 - 0x80037300 range. Well, it seems to hold the raw (security) sectors FD0210 - FD021F including the headers. You can check this by dumping the range. The sector header will hold the sector number amongst other things.

Thanks for the kind words and the heads up. I'm still playing catch up with the progress that has been made since the DVD firmware thread was shut down. Very interesting stuff.

Edit: If anybody can confirm/deny that it works with their drive, then please post and let me know. Although it's not the easiest thing in the world to test. Can anybody think of a safe way to pull tray_status low without removing resistor R214?

[G0t m4xx 21]

I made an adapter to power the drive from my PC, and, unless I'm doing something wrong, the grounding of the tray state during powerup does not seem to work for the TS-H943. I have done everything in my power and it refuses to show up in the device manager (I'm using a SATA PCI card, it works fine with the X360 hard drive). Unfortunately I dont have access to a HL3120 to test.

[SeventhSon]

I made an adapter to power the drive from my PC, and, unless I'm doing something wrong, the grounding of the tray state during powerup does not seem to work for the TS-H943. I have done everything in my power and it refuses to show up in the device manager (I'm using a SATA PCI card, it works fine with the X360 hard drive). Unfortunately I dont have access to a HL3120 to test.

Thanks. The fact that it doesn't work on the TS-H943 suggests that it's not something the 360 ever makes use of.

In case anybody is thinking of trying it and doesn't care to trawl through my endless, incoherent notes, I'll repeat an important warning here.

The tray_status line is a driven output most of the time (all of the time, if I am wrong about the HL3120 release at power up). It shouldn't ever be shorted directly to GND. Shorting a driven output to GND can damage the microcontroller.

The safest way to induce modeB is to remove R214 and replace it with another 10K resistor to GND instead of +3.3V. But obviously poking about inside the drive with a soldering iron brings its own set of risks. One way that requires no soldering would be use a potential divider. This is how I stumbled across modeB in the first place. I used a 1.8K resistor as a transistor base resistor, this formed a potential divider with the 10K R214 which, when the base-emitter voltage drop is taken into account, held tray_status at ((1800 * 2.7) / (10000 + 1800)) + 0.6 ~= 1V. Without the transistor (just a 1.8K resistor between tray_status and GND) you'd be looking at holding tray_status at approx. 0.5V which will easily register as a logic zero. The 1.8K will allow approx. 2mA of current to flow when the tray_status is driven high. I've no idea what current the MN103 can take, 2mA is probably okay. You can replace the 1.8K resistor with a bigger resistor which will reduce the current, but it will increase the tray_status voltage when it is released (which may make it logic 1).

It's just not all that easy to do safetly. If you just want your drive to work in Windows then I'd advise the swap trick or Tiros' method of grounding eject at power up (eject is an input, you can short it to whatever you like :-). If you just want to send ATAPI commands to the drive or dump the Internal ROM/RAM/encryption key/firmware, then you don't even need windows to detect it. If, like me, you're curious about modeB or have had no luck with the above techniques, then give the potential divider a try. It shouldbe noted I'm not an electronics guru, and I've no formal education in electonics. Don't trust me blindly!

[Tiros]

It does work on the TS 943.
Reread my post, all you need is eject low on power up, no connection to the other pin.
Try this:
1) Not hooked up to 360 at all, power up with eject jumpered to ground.
2) Remove the jumper
3) Drawer pops out, so put something in.
4) Replace the jumper.
5) Drawer goes in, you will hear the disk spin up.

I recommend powering everything with the PC.
Try read10 instead of read12.
For inquiry "12 0 0 0 b4 c0".

[G0t m4xx 21]

Yes I tried that but it still won't show up in the windoze device manager (XP Pro, sp2). The drive behaves as you described, and it spins up and reads the disk, and that's it. Its like windoze doesnt even know its there.

Yet if I plug my 360's hdd into the same sata port, it gets recognized immediately.

I'm going to tinker with it some later tonight.

[G0t m4xx 21]

Hmm it seems i broke the drive

Should've known tinkering with the tray status pin would do me in eventually.

The pin is now completely unresponsive, it always sits at about 70mv, whether the tray is open or closed. The drive acts really weird in the 360, it ejects itself when powered on, then if you push the eject button on the 360 to close it, the tray closes for a few seconds, then pops back out. Pushing the power button makes the 360 close the drive, then it opens it again, then powers off (with the drive open).

It seems i managed to blow the tray status logic in the TS-H943.

However, after some tinkering, I got the drive working again.

Since the eject function still worked fine when powered by the PC, I figured the funnyness was in the 360 itself, getting confused by the lack of the tray state pin. So, all I had to do was fudge it.

After some tinkering, I discovered that if the tray state pin is pulled high all the time (just tied to 3.3v through a 10k resistor), the 360 thinks the drive is closed all the time, and all is well. In the TS-H943, the tray status pin takes an odd journey to the microcontroller, I couldn't trace it exactly or locate the pullup resistor, so I jsut broke the trace near the dvd power plug (there's a 0 ohm jumper there, just remove it), and soldered in a 10k resistor to +3.3v (there's an 8 pin voltage regulator near the power plug, it takes 5v in, and outputs 2.5v and 3.3v). Datasheet:

www.cheertech.com.tw/RichTek%20CD/Data%20sheet/DS9184A-02P.pdf

Everything seems to work fine, the drive opens and closes normally now, except the tray will not close automatically if the system powers down when the tray is open.

[SeventhSon]

Try read10 instead of read12.
For inquiry "12 0 0 0 b4 c0".

Thanks Tiros. Both of those things work a treat. Although I'm not so much interested in getting the commands to work, as I am interested in *why* the standard Inquiry and READ(12) commands work in the Hitachi if you pull tray_status low at start up, but fail or require vendor specific bits under normal operation (tray_status tied high).

I think I'm getting pretty close to satisfying this interest at last (gratuitous details available to anybody who cares for them). If I'm right (a big if, granted) and if there's some way to write to low memory in software, then a software solution for getting the hitachi working in windows should be possible (edit: this also assumes that the non-standard Inquiry command is the reason windows chokes on the hitachi drive, which I think it is). Not achievement of the century by any means, but it might be useful to someone. And if not, it will still have been enjoyable to develop

[SuperMario]

SeventhSon:

Something for you... 

You might want to look further into Vendor command "HIT", Subcommand 0xD0, Parameter 0x01 will set your ModeA/B bit for you.


ROM:90025FA7                      Vendor_HIT_0x30_Sub_0xd0:               ! CODE XREF: Vendor_HIT_0x30_Proc_Subcmds+C1j

ROM:90025FA7 34 C0 05                            movbu   (0x5C0), D0
ROM:90025FAA A0 01                                cmp     1, D0
ROM:90025FAC C9 48                                 bne     loc_90025FF4
ROM:90025FAE 34 98 05                            movbu   (0x598), D0
ROM:90025FB1 85 64                                 mov     0x64, D1
ROM:90025FB3 F8 E4 40                             or      0x40, D0        ! SET bit#6 0x598
ROM:90025FB6 F8 E4 10                             or      0x10, D0
ROM:90025FB9 02 98 05                             movbu   D0, (0x598)
ROM:90025FBC 00                                      clr     D0
ROM:90025FBD FC 82 D8 E6 03 80               movbu   D0, (0x8003E6D8)
ROM:90025FC3 80 01                                 mov     1, D0
ROM:90025FC5 CD EE 8E E0 10                   call    sub_9001EEB3, [D2,D3,A2], 0x10
ROM:90025FCA CA 2A                                bra     loc_90025FF4

To me, it does look surprising like some kind of authenticated state flag, too!

SuperMario.

[Slack3er]

I'm trying to dump my 360 dvd drives memory(H/LG GDR-3120L 0046DH), but having some problems. I picked up a PCI to Sata Controller, it has a Sillicon Image 3112 Bios(4.2.47). The card detects my Samsung 360 drive fine & I can used xplorer360 to view the files.

There doesn't seem to be any bios options, only setting up raid. It says to make bootable set mobo to scsi. Booting with my 360 connected , the sil bios doesn't seem to detect the dvd drive(It does show the samsung), just boots normally. When I enable scsi and use a bootable linux cd, it just hangs at booting from cdrom. Then after five minutes it shows please insert boot disk. 

So has anyone have any luck dumping there drives memory with a pci to sata, under plscsi. Also I understand you don't need the drive to be detected under your os to dump your memory. Do you need it detected by your sata bios just to dump. Also what would you set plscsi to with a pci to sata  controller. Ex. set plscsi=??

Image: http://www.soft3.net/hardware_images/sii3112.jpg

Regards;

[SeventhSon]

I'm trying to dump my 360 dvd drives memory(H/LG GDR-3120L 0046DH), but having some problems. I picked up a PCI to Sata Controller, it has a Sillicon Image 3112 Bios(4.2.47).

So has anyone have any luck dumping there drives memory with a pci to sata, under plscsi.

Yes (edit: actually I'm lying, not with plscsi, with a program that I wrote myself that used the OS driver once the drive was detected by both the PCI SATA adapter bios and the OS), but it required a hardware mod to the drive (or at least the power cable). I have an adaptec PCI SATA card also with a SiI bios (I forget the version). I had the same problem. I'm guessing that our SiI bios will not pick up a DVD device that doesn't respond to a standard ATAPI Inquiry command. As I mentioned in some of my posts above, the Hitachi can be put into a state in which, among other things, it will respond to a standard Inquiry command. This can be achieved by holding tray_status low during drive start up (see red warning text above). It can also be achieved in software using the command that SuperMario discovered (a few posts above this), but I can't think of a single (feasable) way to send a command to the drive if the PCI card doesn't detect it.

Also I understand you don't need the drive to be detected under your os to dump your memory. Do you need it detected by your sata bios just to dump.

Yes. I think you do need the adapter bios to detect it. It is conceivable that you could bypass your OS and communicate directly with your PCI card to control the drive (I did this with the PATA controller in my PC with the 360 drive connected via a PATA - SATA adapter, but that is far far simpler), I imagine it would be far more trouble than it's worth I think that if your OS (or your SATA controller bios and therefore your OS) doesn't pick up the drive, then the only option is to go to the hardware directly.

[Slack3er]

Thanks SeventhSon, really helpful. BTW, great work with your website, really enjoyed reading it.

Red text is noted and understood, lol. I think I'll try a different safer method, I have some friends with native sata or I'll get that pata to sata. That pci card was from ebay, and it works with my 360 hard drive so I'm happy.

Regards;
Slack3er

Edit: BTW, theres a fork of the plscsi project called fPLScsi, if anyone is interested.
http://nil.rpc1.org/

[BiMP]

It's just not all that easy to do safetly. If you just want your drive to work in Windows then I'd advise the swap trick or Tiros' method of grounding eject at power up (eject is an input, you can short it to whatever you like :-). If you just want to send ATAPI commands to the drive or dump the Internal ROM/RAM/encryption key/firmware, then you don't even need windows to detect it. If, like me, you're curious about modeB or have had no luck with the above techniques, then give the potential divider a try. It shouldbe noted I'm not an electronics guru, and I've no formal education in electonics. Don't trust me blindly!

So how does one dump the firmware then?  I used to do some interesting software hacking/cracking back in the day, and I think I could benefit others if I could take a look at the firmware myself.

[SeventhSon]

It's just not all that easy to do safetly. If you just want your drive to work in Windows then I'd advise the swap trick or Tiros' method of grounding eject at power up (eject is an input, you can short it to whatever you like :-). If you just want to send ATAPI commands to the drive or dump the Internal ROM/RAM/encryption key/firmware, then you don't even need windows to detect it. If, like me, you're curious about modeB or have had no luck with the above techniques, then give the potential divider a try. It shouldbe noted I'm not an electronics guru, and I've no formal education in electonics. Don't trust me blindly!

So how does one dump the firmware then?  I used to do some interesting software hacking/cracking back in the day, and I think I could benefit others if I could take a look at the firmware myself.

With or without your OS detecting the drive?

With is easy. You can dump the firmware using the Hitachi 0xE7 debug command. There is Windows and Linux software that will do this for you at the URL I linked above.

Without is basically the same but you need to go directly to the hardware yourself to send the command. There are currently no tools that will do this, as far as I know. Although the DOS version of PLSCSI might work, I'm not sure. I only know how to do this if you're using an PATA - SATA adapter or an SATA controller with a legacy mode.

If you just want to look at a firmware image, then check this wiki page out. Firmwares and deobfuscation tools

http://www.xboxhacker.net/index.php?option=com_jd-wiki&Itemid=37&id=xbox360_dvd_rom&rev=1141948658

Of course, this all assumes that your DVD drive is the Hitachi-LG. I don't know anything about the Toshiba-Samsung drive.

[BiMP]

It's just not all that easy to do safetly. If you just want your drive to work in Windows then I'd advise the swap trick or Tiros' method of grounding eject at power up (eject is an input, you can short it to whatever you like :-). If you just want to send ATAPI commands to the drive or dump the Internal ROM/RAM/encryption key/firmware, then you don't even need windows to detect it. If, like me, you're curious about modeB or have had no luck with the above techniques, then give the potential divider a try. It shouldbe noted I'm not an electronics guru, and I've no formal education in electonics. Don't trust me blindly!

So how does one dump the firmware then?  I used to do some interesting software hacking/cracking back in the day, and I think I could benefit others if I could take a look at the firmware myself.

With or without your OS detecting the drive?

With is easy. You can dump the firmware using the Hitachi 0xE7 debug command. There is Windows and Linux software that will do this for you at the URL I linked above.

Without is basically the same but you need to go directly to the hardware yourself to send the command. There are currently no tools that will do this, as far as I know. Although the DOS version of PLSCSI might work, I'm not sure. I only know how to do this if you're using an PATA - SATA adapter or an SATA controller with a legacy mode.

If you just want to look at a firmware image, then check this wiki page out. Firmwares and deobfuscation tools

http://www.xboxhacker.net/index.php?option=com_jd-wiki&Itemid=37&id=xbox360_dvd_rom&rev=1141948658

Of course, this all assumes that your DVD drive is the Hitachi-LG. I don't know anything about the Toshiba-Samsung drive.

Thank you!  That helped quite a bit

[probutus]

Sorry for bugging in, but Slack3er just found a way to get the 3120 drive detected by windows via native sata connection without any HW-modification.

He booted Linux with the modified ide-cd.c where the drive entered ModeB and the siimage driver (with a 3112 SATA SIL), rebooted then the sil bios  AND WinXP recognized the drive... See Using the 3120 for Linux thread....

[Slack3er]

Can I just add, SeventhSon deserves full credit for the Reboot from Linux to Windows Technique, to Keep ModeB. I read the idea from his 360 Summary... http://www.kev.nu/360/dvdshort.html

So thanks goes to SeventhSon