1

Hey,

I'm currently trying to *** the library of original Xbox games for use with the XQEMU Xbox emulator ( http://xqemu.com ).
I want to dump my games, including 3 "Microsoft Confidential" press DVDs.

I'll have scans of the covers + underside of all discs soon too. Probably also the game boxes.

However, I've also noticed that the redump standards for the disc data might not be good enough. It lacks some information in the checksums (security sectors) and security sector ranges (only 16 of 23 listed). I'll probably describe this in another topic soon.
But this leads to some delays with the actual data dumps as I'm still trying to figure out how everything works.

As it stands, the current redump quality is not enough to accurately emulate disc security. It's merely enough to fool a drive with modded firmware for ***

My research so far is available at: http://xboxdevwiki.net/Xbox_Game_Disc
Also my tool for experimenting with disc-dumping is at: https://github.com/JayFoxRox/dump-xbox-dvd


(Additionally I probably have a Lindbergh disc or two I can dump. However, I'll need instructions for this. If I don't get any, I'll just raw sector dump it probably)

2 (edited by Jackal 2017-05-26 09:45:19)

Hi and welcome,

Here's a link to the source code of our tool ss_sector_range. I don't have the one for the latest version, but nonetheless this should help you with your research: http://www.mediafire.com/file/7046l9s2h … ha_src.zip

From what I can recall from our research, Xbox360 has 23 security sector ranges, but Xbox1 only has 16. This was also evident from the error log that dvd2xbox created when creating dumps on the actual console, and the Xbox SDK also contained a tool for creating Xbox Game Discs, where you had to position the game data between 16 (8 for each layer) security placeholder ranges.

From the .cpp:

The 2048 byte Xbox1 decrypted security sector file contains 2 copies of the table with sector ranges:

        - table 1: 1633 to 1839 (207 bytes)
        - table 2: 1840 to 2046 (207 bytes)

    The entries are 9 bytes wide, so there are 9x23 entries (or rows). The sectors are the last 2x3=6 bytes
    of each row. On the Xbox1 there is only 16 sector ranges, so you only need to display the first 16 rows.

As for the lack of information: We now merely list the CRC32 of the SS to identify between different sectors that are known for each game. We could also add new fields for any data from the SS that might be crucial, but seeing as to how it's possible to extract files from personal backups, transfer them to the console and play, I guess that emulators will also be able to play games without having to rely on the PFI/DMI/SS (correct me if I'm wrong).

3

Jackal wrote:

Hi and welcome,

Here's a link to the source code of our tool ss_sector_range. I don't have the one for the latest version, but nonetheless this should help you with your research: http://www.mediafire.com/file/7046l9s2h … ha_src.zip

Yes, I've had that tool for a while (you gave it to me 1-3 year ago on IRC iirc) and was wondering about the licensing.
For now, I've just stolen one function and the comment: https://github.com/JayFoxRox/dump-xbox- … r/ss.c#L15

Jackal wrote:

From what I can recall from our research, Xbox360 has 23 security sector ranges, but Xbox1 only has 16. This was also evident from the error log that dvd2xbox created when creating dumps on the actual console, and the Xbox SDK also contained a tool for creating Xbox Game Discs, where you had to position the game data between 16 (8 for each layer) security placeholder ranges.

I haven't looked into it for a week now, but I believe the SS table suggested that 16 out of the random 23 entries are used. Not always the first 16. I'm not sure if the sector ranges from SS bin map directly to entries in the challenge table (also 23 entries) either.

Note how matching pairs have an index > 15: https://multimedia.cx/eggs/xbox-sphinx-protocol/

Jackal wrote:

As for the lack of information: We now merely list the CRC32 of the SS to identify between different sectors that are known for each game. We could also add new fields for any data from the SS that might be crucial ...

The problem is not the SS.bin, but the fact that the SS contains "pointers" into the data sectors. Some of those sectors *might* contain security information which is currently not dumped.
Presumably this information is hashed by the drive and replied in request to security challenges.
As the redump strategy suggests to skip these security sectors, the security related information is missing from redump dumps. (Causing a bad track CRC [!] (or missing a file where these sectors would be stored instead)). The SS.bin on the other hand is probably fine.
In fact, the SS.bin is more than an original stock Xbox drive would return. The Xbox drives only return 1632 bytes for the SS.bin, which does not include the security sector ranges (which are probably handled by the drive firmware) but only the encrypted challenge response table.

