Universal Disassemblers vs. Universal MIILs 
Author Message
 Universal Disassemblers vs. Universal MIILs

Quote:


>>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 {*filter*}, 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)

      Post: 22 S. Warren Avenue, Malvern, PA 19355      Phone: (215)-296-5718



Fri, 19 Mar 1993 14:22:00 GMT  
 Universal Disassemblers vs. Universal MIILs

Quote:

> [...]
>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.

> [... stuff about implications deleted ...]

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

  There's a program called "Sourceror" on the Apple ][ series, by Glen
Bredon I think.  It came with the Big Mac/Merlin assemblers.  It knew
about all Apple's ROM calls (and many DOS calls), most global
variables, the 6502 instruction set, and the "Sweet-16" pseudo-code
instruction set.
  It didn't add comments to the code, but it did take care of things
like assigning symbolic names to labels, etc. which helped a lot if
you wanted to understand programs (I used it on Applesoft BASIC, for
example).  It's a good start, anyway....

                        Anton Rang

+---------------------------+------------------------+----------------------+
| Anton Rang (grad student) | "UNIX: Just Say No!"   | "Do worry...be SAD!" |

+---------------------------+------------------------+----------------------+



Fri, 19 Mar 1993 14:52:00 GMT  
 Universal Disassemblers vs. Universal MIILs

Quote:

>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.

Quote:
>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.

Quote:
>...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 {*filter*}, 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.


Fri, 19 Mar 1993 18:18:00 GMT  
 Universal Disassemblers vs. Universal MIILs

Quote:

>>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 think the nub of the matter is that it makes disassembly more
*useful*, not any easier.

I claim that I can distribute C code to my programs and it is
completely useless.  I gave an example of this quite a while back.
I need to do things such as:

* Rename all variables.
* Hoist (inline) functions.
* Do loop transformations (e.g. for() loop to a goto loop).
* Strip out all comments.
* Run the preprocessor to remove #ifdefs  (Is this the same
  value "4" that appeared in the line before, or are they
  unrelated?)
* Avoid standard libraries.
* Do code motion.
* Delcare wasted variables, dead code, unoptimize code that
  an optimizer can put back together again later, ...

Essentially, preform all the optimizations that I can on the C source,
and  steal liberally from the Obfusacted C Code Contest.  Consider the
following (well-formated) program.  What does it do?

extern  struct  _a7F9a1Xs3 {
        int     _a7F6a1Xs3;
        char    *_a7G9a1xs3;
        char    *_a7G6a1xs3;
        int     _a7G6a1xs7;
        short   _a7F9a1xs7;
        char    _a7F9a1xf7;

Quote:
} _iob[3];

main(_a7F9a1xf3, _a7F61axf3)
    int _a7F9a1xf3;
    char *_a7F61axf3[];
{
    int _a7G61asf3, _a7G61faf3;

    goto _a7G61afx3;
  _a7G61afs3:
    exit(0), _a7G61asf3&=(0x10)+1;
  _a7G61afx3:
    ((_a7G61asf3=(--((&_iob[0]))->_a7F6a1Xs3>=0
        ? *((&_iob[0]))->_a7G9a1xs3++&0377
        :_filbuf((&_iob[0]))))
    !=(-1));
    if (_a7G61asf3*(3-1)==(0-2))  goto _a7G61afs3;
    (--((&_iob[1]))->_a7F6a1Xs3>=0
        ? ((int)(*((&_iob[1]))->_a7G9a1xs3++=(unsigned)(_a7G61asf3)))
        :_flsbuf((unsigned)(_a7G61asf3),(&_iob[1])));
    goto _a7G61afx3;
  _a7G71afs3:
    (--((&_iob[1]))->_a7F6a1Xs3>=0
        ? ((int)(*((&_iob[1]))->_a7G9a1xs3++=(unsigned)(_a7G61asf3)))
        :_flsbuf((unsigned)(_a7G61asf3),(&_iob[1])));
    exit(1);

Quote:
}

Did you guess:

#include <stdio.h>

main(argc, argv)
    int argc;
    char *argv[];
{
    int c;

    while ((c=getchar())!=EOF)
        putchar(c);

Quote:
}

