Re: Encrypting the Source Kode



osmium wrote:

The word "decompile" is commonly misused, something said even by people
who speak carefully. There is no such thing as a decompiler (which would
produce the original source code). The word is used (falsely) to talk
about a program that produces one possible *assembly* listing for the
program..

Personally, I have never heard (or seen) anyone confusing decompilation with
disassembly.

Decompilers (as I understand the term) /do/ exist, and can work quite well.
The difference between what I mean by decompiler and what you state, is that I
understand the term to cover any program which attempts to produce source in
the original language which, if recompiled, would produce essentially the same
program as we started with.

There is no assumption that it's the /same/ source -- it's almost certain to
have different layout, and none of the original comments, even in the most
auspicious circumstances. It'll only [re-]generate the original identifiers if
those are included in the compiled output (debugging information, say). It's
not guaranteed to "guess" right if more than one source-language construction
can compile to the same output. And so on. But it is, for some
languages/target systems, quite possible to [re-]generate clear, idiomatic,
readable source.

The requirement for this to be possible is that the mapping the compiler
performs be quite simple. That is the case for Java for instance (when Java is
compiled to JVM bytecode -- by far the typical case). I believe that it's also
the case for MS's C# -> CLI compiler(s).

The "Jad" decompiler for Java can often do an excellent job of generating
usable source from classfiles. I assume there are equivalents for .NET.

Which, in turn, is why obfuscators exist. I suspect that that might have been
the concept the OP was looking for. Something which will take the
easily-decompiled output of a Java or .NET compiler, and scramble it (while
keeping the meaning intact) so as to confound any attempt to decompile. Such
programs do exist, do work (sort of), and can be useful to prevent /casual/
reverse-engineering of a delivered application or library.

-- chris


.



Relevant Pages

  • Re: How easy is it to reverse engineer a java program?
    ... Thanks for the links to decompiler sources. ... if one decompiles a Java class ... bat you're nixed by the compiler because the decompiled ... no-no's in the decompiled code. ...
    (comp.lang.java.programmer)
  • Re: Disassembler
    ... You seem to insist on ignoring the fact that this technology guarantees to create COBOL code that will produce exactly the same output as the object code. ... the compiler will generate the same code. ... assume your process is always to trash every source program as soon as you compile it. ... So, while your generalizations about decompilers may be true IN GENERAL, this technology is far more than just a 'decompiler' it is 'source recovery' technology. ...
    (comp.lang.cobol)
  • Re: Fortran Question
    ... Fortran accented dialect it will be "Greek" to the decompiler. ... decompiler is likely to be rather sensitive to compiler vendor and ... code interpreter written in the target language. ...
    (comp.lang.fortran)
  • Re: what is the best obfuscator to buy
    ... > The obfuscated code produced by our decompiler is recompiled so incorrectly ... > generated code would have been seen by the compiler, ... or which subtly affects the threading so that a ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Getting source file from the object file
    ... solving the halting problem. ... is the output of a particular compiler whose output is a deterministic ... merely that the writer of the decompiler has access to the compiler ... The decompiler as described will not turn any object code back into C; ...
    (comp.lang.c)