USB HDD - Breaking the 16GB limit

[meat5000]

Hello to you all, this is my first post so please bear with me.

I am pondering ways to break the 16GB HDD limit imposed on USB devices with M$ external storage update.

The 16GB space is reserved using 1GB padded files (all 00 or FF)
File Data0000 is always the same size (524,288KB) and is a 'system file'
File Data0001 contains allocation table information, specifying locations of memory clusters.
File Data0001 grows depending on the size of the drive that has been specified : 264KB = 1GB, 520KB = 2GB, 776KB = 3GB for fresh drives with no saved data indicating there are more memory clusters addressed within.

So with this in mind, one could supposedly add more 1GB Data00xx files and then append Data0001 to reflect the new range of memory clusters available. I assume Data0000 would need modifying to register the new size in order to match CRCs etc

I logically deduce that the drive is limited only on creation and not thereafter:
Hence the use of padding with 1GB files,
Dataxxxx files have 4 digits. If 0017 is max then the 00 would not be needed!
If FAT system has 256 file number limit then theoretical max drive size would be 254GB (given Data0000 and Data0001 are reserved files), assuming you could create and register 254 blank/padded Dataxxxx files.

A drive of 254GB would mean Data0001 would be approx. 65MB in size to reflect the additional cluster locations.
Note that Data0001 is also mostly blank(padded) until such time as content is stored on the drive. Memory cluster locations only seem to be registered for space that is In Use and is not needed for blank/padded space.

I did a comparison of drive sizes 1, 2 and 3GB by creating fresh drives using Xbox dashboard and then comparing the files on PC. In Data0001 I only found 4 Hex entries that differed and the rest remained the same.

In line 0 of each file:

1GB) 58 54 41 46  30 FE 4F A0 H
2GB) 58 54 41 46  5C 32 13 40 H
3GB) 58 54 41 46  55 57 AC 60 H

However I am at a loss at how I should interpret these values. Are there any tools about for decrypting the files? The extract tools I have found only extract data saved on the drives and will not let you read the system file or FAT in any useful output.
If anyone would like to add experience and knowledge to this idea, I'm sure thousands of people worldwide would be eternally grateful to you, including myself!
Regards.

[Eaton]

You are pretty close. I'll share some information.

A formatted USB mass storage device is considered a file partition volume. All data file combined into one makes one FATX image.
The first partition file, 0000, is the system reserved file. It contains system partitions and the configuration data for the entire volume.
The second one, 0001, serves as the boot sector + allocation table for the Content partition.
The rest of them serve as the Content partition's file area, where actual data is stored.

You won't be able to get around the size limit by manipulating the volume alone. You have to patch a plethora of things in the kernel and xam, which is extremely difficult since dealing with multiple file handles is tricky..

However, it has possible, I have done it.. to an extent:


I could only get up the 18gb before the system crashes.


Manipulating volume is the easy part, I would recommend poking around in xam.xex.

[CLK]

The 16GB of space that's being "reserved" is just quick-formatted basically.  If you notice, when you seek to an offset close to the end of Data0000 you'll find old data that was once deleted on your thumb drive.  The Xbox doesn't write over any of this data until it actually needs to, except in the Data0001.  Also, the data you posted for the various file sizes are just the partition header information -- the magic (which is FATX in little endian, so 0x58544146) followed by the partition ID (0x30FE4FA0)

"The extract tools I have found only extract data saved on the drives and will not let you read the system file or FAT in any useful output."

There's really no better or way (or any useful way) of reading it besides mapping out the entire filesystem or just looking at it through a hex editor.

While your idea isn't a bad one (and wasn't thought of before), there are still the console-side limitations and I *believe* there is region data in the Data0000 file that would also need to be changed.  Although that was told to me quite some time ago and I never looked in to it myself.

[meat5000]

Thanks for the replies!

Ok I think I have an idea whats going on. Only trouble is I'm short of tools to make this work. The ones I have, XP wont let me run!
Could you possibly list the tools you use to do this? It would speed up my plight

Also, I'm guessing I should do a Full format on the drive for a clean slate if I wish to do Hex comparison!

