decompiling: is it possible?

Started by
17 comments, last by goodfella412 21 years, 5 months ago
if i have an executable, is it possible to ''decompile'' it so i end up with the source code? if it is possible how do i do it? can it be done with msvs6.0?? any help is greatly appreciated.
Advertisement
quote:Original post by goodfella412
if i have an executable, is it possible to ''decompile'' it so i end up with the source code? if it is possible how do i do it? can it be done with msvs6.0?? any help is greatly appreciated.


You won''t get back the original high level source code. Decompilers will go from executable to assembly.

Patrick
there are apps out there that will create C++ source from an executable (first asm, then C++), but all the symbol names will by garbage made up by the decompiler. If you were really clever you could turn it into something usable, but it''d probably be easier coding from scratch
there are apps out there that will create C++ source from an executable (first asm, then C++), but all the symbol names will by garbage made up by the decompiler. If you were really clever you could turn it into something usable, but it'd probably be easier coding from scratch


that was me up there, oops... (as if you couldn't tell)

[edited by - grizwald on November 5, 2002 9:38:53 PM]
I love me and you love you.
It depends on what language the executable was written in. And what compiler was used. And what compiler settings were used when the executable was built. And the version number of the compiler. Other than that, decompiling is easy .

AFAIK, Java is able to be decompiled pretty easily, due to the fact that is basically an interpreted language. C++, on the other hand, is almost impossible. Even if you manage to decompile the .exe into C++, none of the function/variable/type names will make any sense, as that stuff is not stored in the executable.

-Mike
Unless you are decompiling something like Java you won''t get back the original source, however I have used/reviewed several advanced decompilers that can do a pretty good job at reverse engineering code into a mostly C format (it inserts the original assembly at the places it doesn''t understand, and uses numeric variable names and address). Of course even this type of intelligent decompiler is still not very good at decoding OO programs, as the number of pointers used is much higher.

This post qualifies for 100 per cent Canadian Content under the rulings of the Canadian Internet Commission and the Federal Ministry of Communication. There are four Americans who worked on this post, but they all have landed immigrant status, and have signed CRTC affidavits swearing that they drink beer, eat back bacon, drive snowmobiles and wear toques. Any resemblance between the Content of this post and the content of any American post is purely coincidental and not the intention of the poster or the various Internet Agencies of the Canadian Government who have screened these posts prior to bulk erasing in accordance with the policies of the Federal Internet Identity Board.
quote:Original post by prh99
Decompilers will go from executable to assembly.

That would be "disassemblers." MSVC has one (usually seen in action as the disassembly view in the IDE).
Although I''ve never had any use for a decompiler, this thread left me wondering... Are there any decompilers out there that make use of the debug info stored in MSVC debug executables, or the RTTI information (which could at least be used to restore the names of all the types, IMHO)? Or is such a thing completely impossible?

Kippesoep
quote:Original post by Michalson
Unless you are decompiling something like Java you won''t get back the original source

You won''t get back the original source from Java bytecode either - there''s no direct mapping. You have more "metainformation" than you do in a C++ binary, but not enough to get the original source.
quote:Original post by Kippesoep
or the RTTI information (which could at least be used to restore the names of all the types, IMHO)?

There''s no guarantee that RTTI provides the names of types as they are given in the source code.
Actually, there is. How else would typeid (...).name () be getting the name? It won''t take into account typedefs or macros, obviously, but that''s hardly relevant.
I''m not sure how RTT information is stored on a binary level, but it would make sense if even an entire inheritance diagram can be reconstructed from it (given the way dynamic_cast works).

Kippesoep

This topic is closed to new replies.

Advertisement