From: dlv@bwalk.dm.com (Dr. Dimitri Vulis)
Date: Mon, 22 Jan 1996 03:52:38 +0800
To: cypherpunks@toad.com
Subject: Re: Wipe Swap File
In-Reply-To: <ad266bbe08021004727d@[205.199.118.202]>
Message-ID: <9oF3HD85w165w@bwalk.dm.com>
MIME-Version: 1.0
Content-Type: text/plain


tcmay@got.net (Timothy C. May) writes:
> >Degaussing the media (running a household magnet over it :-) may be an optio
>
> Ordinary household magnets fail for a couple of reasons:

I've just established experimentally that thoroughly running a household magnet
over a 3.5" floppy messed up less than 1/2 the sectors I tried to read.

Not a good option even for floppies.

(Actually, there _was a smiley up there)

> >1. Does anyone know a cheap way to recover the traces of the previous
> >(overwritten) recordings on the media?
>
> There are custom drives for various media which have multiple heads, and
> heads that can be "jogged" a little bit. This allows, I have read, the
> subtle variations of multiple writes to be extracted.
>
> Much more expensive would be various electron microscope-based imaging
> methods to directly image the domains and extract subtle signs of past
> write cycles.

I'll go on a tangent (this has more of a stego than crypto code relevance):

In the early '80s there was much activity related to floppy disk based
copy protection schemes (we got our first PC in Dec 81; most folks today
know dongles, but may not remember disk-based copy protection). The
original IBM PC came with 360K 5.25" floppy drives and a very smart
floppy disk controller chip that was capable of much more than what
the IBM BIOS normally asked of it; and even the BIOS was capable of
much more (floppy disk related) than PC DOS required.

One of the neater tricks I've seen were the so called "weak bits". One
could confuse the FDC and write a sector in such a way that when subsequently
someone read it, he saw 1's some of the times and 0's at other times.
Naturally, the FDC noted the CRC error on the sector. The copy protection
checker could read the sector several times into different buffers and see
that it got different results every time.

I rummaged around my archives and found an assembly program (about 10K)
that I once wrote (dated Jan 84) which I think did exactly this. I can
e-mail it to anyone who cares to take a look. (Disclaimer: I no longer remember
what it does, but I think this is the one with weak bits.)

I would not be very surprised if it turned out to be possible to confuse the
floppy disk controller (or some hard disk controllers) by software alone, so
that instead of operating "correctly" and reading the most recently written
data, it would operate "incorrectly" and pick up traces of the overwritten
bits from the media.

Jim Bell mentioned the trick of hiding information into 'extra' tracks and
sectors not used by the usual DOS formatting. It's very old too. I think I saw
copy protection schemes circa 1982 that hid important data on tracks 41--43.
360K diskettes normally had 40 tracks. If the diskette was copies by DISKCOPY,
it didn't know about the extra tracks, and the copy didn't have the info
(usually, a piece of the program). It's very easy to do with just BIOS calls to
format/read/write the track. Problem is, many cheap floppy drives these days
aren't capable of seeking beyond track 80 when the FDC asks them to. You can
write the data there and give the floppy to a friend who won't be able to read
it from there.

Microsoft uses a variation of this scheme when it formats its distribution
diskettes for some products with additional sectors on every track (and
presumably a smaller inter-sector gap, and good media). Some may recall that
the original PC DOS 1.x formatted disks with 8 sectors/track (for 160K/320K)
and 2.x and later started formatting 9 sectors. There was a popular hack to put
10 sectors on a track (including a DOS device driver to read such disks).
This too can be accomplished by BIOS without any FDC hacking.

(Thanks also to tallpaul for info on Vogons)

---

Dr. Dimitri Vulis
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps