A Idea of a new xbox hack

[SSkillZ]

Hello,
I was wondering about a hack that could work, not really better than the ones we already have but could be interesting.
The plan is to interface (sit in between - sniffing) with a xbox dvd drive laser opto, disc motor hall sensors, and the laser head position stepper.
Then insert a disc, install the game to the xbox HDD, and play it once, using a ADC record all the raw data of the disc (We may use the 0080 fw instead)
that has been passed to the drive. Then using the same interface and DAC to play it back to the xbox sensors.
I know this will be hard because the tracking system is complex, and it has reading errors and such (though they should matter to us), and
the reading speed is over 15MBs because its raw data combined with position and you get even more data so will need a fast hardware.

The advantage of this is that it could be a 1:1 raw (but large) digital copy of the disc and could be unstoppable by m$
if done correctly (depends on how xbox disc format works and if m$ haven't got any secrets on the disc that they didn't reveal yet), And you won't need the DVDKey.
Do you think it could work? How much data do you think the raw copy be? Could a firmware like the 0080 fw be used for the reading part? What hardware will be needed?


P.S I was also thinking about building a raw DVD controller, but I can't find info on someone who even tried a CD one,
all I find is using an already working controller and interfacing the IDE/SATA part. Do you know where I can find projects of someone building the
controller of the tracking system itself?

Thanks ahead,
Paul.

[Xumpy]

I'm not exactly sure what you mean but could it be something like this thing does: http://xk3y.com/

[SSkillZ]

I'm not exactly sure what you mean but could it be something like this thing does: http://xk3y.com/

The result could be the same - using USB/External HDD to load games on xbox,
But that one uses the DVDKey(and ixtreme fw)  you supply and encrypts using emulator software then sends it over sata to the xbox.
I'm suggesting feeding raw data (Playing back) to the xbox dvd drive for it to be encrypted using the original fw on the drive so you won't
need the DVDKey, and in theory shouldn't need updating and maybe can't be defeated...

This is the diagram:

The stepper motor is not analog, so I guess we won't need the DAC/ADC, I don't know if the opto reader is analog, It can be digital (laser on/off, layer1/2).
We connect using the flex cables and we sit before the dvd chip so it gets to do the encrypting for us.
Anyway, we track what sector/position/track the xbox is reading while we install to HDD/play and we write to our storage device (HDD in the diagram).
Then we could use that information to play it back, we track which sector/position/track the xbox is trying to read,using ADC, and play back the correct
data (that we stored earlier) using DAC.

It is a naive approach, possible hard, but could work.

[Xumpy]

If I understand you correctly your trying to get an installed game on the hdd working without the original dvd right??

Well understand that everything in the console is encrypted so you can not change any behavior of the dashboard.

This in mind you need to know that the default behavior is that when an xbox wants to start a game from harddisk it needs to check if the original dvd is in the drive.

This requires it to read a 'dvd-game'. Only the correct firmware is able to play dvd-games. Even if you could somehow duplicate the firmware his actions your still depending on the dvd key that is kept inside of this firmware (which is unique per console).

That is the hole reason why the xk3y needs the dvdkey and ixtreme to work...

So your method might work for your xbox if you have your original drive and scan everything that happens and simulate this, but you can not never ever distribute this to other consoles.

The drive key is in the keyvault which is encrypted with the cpu key.

This can not be changed unless you could sign your kernel again, which is impossible without the private key...

[TicoDePano]

seems a good idea for me

at this level of emulation, you could not need the dvd key

anyway, seems too hard to emulate these signals from the specifics parts of the drive

[xboxbreaker]

I understand what you mean, you mean to actually feed the data the laser would normally read into the drive FW. Yes that bypasses the security, but it would require a very complicated emulation. You would need to work out what sector of the disk the FW is trying to read using the signals sent to the worm gear motor and laser, emulate all the signals the laser caddy produces, then also work out the data rate according to the speed the disc motor would be rotating at. Good luck with that lol.

[HB]

I actually proposed an idea like this a few years back.  Dig around here on the site and you'll find a thread in which I was flamed... repeatedly.  Heh.

