DiSToAGe wrote:
not a backdoor, we forget to much that every system is only 1 and 0 through electricity and physical circuits. If you can make them you can watch them (with time and monney i agree). Perhaps thinking that datas (certs, instructions) can be "hidden" behind a physical thing is only a dream ? I ask myself if not every cryptosystem where you must have something "hidden" or "physically not accessible" in point of the process is not sure ?
In theory the above is absolutely correct. In practice, it's extremely difficult to properly implement an accurate enough emulator, however as an emulator writer you have far more advantages than disadvantages despite the 10-100x in slowdown. (Speaking from personal experience - no, nothing on the kind of scale we're talking about here.) You can always have your virtual CPU decide that when it sees a certain instruction, to disobey it. For example, when it sees a checksum check, to decide to jump around it and so forth. Gotta love it when you can fool a program into thinking that 2+2=5 and that everything is still A-OK with that! ;-) If you can interface with real (protected) hardware, you might even be able to get around public key schemes with the emulator. HP/Agilent made some wonderful logic analyzers, which are very useful against ancient hardware (think Motorola 68K chips at around 5MHz) too bad nothing in the GHz range is (cheaply?) available out there, but there's lots that can be done. What can be done? For example, if you have something like Palladium or whatever it's called these days, you an always build a machine that has custom RAM that can change at the flip of a switch - sort of like the old EEPROM emulators, but with RAM chips that can be flipped to a ROM instead. You flip a switch after the DRM core has validated your BIOS and operating system, and at some point once the CPU cache gets drained, it winds up running code that it did not boot, code which you've written to do *OTHER* things for example - simply change the IRQ vectors to point to your code and you've taken over... Mind you, all this is easier said that done, but it is possible to implement. Remember, security is a chain, and each (media?) player out there is a link in that chain. It only takes one broken player to wipe out your entire investment in that DRM pipe dream. Any employee with access can leak the master keys and the game is over. Any wily hardware hacker with plenty of time on his hands can take a shot at reverse engineering any (media) player to the point of cracking it, etc. In the end, it's a waste of time and money for the makers of DRM as there's enough interest that someone somewhere will break it at some point in the near future. You can play cat and mouse games by watermarking the output with the serial # of the player in order to lock out cracked players, but the attacker only has to break more than one player (perhaps two different models so they get both serial # and model #) and compare the resulting outputs from the same movie to figure out which bits contain the watermarks. XOR is very nice for figuring this out. :-) None of this worries me, because I don't give a rats ass about copying movies or what not. Couldn't care less about it. I'll wait for the shit to make it to HBO, it's usually not worth watching the waste of Hollywood plotless overhyped crud anyway, so why worry about copying it? The few titles that are worth watching, are also well worth buying, and after a few months they can be had for under $20, so why bother? What is cause for worry is that it's quite _possible_ for Intel or other chip manufacturers to insert backdoors in their hardware which someone will go through the trouble of discovering, which does put everyone at risk. No matter how good your operating system and firewall rules, if your network card (and drivers) decide to bend over upon receiving a specially crafted packet, you're owned just the same. Mind you, I've never run across anything close to this, except perhaps the old F00FC7C8 bug in the original pentium (which really was a DOS, not a back door) and the old UltraSparc I in 64 bit mode multiuser hole. The Pentium IV hyperthreading bug is something recent to worry about along the same line of thought. Sadly, you haven't got much choice in this matter, you have to assume that you can trust the hardware that you run on (unless you're willing to make your own and have the resources to do so, etc.)