Post new reply

@JayFoxRox Invitation sent, get your password upon login.

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.

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.

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.

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

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/

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

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).

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

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:

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).