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

Comments

Link to patent publication

[Paska]

For those who are interested, link to the original application publication.

Missed the point

[rhesuspieces00]

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.

Re:Sounds impossible

[StikyPad]

Sounds kind of like having an acid that can eat through anything. How do you can you keep it in a container if it can eat through anything?

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:

"a machine-readable medium that provides instructions, which when executed by a machine, cause the machine to perform operations comprising: installing a first object code program, wherein the installing includes, statically translating the first object code program into a second object code program that is executable on a machine, wherein the statically translating includes, determining an identifier based on a state of the machine or a user attribute; and obfuscating the first object code program or the second object code program, wherein the obfuscating depends on the identifier; and storing the second object code program for execution by the machine."

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.

Has anyone actually read TFPA?

[podperson]

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.