Add XGD support for Kreon Drives

[tbejos]

This adds the ability to dump the security sector from a drive flashed with the Kreon drive, unlock the drive to read the full game partition, and lock the drive again to dump the L1 Video portion.

Security Sector Files:

When dumping an XGD there will now be a .raw_ss file which is the security sector as it was read from the drive. For XGD1 discs this will be copied as a .ss file as well. For XGD2 and XGD3 files it performs the angle cleanup and saves the cleaned version as a .ssv1 file. This allows for both the "raw" and "processed" version of the security sector to be present in the dump.

Testing Status:

All of the following tests were done by myself, unless otherwise noted, using a TS-H353B (SH-D163B after flashing). My dumps had no errors so I manually manipulated the state file to test refine. I have added this modified state file as <image-name>-refine.state in the zip files.

These were all tested on Windows 11, I will retest on Linux and update this line when I do so.

XGD1: (http://redump.org/disc/13538/)

• [x] DUMP
• [x] REFINE
• [x] VERIFY
• [x] SS Matches

XGD2: (http://redump.org/disc/11809/)

• [x] DUMP
• [x] REFINE
• [x] VERIFY
• [x] SSv1 Matches

XGD3: (http://redump.org/disc/37091/)

• [x] DUMP
• [x] REFINE
• [x] VERIFY
• [ ] SSv1 Matches (Could not find SSv1 listed for any XGD3 games I own so nothing to compare to)

PS2: (http://redump.org/disc/22865/)

• [x] DUMP
• [x] REFINE
• [x] VERIFY

Important Information

Linux Fix:

For the vendor specific command to set the lock state of the drive it would normally fit fine into a CDB 6, however a bug was discovered where for opcodes with a group code of 6 or 7 (opcodes 0xC0 - 0xFF) libata in the kernel checks a table which expects the CDB to have a length of 10 and will refuse to send the command to the device. This did not affect drives connected via USB-Attached SCSI, but affected all drives connected via SATA or IDE. Both Windows and Linux work when sending it as a CDB 10 so the change was made to make it that even though not all of the bytes are strictly needed. I have reached out to the Linux kernel mailing list to possibly remedy this issue in the future, however there is no guarantee the change will happen, and if it did only distros that run the newest kernel releases or back-port this patch would see it fixed so this change will likely need to remain for the foreseeable future.

(As a note the CDB is currently a uint8_t [] but if a structure for Generic CDB10 is known I could switch to using that)

Things Missing:

• No changes were made for the info command. @Deterous has plans to add these changes as a follow on PR.
• On some drives there sometimes seem to be issues sending the full security sector dump command sequence, however they seem to be able to send some of the commands with success (so far this has only been reported for XGD2). I will look into adding additional checks so that instead of failing the dump it can save the partial SS in it's own file (or maybe not write to a file at all) but still allow dumping of the ISO to complete.

[tbejos]

Here are the files (non-ISO) from all of my testing. There is a single log file which contains DUMP, VERIFY, and REFINE information. (For the refine logs I copied them over as I tested on a copy of the directory to make sure none of the original files were accidentally disturbed) xgd1.zip xgd2.zip xgd3.zip ps2.zip

[mirh]

Does this mean that now Kreon drives are just as good as the official 0800 ones at dumping?

[Deterous]

Does this mean that now Kreon drives are just as good as the official 0800 ones at dumping?

Kreons have always been able to dump the ISO just fine. It is the security sector for Xbox360 discs that the 0800 drive needed for, and this does not change that. 0800 drive support in Redumper will hopefully come in the future.

[mirh]

Mhh.. then what XGD3 security sector is the cover letter even talking about?

[Deterous]

This is the general layout (that I'm able to figure out anyway) for the XGD1 and XGD2 Security Sectors (XGD3 is quite different). However, the only parts that we touch are within security_ranges (for xbox_skip_ranges) and cr_data (for clean_xbox_security_sector) which have their own structure. I don't think there is any gain in making the SS structured. Rather, it should be treated as a LayerDescriptor at all times, and the specific parts of the media_specific array be accessed.

export struct XGD1_SecuritySector
{
    uint8_t reserved1[703];
    uint32_t cpr_mai;
    uint8_t reserved2[44];
    uint8_t ccrt_version;
    uint8_t ccrt_length;
    uint8_t ccrt[285];
    uint64_t creation_filetime;
    uint8_t unknown2[16];
    uint32_t reserved3;
    uint8_t unknown3[16];
    uint8_t reserved4[84];
    uint64_t authoring_filetime;
    uint32_t cert_time_t;
    uint8_t reserved5[15];
    uint8_t typeA;
    uint8_t game_id[16];
    uint8_t sha1A[20];
    uint8_t signatureA[256];
    uint64_t mastering_filetime;
    uint8_t reserved6[19];
    uint8_t typeB;
    uint8_t factory_id[16];
    uint8_t sha1B[20];
    uint8_t signatureB[64];
    uint8_t ss_version;
    uint8_t ranges_length;
    uint8_t security_ranges[207];
    uint8_t security_ranges_duplicate[207];
    uint8_t reserved7;
};

export struct XGD2_SecuritySector
{
    uint8_t reserved1[239];
    uint64_t unknown1;
    uint8_t sha1X[20];
    uint8_t reserved2[228];
    uint8_t cr_data[207];
    uint8_t reserved3;
    uint32_t cpr_mai;
    uint8_t reserved4[44];
    uint8_t ccrt_version;
    uint8_t ccrt_length;
    uint8_t reserved5[2];
    uint8_t ccrt[252];
    uint8_t reserved6[96];
    uint8_t media_id[16];
    uint8_t reserved7[46];
    uint8_t unknown2;
    uint64_t authoring_filetime;
    uint8_t reserved8[19];
    uint8_t typeA;
    uint8_t game_id[16];
    uint8_t sha1A[20];
    uint8_t signatureA[256];
    uint64_t mastering_filetime;
    uint8_t reserved9[19];
    uint8_t typeB;
    uint8_t factory_id[16];
    uint8_t sha1B[20];
    uint8_t signatureB[64];
    uint8_t ss_version;
    uint8_t ranges_length;
    uint8_t security_ranges[207];
    uint8_t security_ranges_duplicate[207];
    uint8_t reserved10;
};

[superg]

@Deterous the structures are useful, thanks! Even if we don't use it today, can you please add them to xbox.ixx for later?

[tbejos]

Sure I will add the structures for potential future use

[tbejos]

I see now that my current branch is behind a few commits from upstream, do you have a preference of if I do a merge or rebase to resolve it? Or do you have another preference for how I should update it?

[Deterous]

I see now that my current branch is behind a few commits from upstream, do you have a preference of if I do a merge or rebase to resolve it? Or do you have another preference for how I should update it?

A merge should be fine, that's what I've done on previous PRs