From: Jim Gillogly <jim@acm.org>
To: cypherpunks@toad.com
Message Hash: c6c1e0b0a1188d3efb5cbdea3a03d2c28722672df9c1537b28246ec288628ef5
Message ID: <199412200211.SAA28060@mycroft.rand.org>
Reply To: <199412200132.RAA12865@hot.ee.lbl.gov>
UTC Datetime: 1994-12-20 02:15:59 UTC
Raw Date: Mon, 19 Dec 94 18:15:59 PST
From: Jim Gillogly <jim@acm.org>
Date: Mon, 19 Dec 94 18:15:59 PST
To: cypherpunks@toad.com
Subject: Re: Hiding strings in objects code
In-Reply-To: <199412200132.RAA12865@hot.ee.lbl.gov>
Message-ID: <199412200211.SAA28060@mycroft.rand.org>
MIME-Version: 1.0
Content-Type: text/plain
> Jef Poskanzer <jef@ee.lbl.gov> writes:
> When rtm used this technique in his worm I'm sure a lot of people,
> such as myself, spent the five minutes necessary to hack up a program
> that tries XORing the input with all 256 possible bytes. I had the
> program pipe the output of each try through strings and wc, to check
> whether any significant text was uncovered. Only 0x00 and the single
> now-forgotten value he used got hits - no second XOR value.
Yes, I did too -- it was 0x81. I think my message of worm passwords was
the first to make it out, along with my Perl script to try out your own
password file. Yes, Perl was already around.
What method you use in your program depends on your model of your
opponent. If it's somebody only mildly interested, flipping the bits is
fine. For a slightly higher level of anxiety, you could use Vigenere-like
stuff -- XORing with a short key (8 bytes at a time with long longs if
you're in gcc, for example), or use a longer key and restart now and then
(interrupted key). For the next higher level, you might use DES and hide
the key in your data, making them disassemble it. Next step... make your
code obscure. After that... hardware.
You might want to study some virus code to see how they try to thwart
disassemblers and debuggers.
YMMV.
Jim Gillogly
Mersday, 30 Foreyule S.R. 1994, 02:06
Return to December 1994
Return to “Jim Gillogly <jim@acm.org>”