A1METALHEAD
Programmer
has anyone herd of a free c++ decompiler? that turns a exe int a cpp file? or a method to do that?
~metalhead
~metalhead
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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
c++ decompiler?
- Thread starter A1METALHEAD
- Start date
- Status
So do you have the source code or not?
The only reason for wanting a decompiler is because the source has been lost.
Perhaps your new programmer should be the one asking the questions here. Otherwise details are just going to get lost in translation.
--
The only reason for wanting a decompiler is because the source has been lost.
Perhaps your new programmer should be the one asking the questions here. Otherwise details are just going to get lost in translation.
--
What I have is the original disk. What I have is something that looks like this:
Uü‹BhP‹MQè™Í ‹UüƒÂlRhê ‹EPè–Í h @ Fh ?‹MüƒÁlQ‹URèvÍ _^[ƒÄD;ìèwÒ ‹å] ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒì@SVW}À¹ ¸ÌÌÌÌó«¡ }C _^[‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒìDSVWQ}¼¹ ¸ÌÌÌÌó«Y‰Mü¸ 0C _^[‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒì@SVW}À¹ ¸ÌÌÌÌó«¡,}C _^[‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒìDSVWQ}¼¹ ¸ÌÌÌÌó«Y‰Mü¸P1C _^[‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìjÿh™ B d¡ Pd‰% ƒìDSVWQ}°¹ ¸ÌÌÌÌó«Y‰Mðj ‹Mðè´Ì ÇEü ‹MðÁÈ è§Ô ‹EðÇ ,2C ‹ôh 2C ÿ¸‚C ƒÄ;ôèßÐ ‹ôh2C ÿ¸‚C ƒÄ;ôèÈÐ ‹ôh2C ÿ¸‚C ƒÄ;ôè±Ð ÇEüÿÿÿÿ‹Eð‹Môd‰
_^[ƒÄP;ìèÐ ‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒìDSVWQ}¼¹ ¸ÌÌÌÌó«Y‰Mü‹Müèêðÿÿ‹Eƒà…Àt ‹MüQèòÊ ‹Eü_^[ƒÄD;ìèÐ ‹å] ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìjÿh¹ B d¡ Pd‰% ƒìDSVWQ}°¹ ¸ÌÌÌÌó«Y‰MðÇEü ‹MðÁÈ è‘îÿÿÇEüÿÿÿÿ‹Mðè$Ë ‹Môd‰
_^[ƒÄP;ìèsÏ ‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒìDSVWQ}¼¹ ¸ÌÌÌÌó«Y‰Mü‹MüèÙÒ _^[ƒÄD;ìè Ï ‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒì@SVW}À¹ ¸ÌÌÌÌó«è# è^ _^[ƒÄ@;ìèÑÎ ‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒì@SVW
Uü‹BhP‹MQè™Í ‹UüƒÂlRhê ‹EPè–Í h @ Fh ?‹MüƒÁlQ‹URèvÍ _^[ƒÄD;ìèwÒ ‹å] ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒì@SVW}À¹ ¸ÌÌÌÌó«¡ }C _^[‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒìDSVWQ}¼¹ ¸ÌÌÌÌó«Y‰Mü¸ 0C _^[‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒì@SVW}À¹ ¸ÌÌÌÌó«¡,}C _^[‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒìDSVWQ}¼¹ ¸ÌÌÌÌó«Y‰Mü¸P1C _^[‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìjÿh™ B d¡ Pd‰% ƒìDSVWQ}°¹ ¸ÌÌÌÌó«Y‰Mðj ‹Mðè´Ì ÇEü ‹MðÁÈ è§Ô ‹EðÇ ,2C ‹ôh 2C ÿ¸‚C ƒÄ;ôèßÐ ‹ôh2C ÿ¸‚C ƒÄ;ôèÈÐ ‹ôh2C ÿ¸‚C ƒÄ;ôè±Ð ÇEüÿÿÿÿ‹Eð‹Môd‰
_^[ƒÄP;ìèÐ ‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒìDSVWQ}¼¹ ¸ÌÌÌÌó«Y‰Mü‹Müèêðÿÿ‹Eƒà…Àt ‹MüQèòÊ ‹Eü_^[ƒÄD;ìèÐ ‹å] ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìjÿh¹ B d¡ Pd‰% ƒìDSVWQ}°¹ ¸ÌÌÌÌó«Y‰MðÇEü ‹MðÁÈ è‘îÿÿÇEüÿÿÿÿ‹Mðè$Ë ‹Môd‰
_^[ƒÄP;ìèsÏ ‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒìDSVWQ}¼¹ ¸ÌÌÌÌó«Y‰Mü‹MüèÙÒ _^[ƒÄD;ìè Ï ‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒì@SVW}À¹ ¸ÌÌÌÌó«è# è^ _^[ƒÄ@;ìèÑÎ ‹å]ÃÌÌÌÌÌÌÌÌÌÌÌÌÌU‹ìƒì@SVW
Go to You can get a free stock quote program that is pretty good.
Thanks for that, but Iam already aware of those kinds of services. I already have live quotes through my broker.
What I have is a custom built program for options that was designed and built by professionals. That is what I am trying to get rewritten with updates that I have in mind. It is quite complex.
What I have is a custom built program for options that was designed and built by professionals. That is what I am trying to get rewritten with updates that I have in mind. It is quite complex.
Just for grins, let's sum this up.
It is impossible to decompile and .exe file and come up with the original C or C++ code that created it. The problem is that a lot of language sematics is lost in reducing the source to binary. Take, for instance, the first pass of the compile - the C preprocessor. Among other things, it strips comments, changes macro calls into their definitions, and drops the include file contents right into it's output in place of the include statemnents, so all preprocessor information is lost. And that's just the first step.
It is possible to de-assemble binary back into a pseudo-assembly code. Experienced programmers (experienced in C++ and in assembly, and who have taken the time to look at their own code de-assembled) can use this to make guesses about the C code that created the assembly. There are usually better ways to use that person's time, though.
As someone mentioned above, a lot of the newer libraries and frameworks are leaving information lying around in the binary, for many reasons. Since de-compiling a program is the pot-at-the-end-of-the-rainbow for the cracking community, this may well serve as a warning to the paranoid.
It has been rumored that MS does indeed have at least a fair de-compiling technology, but for obvious reasons keeps it for in-house use only. Conspiracy theories abound, but then again, that's just plain paranoid - the question is, is it paranoid enough?
If you really want to get into this in a big way, then you need to take up digital electronics, I/O and interrupt programming and assembly level programming, on all the machines you want to target - essentially learn the cracker's game. Wouldn't hurt to learn some law about Copyright infringement and what lawyers mean by the word de-engineering in those shrink-wrapped licenses, not to speak of what the latest copyright laws do for tooling intended to crack, even if not used for that purpose. Be very careful.
It is impossible to decompile and .exe file and come up with the original C or C++ code that created it. The problem is that a lot of language sematics is lost in reducing the source to binary. Take, for instance, the first pass of the compile - the C preprocessor. Among other things, it strips comments, changes macro calls into their definitions, and drops the include file contents right into it's output in place of the include statemnents, so all preprocessor information is lost. And that's just the first step.
It is possible to de-assemble binary back into a pseudo-assembly code. Experienced programmers (experienced in C++ and in assembly, and who have taken the time to look at their own code de-assembled) can use this to make guesses about the C code that created the assembly. There are usually better ways to use that person's time, though.
As someone mentioned above, a lot of the newer libraries and frameworks are leaving information lying around in the binary, for many reasons. Since de-compiling a program is the pot-at-the-end-of-the-rainbow for the cracking community, this may well serve as a warning to the paranoid.
It has been rumored that MS does indeed have at least a fair de-compiling technology, but for obvious reasons keeps it for in-house use only. Conspiracy theories abound, but then again, that's just plain paranoid - the question is, is it paranoid enough?
If you really want to get into this in a big way, then you need to take up digital electronics, I/O and interrupt programming and assembly level programming, on all the machines you want to target - essentially learn the cracker's game. Wouldn't hurt to learn some law about Copyright infringement and what lawyers mean by the word de-engineering in those shrink-wrapped licenses, not to speak of what the latest copyright laws do for tooling intended to crack, even if not used for that purpose. Be very careful.
Although I certainly do agree that compilers that leave a lot of the original info in the binary are bad and it would be very bad for software companies if C++ decompilers did exist, I do however think that it should be "possible" to create a decompiler that restores quite a bit of the original source code.
As LyMc said, include files get directly included into the file being compiled, but if you knew which compiler was used to create the executable, I think the decompiler should be able to recognize chunks of code that belong to the include files and just replace them with #include statements.
Variable names would obviously be lost, but hey, what do you expect?
The decompiler should also be able to recognize functions like printf(), cout, open(), write()... and replace all that assembly with the function names.
Custom classes may or may not be able to be reconstructed, I don't know enough about how they get translated into assembly to know.
Would it be worth it to create such a decompiler? Hackers would say yes. Sane people would say no.
As LyMc said, include files get directly included into the file being compiled, but if you knew which compiler was used to create the executable, I think the decompiler should be able to recognize chunks of code that belong to the include files and just replace them with #include statements.
Variable names would obviously be lost, but hey, what do you expect?
The decompiler should also be able to recognize functions like printf(), cout, open(), write()... and replace all that assembly with the function names.
Custom classes may or may not be able to be reconstructed, I don't know enough about how they get translated into assembly to know.
Would it be worth it to create such a decompiler? Hackers would say yes. Sane people would say no.
Boomerang is an open source decompiler. I wrote a .dll file and lost the source code and used Boomerang to decompile it. The code wasn't pretty after it was decompiled, but since I had written it I was able to glean some information from it that I had forgotten. Boomerang is an interesting project and has a ways to go, but I found it pretty cool and helpful. However, you obviously aren't getting exact source code and it's extremely difficult to figure out if you don't know what the source code looked like to begin with.
- Status
Similar threads
- Locked
- Question