Hacking DVD Drive Vulnerability

[TomChaai]

you are absolutely correct - they earned well from XGD3 protection

So I think we have two topics:
1: Figure out how to gain debug access to the "MSODDDSP" chip to figure out how it boots securely, for example how it encrypts, integrity protects and restricts access to its firmware flash chip. Find a way to dump the drive key and compile new firmware to flash it like on the 360. This should at least help with drive repairs even if loading backup discs aren't possible yet.
According to you at least getting into the chip is possible now?

2: Figure out the disc logical structure and topology layout to understand the possibility of C/R spoofing. From what I understand, XGD3 used a variety of "bad" sectors that are crafted in a certain way that a normal drive won't be able to read and write back identically, the drive reads raw channel bitstream and also measures angular distances between some of them, compare to the prerecorded C/R table to verify if the disc is genuine.
Is the dual overlapping track technology already present on XGD3? Or is it XGD4 exclusive? If the similar technology is already present on XGD3, we can probably move the similar "topology data" countermeasure used in LTU firmware to here.

 

[MrQQ]

So I think we have two topics:
1: Figure out how to gain debug access to the "MSODDDSP" chip to figure out how it boots securely, for example how it encrypts, integrity protects and restricts access to its firmware flash chip. Find a way to dump the drive key and compile new firmware to flash it like on the 360. This should at least help with drive repairs even if loading backup discs aren't possible yet.
According to you at least getting into the chip is possible now?

2: Figure out the disc logical structure and topology layout to understand the possibility of C/R spoofing. From what I understand, XGD3 used a variety of "bad" sectors that are crafted in a certain way that a normal drive won't be able to read and write back identically, the drive reads raw channel bitstream and also measures angular distances between some of them, compare to the prerecorded C/R table to verify if the disc is genuine.
Is the dual overlapping track technology already present on XGD3? Or is it XGD4 exclusive? If the similar technology is already present on XGD3, we can probably move the similar "topology data" countermeasure used in LTU firmware to here.

To a degree but you forget that every deviation angle now is truly random. Rip it once thats fine but rip those same sectors or angles again and it will be truly random. This is I assume how the "silver bullet method" was discovered when it came to AP25 challenges and responses. Firmware CRC checking is also a clear reality and has been since the slims but its good to discuss this to someone who has clear knowledge of this. Could you send me a PM. Myself and a few others have been looking into this in private channels and regarding XGD4 it is exclusive from what I can see and again, truly random your entire premise is all correct provided even step one can be completed.

 

[Finray]

Yes!..I would hope research continues in this. It is very suprising to me that there doesnt seem to be much interest in this. I think it would be extremely useful for booting backups of OG and 360 disc's. Especially because Xenia is still wonky. Just imagine, you pop in your backup of SH-Downpour because your original is scratched to all heck and it recognizes it as legit and grabs the license.

 

[jujuba]

So we got hb on the Xbox One now? Neato

not exactly homebrew

 

[sombrerosonic]

not exactly homebrew

I was already told this several times sir.

 

[SylverReZ]

not exactly homebrew

Do you realise that dev mode exists for homebrew such as emulators?

 

[blinkoutatime]

I do not think the BD is the key to finding exploits here, I honestly believe the drive itself has nothing to do with getting an exploit working. Not that it isn't a possible route to take, but I think there are more than one. These checks would be irrelevant on systems without the disc drive. It may be a way to find an exploit on original systems, but how that would affect non disc systems can't be predicted. I believe web exploit in the web apps is the key to running unsigned code on this system, considering the possible vulnerabilities here. The key(s) needed to do so would need to be found first, which I am told they have been by the real people who hacked PS3 and WiiU, they are the same group of 3 people. There is a ton of misinformation on who actually helped hack these systems and the real people do not want their names given out, I can tell you that some people on this forum claim to have been these people but they are not.

On a serious side note: I am wondering how you can 'overlap' tracks while burning to BD. BDs have two layers on bigger games, not every BD has multiple layers and both layers cannot/do not overlap or touch. The tracks cannot overlap on a single layer for obvious reasons, so then they would need to overlap between the two layers to accomplish some type of security feature, but those layers could still be read separately and then looked at from this angle after dumping. Then we would would probably need to do this again with another disc and compare the two dumped layers of each BD looking for byte similarities, that would be a clue as to where these 'keys' are and how/when they are used by the system.

 

[TomChaai]

I do not think the BD is the key to finding exploits here, I honestly believe the drive itself has nothing to do with getting an exploit working. Not that it isn't a possible route to take, but I think there are more than one. These checks would be irrelevant on systems without the disc drive. It may be a way to find an exploit on original systems, but how that would affect non disc systems can't be predicted. I believe web exploit in the web apps is the key to running unsigned code on this system, considering the possible vulnerabilities here. The key(s) needed to do so would need to be found first, which I am told they have been by the real people who hacked PS3 and WiiU, they are the same group of 3 people. There is a ton of misinformation on who actually helped hack these systems and the real people do not want their names given out, I can tell you that some people on this forum claim to have been these people but they are not.

On a serious side note: I am wondering how you can 'overlap' tracks while burning to BD. BDs have two layers on bigger games, not every BD has multiple layers and both layers cannot/do not overlap or touch. The tracks cannot overlap on a single layer for obvious reasons, so then they would need to overlap between the two layers to accomplish some type of security feature, but those layers could still be read separately and then looked at from this angle after dumping. Then we would would probably need to do this again with another disc and compare the two dumped layers of each BD looking for byte similarities, that would be a clue as to where these 'keys' are and how/when they are used by the system.

Drive hacks ONLY allow you to run backups that have identical content as authentic discs, nothing more, it does not allow unsigned code execution in any way. Oh maybe it also helps console repair effort, there are many consoles without a matching drives bricked during an update, if we can rekey the drives we can repair them.

Overlapping tracks are not burned onto a burnable BD, instead it's burned onto the master disc and stamped onto production stamped discs instead.

The master disc is a truly flat surface, with only data pits aligned to form a spiral data track, it can be burned twice to create overlapping features. "Burnable" BDs that you can buy from retail channels and burn with consumer burners are "pre-tracked" with valley-like blank data tracks so consumer burner lasers can track them. Since consumer burnable discs are already built, the track feature cannot be changed in any way.

It is not very useful to compare "byte streams", some features are truly random on a physical level, meaning for the SAME drive and SAME disc, read it twice and the byte streams can be different because those features are built to trick the drive electronics to measure them incorrectly and often randomly. A successful firmware hack needs not only to replay captured answers, but also replay different possible answers, or know how the answers will probably be generated on a physical level and simulate that.