ASM => C

[Unsolved Mysteries]

Anyone know of a translator that converts an Intel Pentium assembly
listing into C? The quality of output code doesn't have to be great,
so long as it's accurate.

[Gordon Burditt]

Re: ASM => C

>Anyone know of a translator that converts an Intel Pentium assembly[color=blue]
>listing into C? The quality of output code doesn't have to be great,
>so long as it's accurate.[/color]

It is possible to write an emulator for a Pentium CPU in C.
From there, you can add

unsigned char memory[] = {
(code for program goes here)
(oh, yes, you probably have to throw in a copy of
the BIOS ROM and the OS, too)
};

and the emulator will run the code, and it's written in C.
(You will probably have to do something more specific about I/O
getting to a real device, and the emulator probably won't run
real-time).

Gordon L. Burditt

[Unsolved Mysteries]

Re: ASM => C

gordonb.dojb7@b urditt.org wrote...[color=blue][color=green]
> >Anyone know of a translator that converts an Intel Pentium assembly
> >listing into C? The quality of output code doesn't have to be great,
> >so long as it's accurate.[/color]
>
> It is possible to write an emulator for a Pentium CPU in C.
> From there, you can add
>
> unsigned char memory[] = {
> (code for program goes here)
> (oh, yes, you probably have to throw in a copy of
> the BIOS ROM and the OS, too)
> };
>
> and the emulator will run the code, and it's written in C.
> (You will probably have to do something more specific about I/O
> getting to a real device, and the emulator probably won't run
> real-time).
>
> Gordon L. Burditt
>[/color]

I am looking for something that more directly translates an .s (or
..asm) file into a .c file -- but that's an interesting observation
you've made.

[Kevin D. Quitt]

Re: ASM => C

Generally speaking, what you're asking cannot be done. Even assuming the
assembly was generated by a C compiler, it's still impossible in theory.
The general statement is "You can't make steak from a hamburger" -
information is destroyed in the compilation process; you cannot recover
the original code. Go to vivisimo and search for 'decompilation' .

You *can* generate a C program that does the equivalent of what the
assembly code does, although that depends on how strictly you define
'equivalent'. What you cannot do is create a C program that is guaranteed
to do all and only the things the original C program did. Information on
variable types can be lost. For example, a variable may be signed in the
C code, but the assembly gives no indication because there was nothing in
the C that actually made use of the sign. If you make it unsigned in the
decompilation, it's possible to get behaviour that is different from the
original program.

That being said, my rates are semi-reasonable.

--
#include <standard.discl aimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list

[E. Robert Tisdale]

Reverse Engineering: ASM =&gt; C

Something that calls itself Unsolved Mysteries wrote:
[color=blue]
> Anyone know of a translator
> that converts an Intel Pentium assembly listing into C?[/color]

In general, no.
C does not implement all Intel machine instructions.

Design information is discarded when C is converted to assembler.
More generally, this is a problem
when programmers fail to document their designs
*before* they implement them as C programs
because they never get around to documentation
after the design is working.
It is very hard to "reverse engineer" undocumented C code
because the original author's intent is unknown.
[color=blue]
> The quality of output code doesn't have to be great,
> so long as it's accurate.[/color]

I used Google

http://www.google.com/

to search for

+"convert assembler to C"

and I found a couple of things that might interest you.

[Stephen Sprunk]

Re: ASM =&gt; C

"Unsolved Mysteries" <um@domain.inva lid> wrote in message
news:MPG.1ca0fc 3c8c06fdf798a16 e@news.verizon. net...[color=blue]
> I am looking for something that more directly translates an .s (or
> .asm) file into a .c file -- but that's an interesting observation
> you've made.[/color]

Disassembly works because there is a 1:1 (or nearly so) correspondence
between machine and assembly code. There is no such correspondence between
assembly and C; there are an infinite number of C sources that could result
in the same assembly listing and vice versa.

So, if you want the original C source corresponding to a given assembly
file, you're completely out of luck. If you want _any_ C source that might
compile to a given assembly listing, you might have a chance of writing such
a program, but AFAIK none exists. Even with debug symbols (which aren't
guaranteed to exist), the C you end up with is unlikely to even
superficially resemble the original C program or even any C that a human is
likely to write.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

[Unsolved Mysteries]

Re: ASM =&gt; C

stephen@sprunk. org wrote...[color=blue]
> "Unsolved Mysteries" <um@domain.inva lid> wrote in message[color=green]
> > I am looking for something that more directly translates an .s (or
> > .asm) file into a .c file -- but that's an interesting observation
> > you've made.[/color]
>
> Disassembly works because there is a 1:1 (or nearly so) correspondence
> between machine and assembly code. There is no such correspondence between
> assembly and C; there are an infinite number of C sources that could result
> in the same assembly listing and vice versa.
>
> So, if you want the original C source corresponding to a given assembly
> file, you're completely out of luck. If you want _any_ C source that might
> compile to a given assembly listing, you might have a chance of writing such
> a program, but AFAIK none exists. Even with debug symbols (which aren't
> guaranteed to exist), the C you end up with is unlikely to even
> superficially resemble the original C program or even any C that a human is
> likely to write.[/color]

The mapping between some large number of C programs and a given
assembler listing is understood, and OK.

I don't care at all how close to the original program it is.

[Eric Sosman]

Re: ASM =&gt; C



Unsolved Mysteries wrote:[color=blue]
> stephen@sprunk. org wrote...
>[color=green]
>>"Unsolved Mysteries" <um@domain.inva lid> wrote in message
>>[color=darkred]
>>>I am looking for something that more directly translates an .s (or
>>>.asm) file into a .c file -- but that's an interesting observation
>>>you've made.[/color]
>>
>>Disassembly works because there is a 1:1 (or nearly so) correspondence
>>between machine and assembly code. There is no such correspondence between
>>assembly and C; there are an infinite number of C sources that could result
>>in the same assembly listing and vice versa.
>>
>>So, if you want the original C source corresponding to a given assembly
>>file, you're completely out of luck. If you want _any_ C source that might
>>compile to a given assembly listing, you might have a chance of writing such
>>a program, but AFAIK none exists. Even with debug symbols (which aren't
>>guaranteed to exist), the C you end up with is unlikely to even
>>superficial ly resemble the original C program or even any C that a human is
>>likely to write.[/color]
>
>
> The mapping between some large number of C programs and a given
> assembler listing is understood, and OK.
>
> I don't care at all how close to the original program it is.[/color]

Then what's the purpose of creating "trashy" C source?
The value of a source file is that it can be read and
understood, then modified and recompiled to produce a new
program. If it's unreadable (or nearly so) it's also
unmodifiable (o.n.s.) -- so, what do you intend to do with
your cow made from hamburger?

--
Eric.Sosman@sun .com

[Unsolved Mysteries]

Re: ASM =&gt; C

eric.sosman@sun .com wrote...[color=blue]
>
>
> Unsolved Mysteries wrote:[color=green]
> > stephen@sprunk. org wrote...
> >[color=darkred]
> >>"Unsolved Mysteries" <um@domain.inva lid> wrote in message
> >>
> >>>I am looking for something that more directly translates an .s (or
> >>>.asm) file into a .c file -- but that's an interesting observation
> >>>you've made.
> >>
> >>Disassembly works because there is a 1:1 (or nearly so) correspondence
> >>between machine and assembly code. There is no such correspondence between
> >>assembly and C; there are an infinite number of C sources that could result
> >>in the same assembly listing and vice versa.
> >>
> >>So, if you want the original C source corresponding to a given assembly
> >>file, you're completely out of luck. If you want _any_ C source that might
> >>compile to a given assembly listing, you might have a chance of writing such
> >>a program, but AFAIK none exists. Even with debug symbols (which aren't
> >>guaranteed to exist), the C you end up with is unlikely to even
> >>superficial ly resemble the original C program or even any C that a human is
> >>likely to write.[/color]
> >
> > The mapping between some large number of C programs and a given
> > assembler listing is understood, and OK.
> >
> > I don't care at all how close to the original program it is.[/color]
>
> Then what's the purpose of creating "trashy" C source?[/color]

I said it doesn't have to be the original C. While I think we could
agree that there are many, many readable C programs that do the same
thing, your question implies otherwise.
[color=blue]
> The value of a source file is that it can be read and
> understood, then modified and recompiled to produce a new
> program. If it's unreadable (or nearly so) it's also
> unmodifiable (o.n.s.) -- so, what do you intend to do with
> your cow made from hamburger?[/color]

But if it's a readable C program, then your question is badly formed.
Nonetheless: C is more portable than ASM, last time I looked.

--
"It is much easier to propagandize a public that believes in its own
freedom." - Robert McChesney

[Stephen Sprunk]

Re: ASM =&gt; C