After doing a bit of research, it actually looked like you didn't need to accurately track the motors themselves - the way a DVD works is very similar to a record-player, in that the drive controller positions the laser-head approximately where it thinks the data it is looking for, and then it lets the laser automatically track the "groove."  The controller doesn't make any "fine" control movements once it finds the location it is searching for.  It literally is like a person searching for a particular track or even location on an old vinyl record - just move the head to your best guess, listen to see if you're close, and if you are just let it keep playing.  If you aren't close enough, then you try again.  The tracking happens automatically without any software intervention.  Focus adsjustment is also done in a similar, automated fashion without software interaction.

If you dig around, you'll find that the laser-head uses an optical detector which has 4 quadrants.  The lense is such that when the head is "in-focus" and "on-track," all four quadrants are illuminated by the reflected laser light equally.  When the beam is out-of-focus or off-track, then the 4 quadrants are illuminated incorrectly and the difference between the signals is amplified and used to adjust the focus or tracking.  Zero software interaction and very easy to emulate using DACs.

The algorithm to emulate this behavior would be to loosly listen to the motor commands issued by the DVD controller and playback data via the virtual optical detector (using a DAC) and then listening to the additional motor commands from the DVD controller.  Again, you don't need to be ultra precise, because eventually the controller just realizes the data is close enough and that eventually it will find the data it is actually searching for as it gets played back.

A 12X DVD drive would require about 125mbps of data (10.5mpbs per "X"), which means you need a pretty fast DAC and a lot of throughput in your system.  One hurdle I found at the time was finding a suitable micro-controller that could behave as a SATA device (there are tons of micro-controllers out there which behave as SATA hosts, but I didn't find many that worked as SATA devices).  Finding devices that ALSO supported USB 2.0 speeds (for the hard-drive connection) was a tall order.  FPGAs and CPLDs could be used, but that is a huge problem to tackle.  But there are probably devices out there will fit the bill.

EDIT: Found my old thread - http://www.xboxhacker.org/index.php?topic=12220
EDIT2: Not sure why I mentioned it being a complication that most microcontrollers aren't setup to be SATA devices (vs hosts) - that isn't relevant here.

[Tiros]

I actually proposed an idea like this a few years back.  Dig around here on the site and you'll find a thread in which I was flamed... repeatedly.  Heh.

And all those flames were well deserved 
This was and still is a stupid idea, proposed again and again by people (aka "Idea Men") who haven't the slightest clue how to pull it off. In fact its even worse an idea now than it was in the pre - ap25 days. Even if you had the uber expensive hardware and the gigantic amount of space required for each image, it still isnt going to encode security information required to pass various disk checks.

[Gazcoigne]

All the hacks were deemed "impossible" or "dumb" and by "idea men" at one stage or another.

i for one think this is plausible, and what is the harm in discussion?

i remember the author of the reboot hack being flamed on here for his ideas. now we have rebooters.

i remember c4eva being flamed on here for his ideas bythespecialist yourself and arakon. people on this board wouldnt touch his CFW but i believed in him and sacrificed my xbox to test it. now we have LT.

some idea men do produce the goods, dont stamp them out from your high horse, just because you can.

i remember you stating "slims wont be playing backups on live for very long" or something to that effect

edit:

http://www.xboxhacker.org/index.php?topic=16256.msg120182#msg120182

1) Ap25 is not "beat".
2) XGD3 won't fit on burnable media.
3) The FS can not "trimmed".
4) The "rootkit" is a joke.
5) Without a new Hv/Kernel level hack, backups and FW mods will soon be over, both on and offline (at least for slim).
6) The emporer has no clothes

1. Looks like it to me, even with console specific DAE.bin changing frequently, silver bullet beats all currently.
2. Burnermax FTW
3. Agreed
4. Seems to be working
5. CFW going strong

my slim has been running fine for quite some time now, and with the latest topology hack for LT3.0, and AP2.5 seemingly defeated, i wonder what your next opinion will be on this, i for one would love to know, care to share?

I know you have no affection or concern for CFW, but i value your opinion, want to join the discussion as to why it wouldnt work instead of just flaming?

this looks a like a good discussion on hacking, not how to make a mass produced device to enable easier piracy to the masses.

