deriving code from exe files..
Results 1 to 7 of 7

Thread: deriving code from exe files..

  1. #1
    Junior Member
    Join Date
    Sep 2005
    Posts
    10

    deriving code from exe files..

    hi..i thought this 1 was related to programming,so i m posting it here..
    after we compile a c++ program an executable is created..suppose we delete the code files so that all is left of the program is its executable so that we can run the program but cannot see its actual code..is there sum way of deriving the actual code just from the executable..

  2. #2
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,403
    Yes, there is.. You can use a disassembler.. Most C/C++ compilers generate "predictable" assembly..
    Based on this there are also some programs that can produce readable C/C++ source code from an executable..
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  3. #3
    Banned
    Join Date
    Jul 2005
    Posts
    511
    . o O (Agrees with SirDice)
    One problem though with disassemblers, though. While they might recreate part of your sourcecode again, they won't be able to reproduce any of the variable names that you've used when writing the code. And they might not be able to convert to C code completely, if they are even capable of recognising C-code pattern in the binaries. You're more likely to end up with some assembler code instead.
    One other problem that you'll encounter when decompiling C++ code is that the language makes a lot of use of classes. The disassembler might be able to reconstruct some information about these classes but not everything.

    Decompiling an application is easier if the executable was compiled with some additional debug information. In general, most production software should be compiled without debug information just to make it more difficult for hackers to crack the code. But sometimes you'll find programs that still have some debug information still left inside.

    It's easier to not just lose the code of your projects, btw. Decompiling WIN32 or Linux/Unix executables tend to be time-consuming.

    It's a bit different when you're working with Java or .NET binaries. These are actually more binaries containing some pseudocode for a virtual machine. (Well, Microsoft won't call it that but the principle is similar.) When a Java or .NET binary gets executed, the system will first compile the binary to more platform-specific machinecode. Thus the binaries are portable on multiple platforms. But it also means that these binaries are a bit easier to decompile. If I understood correctly, with Java binaries you can even retrieve the full Java code, except for the variable names that is. With .NET applications, it's just a matter of time before there's a decompiler that is able to recognise if it's written in VB.NET, C# or managed C++ and thus decompile with the proper pattern set.

  4. #4
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,403
    You might be interested in Hacker Disassembling uncovered by Kris Kaspersky. The book talks a lot about recognising assembly instructions and deducting it's C/C++ source from that. It also gives hint and tips on how to "hide" stuff or at least make it hard to get certain information from an executable (like passwords and such)..

    NB Storing passwords in an executable and thinking it'll be safe is silly..
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  5. #5
    Banned
    Join Date
    Jul 2005
    Posts
    511
    Hmmm. Passwords in executables? Not a good idea indeed. However, if you know a good hashing algorithm, you could calculate a hash value over the password and store this hash value in the executable instead. While a hacker might still get this value from the executable, he will still have to find the proper password that -after hashing- matches this hash value.

    Then again, hackers will just modify the code to bypass the whole password checking instead. Again, any security measure that you take to protect your code can be bypassed and probably will be bypassed if it's interesting enough for hackers to do so. All it takes them is some time to crack your code.

    Keep in mind that an application doesn't have to be written in C++. There are several other options instead. For example, Delphi, Visual Basic, Fortran to name a few alternative languages. But if you're trying to decompile your own code then you have an advantage since you know which compiler was used.

    If you're trying to make decompiling your code a bit more difficult... Well, there are several ways to do so. Tip 1: Don't include debug information in your application.
    There are tools like AsPack and AsProtect that will encrypt the executable and thus make it a bit harder to disassemble. Of course there are also tools that can undo these encryption tools again so it's not failsafe.

    Still, it does take some skills to disassemble from binary to full sourcecode. And some knowledge of assembly code.

  6. #6
    Junior Member
    Join Date
    Oct 2005
    Posts
    15
    Well... The exe created after compiling and linking a c++ code would ofcourse not be containing any variable names but it contains the references to the memory locations allocated for variables of the original source code....

    I have been using ollydbg for decompiling most of the windows applications... All the inner working of the code can be viewed at the machine level using this code... Generally such programs are used to crack or byepass the passwords...

    But the exe code which is generated after compiling any c++ source is either 8086 compatible or 80286 compatible (if I m recalling it properly). Some tools do exit for decompiling this also... You may try this for decompiling the DOS exe created after compiling a c code using TurboC compiler. This seems to be the tool that u are looking for...

  7. #7
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    Hi

    tomalex, the art to reconstruct a "source-code" from a binary is in a more
    general context called "reverse engineering"[1]. There is an online book
    under development[2], which I can recommend. For a few more tools,
    more references and an example see a tutorial here on AO[3]

    A while ago, we had a discussion whether the difficulty to reverse engineer
    a binary depends on the language it was written in - or not[4]. You
    might find there some additional thoughts, to the nice ones presented here,
    as well.


    Cheers


    [1] http://en.wikipedia.org/wiki/Reverse_engineer
    [2] http://www.acm.uiuc.edu/sigmil/RevEng/
    [3] http://www.antionline.com/showthread...hreadid=262954
    [4] http://www.antionline.com/showthread...hreadid=265616
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •