Can a floppy disk be traced back to a specific computer?

  • Thread starter Thread starter Jimmy Hoffa
  • Start date Start date
J

Jimmy Hoffa

I saw a story on television last night about the BTK serial killer.
The reporter said that the killer was caught because he sent in a floppy
disk and floppy disks have code written to them that identifies the computer
that the floppy was written on. The story didn't specify whether the code
is written to the floppy during formatting or during a normal write
operation. Is this true?

J.H.
 
Nope, the volume serial number, etc. is useless for tracing.

Office documents include GUIDs based on the 48-bit MAC address.
 
In comp.sys.ibm.pc.hardware.storage Jimmy Hoffa said:
I saw a story on television last night about the BTK serial killer.
The reporter said that the killer was caught because he sent in a floppy
disk and floppy disks have code written to them that identifies the computer
that the floppy was written on. The story didn't specify whether the code
is written to the floppy during formatting or during a normal write
operation. Is this true?
J.H.
Click to expand...

As usual, it depends. I'll try to break it down:

1. Space to store something:

There is space in the boot-sector of a floppy for information.
It does hold some structural info about the floppy and the actual
boot code, if present.

As a consequence in a non-bootable floppy there is around 300 bytes
free space. In a bootable floppy there is less, depending on the boot
loader code.

So there _is_ space. However the boot sector is the only safe space
that can be used for this type of information.

2. "identifies the computer" and how to trace that identity:

There are devices in a modern computer that have unique serial
numbers that can be read by the OS. There are also possible temporary
values that are unique at one point in time. Examples are HDD serial
number, MAC address of the network card and (possibly temporary)
IP address. Also there is a GUID (Globallu Unique ID)
windows generates on installation.

The only one of these relatively easy to trace is the IP address,
and the GUID. It is possiblethat the GUID gets transmitted to MS
on every update and can then be tied to an IP address. Also remember
that you have to register your OS with MS today.

3. When is something stored and what code does it:

On formatting there is a chance that the GUID of the OS is
written to the floppy, I don't know what Windows does.
Maybe somebody else here knows...

On normal floppy access nothing is written to the boot sector.
Nothing is written to identify the accessing computer.

The only two possibilities I see is spyware (never heard of
one that writes any computer ID on the floppy) and the
ID being in, e.g., a MS word document. They contain all
kinds of information that is not supposed to be in a
text file, e.g. the mentioned GUID.


Bottom line:

For a MS box I consider it possible to identify the computer the
floppy was formatted on and it may be easy to identify the computer
a MS word document was created on or worked on.

On the other hand an ASCII file written on a preformatted
floppy or one formatted, e.g., on a Linux box would likely
be impossible to trace.

I consider it far more likely that they identified the computer
from a file and not from the floppy.

Arno
 
Arno Wagner said:
As usual, it depends. I'll try to break it down:

1. Space to store something:

There is space in the boot-sector of a floppy for information.
It does hold some structural info about the floppy and the actual
boot code, if present.

As a consequence in a non-bootable floppy there is around 300 bytes
free space. In a bootable floppy there is less, depending on the boot
loader code.

So there _is_ space. However the boot sector is the only safe space
that can be used for this type of information.
Click to expand...

Actually there is more room for data on floppies than the above. A sector
doesn't consist of just 512 bytes but has a preamble that is seen by the
controller and serves to locate the sector CHS, the sector size, and for ECC.
The CHS data and size is written when unconditionally formatting the floppy and
the CRC is re-written by the controller on every "write" to the sector.

The above data occupies just a few bytes of the preamble section which has ample
spare space for extra sectors on the track. Old timers may remember FDFORMAT, a
utility by Christoph H. Hochstaeter that allows formatting floppies to smaller
or larger capacity than the default, by changing the number of sectors per track
and adding extra tracks.

Old timers may also remember the software copy protection schemes that were
based on non-standard tracks that were deliberately created to protect from
software piracy. Both features are based on manipulating data structures that
cannot be accessed normally by the user.

Yet there is no computer-specific data in the preamble area.
2. "identifies the computer" and how to trace that identity:

There are devices in a modern computer that have unique serial
numbers that can be read by the OS. There are also possible temporary
values that are unique at one point in time. Examples are HDD serial
number, MAC address of the network card and (possibly temporary)
IP address. Also there is a GUID (Globallu Unique ID)
windows generates on installation.

The only one of these relatively easy to trace is the IP address,
and the GUID. It is possiblethat the GUID gets transmitted to MS
on every update and can then be tied to an IP address. Also remember
that you have to register your OS with MS today.

3. When is something stored and what code does it:

On formatting there is a chance that the GUID of the OS is
written to the floppy, I don't know what Windows does.
Maybe somebody else here knows...
Click to expand...

It does nothing of the sort.
On normal floppy access nothing is written to the boot sector.
Nothing is written to identify the accessing computer.

The only two possibilities I see is spyware (never heard of
one that writes any computer ID on the floppy) and the
ID being in, e.g., a MS word document. They contain all
kinds of information that is not supposed to be in a
text file, e.g. the mentioned GUID.
Click to expand...

If the floppy wasn't pre formatted and out of the box, then it may have
contained erased data that could link the floppy to the computer on which it was
processed. Whether computer specific or not depends on the exact nature of such
data, if there was any.
Bottom line:

For a MS box I consider it possible to identify the computer the
floppy was formatted on
Click to expand...

