Security (and size, and performance) through obscurity

I was playing around in the NetBeans IDE today, as we are going to use it for some mobile programming classes. In the project properties menu, I found “Obfuscation”. This seems to be ten levels of code obfuscation, ranging from clean to “High obfuscation”.

Though it seemed very easy to use, it did not explain anything deeper about what was going on. So I checked the “Help” documentation

I cite SUN’s statement about obfuscated programs, from the help page “About Obfuscation” here:
“Obfuscated programs are not only more difficult to decompile or reverse-engineer, they are also frequently smaller in size, improving performance and mobility as well as security.”

So SUN states that an obfuscated program is smaller, has better performance and is more secure.

I would really like to have some SUN people explaining why this is true.

This entry was posted in English posts, Open Source, Security and tagged , , . Bookmark the permalink.

One Response to Security (and size, and performance) through obscurity

  1. purplehex says:

    Hej

    Jeg kan måske svare på lidt af det. Java obfuscation funktionen i NetBeans leveres af en af de to mest populære open source obfuscators kaldet ProGuard (http://proguard.sourceforge.net/).

    Den anden hedder RetroGuard (http://www.retrologic.com/retroguard-main.html).
    EclipseME benytter iøvrigt også ProGuard.

    ProGuard beskriver selv brugen af deres produkt som:

    1) Creating more compact code, for smaller code archives, faster transfer across networks, faster loading, and smaller memory footprints.
    2) Making programs and libraries harder to reverse-engineer.
    3) Listing dead code, so it can be removed from the source code.
    4) Retargeting and preverifying existing class files for Java 6, to take full advantage of Java 6′s faster class loading.

    Mht. sikkerhed tror jeg, at der er tale om punkt 3, der synliggør overflødig kode, der kan fjernes og derved minimere programmet. Mindre programmer har normalt færre fejl, hvis man måler på fejl per linie kode.

    Det kunne i hvertfald være en del af forklaringen på at sikkerhed har sneget sig ind i den sætning.

    mvh. Sidsel

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>