from HB's posts i think he has done quite a lot of research, not the usual type of "idea men" that you see on screaming for new haxorz for their warez.

[SSkillZ]

I actually proposed an idea like this a few years back.  Dig around here on the site and you'll find a thread in which I was flamed... repeatedly.  Heh.

And all those flames were well deserved 
This was and still is a stupid idea, proposed again and again by people (aka "Idea Men") who haven't the slightest clue how to pull it off. In fact its even worse an idea now than it was in the pre - ap25 days. Even if you had the uber expensive hardware and the gigantic amount of space required for each image, it still isnt going to encode security information required to pass various disk checks.

I do have the slightest clue, but I was just wonder what hardware will it take, have you got any idea?
Why should AP25 makes any difference? Its a raw copy, the software will emulate a real disc. 
And the data could be compressed to more of a reasonable size.
I don't think the hardware should be that expensive, if an DVD drive costs 20$ and can handle the 12x read speed how much more will it
cost to add some DAC/ADCs? Don't take the storage device as a cost as it replaces buying discs.
You can buy an arm7 development board for 50$, the parts them self are much more cheaper...

As m$ manages to block Jtaging/RGHs newer consoles, if they make the DVD read only or its DVDKey undumpable this could be a solution.

[xboxbreaker]

Why should AP25 makes any difference? Its a raw copy, the software will emulate a real disc.

The main problem being that images that are around now are not raw copies, and they do not contain positional/geometry data.
For example, even if you had a custom drive FW that ripped an exact raw copy of the disc from the first "pit" to last pit, that image still does not contain information on what the angles are between two data sectors. So your emulator also needs a way to calculate the exact position of data on your emulated disc and measure angles within a reasonable degree of accuracy.

I'm sure it will be more complicated than using the equation for a spiral to calculate positions and then working out some fake data fetch times. But then perhaps you can implement the topology data as is used at the moment in LT3.0 into the raw image.

The advantage xkey has is that it uses the topology hack to answer ap2.5 queries, and also it can decode the commands issues by the motherboard, so it knows exactly what data it is looking for. You have to work all this out using voltages being sent to motors.

I also agree that it is possible and would be fun to try, but it seems like a monumental and impractical task!

[Xumpy]

I see it know, it's not about the data being sent to the xbox but the data being sent from the lens to the firmware...

You want to record this data and replay it so the xbox thinks you have the original disc inside the drive and boot the game from harddisk???

I'm not so knowledgeable with the dvd drive but couldn't ms just change the way games need to be read.

I mean just a simple security implantation that first the end of the disc must be red until the game may start could be enough not??

It seems to me that this hack is possible but that it can be easily overcome, especially if you want to play on live or keep the box updated not???

Hey but nice idea,

Regards

*EDIT*
Nevermind you want to record the entire disc as raw data and build an interface to emulate this disc.
Cool idea but sounds very pricy :p Good luck, I'm keeping my nose out of this

[xboxbreaker]

It seems to me that this hack is possible but that it can be easily overcome, especially if you want to play on live or keep the box updated not???

Provided the massive task of emulating a DVD realistically is overcome I don't see how MS could detect it or prevent it. If someone could care to correct me? The placement of the hack means that it is right at the bottom level, before any security is implemented.

The problems are making a 100% raw copy of the DVD and emulating it within software with a small margin of error.

[SSkillZ]

Well one of the reasons I posted this is to get a idea of the hardware needed for this project,
What processor speed?, DAC/ADC speed will be needed? If anyone can estimate please do...
I couldn't find projects for building a DVD Drive controller, all I find is from the SATA/IDE end. If anyone can help
me find projects of someone building one or something of the like please post.

Thanks,
Paul.

[Tiros]

i remember the author of the reboot hack being flamed on here for his ideas. now we have rebooters.
i remember c4eva being flamed on here for his ideas bythespecialist yourself and arakon.
i remember you stating "slims wont be playing backups on live for very long" or something to that

