Do ISOs created with XBC contain enough info to recreate exact original?

[HB]

Hey folk... I was just curious if the ISO files which are created using XBC contain all the information necessary to create an exact pit-for-pit (yes, pit - not bit) duplicate of the original.  Do the ISOs contain all the info in the lead-in, the lead-out, the "corrupted" special areas, etc?

My thought is to create an adapter board which essentially replaces the DVD drive sled/laser/pickup and mimmicks it using a PC.  An MCU could be developed which basically plugs in via the ribbon cables to a stock drive and using A/D converters, senses the sled movement requests.  It then basically "guesses" where the head is trying to get to and then starts spitting out a signal via a D/A into the stock drive's sensor inputs.  The stock drive's processor/DSP will decode that, decide if the correct data is coming through, and then attempt to adjust the sled position.  "Tracking" would happen automatically.

We'd essentially be emulating the DVD motor controller and the pickup sensor array.

Using this method, it would be possible to emulate the disc itself - no firmware hacking on future drives, or anything.  You just store an ISO on your PC which has all the necessary from the original.  You could recreate sector-to-sector angles, errors, etc.

Yes, it would require a fast D/A and potentially a precision A/D, but I think the hardware is very doable.  No idea how much it would cost, though... but I'd like to do it as a project just for my own personal gratification, if nothing else.

[B1N4RY]

Honestly, you are not the first one who have came up with crazy ideas like this

[HB]

Honestly, you are not the first one who have came up with crazy ideas like this

I am not looking for commentary on whether or not my idea is crazy.  I'd be willing to bet that a lot of what has already been accomplished by others with the Xbox, Xbox 360, and many other consoles was considered crazy before someone actually did it.  Look at the "unhackable" Lite-On, the 8xxxx key cracking going from "it'll never happen" to "here's FreeKey, have fun" in about two days... etc, etc.

All I am doing is asking a reasonably simple question and would appreciate it if people would keep their flames to themselves.  If there is constructive criticism with actual insight as to why what I'm talking about doing might be impossible, then sure - let me know.  But just saying it's crazy because it hasn't been accomplished before is not helpful or useful at all.

[B1N4RY]

The Liteon 83530C hack was highly plausible, so is an ISO emulator.
However, making an ISO emulator work the way you have described is ,no offense, but ridiculous
Expect a ISO emulator to surface once a custom dashboard is made

[HB]

The Liteon 83530C hack was highly plausible, so is an ISO emulator.
However, making an ISO emulator work the way you have described is ,no offense, but ridiculous
Expect a ISO emulator to surface once a custom dashboard is made

You know... wouldn't it be easier to just answer my original question, than to attack and decry that my idea is ridiculous (regardless of whether the idea is easy, the best approach, original, or not)?  I don't understand why everyone is so hostile towards new (or even old) ideas.

I agree that there will probably eventually be ISO emulators that run directly on the 360.  And there will probably be a lot of other amazing innovations, too.  But that doesn't mean I have to just sit back, twiddle my thumbs, and wait.  I have most of the resources and skills necessary to explore this idea, so there's no harm in my doing so.  And if absolutely nothing else, it would be a good way for me to learn a lot of new stuff.  Even if the idea fails doesn't mean I can't gain from it.

Anyhow, I'll keep looking into things and if it turns out that it isn't feasible afterall, then hey - so be it.  But for now, I feel it is feasible and it is something that I will pursue.

If anyone has an answer to my original question, thank you and I appreciate it.  If anyone has any specific thoughts on why this might not work, I appreciate that, too.  But if you just want to tell me I am ridiculous (no offense taken) with little to no basis for the statement, then please just ignore this thread and move on.

A DVD burner already has most of the hardware that would be necessary - just take the signal that would ordinarily go to the write-laser, massage it a little bit, and send it into the read-sensor of the 360 drive.  Yes, this is an overly simplified model, but it's the basic idea.  You just cut the middle-men out of the situation (the middle-men being the write-laser and associated optics, the actual disc itself, and the read-laser and associated optics).

