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
they are all off patching their php software
well, if the sssca gets passed, I'm not gonna be the one trying to break any tamper proof software :(
Liberty.
who says u cant obfuscate.
rm -> obfuscate to white space
My Aurora : http://www.youtube.com/watch?v=o91ZsGwJYyg
FB : https://www.facebook.com/TanveersPhotography
i have a mathematical proof that shows the impossibility of mathematical proofs, but i can't get it past the lameness filter.
It was proved in the 1970's that even Databases that lie can be compromised.
The game of Go (Igo, Weiqi, Baduk) has the simplest concept and the deepest play.
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
But should we really give two shits?
Follow me on this one ok.. We all know this for the most part now anyway.. so don't keep anything of value on a machine that can be physically or remotely accessed.... simple eh?
...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!
A lot obviously because I trust IE with my data. It just lost my last post.
F#*k
... if they want to use the features of "late-compiling". IL reads very easy, and there are some obfuscators around. :-)
.. so, they were not using a UNIX.
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.
They prove that there can be no "Obfuscator" which works for all functions. essentially, they show that there are some functions which can never be obfuscated, and hence no universal obfuscator can exist. also, their model of obfuscation is rather strong. they require that the obfuscated program be as good (or worse) as a black box. the idea is that if you have a function which stores some kind of secret (otherwise why would you obfuscate) then however you obfuscate it, you can always tell something more if you have access to the tapes(or memory) of the program works with, than if you dont.
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.
Surely the machine code compiler is an unsolvable example?
I appreciate that this is not direclty related to DRM, but it is an obfuscation of sorts...
Invoicing, Time Tracking, Reporting
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.
write really bad code. Or write in perl - it's obfuscated even when it's not.
Sotware protection is not, and will never be completely safe from cracking. When, oh when; will the dipshits realise this!
The only way to make your code tamper proof for ever is to write the code, print it out, drop the PC into a live volcano, then get the printout and jam it fair up your ass. Then go and put on a good old fashioned chastity belt. Lock it up, and smash the key to bits (do NOT eat a curry before doing this). The final step for total security is for you to jump into a live volcano.
Your code is now secure.
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.
..., it wasn't made to hide it. Andy Müller-Maguhn of german ChaosComputerClub said this over a year ago (IIRC "Der PC ist eine Dateverarbeitungsmaschine, keine Datenversteckmaschine")
b4n
why are newer posts modded up, while older with same content are classified as redundant?
people seem to confusing the notions of 'obfuscation' and 'tamper resistance'. given an obfuscated program, one can learn nothing about it beyond its input-output behavior (the paper states this in formal terms). given a tamper-resistant program, one might be able to learn some things beyond its input-output behavior, tamper-resistance means you cannot make meaningful _changes_ to the program without breaking it. this paper deals with obfuscation, not tamper-resistance. obfuscation implies tamper-resistance, but take care to note that tamper-resistance is a weaker requirement.
a group of coders who choose to make our lives miserable. But now, there is proof that they will always win.
Try writing in perl. It's pretty much self-obfuscating. Even better: try APL. Five minutes after writing an APL program, the only way of figuring out what it does is to execute and reverse engineer it. But five minutes after that, you're lost again. It's the ultimate write-only language.
MSN 8: Now Microsoft even has bugs in their ad campaigns.
The point of drm is not to stop Every one copying a file illegaly, but to stop the majority of people and this is something which could be achieved.
,to a certain extent and there growth can be curtailed.
/time warner and sony are the only two players that come to mind who have the ability to do this at the moment.It would not be very difficult to get people to think of the internet along the same lines as tv,where you chose your provider by what content it offers.This would up the ante in the isp business , people would start demanding exclusive content bundeled with there internet connection and the majority of small isps would not be able to afford this and in turn this would probably lead to a drop of in there customer base.Aol/time warner and say for example other big content providers would then be in a position to sell access to there drm networks to the small isps with plenty of strings attached,(i.e put lots of restrictions on your users), and if they did not play by the .
.Hell you could even trow in a free drm media player to people who sighn up for the 30 buck a month content + net plan, that would be a quick way toget people to use the format.
,as if there is no big all ecompassing drm format which is widely used ,(mp3 for example),then people will not buy the drm players and people will continue buying
,'free lunch'.However for drm to work the content making industrys would have to play there cards right and cooperate alot more as well as be perfect in there timing .I do not think they will do this and therefore I do not think drm will be successfull ,my point is that it does have the potential to be successfull and
How this could be achieved is through making it more hassel than it is worth to get the file. First of Programs like napster which are not controled by The music industry or the people who manufacture the content in question need to be eliminated or taken over.
The reason for this is that downloading and finding a song is made way to easy for the average person by these programs and these programs distribute content in a format which enabels the user to make say for example,mp3 / ogg/whatever cds, and give them to there friends. These programs cause further redistribution through other means and encourage a snowball like effect in terms of distrbuting.
So the first step to making Drm work is to use
a legal hammer to smash the main and hence most populised file trading networks,(you do not need to get them all just the main and hence most popular ones), and to put out your own content networks which distribute at say a set monthly fee your content in your format,(i.e drm enabeled),which may not completly stop the snow ball effect but will minimise the damage.
The majority of people are not that computer savy,if some thing is to difficult to use they will not use it.If some thing is difficult to find they will probably not try to find it.Through legal harrassment p2p network programs can be kept under control
However at the end of the day the question must be asked , how long can they keep this up ? This strategy is short term at best , a more long term game plan is needed.
How I could see drm really working is in
a senario where the internet was treated like tv.For this to happen what you would need to see is the close intergaration of content providers and isp's,where internet usage and special content
are sold as one packet, i.e pay 30 bucks a month and get access to our drm film/tv/music network
as well as firewalled internet access.
Aol
rules the isps acces to the content would be revoked
Independent Isp's who refused to play along could be harrassed by legal means and eventualy the majority of them would close shop or intergrate with one of the few big players. What this sort of senario would lead to is a very centeralised internet which would be alot easier to control.
The next step in this plan would be to start brining out drm media players at a cheap price and to keep the cost of the net/drm content bundel low until the majority of people had accepted it then when that has occured you can rachet up the price as much as you like
obviously people could convert the drm files to mp3/whatever and obviously there would be ways around the fire wall, but this does not matter if the majority of people can not do these things.All the isp/content providers would have to do is maintain a unified firewall position of blocking anything which made 'piracy' simple and potentialy easy to use and even if alot of sites mirroring special p2p networks which would work behind the fire wall could get through via special sites/programs that would not matter much as the majority of people could be prevented from finding them and using them.
Now this is the strategy, which i think will be attempted and here is why I think it will ultimately fail.First off , there is no major drm which has been universaly accepted by all the big player,they are all trying to push there own formats and this is going to be a big problem in terms of getting people to use there drm content , music specificaly
mp3 players.
Secondly all of the players in this drm game have different agendas and visions and alot of the time they are odds with one another.For example microsoft and aol/time warner or microsoft and sony. If all 3 of these big players sat down and agreed on a drm format , it would more likely than not be accepted, but all 3 have different formats and different agendas as regards drm and the future of there business.This conflict of interests will prevent there being a single widely used drm format coming about any time soon.
Thirdly drm is completly anti the consumer.No matter what way the big players try and phrase it the deal always comes out the same.We sell you less for more.This is not the right way to make money and to encourage customers to spend money with you and as long as there is an easy alternative to the customers using your drm technology they will use it and not your product.
Drm could work , it may not be uncrackable, but under the right conditions and in the right enviroment it could stop the majority of money spending individual from getting what the content industry see as a
be adopted by the masses andthat is something which worries me.
_________________________________________________
For those interested, the paper is available here:m a-secur ity.ps.gz
http://www.icsi.berkeley.edu/~tschudin/ps/
Theorem. All software can be cracked. Looks like someone finally proved something that's been obviously true for a long time... myria
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
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
Many proofs saying that there can be no algorithm that performs X make a fundamental false assumption: there is infinite memory. Just because with infinite memory some algorithm can't exist doesn't mean that it can't be done with finite memory.
Consider the "halting problem". The reason no perfect debugger can exist is because it would necessarily have to get into an infinite loop for certain programs. On real computers, however, an infinite loop will not occur. Program H(K, K) will terminate with the correct answer on any real computer. H will recursively act upon K and H trying to figure out what happens. At some point, program H will see a subinstance of itself running out of memory, a "terminate" answer. This will propagate alternately back to the "root" H, which will return the response. Which response occurs depends on the size of memory and other factors, but it returns the correct answer.
Corollary: No program can truly have itself as a parameter. This is because no program can emulate a memory bigger than its own. Compression is ignored because then some inputs are disallowed (IE, random data that before compression was the maximum input size).
Proof that a perfect debugger for some input size exists: Simply manually create a truth table for all possible inputs, and create a program that returns table[input].
myria
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Bleemcast has never been cracked.
The reason is obfuscation that has proven impossible to reverse.
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?
Well, you should expect the engineers to get it right, because they understand the issues, but to hear that the sub-beancounters have been trained to get it right too is most impressive indeed.
I'm sure the the Intel engineers have microprobed more circuits than their own, if you catch my drift, so they know.
Belief is the currency of delusion.
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.
I think this is a very nice analogy, but in all honesty: it proves that you got yourself into this trouble. The company can (and will) argue that, if you were not satisfied by the security-scheme, you shouldn't have bought the product...
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
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.
"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. "
,(most people),will be willing to pay and which incorperates the drm of choice.The problem these content producers incounter is that there is no main drm and that there are to many big players pushing in different directions.In the right enviroment drm can achieve its primary goal ,stopping the majority of people copying files that the content industry does not want copied,The question is can the big content holders create that enviroment?
,"The argument of keeping the honest people honest is therefore kind of invalid"?
You have to hear about that piece of software and be able to obtain it before this comes into effect. Also if the majority of people are to use this program it must be simple to use and not involve user x jumping through to many hoops.
"That's why they need another legal hammer, a DMCA-like one that makes it illegal to talk about circumvention"
Not neccessarily,(although I am sure they would love something like that),What they,(the content industries in question), need to do is present an easier option for most people at a price which,(initialy cheap,later expensive),they
On a side point what do you mean when you say
_________________________________________________
Is it not only mathematically proven, but obvious and logical as well? We all know that anything readable by a machine is readable by a human (ie cracker) in some shape or form and therefore is crackable. Also, this paper would apply to hardware protection because if you think about it, there isnt any *real* difference between hardware and software protection, besides the fact that the protection is physical rather than "virtual" (?) Theres plenty of proofs of cracks on the net to prove that protection does not work. Basically, if someone wants to crack/distribute a program then they *will*. It is just a hassle for legitimate end users to configure the software protection most of the time, and just a minor issue for a cracker.
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.
I guess 0.1% computer usage may be
related to music, it's clearly not fair
(or stupid) to allow obfuscate computers.
However, 99.9% speakers usage may be
related to music. If law will allow
this xyz "industry" to obfuscate something,
target should be audio industry, not
computer industry.
Moreover the speaker (or earphones) are the
last thing on the music path to the human ear.
So obfuscation will be most strong exactly on
this point. They should implement asynchronous
cryptography into every speaker sold. Or every
audio amplifier and earphones, to be realistic.
This may cost some bilions of dolars, may be
highly unecological and may slowdown progress of
earth civilization somehow;
but obfuscating computers will bring even more
damage.
I recommend politicians to wear glasses to see
what they do, prior they actualy do something.
rudo
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
I think you are overlooking a HUGE area of research called "digital signatures". The producer signs or watermark the data and a description of the transaction (including the recipient) with his private key. The DRM can then use the public key of the producer to verify the signature is intact and valid for the particular user in question.
The only assumption here to be made is the DRM itself is not subject to attack: if it has been altered to forego these checks, then of course, anything is possible.
120 characters isn't enough to explain it.
..because they sure are going to great lengths to make it look like their prior art goes back a ways:
Last updated on Wed 31 Dec 1969 04:00:00 PM PST
;-)
Josh Woodward
Check out some of the winning entries from IOCCC competitions and then tell me code can't be completely obfuscated.
Some examples mp3, mpeg video, etc.
I would say copy protection also falls into this catagory. (single stepping asm -vs- development/design)
If intel cpu core startes running encripted instructions perhaps we have a solution.
If a seperate chip is used (aka DSS) it can be hacked by looking and data transfers.
FEH! I'll bet Micro$oft's code is already obfuscated to the point of being unusable. The APIs already are. : )
Oh, you want the user's machine to be as secure as the intellecutal property... well that's a different matter... ; )
You are dumb. That's not a proof, it's a story.
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?
Read The Machine Code. The processor can only do what it's told, so look at what it's told. No obfuscation there since it has to branch around or process any junk.
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.
See Matthew Skala's "blind substring" paper. He shows that it's possible to construct a substring searcher where even if you reverse engineer the code, you can't easily find out what substrings are being searched short of just guessing all possible substrings until one matches. The possible applications include censorware, which is pretty amusing when you consider the author's later, more famous, work...
Although the special cases are going to be sufficient for the purposes to which we put obfuscators today (keeping people from reverse-engineering your programs), they suggest other uses for the sort of perfect obfuscator they worked on.
For example, if you had a perfect obfuscator, you could use your (simple) private-key cryptosystem rather than your (complex) public-key one (by obfuscating the private key and calling it your public key). You wouldn't trust your credit card number to the idea that this particular private key probably isn't one of the ones that the obfuscator fails on.
Their proof seems valid (I haven't completed my analysis), so it's good science, but it doesn't mean I'd throw away my obfuscators. For those purposes, I've found that alpha-renaming (just renaming all of the variables) makes it sufficiently hard to prevent software reverse-engineering; it would be easier to just break into my office and steal my computer.
It's unbreakable!
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.
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.
Check it out for yourself...
www.rightsmarket.com
It's very frustrating when people expect a lock on their house to prevent all intrusions. It won't work, it can never work. So why bother locking the door? Someone will simply go through the window. Gee, if you didn't lock your door, will the insurance company cover the loss of items? Probably not. But if they broke the window, you can show forced entry. You're stuff is covered. The same goes for "intellectual property".
Let's be really quiet: while they believe software-based DRM is enough, we'll always have a way around it. When they start forcing HW based DRM, bye-bye "fair use"... (Or poor-man's piracy... Professional piracy tools will ALWAYS be there...)
DRM has to rely on private key protection, which is what the obfuscation is about. Why? The DRM software has to be uniquely tied to an individual so that a) the individual can be made accoutable for their actions, both permitted and disallowed, and b) the individual cannot repudiate their actions later It's about bill-back, far more than it is about preventing redistribution. If content authors can be guaranteed of being paid every time something is played, of course they'll want it distributed by anyone and everyone - Napster go wild! But if they only get paid iff they control its distribution, that's what they'll do to get paid. Finally, the obfuscation has to assist "trusted applications" that are certified not to save things for people not permitted to save them, or print them if not permitted, etc.
If you mean assembler, ten you can write self-modifying code, but even that isn't impenetrable.
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.
This is the reason the content industries are focusing on Watermark and mandaate DRM software/hardware. With certain watermarking scheme, the watermark still remains after you videotape off a monitor. Thus, though you may be able to make an analog copy, your buddy still may not be able to play it if the watermark ties it to a specific device or some biometric ID.
LOL.
I actually have a moderator point right now, but I want the Slashdot team to notice this because I haven't seen the filters defeated this effectively in ages. So I'm not going to mod you down.
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
A few points:
My maze provider is now a huge corporation. Should they have to pay if their supposed security system fails?
Whether or not they are a huge corporation should have nothing to do with whether or not they pay. Just pointing it out...
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?
You're implying that it is my responsibility to look out for you. If you go the grocery store and buy romaine instead of iceberg lettuce, is it the grocer's fault? Clearly not. Nevertheless, you're suggesting that it's my job to ensure whatever I sell you is fit for whatever you're doing, an impossible task.
The hacked scripts (called 'folio', I think) are often particularly interesting in that they give us a snapshot of the state of the plays at a particular time.
The 'authoritative' (called 'quarto', unless I have the two reversed) scripts were published after his death, by reassembling the individual actors' copies, trying to remember how bits went when some of the actors' copies were unavailable, editing things together when the different actors' scripts were from different versions/cuts of the play, etc. As a result of all this, they may well represent a state of the script that was never actually performed
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?
Nevertheless, you're suggesting that it's my job to ensure whatever I sell you is fit for whatever you're doing, an impossible task.
'Fitness for a particular purpose' as the disclaimers say. Not for whatever he's doing, just WHAT YOU ARE SAYING it should do.
__
Comment submitted. There will be a delay before you understand what you posted.
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.
There was the abbacus, Pascals mechanical computer, and now silicon. Who knows? maybe bio-computers or quantum computing will be the next kid on the block.
make Linux, not Microsoft. sin(beast) = -0.809016994374947424102293417182819
"Moore's law states that computing speeds and densities double every 18 months. In other words, every 18 months we can buy a computer that is twice as fast and has twice as much memory for the same cost. Remarkably, this law has held true for more than a hundred years, from the mechanical ... Dr. Gordon Moore, who became Intel's CEO in 1975, first observed this phenomenon in the mid 1960's at which time he said the doubling occurred every 24 months. Ten years later, he revised this to to 18 months. There are more than enough new computing technologies being developed to assure a continuation of Moore's law for a very long time."
card-based computing technology of the 1890 census, to the relay-based computers of the 1940's, to the vacuum tube-based computers of the 1950's, to the transistor-based machines of the 1960's, to all of the generations of integrated circuits since.
BTW I would say it's about every 6 months that it doubles anymore.
make Linux, not Microsoft. sin(beast) = -0.809016994374947424102293417182819
Should have been '18 months' or '1.5 years'. Even a user at the Kap makes mistakes every once in a while, and sometimes, even the Preview Button doesn't catch every single one.
However, under the Freudian slip, after the current rate of doubling burns out, it may well slow down to 18 years per doubling.
Will I retire or break 10K?