views:

1054

answers:

9

A different question, i.e. Best .NET obfuscation tools/strategy, asks whether obfuscation is easy to implement using tools.

My question though is, is obfuscation effective? In a comment replying to this answer, someone said that "if you're worried about source theft ... obfuscation is almost trivial to a real cracker".

I've looked at the output from the Community Edition of Dotfuscator: and it looks obfuscated to me! I wouldn't want to maintain that!

I understand that simply 'cracking' obfuscated software might be relatively easy: because you only need to find whichever location in the software implements whatever it is you want to crack (typically the license protection), and add a jump to skip that.

If the worry is more than just cracking by an end-user or a 'pirate' though: if the worry is "source theft" i.e. if you're a software vendor, and your worry is another vendor (a potential competitor) reverse-engineering your source, which they could then use in or add to their own product ... to what extent is simple obfuscation an adequate or inadequate protection against that risk?


1st edit:

The code in question is about 20 KLOC which runs on end-user machines (a user control, not a remote service).

If obfuscation really is "almost trivial to a real cracker", I'd like some insight into why it's ineffective (and not just "how much" it's not effective).


2nd edit:

I'm not worried about someone's reversing the algorithm: more worried about their repurposing the actual implementation of the algorithm (i.e. the source code) into their own product.

Figuring that 20 KLOC is several month's work to develop, would it take more or less than this (several months) to deobfuscate it all?

Is it even necessary to deobfuscate something in order to 'steal' it: or might a sane competitor simply incorporate it wholesale into their product while still obfuscated, accept that as-is it's a maintenance nightmare, and hope that it needs little maintenance? If this scenario is a possibility then is obfuscated .Net code any more vulnerable to this than compiled machine code is?

Is most of the obfuscation "arms race" aimed mostly at preventing people people from even 'cracking' something (e.g. finding and deleting the code fragment which implements licensing protection/enforcement), more than at preventing 'source theft'?

+1  A: 

I tend to think that obfuscation is really not very effective if you want to protect your source. For the real expert in the field (I don't mean a software expert here or a cracker, I mean the expert in the field of the functionality of the code), usually he or she doesn't need to see the code, just see how it does react against special inputs, edge cases, etc., to get an idea of how to implement a copy or a code that is equivalent to that protected functionality. Thus, not very helpful in protecting your know-how.

Diego Sevilla
I'd be trying to prevent theft of the maintainable implementation (i.e. source code), not prevent reverse-engineering of the algorithm.
ChrisW
A: 

If you have IP in code which must be protected at all costs, then you should make your software's functionality available as a service, on a secured remote server.

Good obfuscation will protect you up to a point, but it's all about the amount of effort required to break it against the 'reward' of having the code. If you are talking about stopping your average business user, then a commercial obfuscator should be sufficient.

Mitch Wheat
+9  A: 

Obfuscation is a form of security through obscurity, and while it provides some protection, the security is obviously quite limited.

For the purposes you describe, obscurity can certainly help, and in many cases, is an adequate protection against the risk of code theft. However, there is certainly still a risk that the code will be "unobfuscated" given sufficient time and effort. Unobfuscating the entire codebase would be effectively impossible, but if an interested party only wishes to determine how you did some certain part of your implementation, the risks are higher.

In the end, only you can determine whether the risk is worth it for you or your business. However, in many cases, this is the only option you have if you wish to sell your product to customers to use in their own environments.

Regarding the "why its ineffective" - the reason is because a cracker can use a debugger to see where your code is running regardless of what obfuscation technique is used. They can then use this to work around any protection mechanisms you've put in place, such as a serial number or "phone home" system.

I don't believe the comment was really referencing "code theft" in the sense that your code is going to be stolen and used in another project. Because they used the word "cracker," I believe they were talking about "theft" in terms of software piracy. Crackers specialize in working around protection mechanisms; they're not interested in using your source code for some other purpose.

wuputah
You say, "given sufficient time and effort". Do you know anything about quantifying that: how much time and effort?
ChrisW
In practicality, I don't think you have much to worry about. It would likely take years to fully deobfuscate your 20k LOC project; it would be much faster to reimplement it. Anything truly novel in your code would be patentable, which would be another line of defense in addition to your obfuscation.
wuputah
The fact remains that this is what obfuscation is for; anyone who looked at your code and saw it was obfuscated is not going to bother. The "arms race" is either to sell a new product (one up a competitor) and to try and make it even harder for crackers.
wuputah
It would be comforting to believe that "it would likely take years to fully deobfuscate your 20k LOC project; it would be much faster to reimplement it". Do you know of any evidence for that: why do you think that's true?
ChrisW
I can give you evidence of the contrary game consoles, with specialized encryption, millions of dollars, and hardware keys to make stuff hard to figure out, gets cracked within months, if they are lucky, days if not.
Robert Gould
Robert, I'm explicitly not asking about 'cracking' licensing protection (i.e. about finding and then skipping small sections of functionality).
ChrisW
A: 

Short answer is yes and no; it depends entirely on what you are trying to prevent. Section twelve of Secure Programming Cookbook has some interesting comments on this on page 653 (which is conveniently unavailable in google books preview). It classifies anti-tampering into four categories: Zero day (slowing down an attacker so it takes them a long time to accomplish what they want), protection of a proprietary algorithm to prevent reverse engineering, "because I can" attacks and I can't remember the 4th one. You have to ask what am I trying to prevent, and if you are really concerned about an individual getting a look at your source code then obfuscation has some value. Used on it's own it's usually just an annoyance to someone attempting to mess with your application and like any good security measure it works best when used in combination with other anti-tampering techniques.

Kevin Loney
I said what I'm trying to prevent: theft of source code by a competing software vendor who might then incorporate it into their own product.
ChrisW
My answer was intended to be broad and cover obfuscation as a general anti-tampering approach.
Kevin Loney
+2  A: 

Most people tend to write what appears to be obfuscated code and that hasn't stopped the crackers so what's the difference?

EDIT:

Ok, serious time. If you really want to make something that's hard to break, look into polymorphic coding (not to be confused with polymorphism). Make code that is self-mutating, and it is a serious pain to break and will keep them guessing.

http://en.wikipedia.org/wiki/Polymorphic_code

In the end, nothing is impossible to reverse engineer.

James Jones
Hilarious and should be a comment, not an answer.
Kevin Loney
Ouch. Didn't know I'd be blasted for making a funny. My bad...
James Jones
+1 for polimorphic code!
backslash17
+16  A: 
Simucal
Your statement, "The cost involved with reversing your application quickly exceeds the cost of writing it from scratch" seems to be rather the opposite of the statement I cited in the OP, i.e. "if you're worried about source theft ... obfuscation is almost trivial to a real cracker".
ChrisW
@ChrisW, not at all. Source Theft != Cracking. Reversing an application to the point of being able to crack it is no where near the same thing as reversing a significant chunk of source code from it. And obfuscation isn't what makes the reversing of any sizeable portion of an app difficult.
Simucal
I'll edit my post to clarify.
Simucal
Tried to clarify a little ChrisW.
Simucal
I'm not worried about someone's reversing the algorithm ... more worried about their repurposing the actual implementation of the algorithm (i.e. the source code) into their own product. Figuring that 20 KLOC is several month's work to develop, would it take more or less than several months to ...
ChrisW
... deobfuscate? Is it even necessary to deobfuscate something in order to 'steal' it, or might a sane competitor just incorporate it wholesale while still obfuscated, accept that it's a maintenance nightmare and hope that it needs little maintenance? Is most of the obfuscation "arms race" aimed ...
ChrisW
... at preventing people people from even 'cracking' something (e.g. finding and deleting licensing), more than at preventing 'source theft'?
ChrisW
@ChrisW, The cost of source theft is greater than the cost of developing it form scratch is almost all cases except the ones I listed above. Most of the obfuscation and protection is used to prevent people from pirating your applications and we all know how well that goes down.
Simucal
What evidence is there for saying that "The cost of source theft is greater than the cost of developing it form scratch" and "It would take almost an order of magnitude longer to reverse those equivalent 20kLOC from your application into workable source if you took the bare minimum precautions"?
ChrisW
And, to be specific, might taking "the bare minimum precautions" mean 'using the Community Edition of Dotfuscator', or are the minimum precautions higher / more rigorous than this?
ChrisW
@ChrisW, if I honestly was worried then I would use any obfuscator (Dotfuscator is fine) ~and~ I would use a 3rd party packer. Since you are using .NET this has the added advantage of preventing people from using reflector on your application and it can be troublesome to unpack.
Simucal
Your source code, as such, no longer exists in the executable, just the instruction set generated by the code. It is a blue-print, not in the final product. Its like will putting curtains over my building stop people from stealing my blueprints? ... there is no connection between both in this cases
Robert Gould
@Robert Gould, I'm not sure what you are saying. Nowhere I am suggesting that your source code still exists in it's original form. That doesn't mean algorithms can be derived from your machine instructions, and in that sense, source-theft.
Simucal
@Simucal, no you don't imply it at all, but I think ChrisW might believe the source is somehow obtainable from the executable, when its not. He seems more concerned about his line count than his algorithms. So I think he has a misconception that doesn't allow him to understand the problem correctly.
Robert Gould
@Robert Gould, Ahh, I see what you are saying now. Yes, I agree.
Simucal
In the case of .Net (e.g. C#) the source code (including bodies of each method, symbolic names of local variables, everything except comments) can be retrieved from the intermediate language to which it's "compiled": i.e. a 1-to-1 reversible mapping to the source *is* in the executable.
ChrisW
@ChrisW, the .NET Compiler changes many things and it is never possible to go from compiled MSIL to what the developers source is. You can get relatively close, but even just deciphering the compilers "optimizations" can be tricky. If you don't wan't reflecting then use packers.
Simucal
Thanks for the reference to the book.
ChrisW
well said and thx for the book reference
Konstantinos
I love the Apple example.I'll respond with an Italian Job reference. "Are you the real Napster?"
samoz
+2  A: 

Look at it this way; the WMD editor that you typed your question into was reverse engineered by the SO team in order to fix some bugs and make som enhancements. That code was obfuscated. You are never going to stop intelligent motivated people from hacking your code, the best you can hope for is to keep the honest people honest and make it somewhat hard to break.

Ed Swangren
+2  A: 

You are worried about people stealing the specific algorithms used in your product. Either you are Fair Isaac or you need to differentiate yourself using more than the way you x++;. If you solved some problem in code that cannot be solved by someone else puzzling over it for a few hours, you should have a PhD in computer science and/or patents to protect your invention. 99% of software products are not successful or special because of the algorithms. They are successful because their authors did the heavy lifting to put together well-known and easily understood concepts into a product that does what their customers need and sell it for cheaper than it would cost to pay others to re-do the same.

Rex M
Exactly. The "heavy lifting" isn't any super-secret algorithm, it's the 20 KLOC of carefully-designed and tested source code. And if everyone can reverse that more easily than I can write it in the first place, then it would be hard for me to compete with them by "selling it for cheaper".
ChrisW
@ChrisW, No one is going to reverse your "heavy lifting" cause it is nothing special! Like Rex was saying, they would simply write it themselves. The only time source-theft enters the game is if you have some specific algorithm that is complex or novel enough that others don't have it.
Simucal
Assuming that the legality of the action is immaterial, they'll write it themselves if-and-only-if it's cheaper to do that than to reverse it. Is there any evidence about whether and if so how much more expensive it is to reverse obfusticated source than it is to write it from sratch?
ChrisW
A: 

If you've ever seen the output from a disassembler, you'd realize why obfuscation will always fail.

toast