Decompilation

Decompilation

[Doug Evans]

J. Grant writes:
 > I am currently working on some decompilation methods/ideas. I have been 
 > looking at the suitability of implementing using the GNU tools as a 
 > base. I realise this is a very complex process, so would like to ask 
 > peoples opinions before diving in and coding in all the wrong places.
 > 
 > I would like to achive something similar to the way that gcc is the 
 > front end for compiling. For each of the stages below I would welcome 
 > sugested  areas of binutils/GCC that I should focus my work on. I have 
 > been modifying objdump to produce the intermediate code.  Clearly a lot 
 > of new code needs to be written to complete this work. If anyone has 
 > sugestions for the direction I should take this is welcome.
 > 
 > Stage 1: Front end
 > Input machine code binary
 > Disassemble
 > Abstract intermediate code generation
 > Intermediate code output

What if you used cgen for stage 1?
I've always wanted to add the rtl to the opcodes files of cgen (*1),
but haven't had a reason or impetus to.
With that (and some suitable cover/utility fns) I believe you could easily
go from binary to intermediate code (*2).  Only for the targets that cgen
supports of course.

(*1): At some point I've been expecting binutils to want to boot cgen
out of libopcodes.  I dunno.  But I've always wanted to create libcgen too.
There's a lot more ISA utilities that can be provided with cgen and should
be made available in the form of a library, but whether they belong in
libopcodes and shipped with binutils is certainly debatable.

(*2): pedantic: insert all the usual caveats of determining what's code
and what's data.

 > Stage 2: Universal decompilation machine (UDM)
 > CFG generation
 > CFG analysis
 > Data Format analysis
 > 
 > Stage 3: Backend HLL target
 > HLL constructs identified
 > HLL output

Re: Decompilation

[J. Grant]

Doug Evans wrote:
> J. Grant writes:
>  > I am currently working on some decompilation methods/ideas. I have been 
>  > looking at the suitability of implementing using the GNU tools as a 
>  > base. I realise this is a very complex process, so would like to ask 
>  > peoples opinions before diving in and coding in all the wrong places.
>  > 
>  > I would like to achive something similar to the way that gcc is the 
>  > front end for compiling. For each of the stages below I would welcome 
>  > sugested  areas of binutils/GCC that I should focus my work on. I have 
>  > been modifying objdump to produce the intermediate code.  Clearly a lot 
>  > of new code needs to be written to complete this work. If anyone has 
>  > sugestions for the direction I should take this is welcome.
>  > 
>  > Stage 1: Front end
>  > Input machine code binary
>  > Disassemble
>  > Abstract intermediate code generation
>  > Intermediate code output
> 
> What if you used cgen for stage 1?
> I've always wanted to add the rtl to the opcodes files of cgen (*1),
> but haven't had a reason or impetus to.
> With that (and some suitable cover/utility fns) I believe you could easily
> go from binary to intermediate code (*2).  Only for the targets that cgen
> supports of course.

Thank you for the reply.

Having just checked cgen, I think it might be useful to use for this
purpose. It is a very interesting project.

Is the CPU description language complete? I have been working with 
C--(http://cminusminus.org/) and modifying objdump currently.  C-- seems 
more of an intermediate code language than the cgen one (from reading 
the docs). I am not sure of the exact organisation of GCC and binutils.

I notice the use of Scheme as the implementation language, I have been
leaning towards C for my research so far. Certainly for the first phase
it seems suitable IMO. I have not started on phase 2 or 3 yet (beyond 
considerations of techniques).

> (*1): At some point I've been expecting binutils to want to boot cgen
> out of libopcodes.  I dunno.  But I've always wanted to create libcgen too.
> There's a lot more ISA utilities that can be provided with cgen and should
> be made available in the form of a library, but whether they belong in
> libopcodes and shipped with binutils is certainly debatable.

Is there cgen Scheme source in binutils currently? I have not seen any 
as part of the opcodes dir or other areas. Is it only available 
separatly from the home page currently?

> (*2): pedantic: insert all the usual caveats of determining what's code
> and what's data.

This should be feasible on architectures that separate data & code in
different sections. Targets such as SH that I believe place const data 
inline in .text would have to use some heuristics based on access of the 
data I expect.


Comments or sugestions welcome

JG

Re: Decompilation

[Ben Elliston]

>>>>> "J" == J Grant <jg-lists@jguk.org> writes:

  J> Is there cgen Scheme source in binutils currently? I have not
  J> seen any as part of the opcodes dir or other areas. Is it only
  J> available separatly from the home page currently?

It is in src/cgen, in the same repository as binutils itself.

Ben