Slashdot Mirror
On the (Im)possibility of Obfuscating Programs
sl956 writes: "We all know that anybody using the words 'tamper resistant' to describe a software-based solution is incompetent at best. But some of the big players in the DRM field are believing in software-only protection schemes (see Cloakware, Hitachi, IBM or Intel). A mostly unnoticed paper presented to CRYPTO'01 (Santa Barbara, CA, August 19-23, 2001, LNCS vol.2139) *proved* the impossibility of efficiently obfuscating programs. It is the mathematical proof of the impossibility of a software-only DRM system on an untrusted client such as a PC. There are also a lot of interesting theoretical side-effects. You can read the html abstract here, or the postcript full paper here." The paper is from last year, but that doesn't make its conclusion less interesting. (Of course, even hardware isn't always all that secure, either.)
but I found the paper sufficiently obfuscated!!
I stole this Sig
well, if the sssca gets passed, I'm not gonna be the one trying to break any tamper proof software :(
Liberty.
i have a mathematical proof that shows the impossibility of mathematical proofs, but i can't get it past the lameness filter.
as a developer myself, i spent a bit of time messing around with protection schemes for applications i wrote for the Palm OS platform. i wrote a paper on it, which was made available at PalmSource 2000 and is available here. i enjoyed understanding the inner workings of how they did it - so, i documented it. however, i knew that there was no beating them - the question remained.. how long would it take for them to crack it? does it give me some selling breathing space? (more time = more sales) :P
I think the conclusion is at best, obfuscated... /generalized/ but that doesn't not preclude obfuscation under very specific conditions. Although they formalized a counter-example to an already special case, which precludes generalization of the concept, that does not mean other specific cases do not apply.
Yes you can say that obfuscatable programs can not be
...because it means that the ONLY recourse for these money hungry bastards in the "content industry" (is legal prostitution considered and "industry"?) is legislation. As long as they can be fooled into thinking that Mr. Wizbang's new ROT-14 encryption scheme is uncrackable by all but the most devious of minds, they will relax and let themselves sink slowly into the mire of contentment that will someday be thier graves. But when people come around spouting off how impossible it is to have DRM on "untrusted" machines, the only solution is legislate trust into all the machines in the most draconian and Brotherly way possible.
PLEASE somone start publishing papers on how all digital content can be protected by XORing it with the number 0x42 and will be secure as such for decadeds to come.
"Your superior intellect is no match for our puny weapons!"
There will always be a Mozart to break the DRM of publically performed (or distributed) works. DRM is a way of controlling the sharing of some piece of work. In reality, the only way to perfectly safeguard the rights is to not share the work -- or trust people. Hmmm...
-- @rjamestaylor on Ello
It was already obvious that this was true.
Quick proof:
1)A software-only DRM system attempts to make a product run in cases where it is not a copy.
2)It makes it's decision based on information content of some kind.
3)A copy will perfectly replicate all information content. (If it can't, then you don't need DRM.)
4)If a copy has the same information content as the original, then the DRM cannot distinguish between the copy.
5)Therefore DRM has no way to shut down only the copies.
6)The only way to make DRM work is to have some sort of information that is impossible or very much harder to copy. Thus, the web-activation type scheme, although IP packets could easily be spoofed.
7)God, I should have published this years ago, if it weren't so GODDAMN OBVIOUS!
I read the article last year when it came out. The results are not as far reaching as they sound from a first reading of the abstract.
They proved that not every function is obfuscatable. However for all we know, it might be that most functions are obfuscatable, which is good enough. Also the notion of obfuscation is somewhat contrived (this is because of the lack of a generally well defined notion of what de-obfuscation is, they did the best given what is a new field).
Say, in general proving that a program terminates is impossible. Nevertheless millions of lines of code are put out every day which we are positive they terminate, as we restrict ourselves to designing programs that always do so (even though the occasional bug gets in the way).
If you look at the abstract page, you'll see that it hasn't been updated since 1970. It took 31 years to get it accepted for a conference? Wow, that sure makes me feel better about academia ;-)
Tales from behind the Lagom Curtain
I don't want to be a pedant, but resistant doesn't mean immune in all contexts, it also means "the attempt to prevent something by action or argument" [or something to that effect - I don't have a dictionary within reach].
So tamper resistant isn't an absolute statement and often refers to the ability to buy time. However many companies (typically the saled dept.) often refer to it as though it buys *complete* piece of mind, yet even physical bank safes are rated by time to resist cracking/breaking.
I think this paper is good because it means that PR claims can be provided with a counter argument from a third party that provides a proof. However I think that anyone using the word tamper resistant is not an imbecile, I think that anyone who uses it in the context of tamper-proof is an imbecile. Resistant has so many contexts.
e4 e5
If I wrote a copywrited piece and then used a form of copy protection that I knew people could break (similar to what some people were doing to "encrypt" song titles on Napster a while back), do I have the right to sue them under the DMCA (and a while back the judge said no)? Maybe so, maybe not, maybe it's a grey area, maybe there are other loopholes I know nothing about. But one thing I think the courts have upheld is that legally there is no degree of separation.
For instance of a judge rules that breaking someone's "lame encryption" does not violate the DMCA, because they knew ahead of time that a person could break it. Then adding to the complexity shouldn't change anything. If you have a proof that shows that software only DRM on an untrusted client is not secure can you or should you be able to claim damages when someone eventually exploits the hole you knew had to exist.
Of course IANAL, and I'm sure this will not cause the DMCA to crumble, but I think it raises some questions. Similarly are you allowed to advertise that such systems baised on obfuscation are secure or should they be clearly labeled as deterants, and not iron clad security?
If a piece of software (with some kind of copy-protection) runs on a computer, it can be cracked to run without that protection. Tools such as Procdump will start the program, and after the user has clicked yes on a nag box and the program is decryptet, procdump will scan the memory and rebuild the executable.
If a movie or music file is protected by some encryption it still has to be decrypted to be played. There are many ways to crack this. Crack the encryption, intercept the data stream after it has been decrypted or just record the analog stream. A small quality loss, but with no protection at all. I remeber reading an article by Tron Øgrim, where he had interviewed a boss in a publishing corporation or something like that about DeCSS and ways to protect digital data (movies in this case). He asked if they had some way to stop people from just using a camcorder to record the tv, and the boss-guy said no, and I had the impression that they just hadn't thought of it. They can protect their movies and music with super-strong encryption, but people still have to be able to watch the movies or listen to the music. If people can watch or listen to it, they will be able to record it.
The Centre for Software Maintenance" is hard to beat.
Of particular interest is dcc , the GPL decompiler.
Input ".exe" files, and output high level C code.
A corollary is that Warcraft III was doomed to be cracked, and that no matter what they do, it will be 'easy' to hack a cheat. Possibly a realization of this will lead to a different approach to game design a la Bioware: no effort is spent to stop cheaters, you just have to trust your friends.
And they were always very careful to point out that their software is merely tamper *resistant*, not tamper *proof*. This is not just the sales guys, but the engineers too, and even in meetings if I accidentally said, for example, "*blah* will prevent copying", they were quick to correct my mistake.
All programs have to be "interpreted" by something when run. Usually it's a hardware CPU but it could just be a good software emulator. If a program is running on a s/w interpreter emulating a CPU it's trivial (though lengthy) to determine the algorithms and data used by the program. It doesn't matter how hidden the code and data are, when they hit the CPU they must make sense.
would be the Realnetworks DVD software used by the DeCSS team.
As many Linux DVD enthusiasts already know, DeCSS was made by looking at the binaries that the Realnetworks DVD software contained and locating the decryption key.
Desperation is a stinky cologne
NT is built upo an HAL (Hardware Abstraction Layer) which makes it actually seen as software so, it is obvious DRM hardware can't be 100% secure !?
Now, if they promote brain-implants, then they might have the users DRM'ed which will be quite different to bypass...
Unless one finds enough red pills.
Trolling using another account since 2005.
Its the reason that 40 bit encryption of no longer considered secure. And why RSa is secure with 1024 bits for now.
When beowolf clusters came out (obligitory reference) lots of 'unbreakable' encryption was considered suspect (eg DES) Any encryption system is only secure for a limited amount of time. When new hardware/software comes out the limit is shortened.
I remember a hardware 'key' system that plugged into the parallel port, and all the circuitry was encased in a solid block of black plastic. It was broken by sampling the data in & out then wedged itself in and emulated the hard key (software replaced hardware). The real trick is to spend a resonable amount of money to protect your data/programs for what you might get in monetary compensation. Eg don't put a $40,000 dollar lock on a $2 product.
I think the real question is this: what are they trying to protect, and for how long? Could you guarantee that some code would get 5 yrs of time where the encryption is unbreakable? A twisty mind may think up a interesting 'unbreakable' codec, but a differently twisted mind can crack it.
make Linux, not Microsoft. sin(beast) = -0.809016994374947424102293417182819
There's a paper called Protecting Mobile Agents against Malicious Hosts by Tomas Sander and Christian F. Tschudin, which demonstrates it's possible to write a program which can compute a digital signature or other various functions in such a way that it's impossible for the host to hijack the process, i.e., it's cryptographically hard to reverse engineer the program to extract the public key being used, or the function being computed (This paper has been used for various purposes, including proving that it's theoreticaly possible to write computer viruses which have signatures which are impossible to detect).
These papers aren't contradictory, there are important differences between the results.
Ultimately, one paper demonstrates a certain type or program (which would be usefull in implementing a DRM scheme) is impossible, the other paper demonstrates another similar type program (which would also be usefull in implementing DRM schemes) is possible (and demonstrates how to create such a program, and gives a non-trivial example).
Is this the theoretical end of all DRM as the poster is suggesting? Not yet.
Given a DRM program that relies on certain inputs (encypted content, permissions etc) to produce the desired output (viewable media), one can construct another program to provide it with these inputs from another source, and divert its output elsewhere as desired.
So Eisner really does need to outlaw Turing machiens to have his way.
I attended the 2002 IPAM Crypto conference at UCLA where Steven Rudich gave a presentation on this. There is an important point that, from reading the comments thus far, is not being appreciated.
The paper does not say that programs can't be obfuscated. What it does say, is that there can be no generalized "obfuscator" that you run your program through and voila you've got an obfuscated version. Hoever, program obfuscation is possible on a per program basis. Simply put, the more obfuscated a program is, the more difficult it might be for someone to reverse engineer it.
The folks at cloakware have done what's supposed to be a bang up job of embedding AES keys in an obfuscated client. What that means is that you can use powerful, yet easy to compute, block ciphers with symmetric keys for "public" key cryptography. The clients will have your key embedded in the program, but in theory they won't be able to recover it. As the paper proves, Cloakware has to do the obfuscation on a program by program basis. They can't have a generalized obfuscating machine because such a machine can't exist.
Now, while I firmly believe that perfect DRM is an impossible goal (assuming no SSSCA), good enough DRM is certainly conceivable. If CSS had been obfuscated, DeCSS might have come out much later than it did. Program obfuscation could easily be used by those want DRM. They'd have to be prepared to be in a digital arms race, but they could probably as least give those who want to crack DRM a run for their money.
All things considered, we'd be better off if content providers were willing to trust software DRM rather than forcing all non copy-compliant hardware out of existence.
The result is not particularly surprising. In some sense, the DMCA exists precisely because people can break these schemes: where technology can't enforce the behavior, you need the power of the state to enforce the behavior.
I have to say that "the (Im)possibility of Obfuscating Programs" should be self evident particularly to anybody with a detailed knowledge of CS.
In order function the program must be 'interpreted' in someway, since that interpreter could be an engineer, the *best* than can ever be acheived is to make that task more difficult, not impossible.
Since openness is in the interests of all Computing Engineers we need to debunk the urban myth that it's possible.
For those interested, the paper is available here:m a-secur ity.ps.gz
http://www.icsi.berkeley.edu/~tschudin/ps/
Okay look guys, I know this, you all know this but let's not tell the suits okay.
I like watching them fuck it up
dcc isn't practical though, unless you've got a heavily modified version. The offical version is hardwired to only support very small programs, and fixing that would require extensive rewriting of its internal structures.
Not saying that it isn't interesting, only that today, no one (I'll wager) is using dcc for practical reverse-engineering.
There's also rec (reverse-engineering compiler), but it's sort of limited in the kind of input it allows.
IDA on the other hand is the tool of choice for the kind of reverse-engineering you're thinking of. If there were to be a source-generating backend on that one, you'd see a lot of worried faces, I assure you.
Belief is the currency of delusion.
The first time a traveling salesman walks into my living room, I complain to my maze provider. He then releases Labyrinth 2.0. Instead of a maze of brick, the maze is now full of mirrors.
Of course this maze is foiled by crafty salesmen who lay breadcrumbs and place markings on the ground to indicate where they'd been (sure they could have done this before, but lets say they didn't).
So again I complain and the maze provider offers another solution. But this time the maze provider does something new. Labyrinth 3.0 offers support for trolls who live under the maze and can rearrange the markings and discard the breadcrumbs left by the salesmen. You can buy the trolls from the maze provider as well as troll food each month.
Now I've paid for 3 versions of my Labyrinth security product, and am continuing to pay now for trolls and food on a per month basis. My maze provider is now a huge corporation. Should they have to pay if their supposed security system fails?
What if they knew all along that the maze technology was insecure and that no matter the obfuscation there was always a way an intruder could enter your house through supposedly legal means (assume that simply using the maze fairly is not illegal). If it can be shown that the maze provider knew ahead of time that maze tech was inherently insecure and that while the upgrades seemed to fix security holes as they were discovered, that these types of holes would always be present and are indeed unfixable. Should a company be allowed to continue to "upgrade" their technology and make even more money, while they know their product will never be fit for this particular purpose?
Want to know what is possible? Want something to think smile about when you hear about the latest and greatest smartcard system? Just curious about how one actually can go about rev-eng'ing a chip?
You owe it to yourself to read the following paper: Design Principles for Tamper-Resistant Smartcard Processors and check out the slides for lots of interesting pictures.
Everything from how you use acid to remove the packaging without destroying the chip logic itself, to the actual microprobing to extract information from the circuit.
Belief is the currency of delusion.
The only thing that could come from this is a lawsuit for misleading advertising, and then only if the company advertised the maze as completely secure.
But a certain software company is advertising that it's latest server software is completely secure, and will run long periods unattended. The default installation turns out to be wide open, and I rather suspect that the servers will have to be rebooted far more often than is true of well-tuned installations of several competing products, two of which are _free_. The problem here is that American courts will generally figure that obfuscated phrasing in the fine print of contracts override public claims like this...
Though the work presented at crypto 2001 may prove that it's not possible to provide program obfuscation in the general case, some other researchers have shown how to do obfuscating in more restrictive, yet powerfull scenarios.
For example, there is a paper that describes a method to do Function Hiding. This allows to compute a function on an untrusted host. A lot of problems can be modeled that way, and though we may never see methods to provide obfuscation in the general case, it does not rule out the possibility of obfuscating special classes of programs.
You've recreated the protection scheme of the Atari 7800. There was no need to encrypt the binaries, the console wouldn't run any ROM that wasn't signed by Atari. Since the average 14 year old of the time wasn't up to modchipping, this was an effective way to control developer access to the platform.
You're not going to be able deny access to your code from the clients forever. As you say, the public key and therefore the code is recoverable. As a security method against script kiddies though, your idea has merit. They would have to be able to replace your public key with their public key in order excute altered code. This would have to be combined with other security methods like Tripwire or Aide to make something truly effective. I wouldn't even bother obfuscating the code or the public key; just sign your program and stipulate the use of the key enabled Python.
BTW The Atari 7800 private key was lost long ago. 7800 emulators don't even bother to check the signatures on the ROMs. Contrary to popular belief, 7800 ROMs were not encrypted, only signed. This also means a 7800 could be chipped to allow new 7800 games to be played. Don't laugh; new titles have been created for 2600s, ColecoVisions, Vectrex, and others.
The point of obfuscation, however imperfect is to drive crackers crazy to the point that they give up trying to break it. It really isn't necessary to have perfect obfuscation (even if there were such a thing). All you have to do is make the code so twisty-turny, redundant checks, weird loops, self modifying code and more that the cracker gives up exasperated.
Let's face it, there are very few programs that good to warrant someone sitting down for weeks trying to break them. Hell, there comes a point where its simply cheaper to buy them than the time you waste trying to crack them.
If you want to see some good tips on making software crack resistant, try here.
That's what they tell us every time we tell them it's not going to work. The problem here is how those DRM systems fail. They are not broken instance by instance. Once a single instance is broken, all instances are broken because the newly discovered way of circumventing can be encoded in a piece of software and thus be used by everyone. The argument of keeping the honest people honest is therefore kind of invalid. Once someone has broken a system, everyone has broken it.
That's why they need another legal hammer, a DMCA-like one that makes it illegal to talk about circumvention, not to tell implementing it. It's the only protection against honest people who happen to download some software from the Internet -- it ensures that software they don't like is verboten, as is all information that could lead to implementation of such software.
http://erichsieht.wordpress.com/category/english/
Have you read the paper? What you say is clearly obvious, but that's not what the paper is about. They are not proving that you can't run a copy of a software, they talk about retrieving an encryption key hidden inside a program.
-- Slef
My SOURCE codes are copy protected because they are written in Object Pascal. The unwashed masses can't crack 'em because they don't program while persons savy enough to make sense of the code will sniff that anything not in C/C++/Java/Perl/CLisp is not worth bothering to read.
Dude, shut up, or else theyll move to schemes that ARE impossible to crack ;-)
A point that is often missed is that DRM and the DMCA are about protection, not security. Protection aims to take reasonable steps to prevent damage, and to introduce means to control damage.
The DMCA is a backup for DRM. It does go too far, though. But the DMCA has been passed because it is clear that, in the light of the failure of existing DRM techniques, industry has been unable to resort to existing laws for damage control.
Copyright is an asset and as such needs protection. I disagree with the term of copyright and repreated extensions, but the rationale for having it in the first place is sound.
DRM is a first line of protection of copyright, and should prevent casual tresspass or theft. A successful DRM does not completely prevent duplication; it prevents casual duplication and should present a barrier for illegal mass duplication.
It is widely acknowledged (even within the record industry, although not publically) that DRM cannot provide security -- it cannot prevent determined (or even eager) crackers from getting around the protections. It doesn't need to. Once the number of transgressions is limited, it is possible to resort to legal action in those cases. DRM is intended to reduce the number of transgressions to an acceptable, and managable, level.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
You can aways record the entire legal transaction and then replay it every time. If you manage to "sandbox" the program so it will run perfectly equal conditions it will be fooled to work. Even random numbers choosen by the program would be choosen equaly since the program is runing in the exactly same environment (time/date, I/O, etc). Of course it could not access new information from the outside world, so this scheme would not work to access online resources.
[]'s Victor Bogado da Silva Lins
^[:wq
Why incorporate a DRM system if people are willing to pay? :^).
http://erichsieht.wordpress.com/category/english/
First of all, let me state that my day job is CTO of Cloakware (as mentioned in the post - the leader in Tamper-Resistant SOftware, along with some other 2-bit companies :-) This is actually jumpping the gun on some announcement that we are about to make (but those will be mostly PR pieces that are of less interest to this audience).
I like to make several points:
- what the "(im)possibility" paper says
- "we all know" does not mean its true
- lots of other published works
- resistance is not an absolute thing
timothy has mis-understood the importance of the "(im)possibility" paper. The breakthrough is that this is the first real theoretical treatment of obfuscation. They show that it is not possible to build a totally automated system that is Really Secure (to vastly over-simplify, they construct program that actively leaks a single bit and then show that no obfuscation program can protect this program against itself). This is really interesting but not directly applicable to what we do - we work with our OEM customers to help design the system, the protocol, the programs so that all the pieces are working together; then we "cloak" the critical pieces. (I spoke to some of the authors before the conference, and many Big Names during Crypto'01; I think it is fair to say that most knowledgable people have this view).
As to the "we all know" truism; it is clearly not true. Real life examples abound - any old, large software system is hard to fix since people don't understand the relations between modules (i.e., the market for reverse-engineering tools). These systems are Tamper-Resistant. The well know IOCC (International Obfuscated C Contest) is another good source of Tamper-Resistant programs. In a manner of speaking, the goal of Cloakware is to achieve this Tamper-Resistance on-demand, for easily maintained code.
The "(im)possiblity" paper is breakthrough on the theory side, but many other people (including us) have published on the practical problems. Some names include Cohen, Collberg, Forest, Wang, Knight. There are many schemes that are reducible to various complexity classes, usually NP-complete and we have one that is PSPACE-hard. All of these papers are correct, there is no conflict.
Lastly, "security" is not binary and has many different attributes. Each application has its unique requirements. For example, diplomatic files are protected for many decades or centuries; a Britney Spear song probably needs only a few months; real-time stock market quotes for 15 minutes. Factors like Usability, Speed, Deployment are often more important than raw security.
NT is built upo an HAL (Hardware Abstraction Layer) which makes it actually seen as software so, it is obvious DRM hardware can't be 100% secure !?
Versions 5.0 and later of NT Kernel, used in Windows 2000 and Windows XP, include support for signed device drivers. When you install a device driver, the OS tells you whether or not Microsoft Hardware Compatibility Labs has digitally signed the driver. Signed audio drivers must support a function to turn off all cleartext digital outputs, and applications can choose to output only to signed drivers. See also Secure Audio Path.
However, without watermarks, Microsoft won't be able to stop D/A/D copying, and the standard SDMI watermarks have already been broken.
Will I retire or break 10K?
When Beowulf clusters came out (obligitory reference) lots of 'unbreakable' encryption was considered suspect (eg DES) Any encryption system is only secure for a limited amount of time. When new hardware/software comes out the limit is shortened.
Not so fast. Moore's law states that transistor density (and thus computer power per square foot) doubles every 18 years, and a doubling of computer power reduces effective key length by only one bit. Given that one of the world's largest clusters hasn't yet cracked a 64-bit key, barring some sort of quantum breakthrough, I see a 128-bit key as potentially running into the limits of the silicon that underlies our current classical computing architecture. Do you really believe that Moore's law will hold for the next century (i.e. time for 64 doublings)?
Eg don't put a $40,000 dollar lock on a $2 product.
More like a $2 million product if you sell one copy to a pirate who makes 2 million copies through a peer-to-peer file sharing network.
Will I retire or break 10K?
Check out some of the winning entries from IOCCC competitions and then tell me code can't be completely obfuscated.
Many if not most of the IOCCC entries can be effectively de-obfuscated by running `cpp' (C pre-processor) then GNU `indent' on the code.
Will I retire or break 10K?
Don't need a proof. Just look at it this way: You've want code that a computer has to be able to figure out how to execute, but a human can't? News flash: Humans are smarter than computers. By a lot.
The day that changes, it will be big news that totally eclipses anything coming from the entertainment industry. We'll be too busy enslaving the AIs to entertain us for free instead of Hollywood (good version) or getting vaporized by Skynet-launched nukes (bad version).
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Now if they only would prove the same thing with copy protection of music and movies, maybe it could be used to finally put an end to all of the MPAA and RIAA bickering.
Need Free Juniper/NetScreen Support? JuniperForum
They even have a way for you to distribute the source code with the essential parts extracted, compile it and run it assuming that you have the card for the program.
Since I am lazy I am not going to use Google to look it up, but they were at the last CTST conference selling their system.
Lasers Controlled Games!
I'm going to have to give this another go, because moderators didn't quite catch on. Your point number (2) is where you made a mistake. The DRM can not only make its decision based on the information content but on the DRM's execution environment. If it is able to find _any_ information that is unique to a particular machine (quite easy actually), then it can enforce copy protection through public key cryptography. When the transaction that grants a user a copy of the product in question, the producer can insert a watermark including this unique information and (unforgeably) digitally sign it. The DRM can then check that the signature is correct and matches the unique identifying information. So yes, DRMs can enforce copy protection--through cryptography.
Now, having said that, if the DRM itself is under attack, then it can be altered to not enforce signatures, or (as someone already suggested) run in a sandbox where all unique identifying information can be forged. This is a different problem.
From what I read of the paper, it stopped short of making claims about copy protection, and basically stated that it is impossible to obfuscate a program, not that it was impossible to sign data or verify its source. So, no, it's not obvious, and you are over simplifying an erroneous proof of a claim they didn't make.
120 characters isn't enough to explain it.
Yes, but you are missing an important point: if the people creating the obfuscated code are orders of magnitude more intelligent than the crackers, it is impossible for them to create protection that can't be broken. Unfortunately for the industries that want this kind of protection, the really really smart people typically don't get into computing.
You're assuming a cracker is motivated by "monetary profit". This may be true for some crackers, or some crackers under some circumstances, but it totally ignores the much more likely reason for crackers being crackers, namely that they enjoy the challenge.
If you look around you will see that interesting schemes attract crackers like honey does bees. Crackers hone their skills by creating "crackme's" for each other, where they show off new techniques. Days can be spent reparing a dummy executable purposedly broken by another cracker, dissecting layer after layer of encryption and obfuscation, and then reversing its core functionality into HLL -- all for the fun of it.
A good cracker is something amazing to watch. Just like there are wannabe-hackers and a few supperior wizards, there are a _lot_ of wannbe-crackers ("Ohh! I can nooop!") and very few wizards. Some of these wizards does NOT engage in cracking for distribution.
Dedicated and passionate crackers never give up. However, the delay between release and published crack may be valuable to the obfuscator. But at the same time, if you release a product that will take crackers weeks to analyze, it's actually quite likely that some warezd00de somewhere will simply card the software, and distribute that.
So there are the producers which want to hold off cracking as long as possible, and there are the lUser-hordes who want the cracked software as soon as possible, but in between there are a lot of crackers who, for the most part, couldn't care less about time-frames.
New target, new protection-scheme, new puzzle.
IANAC.
Belief is the currency of delusion.
My algorithms professor from last quarter, Russell Impagliazzo, worked on the paper. Hoo bah.
I could not justify my existence if I were a turkey farmer. Would I terminate myself? Undoubtably, yes.
When writing your congressman about the stupidity of the SSSCA, please take note of the following:
Copyright is an asset and as such needs protection. I disagree with the term of copyright and repreated extensions, but the rationale for having it in the first place is sound.
DRM is a first line of protection of copyright, and should prevent casual tresspass or theft. A successful DRM does not completely prevent duplication; it prevents casual duplication and should present a barrier for illegal mass duplication.
DRM is worthless for achieving those goals. This will become evident to the Media Cartels, and even to our thickheaded congress, though it appears not before the destroy the industry most responsible for America's prosperity over the last decade.
The software industry is even more vulnerable to copyright violation than the music and film industries ever will be. It always has been, by virtue of existing within a medium in which an infinite number of perfect copies can be made at virtually no cost. As game and other software designers learned over time, no copy protection worked, even for the length of the development/sales cycle of the product. Whatever scheme they came up with could be defeated, and no amount of laws banning such activity are going to have any effect on that since the act of copyright violation is/was already illegal and the abusers were perfectly willing to disregard the law regardless.
What does work is product serialization, perhaps coupled with stamping a person's identity (e.g. name, ip address) on the product. No one with any sense of self preservation is willing to share a copy of a product that can be traced back to them, or traced back to their credit card.
Yes, there are people who trade in warez. The law already has plenty of clout to deal with them. But the vast majority of people who use proprietary software pay for it and are not willing to share it with their family and friends, precisely because of the serialization and identity coupling approach I just described.
This will work perfectly fine for movies, television, music, and any other "infinitely copyable" product you care to name, without the need for draconian laws, without the need for DRM, indeed, without the need for the DMCA.
The software industry, whose very bread and butter are most vulnerable to copyright violation, already solved this problem without running to Uncle Sam for new, coercive, draconian, indeed, some might say Orwellian, legislation. I suggest the entertainment industry do the same, and I suggest anyone writing their congresspeople make this point very clear to them.
The problem has been solved by the software industry. The RIAA and MPAA Do not need the SSSCA to protect their profits, period.
The Future of Human Evolution: Autonomy
Commercial software could then be encrypted.
When you install a new piece of software your public key is read out and you type a product authorization key which is printed on a card in the box, and this is sent via the Internet to the vendor. The vendor checks that the product key hasn't been used before and then encrypts the session key for the software package with your CPU's public key. This encrypted key is sent back to you and stored in a file on your computer's hard drive. When you launch the application, the loader reads the encrypted session key into the CPU and issues a special machine instruction which causes the CPU to decrypt the session key and store it in a CPU register which can't be read out by anyone. But at this point the CPU can start reading the encrypted software code and execute it. The plaintext code is never exposed outside the CPU.
This would not only provide perfect copy protection for software, but also allow DRM in software that can't be cracked.
Expect this soon after the SSSCA passes. Technologically, it wouldn't be hard to implement.
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
Why? Every time some new copy-protection technique is implemented in a device, that device becomes more complex, and therefore more expensive. This expense alone hurts consumers. The other problem is that CP techniquess, by their impossible nature, cannot be made public and still remain secure, raising the barrier to entry into the market of player technology (see DeCSS and Linux DVD players), again hurting consumers. Copy-protection schemes are also unethical, since they discriminate against the law-abiding and less technically-skilled population. However, many people do not consider themselves technically competent enough to criticize highly successful technology companies such as Microsoft over technical issues, they simply accept CP technology with little objection.
However, many more people understand legal matters fairly well. For example, "I can use my stereo to record the songs from my favourite CDs onto a cassette so I can play them in my car, but the greedy record companies want to make that illegal so they can make me pay again for a casette of all the songs want to sell me? Screw that!"
So my point is that I think the legal campaign these companies will make will fail, especially as it becomes more and more obvious that it is nothing but blatent corruption and power-grabbing, but technical measures are narrowly understood and simply harm the industry without anyone noticing.
This type of crap should bug you. It's your computer, so it should do what you, and only you, tell it to do.
Except with IP, it's not actually your stuff. By your analogy, you sold someone a house, but left the doors locked and plan to have him/her charged criminally if he/she tries to get into the house.