obfuscation

[GK]

Hello,

Can anybody suggest a best code obfuscation tool based on their exeperience
? (e.g.: testing effort after obfuscation is 0)

thanks,
GK

[Zeppe]

GK wrote:

Hello,

Can anybody suggest a best code obfuscation tool based on their exeperience
? (e.g.: testing effort after obfuscation is 0)

My compiler obfuscates the c++ code quite well.

Regards,

Zeppe

[Puppet_Sock]

On May 29, 8:45 am, "GK" <[e-mail]:
[snip]

? (e.g.: testing effort after obfuscation is 0)

Maybe I've just had too little coffee today. But why
would you expect obfuscation to reduce your testing
effort?
Socks

[JohnQ]

"Zeppe" <zep_p@.remove.all.this.long.comment.yahoo.itwro te in message
news:f3**********@aioe.org...

GK wrote:

>Hello,

Can anybody suggest a best code obfuscation tool based on their
exeperience
? (e.g.: testing effort after obfuscation is 0)

My compiler obfuscates the c++ code quite well.

I'll bet you haven't looked at your executables with an editor lately if you
think that. If you leave it the way the compiler leaves it, you'll probably
be able to generate class and function diagrams from the human-readable text
in the code.

I have kinda the same question the OP has, BTW. I've heard that at least one
"standard practice" is to compress (therefor making the executables
non-human readable) the executables and expand them upon start up. Yes, one
could walk memory after the program is loaded and get function and class
information, but at least that takes some effort to do.

John

[JohnQ]

"Puppet_Sock" <pu*********@hotmail.comwrote in message
news:11**********************@o5g2000hsb.googlegro ups.com...

On May 29, 8:45 am, "GK" <[e-mail]:
[snip]

>? (e.g.: testing effort after obfuscation is 0)

Maybe I've just had too little coffee today. But why
would you expect obfuscation to reduce your testing
effort?
Socks

I think he's saying that he wants to obfuscate his code and then run the
same tests on it that he did prior to the obfuscation to ensure that the
obfuscation didn't mess anything up. (?)

John

[Ian Collins]

JohnQ wrote:

"Zeppe" <zep_p@.remove.all.this.long.comment.yahoo.itwro te in message
news:f3**********@aioe.org...

>GK wrote:

>>Hello,

Can anybody suggest a best code obfuscation tool based on their
exeperience
? (e.g.: testing effort after obfuscation is 0)

My compiler obfuscates the c++ code quite well.

I'll bet you haven't looked at your executables with an editor lately if you
think that. If you leave it the way the compiler leaves it, you'll probably
be able to generate class and function diagrams from the human-readable text
in the code.

Only if you leave debugging information in the executable. Otherwise
optimised code is all but impossible to reverse engineer.

--
Ian Collins.

[JohnQ]

"Ian Collins" <ia******@hotmail.comwrote in message
news:5c**************@mid.individual.net...

JohnQ wrote:

>"Zeppe" <zep_p@.remove.all.this.long.comment.yahoo.itwro te in message
news:f3**********@aioe.org...

>>GK wrote:
Hello,

Can anybody suggest a best code obfuscation tool based on their
exeperience
? (e.g.: testing effort after obfuscation is 0)

My compiler obfuscates the c++ code quite well.

I'll bet you haven't looked at your executables with an editor lately if
you
think that. If you leave it the way the compiler leaves it, you'll
probably
be able to generate class and function diagrams from the human-readable
text
in the code.

Only if you leave debugging information in the executable. Otherwise
optimised code is all but impossible to reverse engineer.

You could be right! Thank you, I'll investigate that (or someone will
follow-up post?). But if it's optimization that was your primary thought: I
don't use any optimization compiler settings (I don't need to, and who does
these days?).

So, the question is: are function names and class names not visible in
non-debug code? (That is a/the concern of mine).

(Aside: you're up way too late. Well at least, in the wrong place to up late
at!)

John

[Martin Rennix]

On May 30, 12:57 pm, "JohnQ" <[e-mail]>
wrote:

You could be right! Thank you, I'll investigate that (or someone will
follow-up post?). But if it's optimization that was your primary thought: I
don't use any optimization compiler settings (I don't need to, and who does
these days?).

Plenty of people. Most C++ compilers support a debug (non-optimised)
and release (optimised) mode. So you automatically get optimisation
turned on in release mode even if you aren't aware of it. Optimisation
can make a huge difference to runtime performance, even on todays
machines. Of course, even in release mode you may have some debug code
in there.