[Intersect]

  You need special equipment in order to do an exact dump. Burning it is also an entirely different issue. You'd also need special media to do it. If I remember correctly, tmbinc did some work on this kind of thing, modifying drive firmware to do exact disc dumps, there might be some posts on his blog @ debugmo.de still, and he also has some stuff about disc authentication, but honestly it's too much work and somewhat pointless to go this route when the techniques in the ix firmwares could just be implemented on the device created for emulating discs. If you search google for xboxhacker and then ezekiel I think his name was, he could replicate discs exactly using special equipment, and that might explain a little more about what's required, as well as some discussion with martin_sw (who was right most of the time).

 Drive emulation, can be done in a much easier fashion that wouldn't require as much special hardware as what you're describing, and then all the fine tuning of that to get it to actually work. But the best thing to do would be to take advantage of the 360's existing ability to copy games to the 360 hard drive, and run them from it. Since the disc is required for authentication, you could create a device that can respond to these cdbs, properly encrypted, and make a way to switch between stealth files per game. You would also probably need to store some other information to cover all checks. In the end who would it help? lazy pirate kiddies? I don't see a problem with getting off the couch for a minute and switching games, and if you already own the game, making an iso from it and then running that would just be a waste of time.

[HB]

Intersect,

I appreciate the response.  I will look for the blogs and threads that you have suggested.

As for who it's for - it's not necessarily for anyone.  If noone else finds it useful, then it would be just for me.

[Intersect]

Do you understand the crypto, disc geometry/cr, hashtables, etc ? as well as every single cdb that gets sent to the drive.

[HB]

Intersect,

No - I don't know most of that stuff.  But that is my point - if you emulate the disc (not the drive, but I mean the disc itself without actually using physical disc media... in real-time by injecting signals into the xbox drive's pickup head), then all you're doing is replaying whatever was stored on the original disc.  It doesn't matter what the data is... the custom hardware doesn't need to know why it's getting the data, nor does it need to process it or spoof it - it just needs to get it.

The tracking mechanisms on DVD drives are fairly primitive - they are basically like a record player.  The pickup head is instructed to move a certain distance out, the drive starts reading information and the firmware checks to see if the head is where it is supposed to be, and if it isn't, then it instructs the head to move a bit further (it's just like trying to find a song on an old-school record player - you put the pickup down, listen for a second, and if it's not what you want, you adjust it again).  From there, the head automatically, without firmware intervention, just tracks the spiral "groove" by using a differential amplifier and a servo motor.  This all exists in the stock Xbox drive.  This mechanism has nothing to do with challenge/responses, encrypted data, SS sectors, or anything.  It's just standard, run of the mill DVD technology.

The stock firmware itself has no way of knowing whether the signal that it is receiving into its DSP section is being generated in the standard way, IE through the optical sensor's pickup, or if the ribbon cable has been removed and instead the signal is coming from a custom adapter/processor/whatever.

If this were to work, then you'd never need to worry about future firmwares finally being hacker-proof and not being able to get keys - all those problems go away, because all you're doing is blindly providing data.  The stock MS firmware generates all the responses to the challenges, etc.

The only real challenge that I see is getting a digital-to-analog converter which is fast enough to recreate the signal.  At 12x, the raw data streem is roughly 256mbits per second
(the raw, encoded stream off of the disc... this stream gets processed and reduced by way of stripping the ECC codes, Reed-Solomon codes, etc, to arrive at a final rate of 126mbits).  In order to get even a primitive system working, you need to double that rate... and realistically, you'd need to go 4x that rate - so now we're talking roughly 1giga-sample per second.  And that is fast - DAC's of that speed cost about $25-$35.  Not to mention that you then have to have a very fast processor in order to generate all of this data (the PC sends standard un-encoded data which then has to be turned into DVD frames, scrambled, reed-solomon encoded, etc).

