Weekly Edition
Return to the Press page
| |||||||||||
Protect Your Source Code: Obfuscation 101 (O'ReillyNet)
For those who aren't into open source: O'Reilly gives an introduction to code obfuscation. "Generic variable names, some annoying loops, and a couple of conditionals sure can make a difference! For the cost of determining what this simple piece of code does, are you even willing to paste it in and run it? Would you be willing to pull out a calculator and do the arithmetic? What if you could only use your brain and no additional tools? Somewhere along the line, you'd reach a point where the benefit wouldn't be worth the reward anymore and give up."
(Log in to post comments)
Protect Your Source Code: Obfuscation 101 (O'ReillyNet) Posted Apr 9, 2005 14:47 UTC (Sat) by elanthis (subscriber, #6227) [Link] No wonder commercial apps seem so much slower than Open Source equivalents. Filled with gobs and gobs of useless code so obtuse the compiler can't even optimize it out. Which is what the developers _wanted_, since it protects against decompiling.
And I'm still not sure what the point is. How does obfuscating your code stop piracy? That's like saying that CSS stops piracy of DVDs. You can just burn the DVD to an identical image, with the same encryption in place and unmodified. Likewise you can copy software around without even looking at the machine or source code.
Protect Your Source Code: Obfuscation 101 (O'ReillyNet) Posted Apr 10, 2005 4:56 UTC (Sun) by NAR (subscriber, #1313) [Link] No wonder commercial apps seem so much slower than Open Source equivalents. Filled with gobs and gobs of useless code so obtuse the compiler can't even optimize it out. Which is what the developers _wanted_, since it protects against decompiling.I have to say this is BS. I work for a company that produces closed-source software without the usual "NO WARRANTY" text in the license (unlike the vast majority of open source software). It means that we need to support our own code for years - obfuscating code would make our job more difficult. Now let's check out this story at LWN. An open source developer injected obfuscated code into his own code to get rid of a Debian developer. The fact that people ofuscate their code does not depend on the opennes of the code - it depends on the sanity of the coder/project leader.
"NO WARRANTY" blah blah blah Posted Apr 10, 2005 10:41 UTC (Sun) by jstAusr (guest, #27224) [Link] > I work for a company that produces closed-source software without the> usual "NO WARRANTY" text in the license (unlike the vast majority of > open source software). It means that we need to support our own code > for years.
That may be true in a legal sense. The reality is that alot of software licensed under free (libre) terms is supported longer and better than software licensed under closed terms. Also, freely licensed software can be supported and maintained by anyone, so the "company" isn't needed to keep the software in a workable state.
So BS to you as well :).
"NO WARRANTY" blah blah blah Posted Apr 10, 2005 15:24 UTC (Sun) by NAR (subscriber, #1313) [Link] The reality is that alot of software licensed under free (libre) terms is supported longer and better than software licensed under closed terms. Also, freely licensed software can be supported and maintained by anyoneIt has nothing to do with my original comment (i.e. obfuscated code and opennes of source are orthogonal), but it's also a part truth. Anyone can support and maintain free software who has the necessary resources. Which is quite a strong restriction. I seem to remember the time when the Star Office and the Netscape Communicator source was dumped on the free software community - it took a while (not just in time, but in money too) to produce something useful.
"NO WARRANTY" blah blah blah Posted Apr 10, 2005 20:32 UTC (Sun) by JoeF (subscriber, #4486) [Link] The "No warranty" clause is also very common in closed source. Have you ever looked at the Microsoft licensing agreement?I just installed mapping software for my GPS (closed source, of course), and the producer (Garmin) has the same limitations of warranties etc. that you find in open source. So, that's not quite what distinguishes open and close source.
I agree with your assessment, though, that obfuscating code makes it harder to provide support. That's why obfuscation can nowadays be done on a more or less automated basis, during the compilation process. An example is the product called dotfuscator, which, as far as I understand it, works on the bytecode level (MSIL, as the .Net bytecode is called.)
Protect Your Source Code: Obfuscation 101 (O'ReillyNet) Posted Apr 9, 2005 15:02 UTC (Sat) by chill633 (guest, #16013) [Link] They aren't talking about stopping piracy, per se. They are talking about stopping people from reverse-engineering the code and being able to make patches to take out dongles, registration codes, etc.
And they're right -- after a while it is going to be really annoying and I'm going to stop. Stop using that program and use something less bloated, paranoid and combatitive, that is.
-Charles
Protect Your Source Code: Obfuscation 101 (O'ReillyNet) Posted Apr 9, 2005 15:30 UTC (Sat) by farnz (subscriber, #17727) [Link] The crazy thing about it? The best way to actually obfuscate something like Java or C is to simply ensure that the compiler does as much optimisation as possible, and that where names "leak" from the source into the object code, they get renamed to something less useful.For example, in Java variable names can be obtained from the .class files; a simple program can rename your variables "if", "for", "a", "b" etc., thus not only obfuscating the code, but making a decompiled version not compilable. In C, it's even better; a good optimising compiler can do things like block reordering, thus rendering the compiler output unreadable.
Protect Your Source Code: Obfuscation 101 (O'ReillyNet) Posted Apr 9, 2005 16:17 UTC (Sat) by petegn (guest, #847) [Link] This whole Obfuscation thing really getsa right up my back i aint interested in other peoples code BUT screwing things up basically for the sake of it is just not acceptable sorry to all those out there that think they have a god given right (althou he does not ,never hads and never will exist) to try and be cockey and attempt to hide code it actually means the code is crap so I'll hide it so i dont get ragged by other programmers .
Pete .
Deliberate obfuscation: who needs it? Posted Apr 9, 2005 16:30 UTC (Sat) by rknop (guest, #66) [Link] I find that even well-written code, but written by somebody else (where "me a year ago" counts as "somebody else"), is often hard enough to grok that for minor and medium sized things, it often makes more sense to rewrite things from scratch rather than to adapt it.
In practice, I usually adapt, because that *should* be easier. And, the first time or two, it is. By the third time, though, the process of adaption has naturally obfuscated the code enough (even without trying) that it's time to start over.
-Rob
Deliberate obfuscation: who needs it? Posted Apr 9, 2005 18:00 UTC (Sat) by hppnq (subscriber, #14462) [Link] Uhmm.. One of the characteristics of good code, is that it still makes sense even if you're not familiar with it. ;-)
Deliberate obfuscation: who needs it? Posted Apr 9, 2005 19:59 UTC (Sat) by rknop (guest, #66) [Link] ...then maybe good code doesn't exist?
To be fair, I have written lots of code, and seen lots of code, that does indeed make sense upon reading. However, that's the exception more often than the rule.
If the algorithm is anything other than straightforward, even a wealth of comments at the beginning still leave you with a reasonable task and some time to understand what code is doing. And, once it's been hacked a couple of times to adapt it for other purposes, it almost certainly won't be good code any more. That's when maybe it makes more sense to start over.
-Rob
Deliberate obfuscation: who needs it? Posted Apr 10, 2005 4:15 UTC (Sun) by hppnq (subscriber, #14462) [Link] However, that's the exception more often than the rule. Agreed! I have written my share of really bad stuff, so I know. ;-) What you're basically saying is that writing a sizeable amount of complicated code does not only demand good enough programming powers (knowledge of algorithms, data structures etc.), but also requires proper maintenance (version control, patch management etc). Not unlike how the Linux kernel is developed. ;-)
Deliberate obfuscation: who needs it? Posted Apr 9, 2005 20:34 UTC (Sat) by kokopelli (guest, #11341) [Link] I would make one subtle change - it should make sense to anyone already familiar with the environment even if it's totally incomprehensible to an experienced but newly hired developer. Mature projects tend to develop their own style, and high reliability projects (e.g., kernels and servers) can be nearly incomprehensible because of the heavy use of macros that ensure the state of the software isn't compromised.
Deliberate obfuscation: who needs it? Posted Apr 10, 2005 5:10 UTC (Sun) by hppnq (subscriber, #14462) [Link] Yes, good point. Of course, you can't simplify your code and your means to develop it at the *expense* of its quality, so a steep learning curve is to be expected in some cases, even if you're an excellent programmer.Note however, that complicated software has levels at which things are happening, which makes it possible to compartmentalize parts of it, in black boxes, for instance. Take git for instance. While I am struggling trying to grasp what is happening there, Linus has already moved to the next level. (Of course. ;-) He knows exactly how git could be part of a bigger system like a SCM tool. And the thing is, it works the other way around too, to some extent. These design issues are hard to extract from the actual code itself if you haven't thought about it for a bit before. ;-)
Protect Your Source Code: Obfuscation 101 (O'ReillyNet) Posted Apr 9, 2005 18:28 UTC (Sat) by allesfresser (subscriber, #216) [Link] Ah, one question for Mr. Corbet... if this article is for people not into open source, then... why post it on LWN?
'Coz many closed-source developers base their stuff on Linux? Posted Apr 9, 2005 20:00 UTC (Sat) by leonbrooks (guest, #1494) [Link] I would have counted that to be blindingly obvious.While Linux is relatively easy to hack, a vanishingly small percentage of the users actually do that.
Protect Your Source Code: Obfuscation 101 (O'ReillyNet) Posted Apr 9, 2005 22:47 UTC (Sat) by xorbe (guest, #3165) [Link] Don't get tunnel vision. It's good to be well-rounded, and knowledgable of the "other side".
WHO OBFUSCATES? Posted Apr 9, 2005 21:01 UTC (Sat) by b7j0c (subscriber, #27559) [Link] I hear about this from time to time but have yet to encounter a codebase anyone really cares about that obfuscates.
I remember working for a loser company years ago that dedicated an insane amount of time to the topic of code obfuscation. The simple point was their product was crap and was being written on contract for essentially one user. What was the danger of anyone plowing through their code?
But then again, the CTO of this company also printed out every email, so it doesn't surprise me that they spent a considerable amount of billed time thinking about obfuscating their crapware.
Who obfuscates? Posted Apr 10, 2005 3:05 UTC (Sun) by MathFox (subscriber, #6104) [Link] I've been working in "software maintainance" for some years and I can tell you why good code is never obfuscated: Maintaining obfuscated code costs far more than maintaining normal code. The most time consuming part of bugfixing is reverse engineering the path through the code that leads to the bug, try that with obfuscated code...It is so that programs tend to accumulate "entropy" due to bug fixes and changes, making maintainance increasingly harder when no measures are taken. In a sane project there is a budget for "refactoring", to prevent chaos taking over.
Re: Who obfuscates? Posted Apr 10, 2005 4:55 UTC (Sun) by Wummel (subscriber, #7591) [Link] Maintaining obfuscated code costs far more than maintaining normal code.You don't work with obfuscated code. Obfuscation is normally an automated step before compiling, for example calling retroguard for Java progs. Obfuscating with retroguard actually speeds up the startup time since variable names are shorter and the resulting .class files are smaller. Another possibility is putting all the compiled code in an archive, encrypt it, and write a small C wrapper that loads the archive in memory, decrypts it and runs it (either in the Java/Python interpreter, or directly as a native executable). There is no runtime overhead with this method, only startup is slower. And it is hard to decompile since you have to trace the decryption routine with a disassembler, or make a memory dump of the decrypted program.
Re: Who obfuscates? Posted Apr 11, 2005 1:03 UTC (Mon) by khim (subscriber, #9252) [Link] You don't work with obfuscated code. Obfuscation is normally an automated step before compiling, for example calling retroguard for Java progs. Obfuscating with retroguard actually speeds up the startup time since variable names are shorter and the resulting .class files are smaller. It also makes trace logs useless thus making support nightmare. And it does not make code that much harder to crack. So even automatic obfuscator is useless in 99% cases.
Re: Who obfuscates? Posted Apr 11, 2005 6:57 UTC (Mon) by AAP (guest, #721) [Link] Automated obfuscaters? Bah, I know of an ex-programmer where I work that can outdo any automatic obfuscation! It was one programmer, not a company policy, but he did it because he thought it would make him too "valuable" to fire. Unfortunately for me, he eventually left, and I was the poor schmoe that had to rewrite his crap!
Protect Your Source Code: Obfuscation 101 (O'ReillyNet) Posted Apr 11, 2005 7:12 UTC (Mon) by Seegras (guest, #20463) [Link] Obfuscation sucks. I de-obfuscated some parts of the (legally bought) endymion mailman (perl). Of course, not only the license-thingie was in there, but a web-bug also. Thank you very much. We dumped that thing shortly after.
Protect Your Source Code: Obfuscation 101 (O'ReillyNet) Posted Apr 11, 2005 17:45 UTC (Mon) by XERC (guest, #14626) [Link] Now, suppose one has to work on a speed-critical application, for example, image processing(feature detection).Now, suppose that at least halve of the billed time is spent on ALGORITHM DEVELOPMENT, to be more exact, finding algorithms that give good results and ARE AS FAST AS THE WHOLE TEAM CAN EVER THINK OF. Now, suppose that those algorithms are coded in a fashion that ABSOLUTELY EVERY LINE IS ANALYSED FROM SPEED'S POINT OF VIEW, not to mention the architecture. OK, and what would obfuscation do? It would ABSOLUTELY DESTROY the work that took at least 50% of the development(finding fast algorithms and coding them in a "speed first" style) time. So, my point is that technically there is NO WAY for a vendor, who provides a really speed-critical application, to use any obfuscation.
Protect Your Source Code: Obfuscation 101 (O'ReillyNet) Posted Apr 12, 2005 20:58 UTC (Tue) by XERC (guest, #14626) [Link] I just couldn't leave one joke unsaid:
I wonder, has anybody tried to use obfuscation
OK, if You didn't figure it out, read the following
|
|||||||||||