Enough.

        ;-D on  ( Throw a monkey in the wrench )  Pardo
--

    {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo



Fri, 19 Mar 1993 21:52:00 GMT  
 Universal Disassemblers vs. Universal MIILs

Quote:
>P.S. on the Cracker concept:

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

Yes indeed! Some friends had this running on an Amdahl under the
Michigan Terminal System back around 1980. The disassembler was
part of a program called Glass that ran on 3270 terminals. Glass
was a "window" onto your virtual memory space. By using the PF
keys, you could "page" forward/backward in memory, or jump to
an arbitrary address. You were also able to toggle between three
display modes: EBCDIC, hex, and disassembly. Glass was aware of
the loader's symble table lookup conventions, therefore it was
capable of inserting symbolic names for system subroutines and
entry points into user loaded code. There was talk of adding
knowledge of symbolic de{*filter*} load records, but this never got
implemented.

The program was (apparently) inspired by a similar utility found
floating around SHARE someplace.

Oh yes, you could also use Glass to modify memory contents by setting
the display to hex mode, making changes to the screen, and hitting
ENTER to write the changes. There was also an undocumented PF key
combination that would invoke spells to nuke the hardware protection
bits. Given that the entire OS resided in shared virtual memory,
this feature contributed to some rather interesting evenings ... :-)

*** INLOOP PROTECTION TROUBLE SNARK
*** HELP! SNARK IN MTS!

--lyndon
--



Fri, 19 Mar 1993 07:10:00 GMT  
 Universal Disassemblers vs. Universal MIILs

                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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


Quote:
> You have described "MacNosey" for the Mac by Jasik Designs!  Check it out.

Interesting...does anybody know of a similar product for Intel-family machines?

Quote:
> Yes, this is the problem.  But the point of a MIIL is to prevent obsolete
> software, not prevent reverse engineering.

My article was in reply to a claim that a uMIIL would somehow offer better
security against what we politely call "reverse engineering" than current
machine code.

Quote:
>                                            However, the prevention of
> reverse engineering will probably be required to gain the kind of acceptance
> it needs to make an appreciable impact.

True. And this raises an insuperable problem for uMIIL proponents, because
"preventing reverse engineering" and "easy portability" are diametrically
opposing goals. The uMIIL concept seems to me to be a particularly
ill-thought-ought stab at serving both masters -- but machine-coded proprietary
software already well meets the requirements of the former and HLL source
is pretty good for the latter (modulo OS-standardization problems that any
uMIIL will *also* have).

In case it isn't obvious, I think this is yet another reason to class the
whole notion of uMIIL as a distracting red herring and forget it.
--
      Eric S. Raymond                     (the mad mastermind of TMN-Netnews)

      Post: 22 S. Warren Avenue, Malvern, PA 19355      Phone: (215)-296-5718



Fri, 19 Mar 1993 15:16:00 GMT  
 Universal Disassemblers vs. Universal MIILs
Subject: Re: Universal Disassemblers vs. Universal MIILs

Isn't a 'Universal Disassembler' what the nanotechnology people use
for reverse engineering a competitor's products?

        :-) Paul

--
Paul Campbell, UniSoft Corp. 6121 Hollis, Emeryville, Ca ..ucbvax!unisoft!paul  
Nothing here represents the opinions of UniSoft or its employees (except me)
"Gorbachev is returning to the heritage of the great Lenin" - Ronald Reagan 1988
  (then the Wasington Post attacked RR [from the right] for being a Leninist)



Fri, 19 Mar 1993 16:23:00 GMT  
 Universal Disassemblers vs. Universal MIILs

Quote:
> Essentially, preform all the optimizations that I can on the C source,
> and  steal liberally from the Obfusacted C Code Contest.

This gives me an interesting and twisted thought. Consider the following
notional man page:

--------------------------------------------------------------------------
NAME
   obfuscate -- code obfuscator for semi-secure source code distribution

SYNOPSIS
   obfuscate [file...]

DESCRIPTION
   The obfuscate tool applies transformations to a set of source files intended
to make the source unreadable as possible. The intent is to support secure
distribution of proprietary C source.

   Obfuscate begins by preprocessing the file, throwing away all information