So, the question is: are function names and class names not visible in
non-debug code? (That is a/the concern of mine).

Generally they are not visible in non-debug, stripped code. Your OS
might differ in the stripping utilities provided. Eg Unix strip
generally does more than MS Windows.

[Ian Collins]

JohnQ wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:5c**************@mid.individual.net...

>JohnQ wrote:

>>"Zeppe" <zep_p@.remove.all.this.long.comment.yahoo.itwro te in message
news:f3**********@aioe.org...
GK wrote:
Hello,
>
Can anybody suggest a best code obfuscation tool based on their
exeperience
? (e.g.: testing effort after obfuscation is 0)
>
My compiler obfuscates the c++ code quite well.
I'll bet you haven't looked at your executables with an editor lately if
you
think that. If you leave it the way the compiler leaves it, you'll
probably
be able to generate class and function diagrams from the human-readable
text
in the code.

Only if you leave debugging information in the executable. Otherwise
optimised code is all but impossible to reverse engineer.

You could be right! Thank you, I'll investigate that (or someone will
follow-up post?). But if it's optimization that was your primary thought: I
don't use any optimization compiler settings (I don't need to, and who does
these days?).

Probably everyone who releases binaries. The performance improvements
can be huge, especially if inlining isn't enabled without minimal
optimisation.

So, the question is: are function names and class names not visible in
non-debug code? (That is a/the concern of mine).

(Aside: you're up way too late. Well at least, in the wrong place to up late
at!)

It was 4:15 in the afternoon!

--
Ian Collins.

[Zeppe]

JohnQ wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:5c**************@mid.individual.net...

>JohnQ wrote:

>>"Zeppe" <zep_p@.remove.all.this.long.comment.yahoo.itwro te in message
news:f3**********@aioe.org...
GK wrote:
Hello,
>
Can anybody suggest a best code obfuscation tool based on their
exeperience
? (e.g.: testing effort after obfuscation is 0)
>
My compiler obfuscates the c++ code quite well.
I'll bet you haven't looked at your executables with an editor lately if
you
think that. If you leave it the way the compiler leaves it, you'll
probably
be able to generate class and function diagrams from the human-readable
text
in the code.

Only if you leave debugging information in the executable. Otherwise
optimised code is all but impossible to reverse engineer.

You could be right! Thank you, I'll investigate that (or someone will
follow-up post?). But if it's optimization that was your primary thought: I
don't use any optimization compiler settings (I don't need to, and who does
these days?).

there are reasonable motivations to use optimizations (and to remove
debug symbols) in the release versions of the programs:
1) why have a slow program when it can be faster?
2) why have a big program when it can be smaller?

:)

Anyway, under linux, the debug symbols are activated by -g, so if you
compile without it they shouldn't be included. And the the command

strip executable_name

will remove all the names of all the exported symbols, so there will be
no more readable information. For windows I guess it's similar, look at
the "c++ options" and "code generation" options in visual studio for
example, there should be some "do no include debug information".

So, the question is: are function names and class names not visible in
non-debug code? (That is a/the concern of mine).

they are not, provided you tell the compiler that you don't need him to
preserve the function names. (well, not sure if you can delete also the
names of the function linked dynamically on shared libraries, though...
probably not).
Regards,

Zeppe

[GK]

"JohnQ" <jo***********************@yahoo.comwrote in message
news:WG*****************@newssvr22.news.prodigy.ne t...

>
"Puppet_Sock" <pu*********@hotmail.comwrote in message
news:11**********************@o5g2000hsb.googlegro ups.com...

On May 29, 8:45 am, "GK" <[e-mail]:
[snip]

? (e.g.: testing effort after obfuscation is 0)

Maybe I've just had too little coffee today. But why
would you expect obfuscation to reduce your testing
effort?
Socks

I think he's saying that he wants to obfuscate his code and then run the
same tests on it that he did prior to the obfuscation to ensure that the
obfuscation didn't mess anything up. (?)

John

Yes, I meant the same as John mentioned.
- GK

[Ian Collins]

GK wrote:

"JohnQ" <jo***********************@yahoo.comwrote in message
news:WG*****************@newssvr22.news.prodigy.ne t...

>"Puppet_Sock" <pu*********@hotmail.comwrote in message
news:11**********************@o5g2000hsb.googlegr oups.com...

