On Sun, Oct 12, 2003 at 05:13:06PM -0600, Anne & Lynn Wheeler wrote: > well ... you can take and compare the listing file against the "txt" > deck output of the assembler listing for each module. [...] > then the issue isn't if the assembler has been compromised ... it is > whether the loader has been compromised.
You seem to be describing the characteristics of a particular assembler. Though I may not have expressed it well, my point was really at a different level. The entire program building system, of which the the loader, assembler, and compiler are all parts, is susceptible. Thompson's paper described a very clever way of embedding a trojan in a compiler, but there are multiple places in the program building system where compromises of a similar flavor could occur -- my favorite hypothetical has been the binary library manager (I worked on one for the Cray-1 series, many years ago). > 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. The process you describe is a rather daunting task, especially given that all that is really necessary is a very small bit of code to load more code from a different file. Kent -- Kent Crispin "Be good, and you will be [EMAIL PROTECTED],[EMAIL PROTECTED] lonesome." p: +1 310 823 9358 f: +1 310 823 8649 -- Mark Twain --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]