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 [EMAIL PROTECTED]
