Security sectors not dumped

[JayFoxRox]

On drives which support it, this tool should also dump the security sectors and also give the option for more accurate dumps overall.
[lib]friidump should be submoduled probably?

[romtools]

Looking at your code for dumping the SS, you have an area with "FIXME: I have no idea how to do this correctly!"

From what I've gathered, there is some state being twiddled on the drive as you send the four SS commands; I'm still not 100% sure how this works because documentation is non-existent, but other software (namely Xbox Backup Creator, which is the redump standard for SS still) is simply running those commands in sequence with the same buffer. The result of the last call is the one that is used. This may well only matter for (certain?) 360 games because in my testing I get the same buffer output on every call on multiple different discs. Either way, running it the same way won't hurt and will be consistent with what's already in use.

So that should help you fix that one bit there. What else is missing to get this finished? I can provide patches and help out if you want some help getting closure here. This is a much needed solution vs. the current guide at Redump. No need to be using so many different tools.

[JayFoxRox]

Looking at your code for dumping the SS, you have an area with "FIXME: I have no idea how to do this correctly!"

Yes, that's why I just did what the other tools do (with the same reasoning as yours). But unless we know for certain, I will keep this comment. The way this is done in other tools is.. weird?
I'd like to hear how exactly this command works from one of the firmware authors (or is it just the standard drive command with a less limited range and they don't know themselves?).

This is a much needed solution vs. the current guide at Redump. No need to be using so many different tools.

Yes, agreed. However, around the same time, claunia was working on https://github.com/claunia/DiscImageChef and she also looked into getting more drives into a raw-dumping state.
I'm not sure how far along she is with her efforts, but her tool might make this tool redundant.
Personally, I got distracted with other projects - I mostly worked on Xbox emulation at the time, and disc dumping is only a small part of it. Accurately dumped discs are of no-use without an accurate, working emulator (and vice versa).

(If her tool is better, the main motivation for this one would be to become a lib, so Xbox emulators can read actual Xbox discs on supported drives, without dumping those discs first)

What else is missing to get this finished? I can provide patches and help out if you want some help getting closure here.

Patches would be appreciated. I think one of the first things that should be done, is undo-ing the compression code. WTF was I thinking?

I can't remember what else is missing. I only worked on this for a very short time.
I basically just cloned freecell and tried to integrate the other features so only one tool is required.
It was also worrying to me, that none of the tools I tested, worked fine on Linux out-of-the-box.

The plan was to add more experimental features later to raise the redump standards, as I feel they are not enough for LLE drive emulation (explained below).
I'd rather have all information dumped off of the discs, before it's too late.

So the more testing this gets, the more accurate it gets, the better.
A step towards this goal would be code-cleanups, checking for memory-leaks or logic errors.
Unless we know this creates error-free dumps, nobody should be using it.

We should also make sure that it dumps as much as possible when this tool is leaving this "unstable" state.
People might not want to dump their discs multiple times, only because we add support for dumping another kilobyte of previously unknown data from the disc, even if it later turns out that this information is critical for some purposes.

---

Also I think you misunderstood the issue. If I remember correctly, this is not about dumping SS.bin, which would be the Security Sector table.
I believe I meant this issue to be about SS contents, so the sectors the SS points at (as suggested by the friidump comment, which implies raw-data dumping).
I do agree that the terminilogy and this issue naming are quite confusing.

Unfortunately, drives don't like reading them, and I wouldn't necessarily trust the modded firmwares for Xbox dumping either: they might just have been patched to not-fail on read and return 0 instead.

Some of my other research about disc padding information suggests that the security sectors are padded blocks which are filled with random data. The seeds for the older discs can be bruteforced, later Microsoft switched to a new, more secure, random algorithm. But for some discs we can possibly reconstruct the data from the known random stream. However, I can't remember how far along I was with that work.

The reason for dumping these sectors, would be that I intend to have full disc-drive chip-level-LLE in the future. So instead of cheating by using the SS.bin to know the drive security responses, the emulator could generate the data contained in SS.bin itself. We don't know how the drive generates the responses yet, but I'd assume the data in the SS (data sectors) is important.
This LLE is not that important, even for people caring about preservation, but it would be a noble goal.