Women in Technology

Article:		Protect Your Source Code: Obfuscation 101
Subject:		Extremely slow applications
Date:		2005-04-11 06:11:31
From:		ptwobrussell
Response to: Extremely slow applications
Ok, so first let me say that I'm not making the case that obfuscation doesn't incur a performancy penalty in many cases. But there are many techniques that aren't such a performance drain as you'd think and instead impose more of a size penalty --something we might be able to live with a little bit more. One of my favorites is when you duplicate a code block several times, introduce small bugs in each of the blocks, and then make it difficult to determine which of the blocks is actually executed. Sandmark does things along these lines. BTW, the examples in the article for HelloWorld are illustrational and intended to communicate the concept, and weren't intended to be taken as being state-of-the-art. Sandmark, on the other hand, does some pretty clever stuff. If you tailor your obfuscation approach and actually think about what it's doing (as opposed to blindly picking a technique), you can keep the performance penalty fairly minimal many times. In the case of Java or even ObjC, name obfuscation (as you mentioned) can go a long way and it's trivial to do with a few perl scripts. I don't know that I'd agree that 90% of the time your sensitive code areas are going to have to run fast. Maybe so, but maybe not. I wouln't feel comfortable saying that it's anywhere 90% of the time though. Certainly, protecting against nag screen removal, registration code patching and basic security mechanisms along those lines don't need to run at lightning fast speeds, and are some of the most common ones that come to mind -- I'd think that this is especially true for "small" independent developers, who often have created more of a software engineering masterpiece than some cutting edge new algorithm for something.

Showing messages 1 through 1 of 1.

• Extremely slow applications
  2005-05-18 16:11:26  zeon_uk [View]
  
  
  What you're forgetting is that compilers generate code in specific ways. A hacker over time gets used to these layouts and would immediately notice any obscured code. That in itself is saving the hacker time!
  
  Secondly, a lot of protection code jumps through various hoops but nearly always ends up with a simple binary decision. Most hackers would just alter this bottleneck. It's not true for all situations, but you would be surpised how often it does happen. Literaly changing one bit in a branch instruction can circumvent an awful lot of protection code. Not every developer has the ability to check the object code to see if his techniques are affective.
  
  Third, I agree with the remark regarding looking for the distinct features of sandmark, and writing something to reverse its affects. Many years ago when version 3 of a well known dongle maker came out I downloaded a copy of their developers kit and removed the protection on a $3000 application in 45 minutes. Their marketing campaign quoted them as spending a million man hours in its development. I did this by request...the user was having problems and it was impacting his ability to work.
  
  I've seen attempts that cause many problems, including response times. I remember some apps. performing so many security checks that they consumed 10-15% of the running time.
  
  My opinion is that security by obscurity never works...obfuscation is just another form of this.
  
  As has already been mentioned...at best you can slow a hacker down. If you make it require too much time rather than skill he may not bother. Obviously, this applies to those that do it for the challenge. Commerical pirates will spend the time. Eastern Europe used to be the hot bed for this kind of thing.
  
  That my two cents worth...