So like I said... this may not be useful for anyone else.  It is just a project that I have been toying with in my head, and in order to make it work with absolute stock firmware, I would need to be able to get exact images of originals.  I could still experiment with a modded drive using IX1.6 or so, and then it would work with the existing XBC ISOs.  That could be used as proof of concept, and then if I am able to get that working, then the next step would be to make it work using raw images.

All just ideas of things that could be done... not because they need to be done, or even because they should be done... but because they interest me.

[Intersect]

If you can find a way to replicate the disc exactly, then sure it would work, assuming you could get the right media to burn it to, and the proper hardware to burn it, and the proper hardware/setup to dump it exactly pit for pit. I think you will find that getting a combination of all of these things actually working perfectly is a lot harder than the concept seems. If your goal is to just f*** around with some stuff, great, but actually finding out whether you dumped that disc exactly, and properly, is going to be tough. Then there's the issue of finding the proper media, etc etc. What you're trying to do is what the 360 already does with originals. If what you want to do is play from isos, this is the wrong route.

[HB]

This idea does not use recordable media.  Period.  That is part of what makes this idea appealing to me.

[Intersect]

injecting data, well, you'd have to be so impossibly accurate.

[neonpolaris]

Would it not be easier to emulate the whole drive rather than to emulate the hardware to the drive's controller?

[HB]

If you put an original Xbox-360 game inside of a stock Xbox-360 drive, the drive's hardware reads the disc.  I think we can all agree on this.  How does the drive read the disc, you ask?

In very simple terms, a laser is shone on the disc as it spins by.  The laser bounces off of the disc and a sensor (just like the sensor in a digital-camera) picks up that light, and depending on whether the laser is bouncing off of a pit or not on the disc, the intensity of the light is different and the sensor therefore outputs a voltage which is related to the light's intensity.  This voltage then goes into the drive's processor, at which point it is processed and using some DSP techniques, it is determined if the voltage represents a "1" or a "0".  This 1 or 0 is then passed onto the decoder which does all of the ECC, reed-solomon stuff, etc, and from there it goes into the standard firmware that we all know and love to handle challenge/responses, SATA communication, etc.

Well... all that the processor sees from the disc is that one single solitary electrical signal which represents the light intensity on the pickup sensor (well, there are 4 sensors, but I'm ommiting that for now to keep things simple).  That little ribbon cable that goes from the logic board to the laser assembly - that cable is what carries these electrical signals from the sensor and into the logic board.

So why not just unplug the ribbon cable and replace it with a board that generates that single little voltage signal?  You don't actually use a disc or any form of media to do this - you have an adapter board which knows what the signal should look like, generates it, and then the stock firmware sees that signal, thinks that it is coming from a live spinning disc, and decodes it, and does everything else from there.

In order to do this, literally all you need is the following - a digital to analog converter to generate this signal.  a set of analog to digital converters to sense the motor logic for the sled as well as the focus (to select the relevant layer), and a processor to generate the encoded data stream.  All of the data is stored on a PC in ISO format, and the PC has an application which sends out the needed info from the ISO file to the custom processor via a USB 2 connection.

There is no media involved - you have taken the media out of the equation.  That is the entire point.  That and you can now use a PC to store your ISO's.  It doesn't even automate switching games - you still have to get up and go to the PC and tell the PC application which "disc" it should be emulating.  And if MS changes their firmware, this system is unaffected and cannot be detected.

So yes, I just want to f*** around and see if it can be done.  I am certain it is doable - no doubt.  Whether I am able to do it (because of the frequencies involved), I can't say at this point.  But there is not technical reason that it isn't feasible.

[HB]

Would it not be easier to emulate the whole drive rather than to emulate the hardware to the drive's controller?

This has been discussed a number of times, and I believe it has its merits as well.  The main hurdle to that is that you then need to know every single nitty gritty detail about how the SATA, ATAPI, SS, etc works.  And I certainly don't know that.  There are a few people that do seem to know all of that, but they don't want to share.  I don't hold that against them, I'm just saying that I am not in a position to try to reverse engineer the entire security system.

My idea just leaves the existing security system in place and uses it to our advantage.  If Microsoft changes their firmware, no problem - they still have to rely on a raw analog signal coming into their system at some point or another.

It's a little like the "analog hole" in secure digital TV - cable-boxes and most HD devices still have component output cables, even though in reality this breaks the chain of encrypted HDCP devices when using HDMI.  There are devices (Hauppauge HD-PVR) which digitize these analog signals, compress them as H264, and basically allow you to record your own shows in HD (up to 1080i) even though the cable-companies don't want you to.  I did this with my current HTPC setup, and it worked great (I eventually sold the thing, though, because there just wasn't enough stuff in HD that I wanted to watch).

This in the same realm of ideas.

[HB]

injecting data, well, you'd have to be so impossibly accurate.

Agreed - getting a DAC and a host processor running at those speeds definitely poses a challenge.  But that is just regular electrical engineering work - it isn't really reverse engineering work.  Gigabit ethernet uses speeds in that realm, SATA uses speeds in that realm, there are lots of technologies that operate at speeds like that.

And in fact the tolerances of the formal DVD specification allows for something like 8% jitter, which leaves a lot of room for making errors that will still be recovered from.  Not to mention that Microsoft (well, Samsung, Hitachi, BenQ, and LiteOn) all spend a lot of time and money working on good DSP sections of their drives to deal with these inaccuracies because they need to deal with scratched discs, dirty discs, worn pickups, worn motors, etc.

[Intersect]

 You can't think of things on the ultra low level, and ignore the high level. Sure, if you had an exact dump you could attach a magical custom board that plays back the signal exactly. But that's assuming you know exactly what part of what you stored is being retrieved, and that you can replay this accurately enough to be as exact as the 360's challenge/response and lba hash verification needs.

 My point is, by all means have fun f***ing around to see if you can get it to read something, but getting it to correspond with each cdb is going to be a hell of a task. If you want to simply eliminate the chance of backups being detected, play originals. If you want to eliminate the need for a disk, create a device that replicates the original drive's responses to the authentication, then run games from hard drive. You can write all of the technical information you want about how the drive works, but the fact is this stuff can be done cheaper, easier, and less time.

[No_Name]

Would it not be easier to emulate the whole drive rather than to emulate the hardware to the drive's controller?

  If Microsoft changes their firmware, no problem - they still have to rely on a raw analog signal coming into their system at some point or another.

I am confused.. What do you mean raw analog signal??
The console is a digital device not an analog device.

[HB]

I am confused.. What do you mean raw analog signal??
The console is a digital device not an analog device.

The DVD disc itself represents its data digitally - pits and lands (or dark and light, if you're using recordable media) represent 1's and 0's.

However, when the laser bounces off of these pits and lands, what you're getting back is effectively just a measurement of the distance between the data layer in the disc and the optical sensor of the drive - it isn't digital yet.  This measurement is an analog voltage, which is then digitized using an analog-to-digital converter (ADC).  This digital representation is then processed by the DSP and filtered to remove noise from the signal, adjust the gain of the signal, and then it is determined whether portions of the signal represent a "1" or a "0".  From there on, the data is always digital.

But between the optical pickup and the DSP, the signal is definitely analog.

The same principles hold true for almost all modern digital storage technologies (that use media, I mean... SSDs don't count) - hard drives use pole orientation of a magnetic field and a GMR sensor to obtain the signal.  Not sure how tape drives and even old floppy drives work, but they probably use a low-pass filter and a comparator to do very simple processing.

[Intersect]

Either way it's still a waste of time to do