>>On May 29, 8:45 am, "GK" <[e-mail]:
[snip]
? (e.g.: testing effort after obfuscation is 0)
Maybe I've just had too little coffee today. But why
would you expect obfuscation to reduce your testing
effort?
Socks

I think he's saying that he wants to obfuscate his code and then run the
same tests on it that he did prior to the obfuscation to ensure that the
obfuscation didn't mess anything up. (?)

Yes, I meant the same as John mentioned.

But what do you want to do? Isn't the obfuscation provided by optimised
and stripped compiled code good enough?

If not, I'd like to know why.

--
Ian Collins.

[Fred Zwarts]

"Ian Collins" <ia******@hotmail.comwrote in message news:5c************@mid.individual.net...

GK wrote:

>"JohnQ" <jo***********************@yahoo.comwrote in message
news:WG*****************@newssvr22.news.prodigy.n et...

>>"Puppet_Sock" <pu*********@hotmail.comwrote in message
news:11**********************@o5g2000hsb.googleg roups.com...
On May 29, 8:45 am, "GK" <[e-mail]:
[snip]
? (e.g.: testing effort after obfuscation is 0)
Maybe I've just had too little coffee today. But why
would you expect obfuscation to reduce your testing
effort?
Socks
I think he's saying that he wants to obfuscate his code and then run the
same tests on it that he did prior to the obfuscation to ensure that the
obfuscation didn't mess anything up. (?)

Yes, I meant the same as John mentioned.

But what do you want to do? Isn't the obfuscation provided by optimised
and stripped compiled code good enough?

If not, I'd like to know why.

Maybe because compiled code is not portable to another hardware architecture?

I know that some firms (e.g. see www.gimpel.com) distribute their software
in obfuscated C source form so that it can be used on any platform with a C
compiler. Probably they know a good obfuscator program.

[James Kanze]

On May 30, 6:57 am, "JohnQ" <[e-mail]>
wrote:

"Ian Collins" <[e-mail] in message
news:5c**************@mid.individual.net...

JohnQ wrote:

"Zeppe" <zep_p@.remove.all.this.long.comment.yahoo.itwro te in message
news:f3**********@aioe.org...
GK wrote:
Can anybody suggest a best code obfuscation tool based on their
exeperience
? (e.g.: testing effort after obfuscation is 0)

>My compiler obfuscates the c++ code quite well.

I'll bet you haven't looked at your executables with an
editor lately if you think that. If you leave it the way
the compiler leaves it, you'll probably be able to generate
class and function diagrams from the human-readable text in
the code.

Only if you leave debugging information in the executable.
Otherwise optimised code is all but impossible to reverse
engineer.

You could be right! Thank you, I'll investigate that (or
someone will follow-up post?). But if it's optimization that
was your primary thought: I don't use any optimization
compiler settings (I don't need to, and who does these days?).

So, the question is: are function names and class names not
visible in non-debug code? (That is a/the concern of mine).

It obviously depends on the implementation; the standard doesn't
say what is or is not "still visible". In practice, under Unix,
if you link statically, then do strip, very little symbolic
information is left. (Some must still be left floating around,
since typeid().name() has to return something. But that's about
it. And even they're just present as strings; nm doesn't see
them.)

Optimization, of course, has nothing to do with it; you can
strip the symbols from unoptimized code, and leave them in
optimized. Optimization will make it more difficult to
reconstruct the contents of a function, however.

I've also heard of people using the preprocessor to obfuscate.
Write a simple program to extract the user defined symbols from
your code, then generate a file along the lines of:
#define FirstUserSymbol A000001
#define AnotherSymbol A000002
// ...
and include it at the start of every module, before compiling.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On May 30, 7:45 am, Martin Rennix <[e-mail]:

On May 30, 12:57 pm, "JohnQ" <[e-mail]>
wrote:

You could be right! Thank you, I'll investigate that (or someone will
follow-up post?). But if it's optimization that was your primary thought: I
don't use any optimization compiler settings (I don't need to, and who does
these days?).

Plenty of people. Most C++ compilers support a debug (non-optimised)
and release (optimised) mode.

That's interesting. None of the compilers I use (Sun CC, g++
and VC++) have such a simplistic division. They all have a
fairly complicated list of options concerning optimization:
several levels of optimization, and the possibility to turn off
or on specific optimizations, regardless of the level.

So you automatically get optimisation
turned on in release mode even if you aren't aware of it.

With the three compilers mentionned above, you get what you
asked for. Generally, in the places I've worked, we've not
turned on optimization in released code unless we needed it. (A
lot of applications, even today, are IO bound, and it makes no
sense to turn on optimization in such cases. But for those
which aren't...)

Optimisation
can make a huge difference to runtime performance, even on todays
machines.

Especially on today's machines:-).

Of course, even in release mode you may have some debug code
in there.

So, the question is: are function names and class names not visible in
non-debug code? (That is a/the concern of mine).

Generally they are not visible in non-debug, stripped code. Your OS
might differ in the stripping utilities provided. Eg Unix strip
generally does more than MS Windows.

Another important issue is the use of dynamically loaded code.
The symbols needed to link it must remain present.

Also, I'm not too sure just what strip actually does. If I run
it on an executable, after, nm shows no symbols. But if I do
strings on the executable, I still find all of the names.

The real question, of course, is why you'd want to obfuscate to
begin with. The current trend seems to be in the other
direction---more and more companies are delivering the sources
with the product, or at least making them available. (Of
course, in many cases, the quality of the code is such that one
could consider the actual sources obfuscation.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On May 30, 10:45 am, Zeppe
<zep_p@.remove.all.this.long.comment.yahoo.itwrote :

JohnQ wrote:

[...]

Anyway, under linux, the debug symbols are activated by -g, so if you
compile without it they shouldn't be included. And the the command

strip executable_name

will remove all the names of all the exported symbols, so there will be
no more readable information.

That's what I always thought, but a quick check (under Solaris)
shows that it just ain't true. The names are no longer visible
to nm (and the executable is noticeably smaller), but they still
show up using strings.

For windows I guess it's similar, look at
the "c++ options" and "code generation" options in visual studio for
example, there should be some "do no include debug information".

So, the question is: are function names and class names not visible in
non-debug code? (That is a/the concern of mine).

they are not, provided you tell the compiler that you don't need him to
preserve the function names. (well, not sure if you can delete also the
names of the function linked dynamically on shared libraries, though...
probably not).

Obvoiusly not, I'd say. Also, you can't delete the names of
types, at least not if type_info::name() is still going to work.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Zeppe]

James Kanze wrote:

>will remove all the names of all the exported symbols, so there will be
no more readable information.

That's what I always thought, but a quick check (under Solaris)
shows that it just ain't true. The names are no longer visible
to nm (and the executable is noticeably smaller), but they still
show up using strings.

uhm... compiled without -g and with _NDEBUG? I obtain quite clean code
under linux... maybe strip -s.

>they are not, provided you tell the compiler that you don't need him to
preserve the function names. (well, not sure if you can delete also the
names of the function linked dynamically on shared libraries, though...
probably not).

Obvoiusly not, I'd say. Also, you can't delete the names of
types, at least not if type_info::name() is still going to work.

same with assertions... anyway, for the dynamic linking, just my
ignorance on the topic (I don't really know about how it works the name
resolution on a shared library, there will be some version information,
as well as the exported symbols..)

Regards,

Zeppe

anyway,

[Martin Rennix]

On May 30, 8:41 pm, James Kanze <[e-mail]:

>
That's interesting. None of the compilers I use (Sun CC, g++
and VC++) have such a simplistic division. They all have a
fairly complicated list of options concerning optimization:
several levels of optimization, and the possibility to turn off
or on specific optimizations, regardless of the level.

Yes you are right, but in VC++ when you create a new project by
default there are 2 configs, a debug config with optimisations off and
a release config with optimise on. Of course you can change these
settings.

The real question, of course, is why you'd want to obfuscate to
begin with. The current trend seems to be in the other
direction---more and more companies are delivering the sources
with the product, or at least making them available. (Of
course, in many cases, the quality of the code is such that one
could consider the actual sources obfuscation.)

I agree, obfuscation is generally a waste of time. All code can be
reverse engineered given enough time. And plenty of people have a lot
of time. Look how quickly games are cracked, even after spending a
fortune on anti-piracy measures. What is it you need to hide?

[Gennaro Prota]

On 30 May 2007 05:41:08 -0700, James Kanze wrote:

But if it's optimization that was your primary thought: I
don't use any optimization compiler settings (I don't need to, and who does
these days?).

>Plenty of people. Most C++ compilers support a debug (non-optimised)
and release (optimised) mode.

That's interesting. None of the compilers I use (Sun CC, g++
and VC++) have such a simplistic division. They all have a
fairly complicated list of options concerning optimization:
several levels of optimization, and the possibility to turn off
or on specific optimizations, regardless of the level.

It's a common feature of IDE's, not compilers. In Visual C++, probably
the best known example, all projects created by the wizards have two
"configurations" which are named "debug" and "release" and more or
less reflect what they think should be enabled during development and
for shipping your product, respectively. Of course, neither of the two
is useful --as is-- in production.

But I'll concede that the C standard did somehow set a precedent, by
naming NDEBUG that way: if it just turns asserts off why not naming it
NOASRT, for instance? I think what IDE's currently do is basically
applying the same line of thought which led to the name "NDEBUG" to a
number of other things; and --needless to say-- they will define
NDEBUG as well in any "release" configuration. I've seen code using
asserts for unit testing in such "release" configurations (it's just
that of course one wouldn't see the invocations of assert directly,
being them hidden behind some project-specific XXX_TEST macro).

--
Gennaro Prota -- C++ Developer, For Hire
https://sourceforge.net/projects/breeze/
(replace 'address' with 'name.surname' to mail)

[James Kanze]

On May 30, 5:18 pm, Martin Rennix <[e-mail]:

On May 30, 8:41 pm, James Kanze <[e-mail]:

That's interesting. None of the compilers I use (Sun CC, g++
and VC++) have such a simplistic division. They all have a
fairly complicated list of options concerning optimization:
several levels of optimization, and the possibility to turn off
or on specific optimizations, regardless of the level.

Yes you are right, but in VC++ when you create a new project by
default there are 2 configs, a debug config with optimisations off and
a release config with optimise on. Of course you can change these
settings.

I think you're referring to the Visual Studios IDE, and not
VC++; I use VC++ from time to time, and I've not seen two
"default" configurations---VC++ is very much like g++ or Sun CC
in that it has hundreds of command line options, and in any real
production work, the defaults are absolutely worthless; you need
tens of options to get anything useful.

As for defaults in general: you really should carefully read the
documentation of the tools you are using, particularly critical
ones like the compiler, and decide explicitly which options are
relevant to your application. I've never found the defaults to
be appropriate, and it's usual that different applications need
a different set of options.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On May 30, 3:54 pm, Zeppe
<zep_p@.remove.all.this.long.comment.yahoo.itwrote :

James Kanze wrote:

will remove all the names of all the exported symbols, so there will be
no more readable information.

That's what I always thought, but a quick check (under Solaris)
shows that it just ain't true. The names are no longer visible
to nm (and the executable is noticeably smaller), but they still
show up using strings.

uhm... compiled without -g and with _NDEBUG?

Well, I didn't try _NDEBUG, but I did compile and then strip,
and all of the (mangled) names were present in the output of
"strings".

I suspect that this is possibly because at no point during the
build cycle or strip was it explicitly stated that dynamic
linking wouldn't be used, so all of the operations retained the
symbols, just in case.

I obtain quite clean code
under linux... maybe strip -s.

Hmm. I'd tried it under Solaris. Under Linux, strip does seem
to eliminate most of them.

BTW: does _NDEBUG have anything to do with NDEBUG? If it
suppresses assertions, then it can't very well be used in
production code, can it?

they are not, provided you tell the compiler that you don't need him to
preserve the function names. (well, not sure if you can delete also the
names of the function linked dynamically on shared libraries, though...
probably not).

Obvoiusly not, I'd say. Also, you can't delete the names of
types, at least not if type_info::name() is still going to work.

same with assertions... anyway, for the dynamic linking, just my
ignorance on the topic (I don't really know about how it works the name
resolution on a shared library, there will be some version information,
as well as the exported symbols..)

Under Unix, all global symbols will be implicitly exported. (I'm
not too familiar with the GNU ld, but Sun's ld has options to
specify exactly what should and should not be exported.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Gennaro Prota]

On 31 May 2007 02:03:51 -0700, James Kanze wrote:

[in Visual Studio]
BTW: does _NDEBUG have anything to do with NDEBUG?

