Low Level Xbox analysis of the firmware and SA changes

[verpies]

INTRODUCTION
-----------------------

XBox 360 is a gaming console that uses standard yet slightly modified PC hardware and a custom Microsoft operating system.
The hard disk drives used by the most recent XBox 360 S model are standard SATA 2.5 inch hard disk drives. Common Seagate and Western Digital drives are commonly used by XBox 360.

The physical SATA interface is not modified on the XBox plattform, but the firmware and logical structure of the disk is, for example:
1) The drives have 3 non-standard partitions
2) There are security descriptors in the sectors 16-22 and allegedly in the negative sectors of the System Area (SA) of the disk.
3) The file system is the XTAF or FATX file system. See: http://www.arkem.org/xbox360-file-reference.pdf
4) The drive's firmware in the flash memory is modified.


CONSEQUENCES
--------------------------

As a result of these storage modifications it is hard or impossible to:
1) Mount XBox hard drives in regular Operating Systems, and consequently impossible to:
___a) Erase all personally identifiable data (e.g. who knows where the Kinect's photos of the user's face and room are stored)
___b) Read all of the contents of the XBox hard drive (e.g. to make a backup)
___c) Write to all areas of the drive (e.g. to restore a backup)
___d) transfer the full contents of one drive drive to another, (e.g. to save recovered data from a failing drive to a new drive).

2) Buy a standard hard drive and use it in an XBox:

___a) The XBox OS checks for the custom firmware responses and refuses to use standard drives.
___b) New drives with custom firmware and SA can be bought from Microsoft but they cost over 2x more than the standard drives (even for the same model number), leading to a common corporate rip-off.


WORK TO DATE:
------------------------
In order to free us from these limitations, loss of privacy (hidden storage areas) and corporate rip-offs, several solutions have been devised:

There is an utility that can interpret the XFAT file system called an Xplorer360. See:
http://wiki-scene.com/Xplorer360

There is a utility to save and restore the XBox firmware via the SATA interface (on Western Digital hard drives ONLY): See:
http://www.ixtreme.net/downloads-tutori ... hddss.html


INVESTIGATION
--------------------------
I would like to investigate what changes were done to the drive's firmware and System Area, e.g. how many sectors were hidden and allocated for hiden storage area by the XBox OS.

I have 2 identical Seagate drives, (the ST9250315AS). One drive is an original Microsoft XBox hard drive with the custom firmware and custom SA and the other one is a standard hard drive with standard firmware, straight from Seagate.
Both drives are fully functional.
I have the RS-232C to TTL-3.3V converter cable and I can access both drives via the serial port and a terminal (the F3 T> prompt appears)

I lack the knowledge how to us read/dump the custom firmware and SA via the terminal Seagate Diagnostic Commands.
If some expert in these matters could help me to READ all the hidden goodies from these two drives then I would post them here for all the world to compare and learn.

[fzabkar]

AIUI, Microsoft doesn't actually modify the drive in any way. All HddHackr does in the case of a WD ROYL drive is to modify two firmware modules, one in the SA (MOD 02) and the other in the ROM (MOD 0D).

I'm not a data recovery professional, but here is my analysis of HddHackr:
http://www.users.on.net/~fzabkar/HDD/Hd ... lysis.html

Essentially what HddHackr does is to edit those firmware modules which store the drive's serial number, model number, firmware version, and capacity in LBAs. These need to match the information in the HDDSS.BIN file from the source drive.

If you wish to experiment with HddHackr, then I would use a WD ROYL drive. Start with a Fujitsu 20GB HDDSS.BIN file, say, and use it to modify the WD drive. Save the WD's UNDO.BIN file as WD_MODs.bin.

Then use a 60GB HDDSS.BIN file and modify the WD drive once more. This time the UNDO.BIN file will contain the 20GB Fujitsu info. Call it 20GB_MODs.bin.

Compare the two BINs. This will tell you where the differences are. Note that there will be 4 checksum bytes for each MOD.

You could use the DOS File Compare command to do this:

fc /b WD_MODs.bin 20GB_MODs.bin

Afterwards, restore the drive's original firmware using the first UNDO.BIN.

[verpies]

Thanks for trying to help but my post was not about HddHackr or Western Digital drives.

The post was about low level SA analysis of the Seagate drives through their serial interface.
Specifically about reading these special SA modules with Seagate Diagnostic Commands entered via a terminal.

I expect the layout of the SA modules in Seagate drives to be different from what you had described.
Only experiment will tell...

[Amarbir[CDR-Labs]]

Thanks for trying to help but my post was not about HddHackr or Western Digital drives.

The post was about low level SA analysis of the Seagate drives through their serial interface.
Specifically about reading these special SA modules with Seagate Diagnostic Commands entered via a terminal.

I expect the layout of the SA modules in Seagate drives to be different from what you had described.
Only experiment will tell...

well,
he has explained it well .its simple with seagate terminal commands also

[verpies]

Nobody explained how to get this info out of Seagate drives with the Diagnostic Commands via a terminal.
Apparently it is not "simple"...

[JWCC]

After most of a very long list:

Level F 'D': Rev 0011.0000, Overlay, DisplayMemoryBlock, D[AddrHi],[AddrLo],[CompVal],[NumBytes],[Opts],[SizeInBytes]