Perhaps all yer dope smoking has affected your memory
Check my posts, I remember suggesting a rebooter LONG before even arnezami came along (think KK exploit) I called it "two card monte" or "chainloading". in fact I implemented MY idea at that time.
Flaming c4e for not implementing DMI or splitvid? Quite possibly. Was I wrong? How many got banned for that?
Furthermore I stand behind MY post that you quoted. Time will tell.

"Idea Men" are only talk. When you say you have actually tried something, and report your results, at that point you have escalated yourself from being an "Idea Man" to a hacker. Its not my job to explain why ridiculous ideas are flawed. If you think they have merit, than go ahead and implement. Post some results. Ask for help. If you just wanna run yer jaw about them, head on over to XS. Not one single hack has resulted from the speculations of "Idea Men" as defined above. The people capable of implementing thier OWN ideas have provided ALL the results you have seen.

FWIW the checks rely on PHYSICAL characteristics of the media, not only the data. The copy will not be 1:1. Im sure there will be some speculation on some way around that problem as well. Im equally sure that no one in this thread will ever pick up a soldering iron or write one line of code to implement or test any of this nonsense. The people who *might* be capabable, already know better than to waste the time.

I won't be responding in this useless thread again.

[HB]

What processor speed?, DAC/ADC speed will be needed? If anyone can estimate please do...
I couldn't find projects for building a DVD Drive controller, all I find is from the SATA/IDE end. If anyone can help
me find projects of someone building one or something of the like please post.

Well, the data-rate at 12x is, as I said, around 125mbps.  So the absolute minimum clock of whatever output method you choose is 125mhz.  You could use a DAC, though my guess is that just using a GPIO line and a low-pass RC filter would be sufficient (pits and lands on the DVD are 0's and 1's, afterall... so why would you need an analog signal provided by a DAC?).  So with that in mind, you might be able to use a serial shift register, UART, or SPI peripheral.  A thing to keep in mind is how to simulate different read speeds of the drive - 12x is the peak speed, but is not the speed the drive is always read at.  So you'd need to be able to adjust the speed of your output method (either by changing the clock-rate, by extending and dithering the length of the 1's and 0's as the read-speed slows down, or some other method).

The ADCs to monitor the head-tracking would need a bit of looking into, but my guess is that they just apply a bias to the servo-loop's feedback, and therefore a fairly low resolution ADC would be fine (10 bits is pretty common on microcontrollers).

In order to determine the read-speed, you'd need to monitor the digital signals to the spindel stepper motor.  This is just regular GPIO and probably is not a problem on almost any modern processor.  Same with the disk caddy/eject and all that discrete stuff.

Check out the ECMA-267 standard - it is the European equivalent of the ISO standard DVDs are based on, but unlike the ISO standard, the European one is free to download.  It discusses everything you need to know about how to build a DVD drive and includes all of the physical specifications for the DVD disc itself as well as the requirements of the optical system and so-forth.  The precision of the optics and the mechanical head-tracking actuator are the hard-parts (obviously - those are pretty much the guts of the drive); the electronics are fairly simple.

Everyone on here who has said it is a big project is correct - this isn't trivial.  In my opinion, the best way to move forward would be to find some old 1x CD-ROM drives (or just use modern ones with an audio CD which is intrisically 1x) because the timings involved are much looser - you don't need nearly as fast a processor/ADC/DAC/oscilloscopes/etc.  Prototype a system that can emulate an audio CD in a PC, and then take that prototype and ramp it up until you can emulate a 12x drive on a PC, and then keep going from there.As many have pointed out, the ISO rips that are available probably won't have enough information in them to defeat the MS checks on the 360.  But if you can get the hardware working well enough to emulate a CD-ROM or a DVD in a PC, you can eventually build a ripping tool to do a full bit-for-bit rip (including geometry info) of a disc and play it back.  But that's another project in itself.

[SSkillZ]

I read the standard, its an interesting subject, I see the physical bits size of the disc is as twice as the data on the disc because
they convert all the bytes from 8bits to 16bits using a conversion table to prevent trailing 0 and 1 in the NRZI modulation.
This means the reading should be twice as fast than the data... not in our favor, But could be converted back by a fast shift register instead of software.
If we convert those 16bits back to what they represent, the physical raw data size of the entire disc is not as big as I thought, If I'm correct with ECC,
Sector data (Number,Id,flags..) and all the relevant its about 1.155 times the data, so ~8.7*1.155 = ~10GB (Not including lead in and stuff.. but that negligible).
Not that bad...



