One problem with the assertion that "users should be able to decide whether or not they want obfuscated code on their system" is that it isn't always obvious what's obfuscation and what isn't. Something that looks like obfuscation to someone may in fact have nothing at all to do with DRM or anti-reverse-engineering, but may simply be the result of very aggressive optimization. For example:

* A long time ago Henry Massalin did some really neat work on the "superoptimizer" [1], which would come up with really short and unintuitive instruction sequences for common operations. The fact that these were unintuitive and hard to understand doesn't make it obfuscation.

* Conversely, a lousy compiler can generate really crappy code with all sorts of unnecessary and redundant operations. This isn't obfuscation, even though malware also use unnecessary/redundant code ("semantic NOPs") to disguise their code from scanners.

* JIT compilation (and other such dynamic optimization techniques) are a form of self-modifying code.

* There has been work on using selective virtualization to reduce a program's code footprint, for use in memory-limited embedded systems [2]. Again, this isn't obfuscation even though some code obfuscators use virtualization.

References:

[1] Henry Massalin. "Superoptimizer--A Look at the Smallest Program". Proc ACM ASPLOS '87, Sigplan Notices 22,10 (Oct 1987), 122-126.

[2] Jan Hoogerbrugge, Lex Augusteijn, Jeroen Trum and Rik Van De Wiel. "A code compression system based on pipelined interpreters". Software?Practice & Experience vol 29, issue 11 (September 1999).


[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/498/35440#35440