Reverse engineer to a compiled Pro*C
wayne
> the
> executable?
This is really a C question.
Remeber that the process is like this:
*.pc --> Oracle ProC --> *.c --> C/C++ compiler --> *.exe
If you have an .EXE you first need to get the C source code (which is very
had to do, if not impossible). You may get C source, but it will have the
output of the ProC preprocessor (a bunch of calls to an Oracle API). Then
you need a program to "decompile" yet again, this time fro the .c file to
the .pc file.
All in all, I'd place a strong bet that it cannot be done.
wayne
hehe! I guess that "*.exe" makes me a target for all the "Windows sucks"
people! All right, fire away! :-)
wayne
> for me.
No. This is what I meant by saying this was a C question: It is absolutely
dependant on your C/C++ compiler. You need to get a decompiler for your
specific compiler.
It is extremely hard to decompile C/C++ because: 1) It is compiled straight
into Assembler (in the majority of the cases), there is no midlevel
language; 2) This assembler code is usually extremely tight, and there may
be multiple C/C++ statements that can produce the same machine language; and
3) If the program was compiled with optimization turned on, then you may as
well forget it: This produces even tighter machine code and performs all
sorts of complex tricks (ie, to reduce the number of clock cycles a line of
code takes, the compiler may do weird operations). These tricks would
confuse any decompiler.
This is why the decompiler has to be targeted at the specific compiler: The
decompiler has to have intimate knowledge of what machine language is
generated from what C/C++ statements. Even if it has that knowlwdge, the
decompiler must be able to recognize the compiler optimizations (both when
you optimize for code size and optimize for execution speed) and their
machine code output. This is as impossible as it gets.
You may have to settle for assembly language code. There are many
dissasemblers that go from machine code to assembler.
If you want to decompile something, Java is a much better language!
Dan Maas
straight
> into Assembler (in the majority of the cases), there is no midlevel
> language; 2) This assembler code is usually extremely tight, and there may
> be multiple C/C++ statements that can produce the same machine language;
and
> 3) If the program was compiled with optimization turned on, then you may
as
> well forget it
additionally 4) Unless the .exe was compiled for debugging, the symbol names
are gone, so even if you figure out where the data is coming from and going
to, you won't know what it all *means*...
Dan
Phil Haigh
wayne wrote in message <9dv4cc$c...@dispatch.concentric.net>...
>> However, do you a method to get the .c file? ... It will be very helpful
>> for me.
>
>No. This is what I meant by saying this was a C question: It is
absolutely
>dependant on your C/C++ compiler. You need to get a decompiler for your
>specific compiler.
>
Not true - you just need a 'reverse engineering' tool for Windows that will
take an EXE and translate it back to C. But what you get won't be very
readable! Don't ask me if I know of such a tool - I've never needed one so
I've never looked.
Nuno Souto
<phil....@fwpharma.com> wrote:
>>
>
>Not true - you just need a 'reverse engineering' tool for Windows that will
>take an EXE and translate it back to C. But what you get won't be very
>readable! Don't ask me if I know of such a tool - I've never needed one so
>I've never looked.
Exactly. Get a copy of Dr.Dobb's. Somewhere in there are quite a few
adds of executable debuggers that can reverse engineer any Intel code
back to C. The output doesn't make much sense, but it can be used.
I'm quite sure others exist for other CPU architetures. There used to
be quite a few for VMS.
Cheers
Nuno Souto
nso...@bigpond.net.au.nospam
http://www.users.bigpond.net.au/the_Den/index.html