Vulnerability Development mailing list archives
Re: reverse engineer c or java
From: crispin () WIREX COM (Crispin Cowan)
Date: Sun, 28 May 2000 00:49:21 -0700
Jeff Bachtel wrote:
The problem is that with optimizing compilers, a given output of the compiler has an infinite (or thereabouts ;) number of possible source programs.
It is truly infinite. The number of source programs is isomorphic to the number of rational numbers (insert Math undergrad degree here :-)
The fact is, that a decompiler can produce perfectly valid C code, that makes no sense to normal humans.
Agreed.
This does not take into account self-modifying code, which would require a decompiler coupled with a simulation engine, and logic to detect flow between possible states of the program, and the algorythmns used.
Which is the basis for Turing's Halting problem (insert grad course in computability theory here :-) The decompiler would not notice; it would produce a C program that computes pointers that point into the data space, writes to them, and then assigns (*foo)() = (void *) and jumps to foo(). You're right; it won't make sense to humans, unless the humans can understand the byte sequence written to the pinter. Crispin
Current thread:
- Re: reverse engineer c or java AnorEXia (May 20)
- Re: reverse engineer c or java Jacek Lipkowski (May 21)
- Re: reverse engineer c or java Bluefish (May 22)
- Re: reverse engineer c or java Jeff Bachtel (May 23)
- Re: reverse engineer c or java Crispin Cowan (May 28)
- <Possible follow-ups>
- Re: reverse engineer c or java Miller, Timothy (May 21)
- Re: reverse engineer c or java Zoa_Chien (May 22)
- Re: reverse engineer c or java Michael Wojcik (May 22)
- Re: reverse engineer c or java Matt inAmsterdam (May 24)
- Re: reverse engineer c or java Matt inAmsterdam (May 25)
- Re: reverse engineer c or java Jacek Lipkowski (May 21)