[14621] in cryptography@c2.net mail archive
Re: Trusting the Tools - was Re: Open Source ...
daemon@ATHENA.MIT.EDU (kent@songbird.com)
Mon Oct 13 12:07:05 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
From: kent@songbird.com
Date: Sun, 12 Oct 2003 15:48:04 -0700
To: Anne & Lynn Wheeler <lynn@garlic.com>
Cc: Bill Frantz <frantz@pwpconsult.com>, cryptography@metzdowd.com
Mail-Followup-To: Anne & Lynn Wheeler <lynn@garlic.com>,
Bill Frantz <frantz@pwpconsult.com>, cryptography@metzdowd.com
In-Reply-To: <4.2.2.20031012080743.00b7d9d0@mail.earthlink.net>
On Sun, Oct 12, 2003 at 08:25:21AM -0600, Anne & Lynn Wheeler wrote:
>
> It wouldn't have been impossible ... but quite unlikely. It is somewhat
> easier in C-based programs since there are additional levels of indirection
> and obfuscations between the statements in a C program and the
> generated machine code.
Hmm. While I agree with your assessment of likelihood, I think you
understate the seriousness of the issue in both the C case and the
assembler case -- they are not really that different. It's not just a
matter of indirection and obfuscation -- there can be large blocks of
code generated for which there is no external visibility whatsoever (ie,
the map files and other traces of generated code can simply not show the
hidden code. This is true both for C and assembler. The only way you
can really tell is if you capture *all* of the live memory of the
computer, and disassemble it with a verified disassembler.
(eg, what shows as bss 0 in the assembler listing is really code; what shows
as one set of instructions in the listing is in reality different.)
Kent
--
Kent Crispin "Be good, and you will be
crispin@icann.org,kent@songbird.com lonesome."
p: +1 310 823 9358 f: +1 310 823 8649 -- Mark Twain
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
