Re: Taking an AST back into C

vbdis@aol.com (VBDis)
5 Dec 2004 21:34:16 -0500

          From comp.compilers

Related articles
Taking an AST back into C nb_no_spam@synthcom.com (Neil Bradley) (2004-11-28)
Re: Taking an AST back into C Martin.Ward@durham.ac.uk (Martin Ward) (2004-12-01)
Re: Taking an AST back into C torbenm@diku.dk (2004-12-01)
Re: Taking an AST back into C vbdis@aol.com (2004-12-01)
Re: Taking an AST back into C vbdis@aol.com (2004-12-05)
Re: Taking an AST back into C vbdis@aol.com (2004-12-05)
Re: Taking an AST back into C vbdis@aol.com (2004-12-11)
Re: Taking an AST back into C Martin.Ward@durham.ac.uk (Martin Ward) (2004-12-11)
Re: Taking an AST back into C vbdis@aol.com (2004-12-13)
| List of all articles for this month |

From: vbdis@aol.com (VBDis)
Newsgroups: comp.compilers
Date: 5 Dec 2004 21:34:16 -0500
Organization: AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com
References: 04-12-006
Keywords: decompile
Posted-Date: 05 Dec 2004 21:34:16 EST

  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


Post a followup to this message

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