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]

Re: obfuscation

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]

Re: obfuscation

On May 29, 8:45 am, "GK" <ganesh.kam...@ in.bosch.comwro te:
[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]

Re: obfuscation


"Zeppe" <zep_p@.remove. all.this.long.c omment.yahoo.it wrote in message
news:f3he3c$d6t $1@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]

Re: obfuscation


"Puppet_Soc k" <puppet_sock@ho tmail.comwrote in message
news:1180456852 .911280.176320@ o5g2000hsb.goog legroups.com...

On May 29, 8:45 am, "GK" <ganesh.kam...@ in.bosch.comwro te:
[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]

Re: obfuscation

JohnQ wrote:

"Zeppe" <zep_p@.remove. all.this.long.c omment.yahoo.it wrote in message
news:f3he3c$d6t $1@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]

Re: obfuscation


"Ian Collins" <ian-news@hotmail.co mwrote in message
news:5c4c19F2ss n56U50@mid.indi vidual.net...

JohnQ wrote:

>"Zeppe" <zep_p@.remove. all.this.long.c omment.yahoo.it wrote in message
>news:f3he3c$d6 t$1@aioe.org...

>>GK wrote:
>>>Hello,
>>>>
>>>Can anybody suggest a best code obfuscation tool based on their
>>>exeperienc e
>>>? (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]

Re: obfuscation

On May 30, 12:57 pm, "JohnQ" <johnqREMOVETHI Sprogram...@yah oo.com>
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]

Re: obfuscation

JohnQ wrote:

"Ian Collins" <ian-news@hotmail.co mwrote in message
news:5c4c19F2ss n56U50@mid.indi vidual.net...

>JohnQ wrote:

>>"Zeppe" <zep_p@.remove. all.this.long.c omment.yahoo.it wrote in message
>>news:f3he3c$d 6t$1@aioe.org.. .
>>>GK wrote:
>>>>Hello,
>>>>>
>>>>Can anybody suggest a best code obfuscation tool based on their
>>>>exeperien ce
>>>>? (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]

Re: obfuscation

JohnQ wrote:

"Ian Collins" <ian-news@hotmail.co mwrote in message
news:5c4c19F2ss n56U50@mid.indi vidual.net...

>JohnQ wrote:

>>"Zeppe" <zep_p@.remove. all.this.long.c omment.yahoo.it wrote in message
>>news:f3he3c$d 6t$1@aioe.org.. .
>>>GK wrote:
>>>>Hello,
>>>>>
>>>>Can anybody suggest a best code obfuscation tool based on their
>>>>exeperien ce
>>>>? (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]

Re: obfuscation


"JohnQ" <johnqREMOVETHI Sprogrammer@yah oo.comwrote in message
news:WG67i.4530 $u56.2540@newss vr22.news.prodi gy.net...

>
"Puppet_Soc k" <puppet_sock@ho tmail.comwrote in message
news:1180456852 .911280.176320@ o5g2000hsb.goog legroups.com...

On May 29, 8:45 am, "GK" <ganesh.kam...@ in.bosch.comwro te:
[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]

Re: obfuscation

GK wrote:

"JohnQ" <johnqREMOVETHI Sprogrammer@yah oo.comwrote in message
news:WG67i.4530 $u56.2540@newss vr22.news.prodi gy.net...

>"Puppet_Sock " <puppet_sock@ho tmail.comwrote in message
>news:118045685 2.911280.176320 @o5g2000hsb.goo glegroups.com.. .

>>On May 29, 8:45 am, "GK" <ganesh.kam...@ in.bosch.comwro te:
>>[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]

Re: obfuscation


"Ian Collins" <ian-news@hotmail.co mwrote in message news:5c53vqFmsd ipU8@mid.indivi dual.net...

GK wrote:

>"JohnQ" <johnqREMOVETHI Sprogrammer@yah oo.comwrote in message
>news:WG67i.453 0$u56.2540@news svr22.news.prod igy.net...

>>"Puppet_Soc k" <puppet_sock@ho tmail.comwrote in message
>>news:11804568 52.911280.17632 0@o5g2000hsb.go oglegroups.com. ..
>>>On May 29, 8:45 am, "GK" <ganesh.kam...@ in.bosch.comwro te:
>>>[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]

Re: obfuscation

On May 30, 6:57 am, "JohnQ" <johnqREMOVETHI Sprogram...@yah oo.com>
wrote:

"Ian Collins" <ian-n...@hotmail.co mwrote in message
news:5c4c19F2ss n56U50@mid.indi vidual.net...

JohnQ wrote:

"Zeppe" <zep_p@.remove. all.this.long.c omment.yahoo.it wrote in message
>news:f3he3c$d6 t$1@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:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[James Kanze]

Re: obfuscation

On May 30, 7:45 am, Martin Rennix <martin.ren...@ gmail.comwrote:

On May 30, 12:57 pm, "JohnQ" <johnqREMOVETHI Sprogram...@yah oo.com>
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:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34