obfuscation

[James Kanze]

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?

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.)

 

[Gennaro Prota]

[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]

[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>

 

[Zeppe]

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.

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]

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.

 

[Gennaro Prota]

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?

 

[JohnQ]

"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]

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]

"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.

 

[BobR]

/* """

"James Kanze" <[email protected]> wrote 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.

 

[JohnQ]

"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]

"James Kanze" <[email protected]> wrote in message

On Jun 1, 10:16 pm, "JohnQ" <[email protected]>
wrote:

"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.

 

[JohnQ]

"James Kanze" <[email protected]> wrote in message

On Jun 1, 10:16 pm, "JohnQ" <[email protected]>
wrote:

"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