Slashdot Mirror
Apple Files Patent for "Tamper-Resistant Code"
freaktheclown writes "The US Patent and Trademark Office has revealed that Apple has filed patent no. 20050246554 for a "system and method for creating tamper-resistant code." The system is presumably for use in Apple's Intel version of its Tiger operating system."
For those who are interested, link to the original application publication.
They didn't say tamper-proof. They said resistant. The scheme they describe would make it rather hard to alter they bytestream.
The Titanic was really sink-resitant...
What do you know I wrote a novel
This article has been up on mac-centric news sites for a while now. The difference is that all the others pointed out the more interesting aspect of the new patents: You can select, from MacOS X, Windows, and Linux a primary OS and secondary OS.
So not only is Apple not preventing users from installing Windows or Linux along side OS X, they are going out of their way to enable them to do so.
Michael Dell is feeling a tightening of the rectum right about now.
And yet...slashdotters are still preoccupied with how Apple might someday try to prevent the OS from being installed on non-Apple hardware.
By separating it into 2 or more inert components and storing them seperately. How is that at all like tamper-resistant code?
It's not impossible to create code that is very difficult to alter in a desirable manner, unless that desire is to have it cease functioning. The current StarForce copy protection achieves this by encrypting the executable and libraries of the program in question, and then running them on its own virtual machine which runs at the driver level. It sounds like Apple is planning to do exactly the same thing, unless I'm misinterpreting their patent. Each of their points says: But that's just how I'm reading it.. I could be wrong. At any rate, StarForce has yet to be cracked directly, but since its main purpose is to prevent copying, other weaknesses have been exploited; mainly in the area of virtual drives. Evidently it tries to identify the drives on a system, and if it successfully IDs one, it will require the disc to be placed in that drive. To ensure forward compatibility, if it cannot identify any of the drives, it will accept any drive that the disc appears to be in. It still attempts to blacklist virtual devices though, so the virtual drive software must be obfuscated. As I said, the only successful means of defeating the protection thus far have been to alter the data external to the program; the executables and DLLs themselves have not been successfully cracked, except when the publisher opted not to use encryption.
https://www.eff.org/https-everywhere
So patents are apparently written in a very strange way for reasons that no doubt make sense to someone. Aside from converting a tree structure into a series of numbered paragraphs (this patent describes an X being comprised of Y and Z. The Y comprises a Q, R, and S. etc.) it is also written in a bewilderingly specific and yet vague way so as to at all times make it clear that whenever they talk about something in particular, they in fact mean to include stuff that they haven't mentioned and may not even have thought of.
So, having tried to wade through all of this, here's my potted summary.
A "tamper-resistant" code block can be created *automatically* (i.e. not by hand) by translating an ordinary code block into a tamper-proof code block. The tamper proof code-block may be composed of checksummed code with extra inserted code that performs arbitrary operations (using, for example, information stored on a ROM, or taken from the computer's clock, or from the user's settings) and then is expected to produce a specific result.
E.g. multiply the current time by the user's name converted into a number and subtract the checksum of the code block and produce the number it did when the code was initially "tamper-proofed".
To verify the code has not been tampered with it can be executed in an environment (a virtual machine, say) which behaves like the real environment but where system calls have no effect so that only the ancillory results are produced. If these results aren't right, the code block is rejected.
I'm probably missing a lot, but the proposed system is AT LEAST this sophisticated, which is a heck of lot more convoluted than, say, checksumming code blocks. I think figuring this out is well beyond the script kiddies that produce the majority of malware.
It's not that it's unhackable, it's just too much trouble to have been broken so far. The encryption engine and relevant microcode is hidden deep in an ASIC, and no one has been able to secure an e-beam slicer long enough to open it up. There are only a few of them at major universities and chip fab labs, and it's pretty hard to "borrow" time on them during your lunch hour for such a "project". Someday, it will probably be broken but it has served the purpose of any successful encryption system - to keep sensitive data from prying eyes until it's no longer sensitive.
Actually, no one ever really cracked the P3 DRM either, what was known was due to internal leaks, rumored to have been possibly deliberate, as NDC (Rupert Murdoch) owns their competitor, Dish Network! Anyway, the P3 hacks were all workarounds that still needed the real hardware DRM decryption engine to do the work. There was rumors of a soft decryptor, but I never saw one and personally I think that was vaporware.
-- You are in a maze of little, twisty passages, all different... --