[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: Decompiler?

>---- Original Message ----
>From: motamedi24@hotmail.com
>To: debian-user@lists.debian.org
>Subject: RE: Decompiler?
>Date: Mon, 22 Feb 2010 05:11:07 +0000
>>> Date: Sun, 21 Feb 2010 07:28:01 -0500
>>> From: zlinuxman@wowway.com
>>> To: debian-user@lists.debian.org
>>> Subject: Re: Decompiler?
>>> On Sun, 21 Feb 2010 05:06:21 -0500 (EST), Hadi Motamedi wrote:
>>> > 
>>> > Dear All
>>> > 
>>> > I have disassembled the object file on my Debian server , by the
>following :
>>> > 
>>> > #objdump wmain
>>> > 
>>> > In the output , I have recognized the intended subroutine that I
>need to
>>> > find the exact command syntax that it sends out. To this end, I
>>> > you guys on how to capture it through 'tcpdump' but didn't
>success. I
>>> > read this segment assembly language code but it is somewhat
>difficult to
>>> > decode. Can you please let me know what Debian decompiler is
>suitable for
>>> > this case? I tried with 'decompyle' but it didn't get through.
>>> First, let me make sure I understand what you are asking. You have
>>> binary object code and you want to transform it back into the C
>>> code that it came from. Is that right? Or did I misunderstand you?
>>> If that is what you want, then I doubt that it is possible. I've
>>> heard of a decompiler. I have heard of a disassembler, but even
>>> have their limitations. I myself have done extensive work as a
>>> on a disassembler for the s390 platform. It happens to be the
>>> resident in the TRACK for z/VM freeware program. So I am speaking
>>> experience here. Even a disassembler is a guess. Here are some
>things that
>>> you lose, even in a disassembler:
>>> 1. All comments.
>>> 2. The names of all variables
>>> 3. The distinction between code and data
>>> For example, if I encounter the hex string '41101004' that could
>be a
>>> LA 1,4(,1)
>>> instruction. But it might not be an instruction. It might be data.
>>> might be
>>> DC F'1091571716'
>>> Or maybe it's a floating point number in traditional s390
>>> floating point format. Or maybe it's part of an escape sequence of
>>> to be sent to a printer. You can never be sure. All these
>>> are present in a disassembler. In assembly language, there is
>pretty much
>>> a one-to-one correspondence between assembler instructions and
>>> instructions. But in a high-level language, that is not so. A
>>> statement in source code may generate a long sequence of machine
>>> How do you know where one statement ends and another begins?
>>> In short, I doubt if it is possible. Even if you do find something
>>> purports to be a decompiler, its output will almost certainly not
>>> the original input. Compilation is a one-way process.
>>> -- 
>>> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
>>> with a subject of "unsubscribe". Trouble? Contact
>>> Archive:
>>Thank you for your reply . Actually my Debian server is running an
>application program that sends commands toward an attached network
>element . The commands deal with 'profile read' , 'profile modify' ,
>and 'profile delete' issues . On the application gui , there is an
>option to try for 'profile replace' that I cannot find the related
>command . As there is a need to try for this 'profile replace' in
>batch file , so I need to find the exact command syntax for this
>purpose . I tried to capture it through tracing with 'tcpdump' but it
>was un-successful . So I dis-assembled the code and I was lucky to
>find the related subroutine . It is short in length but I cannot
>decode it to find the logic in behind . So I need to find a
>de-compiler to de-compile it to some sort of higher level languages
>to see if I can understand the login behind . Please give me a hint
>on how to accomplish this .
I think you already got your answer although you may not like it.  If
the program was written in assembler than a dis-assembler will give
you the source code; however even if you have that you still do not
have the whole picture (e.g. the symbol tables).  If the program was
written in a HLL such as C I know of no way to go from the machine
code back to the source code.  In fact looking at the machine code
won't even tell you what HLL the source was written in or what
compiler was used.  I think you are proceeding down the wrong path.  
>>Hotmail: Trusted email with Microsoft?s powerful SPAM protection.

Reply to: