Article:		Protect Your Source Code: Obfuscation 101
Subject:		Extremely slow applications
Date:		2005-04-09 13:50:15
From:		elanthis
If this is something that Java professionals really do, it's no wonder Java has such a record for being dog slow. ;-) You are inserting gobs and gobs and gobs of useless, pointless code that the compiler doesn't (is in fact incapable of) optimizing out. What might have been done in a dozen opcodes now takes hundreds or thousands. Doesn't matter if you're using C, Java, or any other language, such obfuscation techniques make your final application far worse performance wise.

Showing messages 1 through 4 of 4.

• Extremely slow applications
  2005-04-09 17:00:50  Matthew Russell | [View]
  
  
  Well, I'd be careful with making such a generalization as that. Clearly, if you obfuscate your entire performance sensitive application then you'd probably see some major meltdown (especially for an interpreted language), but it's almost never going to make sense to obfuscate an entire application.
  
  It's likely just the sensitive portions of code that you want to protect; maybe something during startup that makes sure you've registered it, a portion that determines whether to fire another nag screen, or some other routine that handles how you encrypt some data that's stored to disk -- or something along those lines. i.e. the portions that are likely to be examined and patched.
• Extremely slow applications
  2005-04-10 20:03:32  michaelartemiw [View]
  
  
  What generalization! The code obfuscations in the article will without a doubt slow your software to a crawl. In 90% of the cases your "sensitive" code areas are going to be ones that need to run fast.
  
  Just as you want it to take the hacker longer to break your code than it would be to write it from scratch you want it to be faster for the user to use your software than to do it by hand or use the competition's product.
  
  It should be noted that we are talking about control flow obfuscation which is bleeding edge. You can still perform name obfuscation which will not cause a performance penalty and still deter most snoopers.
• Extremely slow applications
  2005-04-11 06:11:31  Matthew Russell | [View]
  
  
  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.
• 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...