Xref: utzoo comp.arch:6727 comp.lang.c:13390 comp.lang.misc:2012 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!vsi1!altnet!uunet!portal!cup.portal.com! From: bcase@cup.portal.com (Brian bcase Case) Newsgroups: comp.arch,comp.lang.c,comp.lang.misc Subject: Re: Universal Disassemblers vs. Universal MIILs Message-ID: <10191@cup.portal.com> Date: 19 Oct 88 18:18:54 GMT References: <358@istop.ist.co.uk> , knudsen@ihlpl.ATT.COM (Knudsen) writes: >And distributing a uMIIL isn't going to make automatic disassembly *easier*? This, I think, is the one real hurdle is getting a the MIIL concept accepted. >I once started writing a smart disassembler for 8086 code, ... recognize >illegal instructions, flow-of-control analysis on jumps and assign symbolic >labels. 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 have described "MacNosey" for the Mac by Jasik Designs! Check it out. >...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. And the uMIIL-using >manufacturers' code would suddenly be naked, stripped of protection... Yes, this is the problem. But the point of a MIIL is to prevent obsolete software, not prevent reverse engineering. However, the prevention of reverse engineering will probably be required to gain the kind of acceptance it needs to make an appreciable impact.