Talk:Obfuscation (software)

Am I the only one who thinks this article has a few inaccuracies? Obfuscation of the source code makes no difference to the output of a decompiler. Variable names in the source code of any compiled language is reduced to addresses in the final object code. These addresses take the same space regardless of how long the variable name was in the first place.

I'm hacking this article until its not wrong!

---

You are absolutely wrong. Your model is too simplistic, and will even be more so after the C++ committe meets in a few years. Your claims only hold true for a very few languages, like C.

I wrote these parts of the article from a position of experience, while your claims are from a position of theory. Therefore your theory does not consider enough variables. One word: Symbol tables. These tables are important for many forms of dynamic programming (such as Reflection) and are stored with the bytecode/executable/interpreted script in a great number of languages.

That is two articles of mine that have been deleted, out of three. One of them having been my user page. This is extremely frustrating. I am just deleting my entire entry until I have time to revert it with deeper explanations.

---

And furthermore, there is more to obfuscation than just simple renaming. I've heard that Microsoft in its early days inserted instructions that confused and broke common debuggers, to resist analysis of their programs. Obfuscation also covers the realm of destroying all structure that would lend a program to human-readability.

If you look at sourcecode, it is well-structured. It is decomposited into functions for Structured Programming, objects of OOP, etc. Compilers tend to propagate this structure into compiled code. Obfuscators erase as much of this as possible.

---

The following sections of this article were removed (by "forgotten gentleman"); I'm putting them on this /Talk page for future reference.

Uses for obfuscation

There is generally little point in plain obsfuscation of source code although some cases include:

• Attempting to "protect" the IP of something that has to provided in source form (for platform portability)

• Some code-generators (e.g. SDL) generate hard to read code, on the basis that you should tweak the design not the code.

When dealing with interpreted languages it could be argued that smaller (but less undestandable) variable names will keep code size down. However this is a false economy OK that wasn't NPOV

Problems with obfuscation

Debugging

Obfuscated code is extremely difficult to debug. Variable names will no longer make sense, and the structure of the code itself will likely be modified into unrecognizability. This fact generally forces developers to maintain two builds: One that can be easily debugged, and another for release. Both builds should be tested to make sure they act identically.

Defective obfuscators

Occasionally an obfuscator may be buggy, in a difficult to reproduce way. There is little one can do except find a newer version or fiddle with any inputs to the obfuscator until it works.