Trusting the Tools - was Re: Open Source ...

[Anne & Lynn Wheeler]

At 03:48 PM 10/12/2003 -0700, kent at songbird.com wrote:
>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.)

well ... you can take and compare the listing file against the "txt" deck 
output
of the assembler listing for each module . Each "txt": deck is input to the 
loader
which builds the actual executable (almost) memory image. past discussion
of the TXT file format:
http://www.garlic.com/~lynn/2001.html#14 IBM Model Numbers (was: First 
video terminal?)
http://www.garlic.com/~lynn/2001c.html#87 "Bootstrap"
http://www.garlic.com/~lynn/2001k.html#31 Is anybody out there still 
writting BAL 370.
http://www.garlic.com/~lynn/2002f.html#41 Blade architectures
http://www.garlic.com/~lynn/2002o.html#26 Relocation, was Re: Early 
computer games

then the issue isn't if the assembler has been compromised ... it is 
whether the
loader has been compromised. then you compare the memory image file
against the aggregate of the txt decks ... if you've done the assembler
listing comparison against the txt deck correctly .... then the memory
image comparison is looking for a loader compromise ... not an
assembler compromise.

some past discussion of memory/debugger analyser from approx. period that
gnosis started (precursor to keykos):
http://www.garlic.com/~lynn/subtopic.html#dumprx

which also had some capability to work from memory image of the program
in conjunction with assembler listing files.

of course it primarily relied on the REXX interpreter for its functionality so
if there was a compromise in the REXX interpreter .... or any of the utilities
written for analyses and comparison were compromised from the standpoint
of masking compromise in other components related to insertion of malicious
code.
--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
  

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com