There is nothing computer specific in the formatting process.
and it may be easy to identify the computer
a MS word document was created on or worked on.
Click to expand...

Identify the PC, once it is in the hands of the investigator, yes. Easy? Far
from it.
On the other hand an ASCII file written on a preformatted
floppy or one formatted, e.g., on a Linux box would likely
be impossible to trace.
Click to expand...

Plain formatting of a floppy doesn't erase the data area, it just clears the
root directory and the FAT. To clear the entire data area use FORMAT /U
(unconditional formatting).
I consider it far more likely that they identified the computer
from a file and not from the floppy.
Click to expand...

I wouldn't entirely exclude the floppy option.

Regards, Zvi
 
Plain formatting of a floppy doesn't erase the data area, it just clears the
root directory and the FAT. To clear the entire data area use FORMAT /U
(unconditional formatting).
Click to expand...

The /U format option is only available with DOS/Win9x/ME. NT/2K/XP
don't support it, although it won't complain about seeing the /U either.
If NT/2K/XP can read data, it will simply clear the directory info and
do a read scan. Only if it's blank or unreadable will it do a true low-
level format. I've had corrupted floppies where I've had to use an old
Win98 computer to force a format on becuase 2K would either just fail or
get stuck.
 
Andrew Rossmann said:
The /U format option is only available with DOS/Win9x/ME.
Click to expand...

True. I dropped that detail when proof-reading my post before sending it, to not
clutter it with excess of details. ;)
NT/2K/XP
don't support it, although it won't complain about seeing the /U either.
If NT/2K/XP can read data, it will simply clear the directory info and
do a read scan. Only if it's blank or unreadable will it do a true low-
level format. I've had corrupted floppies where I've had to use an old
Win98 computer to force a format on becuase 2K would either just fail or
get stuck.
Click to expand...

I mentioned this before, in the context of ResQfloppy, a utility I wrote to
recover damaged floppies ( http://www.resq.co.il/iv_tools.php#Resqfloppy ). The
text file packed with the utility suggests: "It is preferable to use RESQFLPY
from *plain true DOS*, not to confuse with the DOS shell opened in Windows,
available only on Windows 9x platforms."

The next time you face a problem with a marginal floppy, start your Win 9x box
in command prompt mode and work from the command line. There is a big
difference how floppies are accessed under true DOS or Windows DVM. There is no
much difference between how the DOS capable Win 32 OS (Win 9x/ME) do it and the
NT derived OS (NT/W2K/XP).

Regards, Zvi
 
The /U format option is only available with DOS/Win9x/ME. NT/2K/XP
don't support it, although it won't complain about seeing the /U either.
If NT/2K/XP can read data, it will simply clear the directory info and
do a read scan. Only if it's blank or unreadable will it do a true low-
level format. I've had corrupted floppies where I've had to use an old
Win98 computer to force a format on becuase 2K would either just fail or
get stuck.
Click to expand...

Well, yes. A plain stupid optimisation on MS's part, given that
flopies are not that reliable. In recovery of overwritten data is
possible on floppies.

Arno
 
Andrew Rossmann said:
The /U format option is only available with DOS/Win9x/ME. NT/2K/XP
don't support it, although it won't complain about seeing the /U either.
If NT/2K/XP can read data, it will simply clear the directory info and
do a read scan. Only if it's blank or unreadable will it do a true low-
level format. I've had corrupted floppies where I've had to use an old
Win98 computer to force a format on becuase 2K would either just fail or
get stuck.
Click to expand...
Given that the format command accepts /U, you would expect it to work. Stupid
MS. All those floppies I threw away were probably good.

The IOCTL_DISK_FORMAT_TRACKS exists in every version of NT, is documented in
Platform SDK, but nothing uses it? Another utility to write...
 
Given that the format command accepts /U, you would expect it to work. Stupid
MS.
Click to expand...

Don't take anything for granted. ;-) I just tried FORMAT /U from an XP dropped
CMD shell on used floppies in good condition (readable) and guess what ... they
were unconditionally formatted including the data area (all data sectors were
filled with the F6 byte)!
All those floppies I threw away were probably good.
Click to expand...

They were marginal, at least and they would have failed, eventually.
The IOCTL_DISK_FORMAT_TRACKS exists in every version of NT, is documented in
Platform SDK, but nothing uses it? Another utility to write...
Click to expand...

It works fine for floppy standard formats. Yet it doesn't work for non-standard
values in the format tables. Checked!

Regards, Zvi
 
Thanks Eric, Arno, Zvi, Andrew, for the replies.

Is the same true for other removable media?
(CDR, CDRW, DVD, Zip, etc.)

J.H.
 
In comp.sys.ibm.pc.hardware.storage Jimmy Hoffa said:
Thanks Eric, Arno, Zvi, Andrew, for the replies.
Click to expand...
Is the same true for other removable media?
(CDR, CDRW, DVD, Zip, etc.)
Click to expand...

The sofwrare discussion basically applies as well except that the
writable CD/DVD formats cannot or cannot easily be written after they
are "closed". And of course they can only be written in a burner.

Zip, DVD-RAM, MOD, removable Harddrives, etc. are basically all
harddrives. In routine operation no identification of the accessing PC
is written to the administrative areas of the filesystems. Biggest
risk is likely again non-cleartext file fromats that can (and often
do) contain more information that the user thinks.

Regards,
Arno
 
Back
Top