Cheers dudes!

[Eaton]

Essential tools would include a hex editor, IDA Pro with PPC plugins, and some information:
http://free60.org/FATX

[Ryberyz]

Anyone have an idea?
I really need this tutorial... this HDD 16 GB limit makes me crazy >.<

You are the hope guys ...cmo'n!

Don't give up

 

[Oscar]

I was researching this a little while ago but I got rrod before I actually got to test anything, I'll just post what I have and hopefully it should be of some use.

The configuration for storage on USB devices is in the first 0x400 bytes of the Data0000 file, the layout is as follows:

Code:

struct DEVICE_CONFIG
{
BYTE ConsoleCertificate[0x1A8]; //0x00
BYTE Signature[0x80]; //0x1A8
BYTE DeviceID[0x14]; //0x228
DWORD CertSize; //0x23C
QWORD SizeOfDevice; //0x240 - in bytes
WORD ReadSpeed; //0x248 - in KB/s
WORD WriteSpeed; //0x24A - in KB/s
}

The first 3 members are pretty self-explanatory, the fourth I couldn't work out exactly what it is but it's used when verifying the signature of the device, if the value is 0x228 then the signature is verified with the console signing params (XeKeysConsoleSignatureVerification). Otherwise it's a HDD with a value of 0x100 which is verified with XeKey id 0x3F. The last 2 members are results from the performance test that is done when the device is configured, I'm unsure why these are stored or how they are used later on. The signature is derived from a SHA hash taken from 0x228 (device id) for 0x1D8 bytes (0x400) and signed with XeKeysConsolePrivateKeySign.

When a USB device is mounted there are a few checks in place, the first thing that gets checked is the device id, then the signature and then the size value in the config:

Code:

li r11, 1
extldi r11, r11, 64,34 # 0x0000000400000000 - MAX
cmpld cr6, r24, r11 #max == size of device
bgt cr6, loc_1010D360 #fail

Here shows that the max size of device cannot be any greater than 0x400000000 bytes (16gb exact)

Further on there is a check on how many Data00xx files the system will handle, looping will fail there with STATUS_INSUFFICIENT_RESOURCES (0xC000009A) if the index is >18, else it will either increment the data file index or branch out if there is enough data files found for the size of the device.

You would need to patch out the signature check (or sign it yourself), create additional Data00xx files, increase/remove the check on the size of device and data files and also edit the config to match a new size. (should be divisible by 0x4000)

As for the filesystem.. I have no clue, I've never even taken a glimpse at it so that may be an entirely different problem altogether.

[Eaton]

Excellent work, Oscar!

To map out your unknown, that is the cert size. 0x228 signifies that the USB was formatted on an Xbox 360 console. 0x100 means that it was signed at the factory that pre-formatted the device.

[Ryberyz]

This thing is going fast. Let's go!

 more one hack for M$

 

[CLK]

Great research Oscar, will definitely be useful.

[stoker25]

Just wanted to note that XeKey 0x3F is XEKEY_CONSTANT_SATA_DISK_SECURITY_KEY, which I think is also used to verify the security sector on MU/HDD too.
Also, that Console Certificate seems a strange size, I've always thought they were all 0x1A8... Could somebody maybe post an example of one?

[Oscar]

Also, that Console Certificate seems a strange size, I've always thought they were all 0x1A8... Could somebody maybe post an example of one?

Yeah, I got the size of the 2 sigs mixed up. I thought the one that verified the cert was 0x80 and the attached sig was 0x100. This is the correct layout:

Code:

struct DEVICE_CONFIG
{
BYTE ConsoleCertificate[0x1A8]; //0x00
BYTE Signature[0x80]; //0x1A8
BYTE DeviceID[0x14]; //0x228
DWORD CertSize; //0x23C
QWORD SizeOfDevice; //0x240 - in bytes
WORD ReadSpeed; //0x248 - in KB/s
WORD WriteSpeed; //0x24A - in KB/s
}

It just uses XeKeysConsolePrivateKeySign so the format is the same as any you'll find on a console-signed file.