On Monday, 17 December 2012 at 08:21:43 UTC, Walter Bright wrote:
On 12/16/2012 11:08 PM, Jonathan M Davis wrote:
The concept of .di files and their ilk is fundamentally broken
precisely
because they're trying to strip what's in the file. That's
what causes the
problems.
What is and what isn't in a .di is entirely under the user's
control.
Object files are resistant to reverse engineering because
most of the
information is gone.
True, but they can stll be reverse engineered,
I know what I'm talking about with this. The only time they get
reverse engineered is when somebody really really REALLY wants
to do it, an expert is necessary to do the job, and it's
completely impractical for larger sets of files. You cannot
build a tool to do it, it must be done by hand, line by line.
It's the proverbial turning of hamburger back into a cow.
A binary format of the source code, however, is EASY to turn
back into source code, and it's EASY to write a tool to do it
automatically, and complete idiots can successfully run that
tool and reverse engineer it by pushing a button.
You cannot even begin to compare the difficulty levels between
the two.
and if the problem is that
companies don't want 3rd parties looking at their code, then a
binary format
has obfuscated it and possibly solved that problem.
No, it has not obfuscated it at all.
Object files do make it
harder, but they can still be reverse engineered, so it really
becomes a
question of what it takes to satisfy the folks who think that
not giving the
whole information in a .d or .cpp file somehow protects their
code (since it
doesn't really). And if a binary format can do that (as it
seems to in Java
land), then that seems like a far better solution, because
then we can leave
all of the information in there that inlining and CTFE need in
order to do
their jobs. With .di files, we'll never get that.
Java developers tried to "obfuscate" their code by distributing
them as .class files, and someone promptly wrote a free tool to
turn .class files back into source code.
No such tool exists for object code, and never has. That should
be a pretty strong indication of its possibilities.
Really?!
http://www.hopperapp.com/
I really like the way it generates pseudo-code and basic block
graphs out of instruction sequences.
--
Paulo
