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.)