I also find a book about how DVD works  (including hardware) called DVD players and drives by K.F. Ibrahim, I may read it to understand more about the topic.

[peshkohacka]

It seems to me that this hack is possible but that it can be easily overcome, especially if you want to play on live or keep the box updated not???

Provided the massive task of emulating a DVD realistically is overcome I don't see how MS could detect it or prevent it. If someone could care to correct me? The placement of the hack means that it is right at the bottom level, before any security is implemented.

The problems are making a 100% raw copy of the DVD and emulating it within software with a small margin of error.

Its easily detectable, because when a few consoles report the same PI/PO errors MS will notice the replay-attack pattern, not to mention the constant speed (i.e. your dump would have the same speed as the other people using it) and AP2.5, which here would be a problem, because you don't have a map of the disc to know what data you should return. You can't put an ISO and emulate it, because ISO's are not identical to XGD pressed discs, you need raw data dumped from the pressed disc. Also a game requests different files at different stages, you cant just replay with pre-recorded data, you'll have to create a micro-controller that understands and returns the correct data. So you need 2 things: hardware capable of understanding and forwarding requests and software analyzing/working with the raw dump.

I don't want to bash or discourage you, but this type of attack is not feasible and in the long-term and benefits are only piracy no homebrew or anything worth doing it for.

[SSkillZ]

I think the attack is feasible, and not easily detectable: PI/PO Errors will be generated, speed will be changed by time and by the radius from center (as it will follow the tracking ahead stepper).
And a map of the disc can be generated using the same hardware, as I pointed earlier it shouldn't be that big. Yea the game request different data all the time, this is done by seeking
which in turn moves the reading head to find the sector, we don't know which sector the drive wants, but we know the position of the head motor so we can return the right sectors (because
the disc should be spinning we need to sequence several sectors) with random generated PI/PO errors if you'll like.

Yea this will probably benefit piracy and not homebrew but I wanted to discuss it as I find it interesting, and would like to get a idea of hardware involved
if it won't be too high end, ill give it a go. Speaking of hardware, HB pointed out that:

Well, the data-rate at 12x is, as I said, around 125mbps.  So the absolute minimum clock of whatever output method you choose is 125mhz.

Because all the data on the disc is multiples of 8 we can using a 8bit shift register and 8 parallel inputs to effectively lower the frequency of data and read one byte at a time,
thus lowering the minimum to 15.625Mhz.

[HB]

Yea this will probably benefit piracy and not homebrew but I wanted to discuss it as I find it interesting, and would like to get a idea of hardware involved
if it won't be too high end, ill give it a go. Speaking of hardware, HB pointed out that:

Well, the data-rate at 12x is, as I said, around 125mbps.  So the absolute minimum clock of whatever output method you choose is 125mhz.

Because all the data on the disc is multiples of 8 we can using a 8bit shift register and 8 parallel inputs to effectively lower the frequency of data and read one byte at a time,
thus lowering the minimum to 15.625Mhz.

I agree the only real use of this device would be piracy (and possibly as a "convenience" to store all of your legit images on a hard-drive and therefore not need to swap discs)... it has the same merits as the xKey ODD emulators and those types of devices.  Whether it is useful for anything more than piracy or not doesn't mean it isn't an interesting project from a technical and challenge standpoint, though.  Why'd you climb that mountain?  Because it's there.

Anyhow, your statements are correct that the data would need to be delivered to the serial shift register at 15.625MBps (if the 8-bit data were not encoded into 16-bit format), but the data would still need to be shifted out of the register at 125mbps.  So somewhere, you'd still need a 125Mhz clock for the shift portion.  And as you mentioned before, the 8-bit data is encoded into a 16-bit format to keep the DC bias to a minimum, so you'd need double those data-rates and frequencies.  Suddenly we're talking 250mhz clocks (for the output stage of the serial shift register) which is not a trivial frequency to work with when it comes to design and test equipment.