Universal Disassemblers vs. Universal MIILs

[Eric S. Raymond]

In article <7226 at ihlpl.att.com>, knudsen at ihlpl.ATT.COM (Knudsen) writes:
>In article <e6m10#2eDFfC=eric at snark.UUCP>, I write:
>>Excuse me, but I thought the security problem in for-sale software was to
>>guard it from unauthorized *copying* and *use*, not unauthorized
>>*understanding.
> 
> Well, some vendors are afraid of people (competitors?) understanding
> their code. 

And distributing a uMIIL isn't going to make automatic disassembly *easier*?

Long ago, in my pre-UNIX days, I once started writing a smart disassembler for
8086 code, one that would recognize illegal instructions, do flow-of-control
analysis on jumps and assign symbolic labels (then allow you to change the
names to meaningful ones). It would recognize and interpret OS service calls,
so you'd be able to spot I/O subroutines at a glance. It would keep its
deductions and your comments on them in a database so you could analyze code
interactively in stages. The Cracker, I called it. 

You'd sic this thing on a binary, watch the listings it generated, and add
comments through it. The end product; a text database which, when merged
against the binary through the cracker, would produce a neat  commented
listing.

What stopped me? Well, I got this 68010 UNIX box (which is now dying and being
replaced by an 80386). Suddenly cracking 8086 machine code didn't look very
interesting anymore...but if the code for both machines had been distributed
in a uMIIL, I would have had lots of incentive to *finish* the cracker.

And then I'd have given it to the world. BBSs would start swapping
comment/label databases for popular programs.  And the uMIIL-using
manufacturers' code would suddenly be naked, stripped of whatever dubious
prtection the uMIIL was supposed to get them.

Now, even if (in this uMIIL-using alternate reality) *I'd* never finished
a uMIIL Cracker *someone would have*! Machine-language distribution doesn't
concentrate the incentive to produce such a program the way a uMIIL would,
because in a uMIIL wotld the program would only have to be done *once*.

What price 'knowledge security' then? No, manufacturers are better off without
a uMIIL and *with* multiple barriers to code-cracking.

P.S. on the Cracker concept:

Does anyone know of something like this having been actually implemented?

Notice that all the code except the single-instruction disassembler
would have been machine-independent; plug in a new such routine, and you
support a new instruction set.

Since the only code the Cracker would need to be smart about was control
transfers and service-request traps, I even thought about trying to make it
table-driven from some kind of instruction-set description language.

You know, maybe I *should* go back and finish it, just as an interesting
research problem of course...
-- 
      Eric S. Raymond                     (the mad mastermind of TMN-Netnews)
      UUCP: ...!{uunet,att,rutgers}!snark!eric = eric at snark.UUCP
      Post: 22 S. Warren Avenue, Malvern, PA 19355      Phone: (215)-296-5718