Re: obfuscation
On May 30, 6:57 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Ian Collins" <ian-n...@hotmail.com> wrote in message
news:5c4c19F2ssn56U50@mid.individual.net...
JohnQ wrote:
"Zeppe" <zep_p@.remove.all.this.long.comment.yahoo.it> wrote in message
news:f3he3c$d6t$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.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34