It's _DEBUG, not _NDEBUG. In the two default configurations that the
wizards generate, the "debug" one has _DEBUG defined, the "release"
one has NDEBUG; so, yes, it isn't usable in production as I said in my
other post, except that it is, more often than not :-( (As I also said
in my other post the name "NDEBUG" is a tad misleading, but a
professional programmer is supposed to understand things a little
beyond the level of lexical suggestion)

--
Gennaro Prota -- C++ Developer, For Hire
https://sourceforge.net/projects/breeze/
(replace 'address' with 'name.surname' to mail)

[Gennaro Prota]

On 31 May 2007 02:03:51 -0700, James Kanze wrote:

[in VC++]
BTW: does _NDEBUG have anything to do with NDEBUG? If it
suppresses assertions, then it can't very well be used in
production code, can it?

<OT>
I forgot to add an important piece of information. The macro _DEBUG is
actually *implicitly defined* every time you use the /MTd or /MDd
options and says that a debug version of the CRT is used. That, of
course, also from the command line; the command line which results
from the wizard debug configuration has both /D "_DEBUG" and one of
the two options above (that's from personal observation, from VC6 to
VC8 --probably that's not documented and of course it's nothing to
count on without inspecting it personally).
</OT>

--
Gennaro Prota -- C++ Developer, For Hire
https://sourceforge.net/projects/breeze/
(replace 'address' with 'name.surname' to mail)

[Zeppe]

James Kanze wrote:

BTW: does _NDEBUG have anything to do with NDEBUG? If it
suppresses assertions, then it can't very well be used in
production code, can it?

sure, it was a typo for NDEBUG, sorry (actual mix between _DEBUG and
NDEBUG :)

But I can't understand your sentence. Why should the assertions be
retained in the production code? It's a kind of debug stuff for me.. of
course I was referring actually to that, if you enables assertions (and,
for some other compiler, _DEBUG actually activates other types of
controls inside of the library) it's likely that some names and code
lines are stored in order to print something useful when an assertion is
thrown.

>same with assertions... anyway, for the dynamic linking, just my
ignorance on the topic (I don't really know about how it works the name
resolution on a shared library, there will be some version information,
as well as the exported symbols..)

Under Unix, all global symbols will be implicitly exported. (I'm
not too familiar with the GNU ld, but Sun's ld has options to
specify exactly what should and should not be exported.)

Ah ok, thanks for the explanation ;)

Regards,

Zeppe

[Ian Collins]

Zeppe wrote:

James Kanze wrote:

>BTW: does _NDEBUG have anything to do with NDEBUG? If it
suppresses assertions, then it can't very well be used in
production code, can it?

sure, it was a typo for NDEBUG, sorry (actual mix between _DEBUG and
NDEBUG :)

But I can't understand your sentence. Why should the assertions be
retained in the production code? It's a kind of debug stuff for me.. of
course I was referring actually to that, if you enables assertions (and,
for some other compiler, _DEBUG actually activates other types of
controls inside of the library) it's likely that some names and code
lines are stored in order to print something useful when an assertion is
thrown.

Most application I have used retain assertions. There will always be
"can't happen" situations in the code where an assert is the only safe
option. If nothing else, they give an error message for users to report
when one fires.

Without the original source, file and line number isn't any use to
someone reverse engineering the code.

--
Ian Collins.

[Gennaro Prota]

On Thu, 31 May 2007 11:16:44 +0100, Zeppe wrote:

>sure, it was a typo for NDEBUG, sorry (actual mix between _DEBUG and
NDEBUG :)

But I can't understand your sentence. Why should the assertions be
retained in the production code?

Uh? Did you mean "released" code? Why should they be removed?

--
Gennaro Prota -- C++ Developer, For Hire
https://sourceforge.net/projects/breeze/
(replace 'address' with 'name.surname' to mail)

[JohnQ]

"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@q75g2000hsh.googlegr oups.com...

"The real question, of course, is why you'd want to obfuscate to
begin with."

To protect intellectual property: trade secrets, patents, copyrights...

John

[JohnQ]

"Zeppe" <zep_p@.remove.all.this.long.comment.yahoo.itwro te in message
news:f3**********@aioe.org...

JohnQ wrote:

>"Ian Collins" <ia******@hotmail.comwrote in message
news:5c**************@mid.individual.net...

>>JohnQ wrote:
"Zeppe" <zep_p@.remove.all.this.long.comment.yahoo.itwro te in message
news:f3**********@aioe.org...
GK wrote:
>Hello,
>>
>Can anybody suggest a best code obfuscation tool based on their
>exeperience
>? (e.g.: testing effort after obfuscation is 0)
>>
My compiler obfuscates the c++ code quite well.
I'll bet you haven't looked at your executables with an editor lately
if
you
think that. If you leave it the way the compiler leaves it, you'll
probably
be able to generate class and function diagrams from the human-readable
text
in the code.

Only if you leave debugging information in the executable. Otherwise
optimised code is all but impossible to reverse engineer.

You could be right! Thank you, I'll investigate that (or someone will
follow-up post?). But if it's optimization that was your primary thought:
I
don't use any optimization compiler settings (I don't need to, and who
does
these days?).

there are reasonable motivations to use optimizations (and to remove debug
symbols) in the release versions of the programs:
1) why have a slow program when it can be faster?
2) why have a big program when it can be smaller?

If it's adequate, why take the risk of multi-threaded code not working
right?

John

[James Kanze]

On Jun 1, 10:16 pm, "JohnQ" <[e-mail]>
wrote:

"James Kanze" <[e-mail] in message

news:11**********************@q75g2000hsh.googlegr oups.com...

"The real question, of course, is why you'd want to obfuscate to
begin with."

To protect intellectual property: trade secrets, patents, copyrights...

And what does obfuscation change with respect to that? The
copyright is there, whether the code is obfuscated or not. It's
software, so it's not patentable in the civilized world. And
obfuscation doesn't affect the trade secret status either.

About the only real reason I know for obfuscation is that you're
ashamed of the quality, and don't want the customer to be able
to see how bad it is.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[BobR]

James Kanze <ja*********@gmail.comwrote in message ...
/* """
On Jun 1, 10:16 pm, "JohnQ" <[e-mail]>
wrote:

"James Kanze" <[e-mail] in message...

"The real question, of course, is why you'd want to obfuscate to
begin with."
To protect intellectual property: trade secrets, patents, copyrights...

And what does obfuscation change with respect to that? The
copyright is there, whether the code is obfuscated or not. It's
software, so it's not patentable in the civilized world. And
obfuscation doesn't affect the trade secret status either.

About the only real reason I know for obfuscation is that you're
ashamed of the quality, and don't want the customer to be able
to see how bad it is.
"""*/

