C++ obfuscator

Wouter van Ooijen

unread,

Nov 23, 2014, 4:05:37 AM11/23/14

to

Anyone knows a free C++ obfuscator that can do a single .cpp file?

It does not need to be CIA-proof, just mangling the internal literals
and names and removing the whitespace is probably enough.

Wouter van Ooijen

Mr Flibble

unread,

Nov 23, 2014, 10:42:00 AM11/23/14

to

What is the point of using such a tool? Either you are closed source in
which you don't need it or you are open source in which case you want
your code to be legible.

/Flibble

Wouter van Ooijen

unread,

Nov 23, 2014, 11:05:53 AM11/23/14

to

Mr Flibble schreef op 23-Nov-14 4:41 PM:

The question remains whether the use has a point or not, but FYI: I am a
teacher and I want to give my studenst 10 versions of the implementation
of a class, one (hopefully) correct, and 9 each with one bug. Their task
is to write a set of tests for the class, and find the one correct
implementation, and for each bug the nature of the bug. Giving the plain
source would make a text diff approach too easy.

My students use different compilers (some of which I don't have), so it
is not practical for me to give them the object files.

Wouter

Mr Flibble

unread,

Nov 23, 2014, 11:17:48 AM11/23/14

to

If your students are unable to determine what the code is supposed to do
due to obfuscation then how can they determine which has a "bug" or not?
Writing unit tests for obfuscated code sounds almost impossible. Your
assignment is both unrealistic and pointless.

/Flibble.

Mr Flibble

unread,

Nov 23, 2014, 11:19:39 AM11/23/14

to

Additionally using a diff tool shows initiative and is what your
students would use in the real world anyway.

/Flibble

Wouter van Ooijen

unread,

Nov 23, 2014, 11:33:54 AM11/23/14

to

Mr Flibble schreef op 23-Nov-14 5:17 PM:

> On 23/11/2014 16:05, Wouter van Ooijen wrote:
>> Mr Flibble schreef op 23-Nov-14 4:41 PM:
>>> On 23/11/2014 09:05, Wouter van Ooijen wrote:
>>>> Anyone knows a free C++ obfuscator that can do a single .cpp file?
>>>>
>>>> It does not need to be CIA-proof, just mangling the internal literals
>>>> and names and removing the whitespace is probably enough.
>>>
>>> What is the point of using such a tool? Either you are closed source in
>>> which you don't need it or you are open source in which case you want
>>> your code to be legible.
>>
>> The question remains whether the use has a point or not, but FYI: I am a
>> teacher and I want to give my studenst 10 versions of the implementation
>> of a class, one (hopefully) correct, and 9 each with one bug. Their task
>> is to write a set of tests for the class, and find the one correct
>> implementation, and for each bug the nature of the bug. Giving the plain
>> source would make a text diff approach too easy.
>>
>> My students use different compilers (some of which I don't have), so it
>> is not practical for me to give them the object files.
>
> If your students are unable to determine what the code is supposed to do
> due to obfuscation

What this code is *supposed* to do is of course provided by a
specification.

But again, that does not matter much for the original question. Do you
have anything meaningfull to say on that?

Wouter

Mr Flibble

unread,

Nov 23, 2014, 11:49:54 AM11/23/14

to

I repeat what I said earlier: code obfuscation is totally pointless and
your assignment is also pointless and unrealistic.

/Flibble

Robert Wessel

unread,

Nov 23, 2014, 12:14:30 PM11/23/14

to

A few folks distribute software in a way that it needs to be compiled
by the user. There may be technical or business reasons for that sort
of thing. Consider a (portable) library that should run on platforms
the vendor doesn't directly support. Or code that needs to run in
interpreted form (or at least be distributed that way), for example a
lot of JavaScript*. Obfuscated** source has some appeal in those
scenarios.

Personally I'd sure try to avoid it, and the security possible is
limited. OTOH, a determined enough thief can extract a lot from
binary executables as well.

*Well minified JS is half way there, if you ask me.

**FWIW, I'm not sure when the term "shrouded source" got replaced, but
this has been around for a very long time, particularly in the Unix
world.

Öö Tiib

unread,

Nov 23, 2014, 12:16:05 PM11/23/14

to

On Sunday, 23 November 2014 18:05:53 UTC+2, Wouter van Ooijen wrote:
> Mr Flibble schreef op 23-Nov-14 4:41 PM:
> > On 23/11/2014 09:05, Wouter van Ooijen wrote:
> >> Anyone knows a free C++ obfuscator that can do a single .cpp file?

I don't know of one. C++ is compiled language without standardized
run-time reflection. Run-time reflection is not used by C++ program.
There can be implementation-specific debug information but that is
only used by external tools and so is not deployed with binaries.
Therefore the executable binary is already obfuscated and obfuscators
are for .NET and Java binaries.

> >> It does not need to be CIA-proof, just mangling the internal literals
> >> and names and removing the whitespace is probably enough.
> >
> > What is the point of using such a tool? Either you are closed source in
> > which you don't need it or you are open source in which case you want
> > your code to be legible.
>
> The question remains whether the use has a point or not, but FYI: I am a
> teacher and I want to give my studenst 10 versions of the implementation
> of a class, one (hopefully) correct, and 9 each with one bug.

If the program does anything useful then it contains defects. So there
are no hope that you can provide correct program unless all what it does
is totally abstract and useless.

> Their task
> is to write a set of tests for the class, and find the one correct
> implementation, and for each bug the nature of the bug. Giving the plain
> source would make a text diff approach too easy.

If you are really teacher then you must have *huge* archive of programs
that are all broken in several ways. Even I have such archive despite I
have only sometimes reviewed pre-interview assignments of people who want
to work as C++ programmers. About half of such works do not need any
obfuscators to make them even worse. :D

> My students use different compilers (some of which I don't have), so it
> is not practical for me to give them the object files.

So you do not review their "set of tests" either? They get your code, work
on their compilers and only give you the end results? That sounds rather
distant kind of teaching.

Wouter van Ooijen

unread,

Nov 23, 2014, 1:07:38 PM11/23/14

to

嘱 Tiib schreef op 23-Nov-14 6:15 PM:

I don't recall saying so.

> They get your code, work
> on their compilers and only give you the end results? That sounds rather
> distant kind of teaching.

So it sounds to me too, which is why I mostly don't work that way.

Wouter

Geoff

unread,

Nov 23, 2014, 2:26:57 PM11/23/14

to

It's not pointless if you are trying to teach black-box testing.

If you need to create a black box but you can't compile it for diverse targets
and you need to distribute the source for the black box without disclosing the
contents then the obfuscation tool would make sense.
>

Jorgen Grahn

unread,

Nov 23, 2014, 3:12:41 PM11/23/14

to

On Sun, 2014-11-23, 嘱 Tiib wrote:
> On Sunday, 23 November 2014 18:05:53 UTC+2, Wouter van Ooijen wrote:

...

>> My students use different compilers (some of which I don't have), so it
>> is not practical for me to give them the object files.
>
> So you do not review their "set of tests" either? They get your code, work
> on their compilers and only give you the end results? That sounds rather
> distant kind of teaching.

Why assume that? The students compile the obfuscated system-under-
test, write their tests, and hand them in. He reads and runs their
tests on his own system.

Sounds like a pretty interesting and useful exercise. They learn the
value of documented interfaces, and of programming against interfaces.
And they get to break stuff!

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Öö Tiib

unread,

Nov 23, 2014, 4:06:45 PM11/23/14

to

Sorry, then I apparently misunderstood the problem. IOW ... Why you
obfuscate the code? If the students have to present their tests
then I see no reason why you should deliver them all the broken
programs to test. Tests usually are made to find defects that are
in code now but more importantly what will be made there by maintenance
of future. So ... I did draw too far conclusions from that.

Wouter van Ooijen

unread,

Nov 23, 2014, 5:19:03 PM11/23/14

to

Geoff schreef op 23-Nov-14 8:26 PM:

Spot on, that is exactly my sitiuation.

Wouter

Wouter van Ooijen

unread,

Nov 23, 2014, 5:21:34 PM11/23/14

to

Öö Tiib schreef op 23-Nov-14 10:06 PM:

I'd like to give the students the satisfaction of
discovering/identifying more and more of the bugs while they are adding
more tests. I am sure this is in agreement with some theory about
learning but I don't know which one.

Wouter