Also see: http://xboxdevwiki.net/Xbox_Game_Disc#S … 8SS.bin.29

Jackal wrote:

but seeing as to how it's possible to extract files from personal backups, transfer them to the console and play

These backups don't play on original, unmodified, stock drives. They only work, because the drive firmware was modified to take the security responses from the SS.bin.

I currently believe this is happening on a real Xbox:
1. The Drive loads the disc and on rquest sends the SS[.bin] to the CPU. The SS contains an encrypted table with challenges (32 bit integers) and responses (presumably pre-generated hashes for each sector range).
2. The CPU decrypts the challenge table and picks a challenge, which it sends to the drive to the drive
3. The Drive will find the challenge related data sector (= security sector) on the disc and hashes it or somehow generates data from it (*)
4. The Drive will now send that hash to the CPU
5. The CPU looks in the challenge response table if the challenge was correct and accepts or rejects the DVD

(*) This is impossible with redump dumps, as the data is filled with zero, when it should be a raw sector dump probably.

For a modded drive the same procedure generally applies, BUT: Instead of point 3. it will just decrypt the SS challenge/response table itself (which a stock drive never does). When the CPU asks for a challenge, the modded drive will just send the expected response, which is exactly the same what the CPU does (so the check will succeed, but it was never really done either).

Note that most of this is speculation, and will need a lot more further research (by disassembling an Xbox DVD drive firmware and raw dumping some games for testing).

Jackal wrote:

I guess that emulators will also be able to play games without having to rely on the PFI/DMI/SS (correct me if I'm wrong).

We currently have 3 (maybe 4?) options to solve this issue in emulators:

- Patch the emulated Xbox kernel (this is tricky as it involves messing with the state of the software running in the emulator = hacky approach)
- Emulate a modded drive firmware (this is my current approach, but it feels "wrong")
- Research and emulate a proper drive which does the response calculation itself, possibly even emulating the DVD drive firmware instead of rewriting a custom one (currently our own code handles SCSI emulation).
- (A fourth option might be to emulate a modded drive which always tells the CPU "this disc is already authenticated!"; however, this would depend on how the Xbox kernel works exactly and feels even more hacky)

---

I'd consider the modded drives like a crack, so saying "it works on a real 360 [with modded drive]" is like saying: "this PC game disc dump works if you install a crack".
As redumps stated goal is to create "blueprints" of discs, it should also include the security features.

---

I still don't have an account btw

4 (edited by Jackal 2017-06-02 14:06:47)

Our dumping method revolves around the idea that security placeholders are simply ranges of readable/unreadable sectors with random padding that were placed on the disc as a copy protection mechanism. These unreadable ranges were witnessed by examining DVD2Xbox logs and dumps, and IIRC also by "hot"swapping DVD9's by Xbox discs, to fool a drive into reading the Xbox disc.

I believe the SS table suggested that 16 out of the random 23 entries are used. Not always the first 16.

If this theory is correct, then it would mean that "clean" ranges were replaced with zeroes and actual security ranges were included in the dump? In any case, we haven't encountered any unreadable sectors that were outside the first 16 ranges, with the 1654 Xbox1 discs dumped so far, even though IIRC all security placeholders contain unreadable sectors.

I still don't have an account btw

One of the admins should take care of that.

Feel free to keep posting your findings and contribute any dump info. If our dumping methods prove to be wrong or inadequate, we will do our best to fix that, but so far there is no evidence to suggest that anything is wrong with the dumps.

@JayFoxRox Invitation sent, get your password upon login.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

Jackal wrote:

even though IIRC all security placeholders contain unreadable sectors

Back then, when i dumped some discs manually there were SSranges fully readable. Some discs had 1 range and some discs more than that, but i don't remember to have seen more than three of those per disc. I may be mistaken, but i am remembering or at this point assuming that every disc has at least one range of SSdata fully readable.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)