-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security sectors not dumped #6
Comments
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. |
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?
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. (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)
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. 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). So the more testing this gets, the more accurate it gets, the better. We should also make sure that it dumps as much as possible when this tool is leaving this "unstable" state. 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. 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. |
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?
The text was updated successfully, but these errors were encountered: