«

Is there a way to do this. I mean there is a company who converts asm to
their wsl language and then from that to c is there a way that we can do
this?

Glen Richards wrote:

> Is there a way to do this. I mean, is there a company
> who converts asm to their wsl language and then from that to c?

No.

> Is there a way that we can do this?

No.

Information is discarded in the process
of compiling a higher level language to assembler
that cannot be recovered from the assembler alone.

E. Robert Tisdale wrote:
> Glen Richards wrote:
>
>> Is there a way to do this. I mean, is there a company who converts asm
>> to their wsl language and then from that to c?
>
> No.
>
>> Is there a way that we can do this?
>
> No.
>
> Information is discarded in the process
> of compiling a higher level language to assembler
> that cannot be recovered from the assembler alone.

OK, this is off-topic here, but I'm not convinced by the impossibility
claim. What is surely impossible is to retrieve the _particular_ C
code that, when run through some (unknown) compiler, generated a given
glob of machine code. But given the asm, shouldn't it be possible
in principle to generate (non-unique) C code of equivalent effect?
Whether anyone provides this sort of service commercially, I have
no idea.

--
Allin Cottrell
Department of Economics
Wake Forest University, NC

Allin Cottrell wrote:

> OK, this is off-topic here
> but I'm not convinced by the impossibility claim.
> What is surely impossible is to retrieve the _particular_ C code
> that, when run through some (unknown) compiler,
> generated a given glob of machine code.
> But given the assembler, shouldn't it be possible, in principle,
> to generate (non-unique) C code of equivalent effect?

In general, no. You would be obliged to emulate
the machine architecture and the operating system (OS).
You would need to be able to recognize calls to the OS
for I/O for example. In other words, you would need information
about the program besides what remains in the assembler listing
to resolve all of these references.

> Whether anyone provides this sort of service commercially,
> I have no idea.

There are (or at least were) people in the KBG, CIA, NSA, etc.
that could do a fairly reasonable job of "reverse engineering"
machine codes (assembler).

"Glen Richards" <> wrote in message
news:GYhWb.143769$U%5.658804@attbi_s03...
> Is there a way to do this.

Sure. Find out what the ASM program does, then
write the C code to do the same thing.

> I mean there is a company who converts asm to
> their wsl language and then from that to c is there a way that we can do
> this?

There might indeed exist some 'automated' methods, but
their output (C source) would very likely be very cryptic,
usually meant only for consumption by a computer.

-Mike

Allin Cottrell wrote:

> E. Robert Tisdale wrote:
>
>> Glen Richards wrote:
>>
>>> Is there a way to do this. I mean, is there a company who converts
>>> asm to their wsl language and then from that to c?
>
> >
>
>> No.
>>
>>> Is there a way that we can do this?
>>
>>
>> No.
>>
>> Information is discarded in the process
>> of compiling a higher level language to assembler
>> that cannot be recovered from the assembler alone.
>
>
> OK, this is off-topic here, but I'm not convinced by the impossibility
> claim. What is surely impossible is to retrieve the _particular_ C
> code that, when run through some (unknown) compiler, generated a given
> glob of machine code. But given the asm, shouldn't it be possible
> in principle to generate (non-unique) C code of equivalent effect?

In principle, yes. Enumerate all possible files (an infinite, but
countable set); compile them with all possible compiler/flags
combinations (a finite set); compare the results with the executable.
You will lose information (comments; symbol names; high-level
constructs) but it is guaranteed to work (given a rather large amount of
time).

But of course, there are smarter ways. Searching for "decompilation" on
Google gives a couple of interesting hits.

A large amount of work has been done in this area; both in an academic
setting and a commercial setting. With regard to the latter: there's a
terrifying quantity of code out there that is in active use, but for
which the source code is no longer available (mostly COBOL). Some
companies specialize in semi-automatic reverse-engineering of this vital
software.

Best regards, Sidney

Mike Wahler wrote:
> There might indeed exist some 'automated' methods, but
> their output (C source) would very likely be very cryptic,
> usually meant only for consumption by a computer.
>
> -Mike
>

Yes, it might seem as a Basic program... (only gotos)...

On Wed, 11 Feb 2004, Glen Richards wrote:

> Is there a way to do this. I mean there is a company who converts asm to
> their wsl language and then from that to c is there a way that we can do
> this?

Normally people ask if you can convert machine language to C source. Two
reasons for this. First is that I have the binaries but lost the source
code (it happens even with backups). The second is that I have someone
else's binaries and I want to reverse engineer them.

If you want to go from machine code to C source there are programs out
there that will do something. All are operating system specific and most
are compiler specific as well. Just do a search on "reverse engineer <your
OS> <your compiler>" and you might find something. The source code they
product is difficult to read and next to impossible to maintain. It is
often easier to reverse engineer the requirements and write the program
from scratch.

If you have actual assembly source code and want to turn it into C source
code that might actually be harder. The market for people who know C but
have some assembly code is a lot smaller than people who want to reverse
engineer binaries. It would also be specific to the assembler and the
operating system. Maybe the search for reverse engineering might find
something but the results will be about the same or worse than going from
binary to C source. If you cannot find an assembly language to C source
converter you can try getting an assembler, create a binary then use
machine language to C source converts.

Bottom line, it is usually more effort to maintain the resulting source
code then it would be to write the application from scratch.

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to

[snips]

On Tue, 10 Feb 2004 21:44:59 -0800, E. Robert Tisdale wrote:

>> Whether anyone provides this sort of service commercially,
>> I have no idea.
>
> There are (or at least were) people in the KBG, CIA, NSA, etc.
> that could do a fairly reasonable job of "reverse engineering"
> machine codes (assembler).

Umm... it's not all that hard to reverse-engineer machine code, actually.
It's just tedious, slow, and not amenable to algorithmic solutions.

In < > Kelsey Bjarnason <> writes:

>[snips]
>
>On Tue, 10 Feb 2004 21:44:59 -0800, E. Robert Tisdale wrote:
>
>>> Whether anyone provides this sort of service commercially,
>>> I have no idea.
>>
>> There are (or at least were) people in the KBG, CIA, NSA, etc.
>> that could do a fairly reasonable job of "reverse engineering"
>> machine codes (assembler).
>
>Umm... it's not all that hard to reverse-engineer machine code, actually.
>It's just tedious, slow, and not amenable to algorithmic solutions.

It's an excellent exercise for anyone heavily involved in assembly
programming. And, occasionally, a must if a piece of software (or even
hardware) is not properly documented.

As a trivial example, it's usually easier to figure out how to interface
C code to a Fortran program by looking at the Fortran compiler output
than by digging into the documentation.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: