Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
decompiling .exe files in turbo pascal
- Thread starter Gaz26546
- Start date
lionelhill
Technical User
Sorry, not currently possible. The reason is that so much information in your original pascal files is not necessary for the exe file and is therefore usually removed. For instance, the processor doesn't care at all what you called your variables, so their names are all (generally) missed out.
Borland actually state that the .tpu format is handy because you can sell your libraries of useful procedures in .tpu format and no one can nick the source code.
OK, in theory someone could write a decompiler, but it'd be a hideously difficult job, and I doubt the results would be terribly nice code. And it'd be harder to do than rewriting the original program.
You have my sympathy. I've lost code too.
Borland actually state that the .tpu format is handy because you can sell your libraries of useful procedures in .tpu format and no one can nick the source code.
OK, in theory someone could write a decompiler, but it'd be a hideously difficult job, and I doubt the results would be terribly nice code. And it'd be harder to do than rewriting the original program.
You have my sympathy. I've lost code too.
PROFESSORSPARKIE
Instructor
There have been many decompilers written over the years, usually to generate source code for purchased programs that need updating but the original company is out of business.
There are also certain legal issues if you use it to decompile copyrighted code.
When IBM/MS/DOS first came out, many tried to decompile DOS to find special coding techniques and to better learn assembler.
As noted by one of the other responders the program must make a lot of assumptions and at best gives you some of the code with dynamic created variable names and instruction labels for branch/jumps.
A really good technique was to trace the program one instruction at a time to establish the sections of the program that are instruction & those that are data.(example: data printed, added, etc areas).
Because of the issues and limited success I have not seen a good decompiler for some time.
There are also certain legal issues if you use it to decompile copyrighted code.
When IBM/MS/DOS first came out, many tried to decompile DOS to find special coding techniques and to better learn assembler.
As noted by one of the other responders the program must make a lot of assumptions and at best gives you some of the code with dynamic created variable names and instruction labels for branch/jumps.
A really good technique was to trace the program one instruction at a time to establish the sections of the program that are instruction & those that are data.(example: data printed, added, etc areas).
Because of the issues and limited success I have not seen a good decompiler for some time.
Fangface816
Programmer
I have a program suite (I suppose, not sure what else to call it. Bundle, maybe?) which i obtained a while ago, called Hackman, with other assorted tools. One of the programs was labeled "Disassembler". I'm a few steps up from "noob", and consequently don't hack, so I wouldn't know. But would this Disassembler utilize the same concept of a decompiler, or do I have the wrong idea?
Cheers,
Fangface
Cheers,
Fangface
A disassembler literally translates a binary file to mnemonics. These mnemonics are only a *readable* version of the machine code and makes is easier for programmers to write code (e.g. "MOV AX,BX" is easier to remember than 89D8h).
A decompiler (if one existed) would go one step further and produce (preferrably readable) source code. The problem, however, is that such a decompiler would have to recognize opcode combinations that belong to the same high level language instruction, addresses should be converted to variables, procedures and functions, parameter passing constructs should be appropriately translated, ... The problem gets increasingly difficult when an optimizing compiler was originally used to produce the machine code and when dynamically bound elements are present (e.g. virtual methods in object oriented programming languages), not to mention some hand-written inline assembly code or included object code that was generated using different languages ...
The net result is that a decompiler should be able to know what a program does, without executing it (it might get stuck in an eternal loop, or wait for input the decompiler cannot provide). Here we enter the field of computability since this problem is related to the so called "halting problem": does a program exist that can decide wether a given program halts or loops? It has been proven that such a program does not exist.
Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
A decompiler (if one existed) would go one step further and produce (preferrably readable) source code. The problem, however, is that such a decompiler would have to recognize opcode combinations that belong to the same high level language instruction, addresses should be converted to variables, procedures and functions, parameter passing constructs should be appropriately translated, ... The problem gets increasingly difficult when an optimizing compiler was originally used to produce the machine code and when dynamically bound elements are present (e.g. virtual methods in object oriented programming languages), not to mention some hand-written inline assembly code or included object code that was generated using different languages ...
The net result is that a decompiler should be able to know what a program does, without executing it (it might get stuck in an eternal loop, or wait for input the decompiler cannot provide). Here we enter the field of computability since this problem is related to the so called "halting problem": does a program exist that can decide wether a given program halts or loops? It has been proven that such a program does not exist.
Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
Fangface816
Programmer
Okay I get it. Thanks for clearing that up.
So theoretically, if you had a preset record of possible variable names for the decompiler to use, and focused the effort on one particular language (C++, for example, would be my choice, as it's very flexible), as well as initially assuming one way or another on the subject of halt or loop, then it would be quite possible to create at least readable source code.
I suppose if the objective was mere functionality, it would be achievable, albeit with a lot of work. Infallible accuracy and reliability is another matter.
This is a very interesting subject. I suppose a lot of people have attempted a decompiler.
Cheers,
Fangface
So theoretically, if you had a preset record of possible variable names for the decompiler to use, and focused the effort on one particular language (C++, for example, would be my choice, as it's very flexible), as well as initially assuming one way or another on the subject of halt or loop, then it would be quite possible to create at least readable source code.
I suppose if the objective was mere functionality, it would be achievable, albeit with a lot of work. Infallible accuracy and reliability is another matter.
This is a very interesting subject. I suppose a lot of people have attempted a decompiler.
Cheers,
Fangface
lionelhill
Technical User
I'm not sure I agree that a hypothetical decompiler needs to identify whether a program is going to get stuck in an infinite loop or not. People manage to write code that (sometimes) crashes without knowing that it's going to, or when! But I agree that decompiling, unlike compiling, is more to do with psychology and guesswork than an exact translation. Decompiling could involve guessing the function of the code in the sense that you'd like to know something is a loop-counting variable before you give it a name like "OuterLoopCount". How you go about guessing what variable keeps the score (and calling it "score"
in a space invaders game I don't know.
in a space invaders game I don't know. I said that a decompiler should be able to know what a program does to produce accurate code. A program that can decide what another program does, just by looking at it, is closely related to the halting problem. And even when the program to decompile is executed to see what it does, it's not guaranteed any usable result will be produced, because the decompiler cannot know what input it expects.
Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
Fangface816
Programmer
So the halting issue you mentioned would NOT be need to be addressed in order to have a successful decompiler. This whole subject has gotten me very interested. What language do you think a decompiler would best be written in? (Not that I'm going to try it, I was just wondering about opinions)
Cheers,
Fangface
Cheers,
Fangface
The halting problem is not a problem, it's the name for a theorem and its proof. I mentioned it because it is related to the problem of creating an accurate decompiler. The point I'm trying to make is that it is virtually impossible to produce a program that restores a binary file into its source code representation. This, however, is an opinion; true, one that is shared with quite a lot of traditional and conservative thinkers. Great leaps in science, on the other hand, have been achieved by people who didn't hold with classic thinking and went their own way.
I won't withhold you from trying to build your decompiler, all I say is that will not be easy.
Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
I won't withhold you from trying to build your decompiler, all I say is that will not be easy.
Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
- Status
Similar threads
- Locked
- Question
- Locked
- Question