Re: C/C++ obfuscator

Paul Pluzhnikov <>
6 Feb 2005 14:59:35 -0500

          From comp.compilers

Related articles
[3 earlier articles]
Re: C/C++ obfuscator (Paul Pluzhnikov) (2005-01-25)
Re: C/C++ obfuscator (George Neuner) (2005-01-25)
Re: C/C++ obfuscator (Louis Krupp) (2005-01-30)
Re: C/C++ obfuscator (Ira Baxter) (2005-01-30)
Re: C/C++ obfuscator (Paul Pluzhnikov) (2005-02-03)
Re: C/C++ obfuscator (2005-02-03)
Re: C/C++ obfuscator (Paul Pluzhnikov) (2005-02-06)
Re: C/C++ obfuscator (Louis Krupp) (2005-02-06)
| List of all articles for this month |

From: Paul Pluzhnikov <>
Newsgroups: comp.compilers
Date: 6 Feb 2005 14:59:35 -0500
Organization: Compilers Central
References: 05-01-074 05-01-110 05-02-023
Keywords: C, tools
Posted-Date: 06 Feb 2005 14:59:35 EST writes:

> Am I missing something?

I think you are.

To make a commercial product, you need your obfuscator to produce code
that compiles with *all* the widely-available compilers, but such
compilers are often bad at compiling the results of machine
transformation of the original source.

Consider the EDG front-end and C++-generating back-end, which we (and
many others, including AFAIK SGI's Pro64 you mentioned) use.

It has special cases for VC6.0, 7.0 and 7.1, and for gcc. Yes,
reconstructed code is (in some cases) different for each of the above

It does not officially support and does not handle some of the
g++-2.95 bugs.

Yet in the past 6 month we filed tens of problem reports, where a
trivial source is reconstructed back in almost exactly the same form,
yet the compiler refuses to accept and compile the reconstructed code.

Just in case someone mis-understands me, the bugs are not in the EDG
code; it's the compilers that are buggy.

So, as always, the devil is in the details.

In order to understand recursion you must first understand recursion.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.