in comments and mnemonic defines. Then it randomly renames all variables using
conventions designed to confuse the eye.

   Next, obfuscate  applies a further series of transformations we shall leave
deliberately undocumented here. Some of these are `smart' obfuscations using
source features deducible from flow analysis.

   Finally, obfuscate smashes all non-significant whitespace out of the file
and reformats it as a sequence of solid-filled 8-character lines.

   Though the output of obfuscate will always compile to the same (stripped)
object code as its input, the obfuscate algorithm is deliberately
nondetermistic; some of the transformations applied will vary randomly from
run to run.

NOTE
   To make reverse-engineering of the scramble algorithms more difficult, the
source of obfuscate is distributed in obfuscated form.
--------------------------------------------------------------------------

Maybe this is as good a secure uMIIL as we can hope for. I'd write it, but I've
got my hands full with 3.0 news and changing machines. Anybody else wanna try?
--
      Eric S. Raymond                     (the mad mastermind of TMN-Netnews)

      Post: 22 S. Warren Avenue, Malvern, PA 19355      Phone: (215)-296-5718



Fri, 19 Mar 1993 15:23:00 GMT  
 Universal Disassemblers vs. Universal MIILs
The discussions on HIMIL's, MIIL's, stopped being relevant to comp.lang.c
some time ago.

Please edit your Newsgroups lines more carefully.

Thanks,
        /rich $alz
--



Fri, 19 Mar 1993 20:18:00 GMT  
 Universal Disassemblers vs. Universal MIILs

Quote:


>P.S. on the Cracker concept:

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

Yes - I did this once. It was for Z-80 machine code, and I did it for
a Z-80 ICE for which I needed to extend its functionality. It
was pretty easy, and it was command line driven. (You would create
shell scripts containing the long command lines).

It allowed you to do things like specify what the RST instructions
were for, and allowed things like having some of the RST instructions
being followed by a byte of sub-opcode;

It allowed you to add labels (although not comments for particular lines).
Thus as you understood what parts of the code were doing you could tell
it the labels to use, and any references to that address would come out
symbolically.

Also, since its diffcult to make the machine decide whether something
is code or data, it allowed you to mark selected areas as being
tables and thus avoid disassembling it.

=====================
     //        o      All opinions are my own.
   (O)        ( )     The powers that be ...
  /    \_____( )
 o  \         |
    /\____\__/        Tel: +44 628 891313 x. 212



Fri, 19 Mar 1993 22:15:00 GMT  
 Universal Disassemblers vs. Universal MIILs

Quote:
> NAME
>    obfuscate -- code obfuscator for semi-secure source code distribution

> SYNOPSIS
>    obfuscate [file...]

Perhaps we should have a contest to see who can write the best version
of this... "The Obfuscating C Contest."

Then again, maybe not.



Fri, 19 Mar 1993 00:15:00 GMT  
 Universal Disassemblers vs. Universal MIILs
I think I saw something that was run through this program :-) while working
with a Data General Nova about 10 years ago.  The source was written in an
interpreted BASIC with lots of DG-specific extensions (there was no compiled
BASIC for that machine).  I believe that the program was a payroll package of
about 20k lines or so.  The interesting thing about the source was that all
the variable names were mixtures of "O"'s (capitol-o) and "0"'s (zeros).  It
certainly made for confusing reading.  Luckily :-), once the program was
loaded, there were handy tools which could be (mis-)used to dis-ambiguate(sp?)
the variable naming.
---

Modern Languages and Linguistics, Cornell University


Fri, 19 Mar 1993 00:18:00 GMT  
 
 [ 23 post ]  Go to page: [1] [2]

 Relevant Pages 

1. universal joins, universal stransmission shaft

2. Universal integer or universal expression

3. Universal Virtual Machine

4. OT - Conway Life Universal Computer

5. Universal Virtual Machine

6. Universal Data Cryptography Module V2.0

7. NEW: Universal Data Cryptography Module V2.0

8. Universal headers and TBFinder

9. NEW: Universal Data Cryptography Module V2.0

10. Universal Virtual Machine

11. Universal headers ?

12. CPCS Universal Report Problem

 

 
Powered by phpBB® Forum Software