Re: Taking an AST back into C

  Martin Ward <Martin.Ward@durham.ac.uk> schreibt:


>void
>no_pick()
>{
> if ((adtn1->dsaft == 0 && adtn1->hrfft == 0))
> {
> htst_irf();
> }
> else if (adtn1->dsaft == 0)
> {
> oldgs = 0;
> hwal_zf = hwal();
> if (hwal_zf != 0)
> {
> htst_irf();
> }
> }
> return;
>}


Another possible representation:


void
no_pick()
{
  if (adtn1->dsaft == 0 && adtn1->hrfft != 0 && oldgs = 0, hwal() == 0)
                  htst_irf();
}
(Please ignore possible errors in the code, I decompiled manually ;-)




Provided that your assembler code actually was disassembler output,
I'd furthermore suspect a typo in the original C source code, which
probably should have read as:


  if (adtn1->dsaft == 0 && adtn1->hrfft != 0 && oldgs == 0 && hwal() == 0)
                  htst_irf();


It were not the first bug of that kind that I found while decompiling ;-)




>[I'd think that translating assembler into C should be a lot easier
>than decompiling object code because you have the symbols and
>labels. -John]


True, the separation of code and data often is not trivial. Microsoft
code can contain some very ugly hacks, confusing even sophisticated
automated and experienced human disassemblers. The more stupid the
development tools are, the more creative are the coders :-(


Symbols also are found in object and library modules. It's a good idea
to determine the compiler, OS, and the use of (according) libraries
and declarations. With that knowledge it's possible to re-import many
names and proper data types, and to separate library from application
functions, etc. For the user it's much more helpful to identify the
library functions, which usually are well documented elsewhere, and to
propagate the related data (argument...) types into the application
code, instead of attempting to decompile such functions. I used that
technique in my own C decompiler, and the IDA disassembler uses the
equivalent FLIRT technique.


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.