Universal Disassemblers vs. Universal MIILs

Brian bcase Case bcase at cup.portal.com
Thu Oct 20 04:18:54 AEST 1988


In article <7226 at ihlpl.att.com>, knudsen at 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.



More information about the Comp.lang.c mailing list