Xref: utzoo comp.arch:6693 comp.lang.c:13348 comp.lang.misc:2007 Path: utzoo!utgpu!attcan!uunet!cbmvax!snark!eric From: eric@snark.UUCP (Eric S. Raymond) Newsgroups: comp.arch,comp.lang.c,comp.lang.misc Subject: Universal Disassemblers vs. Universal MIILs Message-ID: Date: 17 Oct 88 14:22:58 GMT References: <358@istop.ist.co.uk> <7226@ihlpl.att.com> Organization: Orbital Mind Control Satellite #17 Lines: 60 In article <7226@ihlpl.att.com>, knudsen@ihlpl.ATT.COM (Knudsen) writes: >In article , 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@snark.UUCP Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718