"Eric Sosman" <eric.sosman@su n.com> wrote in message
news:d17pa4$m0v $1@news1brm.Cen tral.Sun.COM...[color=blue]
> Unsolved Mysteries wrote:[color=green]
> > stephen@sprunk. org wrote...[color=darkred]
> >>So, if you want the original C source corresponding to a given
> >>assembly file, you're completely out of luck. If you want _any_ C
> >>source that might compile to a given assembly listing, you might
> >>have a chance of writing such a program, but AFAIK none exists.
> >>Even with debug symbols (which aren't guaranteed to exist), the
> >>C you end up with is unlikely to even superficially resemble the
> >>original C program or even any C that a human is likely to write.[/color]
> >
> > The mapping between some large number of C programs and a given
> > assembler listing is understood, and OK.
> >
> > I don't care at all how close to the original program it is.[/color]
>
> Then what's the purpose of creating "trashy" C source?
> The value of a source file is that it can be read and
> understood, then modified and recompiled to produce a new
> program. If it's unreadable (or nearly so) it's also
> unmodifiable (o.n.s.) -- so, what do you intend to do with
> your cow made from hamburger?[/color]

If nothing else, it makes a great project for undergrads ;)

Depending on how smart the decompiler is, it might do a reasonable job of
ferreting out calling conventions, flow control instructions, etc. With
debug information available, it could even get the function and variable
names (and types?) right. That's certainly more readable/modifiable for me
than what I get from a disassembler, but the usefulness is still low
compared to the original source.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

[Eric Sosman]

Re: ASM =&gt; C

Unsolved Mysteries wrote:[color=blue]
> eric.sosman@sun .com wrote...
>[color=green]
>>
>>Unsolved Mysteries wrote:[color=darkred]
>>> [...]
>>>I don't care at all how close to the original program it is.[/color]
>>
>> Then what's the purpose of creating "trashy" C source?[/color]
>
> I said it doesn't have to be the original C. While I think we could
> agree that there are many, many readable C programs that do the same
> thing, your question implies otherwise.[/color]

No (or at any rate, I don't think so): I'm suggesting
that mechanical dis-compiling is likely to produce one of
the many possible *un*readable C sources for the object code.
[color=blue][color=green]
>>The value of a source file is that it can be read and
>>understood, then modified and recompiled to produce a new
>>program. If it's unreadable (or nearly so) it's also
>>unmodifiabl e (o.n.s.) -- so, what do you intend to do with
>>your cow made from hamburger?[/color]
>
> But if it's a readable C program, then your question is badly formed.[/color]

If the output is readable, consider yourself either lucky
or an excellent reader ... In any case, questions are valid or
invalid on their premises, not on whatever the answer turns out
to have been.
[color=blue]
> Nonetheless: C is more portable than ASM, last time I looked.[/color]

It depends rather strongly on the C: you have but to lurk
on this newsgroup for a few days to see enough examples of
wildly non-portable C as you can stomach. Here's a plausible
example: somewhere in the object code you find instructions
that load a `double' register from one location and store
it to another. Your dis-compiler may well generate

*(double*)p = *(double*)q;

.... which accurately reflects the object code. Portable?
By no means! What was *really* going on was

struct st { short s; int i; };
struct st x = { 42, 42 };
/* here come the instructions in question: */
struct st y = x;

.... where the compiler decided to copy an eight-byte struct
by copying an eight-byte `double'. How portable is this?
Not very! The compiler has taken advantage of its own non-
portable knowledge in generating the code, as it is permitted
to do. Is the idea that sizeof(struct st) == sizeof(double)
portable? No, it is not. How about alignment: Is there any
guarantee that "alignof(st ruct st)" >= "alignof(double )"?
No, there is not. How about preservation of representation:
Is there any guarantee that loading something that might look
like a signalling NaN into a `double' register will preserve
its bit pattern for the subsequent store? No, there is not.

If you hope to dis-compile on machine A and re-compile
on machine B and get working code, you may well hope and your
hope may be rewarded, at least some of the time. But you would
be well-advised not to expect much ...

--
Eric Sosman
esosman@acm-dot-org.invalid

[Unsolved Mysteries]

Re: ASM =&gt; C

esosman@acm-dot-org.invalid wrote...[color=blue]
> Unsolved Mysteries wrote:[color=green]
> > eric.sosman@sun .com wrote...
> >[color=darkred]
> >>
> >>Unsolved Mysteries wrote:
> >>> [...]
> >>>I don't care at all how close to the original program it is.
> >>
> >> Then what's the purpose of creating "trashy" C source?[/color]
> >
> > I said it doesn't have to be the original C. While I think we could
> > agree that there are many, many readable C programs that do the same
> > thing, your question implies otherwise.[/color]
>
> No (or at any rate, I don't think so): I'm suggesting
> that mechanical dis-compiling is likely to produce one of
> the many possible *un*readable C sources for the object code.[/color]

OK. I guess there _would_ be more unreadable than readable resulting
sources, and purely mechanical rendering would be much more likely to
produce one of the former than one of the latter.
[color=blue][color=green][color=darkred]
> >>The value of a source file is that it can be read and
> >>understood, then modified and recompiled to produce a new
> >>program. If it's unreadable (or nearly so) it's also
> >>unmodifiabl e (o.n.s.) -- so, what do you intend to do with
> >>your cow made from hamburger?[/color]
> >
> > But if it's a readable C program, then your question is badly formed.[/color]
>
> If the output is readable, consider yourself either lucky
> or an excellent reader ... In any case, questions are valid or
> invalid on their premises, not on whatever the answer turns out
> to have been.
>[color=green]
> > Nonetheless: C is more portable than ASM, last time I looked.[/color]
>
> It depends rather strongly on the C: you have but to lurk
> on this newsgroup for a few days to see enough examples of
> wildly non-portable C as you can stomach.[/color]

Cripes. I'm 0-2 here. Point taken.
[color=blue]
> Here's a plausible
> example: somewhere in the object code you find instructions
> that load a `double' register from one location and store
> it to another. Your dis-compiler may well generate
>
> *(double*)p = *(double*)q;
>
> ... which accurately reflects the object code. Portable?
> By no means! What was *really* going on was
>
> struct st { short s; int i; };
> struct st x = { 42, 42 };
> /* here come the instructions in question: */
> struct st y = x;
>
> ... where the compiler decided to copy an eight-byte struct
> by copying an eight-byte `double'. How portable is this?
> Not very! The compiler has taken advantage of its own non-
> portable knowledge in generating the code, as it is permitted
> to do. Is the idea that sizeof(struct st) == sizeof(double)
> portable? No, it is not. How about alignment: Is there any
> guarantee that "alignof(st ruct st)" >= "alignof(double )"?
> No, there is not. How about preservation of representation:
> Is there any guarantee that loading something that might look
> like a signalling NaN into a `double' register will preserve
> its bit pattern for the subsequent store? No, there is not.
>
> If you hope to dis-compile on machine A and re-compile
> on machine B and get working code, you may well hope and your
> hope may be rewarded, at least some of the time. But you would
> be well-advised not to expect much ...
>
>[/color]

--
"It is much easier to propagandize a public that believes in its own
freedom." - Robert McChesney

[Mac]

Re: ASM =&gt; C

On Tue, 15 Mar 2005 18:33:49 +0000, Unsolved Mysteries wrote:
[color=blue]
> Anyone know of a translator that converts an Intel Pentium assembly
> listing into C? The quality of output code doesn't have to be great,
> so long as it's accurate.[/color]

Funny, I thought this was in the FAQ list, but when I went to look for it
I couldn't find it.

It probably should be in the FAQ list.

--Mac

[Richard Bos]

Re: ASM =&gt; C

"Unsolved Mysteries" <um@domain.inva lid> wrote:
[color=blue]
> stephen@sprunk. org wrote...[color=green]
> > So, if you want the original C source corresponding to a given assembly
> > file, you're completely out of luck. If you want _any_ C source that might
> > compile to a given assembly listing, you might have a chance of writing such
> > a program, but AFAIK none exists. Even with debug symbols (which aren't
> > guaranteed to exist), the C you end up with is unlikely to even
> > superficially resemble the original C program or even any C that a human is
> > likely to write.[/color]
>
> The mapping between some large number of C programs and a given
> assembler listing is understood, and OK.[/color]

For a pre-determined compiler, used on a pre-determined platform, with
pre-determined options, perhaps. If you don't know any of that, it isn't
and when push gets to shove cannot be understood.
[color=blue]
> I don't care at all how close to the original program it is.[/color]

Then you have a better chance at generating _something_, but still
hardly a chance of generating something legible, let alone maintainable.

Richard

[Kevin D. Quitt]

Re: ASM =&gt; C

On Wed, 16 Mar 2005 03:08:31 GMT, Unsolved Mysteries <um@domain.inva lid>
wrote:[color=blue]
>Cripes. I'm 0-2 here. Point taken.[/color]

I tried to tell ya.

--
#include <standard.discl aimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list