OP (if your code's that bad):
Do the "Cheshire cat" boogie!!

"Cheshire cat" == handle classes.
--
Bob R
POVrookie

[JohnQ]

"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@o5g2000hsb.googlegro ups.com...
On Jun 1, 10:16 pm, "JohnQ" <[e-mail]>
wrote:

"James Kanze" <[e-mail] in message

news:11**********************@q75g2000hsh.googlegr oups.com...

"The real question, of course, is why you'd want to obfuscate to
begin with."

To protect intellectual property: trade secrets, patents, copyrights...

"And what does obfuscation change with respect to that?"

It makes is harder to reverse-engineer and disuades the casual
infringer.

"The copyright is there, whether the code is obfuscated or not. It's
software, so it's not patentable in the civilized world."

You mean all that hullaballoo in all the US courts about software
patents is moot?

"And obfuscation doesn't affect the trade secret status either."

I disagree. One must take reasonable measures to conceal trade
secrets to be recognized as such.

"About the only real reason I know for obfuscation is that you're
ashamed of the quality, and don't want the customer to be able
to see how bad it is."

Now you're describing _open_ source! ;)

John

[James Kanze]

On Jun 5, 7:25 pm, "JohnQ" <[e-mail]>
wrote:

"James Kanze" <[e-mail] in message

news:11**********************@o5g2000hsb.googlegro ups.com...
On Jun 1, 10:16 pm, "JohnQ" <[e-mail]>
wrote:

"James Kanze" <[e-mail] in message
news:11**********************@q75g2000hsh.googlegr oups.com...
"The real question, of course, is why you'd want to obfuscate to
begin with."
To protect intellectual property: trade secrets, patents, copyrights...

"And what does obfuscation change with respect to that?"

It makes is harder to reverse-engineer and disuades the casual
infringer.

You don't casually "reverse-engineer" software, even if you have
the sources. Look at all the open-source stuff floating around;
unless you're really working with it, you can't do anything with
sources.

"The copyright is there, whether the code is obfuscated or not. It's
software, so it's not patentable in the civilized world."

You mean all that hullaballoo in all the US courts about software
patents is moot?

I said the civilized world. Where international law is
recognized and respected. Software is not patentable under
international law.

"And obfuscation doesn't affect the trade secret status either."

I disagree. One must take reasonable measures to conceal trade
secrets to be recognized as such.

Like having the user sign a non-disclosure agreement. Once
you've delivered software to a customer who hasn't signed such
an agreement, trade secrets are out.

"About the only real reason I know for obfuscation is that you're
ashamed of the quality, and don't want the customer to be able
to see how bad it is."

Now you're describing _open_ source! ;)

Not really. Almost the opposite, in fact: all you can do with
the sources, really, is judge the quality of the software.
Having access to the sources doesn't really buy you much more,
despite all the claims of the open source movement.

I use a number of open source products: g++, vim, etc. I'm
totally incapable of modifying any of them, or even stealing
ideas from them. If, on the other hand, my goal was to steal
the ideas, and I was willing to invest the effort, the lack of
sources wouldn't really hinder me very much. And if I wanted to
modify g++ or vim, I'd start by contacting people already
working on them, to get the additional internal documentation
that they certainly have---things like a description of the
internal data structures and such.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[JohnQ]

"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@w5g2000hsg.googlegro ups.com...
On Jun 5, 7:25 pm, "JohnQ" <[e-mail]>
wrote:

"James Kanze" <[e-mail] in message

news:11**********************@o5g2000hsb.googlegro ups.com...
On Jun 1, 10:16 pm, "JohnQ" <[e-mail]>
wrote:

"James Kanze" <[e-mail] in message
news:11**********************@q75g2000hsh.googlegr oups.com...
"The real question, of course, is why you'd want to obfuscate to
begin with."
To protect intellectual property: trade secrets, patents, copyrights...

"And what does obfuscation change with respect to that?"

It makes is harder to reverse-engineer and disuades the casual
infringer.

"You don't casually "reverse-engineer" software, even if you have
the sources. Look at all the open-source stuff floating around;
unless you're really working with it, you can't do anything with
sources."

Now you're trying to get me started on the unapproachability of open
source (!). My point: class hierarchies and function declarations and
such can be enough to rob someone of their R&D efforts. If that is
readily available by examining the executable in a text editor, it makes
it too easy for someone to steal the concept/trade-secret or whatever.

"The copyright is there, whether the code is obfuscated or not. It's
software, so it's not patentable in the civilized world."

You mean all that hullaballoo in all the US courts about software
patents is moot?

"I said the civilized world. Where international law is
recognized and respected. Software is not patentable under
international law."

That's what I thought you meant. But that doesn't solve the problem of
someone taking from you something you don't want to give them.

"And obfuscation doesn't affect the trade secret status either."

I disagree. One must take reasonable measures to conceal trade
secrets to be recognized as such.

"Like having the user sign a non-disclosure agreement. Once
you've delivered software to a customer who hasn't signed such
an agreement, trade secrets are out."

But if the executables don't contain the information to begin with,
the NDA is not necessary. The thread is about obfuscation beyond
what the compiled code gives in order to keep things a secret.

"About the only real reason I know for obfuscation is that you're
ashamed of the quality, and don't want the customer to be able
to see how bad it is."

Now you're describing _open_ source! ;)

"Not really."

IMO, open source is of low quality in general.

"Almost the opposite, in fact: all you can do with
the sources, really, is judge the quality of the software.
Having access to the sources doesn't really buy you much more,
despite all the claims of the open source movement.

I use a number of open source products: g++, vim, etc. I'm
totally incapable of modifying any of them, or even stealing
ideas from them."

Well if you replace 'stealing' with 'using', then you'd have my
point that open source is of low quality.

"If, on the other hand, my goal was to steal
the ideas, and I was willing to invest the effort, the lack of
sources wouldn't really hinder me very much."

My point is: why make it easy to steal in the first place?
Obfuscation can make the concepts hidden from entire classes
of would-be <whatever you wanna call thems>.

"And if I wanted to
modify g++ or vim, I'd start by contacting people already
working on them, to get the additional internal documentation
that they certainly have---things like a description of the
internal data structures and such."

There's a lot more software than the large and complex
examples though and you're focusing just on them. Also, you
are assuming "the whole program" whereas I am concerned
also about the underlying abstractions that the program is
built up: class libraries etc.

Anyway, point made (?). I'm not sure what can be gleaned from
non-debug executables with the vendor supplied developer
utilities (in my case VC++), but I'll certainly be checking that
before I release any product (beta or otherwise).

John