Re: Help on Untrusted Code?

: I think talking about trusted code requires a clear idea of what you
: trust it to do. I trust a C compiler to not send mail to my enemies
: each time I compile a C program. Trusting the generated code to not
: overstep array bounds is a different issue.


The problem of trusting a compiler is indeed a valid question as was
demonstrated by Ken Thompson
(http://www.abc.se/~jp/articles/computer/unix/ken.txt). The only real
way to "trust" a compiler is to verify the output it produces with a
reverse engineering tool. Today, the best tool one can expect to
aquire is a debugger and the task is anything but simple, involving
the decoding of thousands of lines of assembly language for even your
most simple (functional) programs. A better tool would be a
resourcable interactive decompiler that could produce some similar
(admittedly low level and without comments or variable names
preserved) source code to the original input to the compiler. An
equalily valid suggestion is to assist a decompilation tool with the
original source.. the tool would look for descrepencies in the binary
from the source. These sorts of tools would also be very helpful for
discovering the buffer overflows that you have described in binary
only distrobutions (it is often the users of software who care more
about security than the vendors) and legacy code.


Unfortunately, little research has been done into development of such
tools and even less academic research into these issues has been
funded. I direct interested parties to the University of Queensland
Binary Translation project (http://www.csee.uq.edu.au/csm/uqbt.html)
which is essentially a resourcable decompiler to (very) low level C
which is then fed through a C compiler to migrate binaries between
different (mainly unix variant) platforms.


Trent Waddington

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