All Levels '+': Rev 0011.0000, Flash, PeekMemoryByte, +[AddrHi],[AddrLo],[Opts]
All Levels '-': Rev 0011.0000, Flash, PeekMemoryWord, -[AddrHi],[AddrLo],[Opts]
All Levels '=': Rev 0011.0000, Flash, PokeMemoryByte, =[AddrHi],[AddrLo],[Data],[Opts]

At the very beginning but VERY slow!

I'm going to test these commands out on an older drive once I modify one of my USB-to-serial adapters or make a cheapo adapter. I actually got a 74LS14 just for this purpose, today. Remember that some of these commands behave oddly/differently on specific drives.

[verpies]

The Peek commands can display the contents of system onboard volatile RAM only, but maybe the 'Level T' command 'R' - Read System Sector into System RAM, would allow to read the contents of the magnetic sectors into RAM and then display it using Peeks one-by-one from there. There are also the 'Level 1' commands 'Bxx,yy' and 'Dx,yyyy,zz' for displaying memory.

Unfortunately the 'R' command has no arguments to specify the sector number and the manual mentions THE System Sector, which is in the System Area, isn't it? ...but there are many reserved sectors in the SA so which one is read by the 'R' command?

Just groping in the dark... :/

Pavel who PM'd me, wrote that there is also the 'Level T' command 'uxx' which allegedly can read the reserved cylinders, but In the Seagate Diagnostic Command manual the description of this command is different, so I do not know whom to trust:

uxx
Upload CERT, RWF, CSPT, DEF from reserved cylinder to Buffer
xx = - FILEKEY for downloading.

1H OVLY_CCT
2H OVLY_ACT
3H OVLY_XX
4H DEFRSV
5H DEFFTY
6H DEFUSR
7H DEFLZT
8H RWF
9H SYSVAR1
AH SYSVAR2
BH CSPT
CH VBPI
DH FLSH_AT
EH FLSH_CT
0FH AT_STUFF
10H SECURITY
11H VENDOR_SPEC
12H SMART ATTRIBUTE
13H SMART THRESHHOLD
14H SMART DIRECTORY
15H SMART ERROR LOG
16H SMART COMPREHENSIVE LOG
17H SMART SELF_TEST_LOG
18H SMART CRITICAL_EVENT_LOG
19H SMART HEALTH_LOG
1AH SMART DRIVE_VENDOR_LOG
1BH SMART HOST_SPECIFIC_LOG
1CH WRITE_PROTECT
1DH CON GEN
1EH SKIP CYLINDER LIST

= 8X – For DLE only, ie. Only uploaded to buffer Ram.
= 88 – DLE only for RWF.
= 8B – DLE only for CSPT

[fzabkar]

Thanks for trying to help but my post was not about HddHackr or Western Digital drives.

The post was about low level SA analysis of the Seagate drives through their serial interface.

I do understand that you wish to modify a retail Seagate drive for use in your Xbox. The purpose of my post was to correct what I believe is your misconception that Microsoft somehow doctors the firmware in its Xbox drives. To confirm that this is not the case, I suggested that you use HddHackr to modify a WD drive and then record the changes. This will tell you exactly what is being written to your drive.

I suspect that Microsoft takes a regular OEM drive, issues an ATA Identify Device command, and then computes certain security information based on the returned parameters, eg serial number, model, number, firmware version, and capacity in LBAs. This security information is then written to LBAs 16-22 in the user area, not the System Area.

When the Xbox boots up, it would issue the same ATA Identify Device command, analyse the drive's reported serial number, model, number, firmware version, and capacity in LBAs, and then compare these against the information in the security sectors.

AIUI, you have two "identical" Seagate drives, one an Xbox original, the other a regular retail drive. Assuming that both have the same overall firmware version, then their only difference, as far as the Xbox would be concerned, would be their serial number. The OP in the following thread purports to have written a utility to change the serial numbers of certain Seagate models:

change-seaget-serial-software-t22395.html

As for comparing the firmware in your two Seagate drives, AIUI even if the two drives have the same overall firmware version (eg SD33), then they are still likely to differ significantly in the "package version". AIUI, the latter refers to the various modules that make up the firmware.

By way of example, you can see several package versions for SD33 firmware in the following configuration file:
http://www.users.on.net/~fzabkar/HDD/BR4HSD3B.TXT

The above file contains an update matrix that determines which package versions are eligible for the Brinks 4-head SD3B firmware update.

[verpies]

I do understand that you wish to modify a retail Seagate drive for use in your Xbox.

No, I want to READ the System Area and the firmware of the Seagate drives, in order to compare them.

Your notes on the possible different layout of the same firmware version was very helpful. I will watch out for that once I learn how to get it off the drive.
I appreciate your analysis, but only an experiment will tell if it's correct.

[JWCC]

Meh, the Seagate drive I got as a replacement for the Fujitsu was also a dud. Even after running a Secure Erase cycle overnight and unlocking (standard 'Eins' password), it failed a surface scan under MHDD for the first 10000 sectors after a power cycle. Bunches of delays and read/write failures every so often. MHDD's scan worked fine for the first few hundred sectors and a disk sector editor did, too... Me thinks someone tried and failed at a firmware mod. Before I did the Secure Erase, it was showing data from seemingly the middle of a file and data written to sector 0 kept reverting, so obviously there was some low-level firmware issue. The SE was a shot in the dark hoping that the firmware would overwrite whatever was corrupt.

I took the dumb thing back for a refund and now have no recent Seagate SATA laptop drive to check. Sorry, guys, there'll be no more information on this ST9320325AS drive from me. I'll mess with the older ones, still, though.