dencorso

On Superfloppies and their Images

162 posts in this topic

@all

Can you please review the attached version of the spreadsheet?

I added a tentative way of "classification" and naming and an example .ini, as I am thinking we can use a .ini file to create a "database" of known formats and/or let the user choose only a subset of the available and/or have a common "interchange" format between different utilities/scripts.

Please do review the "known" values and the "ranges" besides the actual "naming proposal", and let me know of any mistake, missing piece or whatever you think about the idea. :angel

Please :), no comment/proposal involving directly or indirectly any of:

  1. access (or any other database format)
  2. xml :w00t:
  3. java
  4. .net :ph34r:

jaclaz

Attachment removed, see a few posts below.

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

There are too many utilities that deal with reading/writing the first sector of physical devices.

For regular floppies and hard disks, yes. For removable media of the "SuperFloppy" type, >2.88MB, NO. Their drives, when used internally, use the hard disk controller, not the onboard floppy disk controller.

How about experimenting with bulk-erased Iomega zip disks, to see whether any of these floppy disk utilities can write track 0 on a bulk-erased/de-gaussed Iomega zip disk? I just bulk-erased an Iomega zip disk, to see what happens. In My Computer, on the context menu of the Iomega removable drive, the selections of Iomega Format, Iomega Protect and Iomega Eject were greyed out. And the Iomega tab in the drive properties sheet displayed: Disk Type: No disk inserted, even if the de-gaussed zip disk was in the Iomega zip drive. Perhaps the de-gaussed zip disk can be revived with the manufacturer-specific Iomega SCSI Utilities under DOS. Good luck.

The Iomega zip 100 drive is single-format only, i.e. it accepts only 100MB zip disks, the drive doesn't have to decide on which type of media is inserted. On dual-format drives ( e.g. LS-120 for 1.44MB/120MB diskettes, or Caleb drives for 1.44MB/144MB diskettes) writing track 0 onto a de-gaussed diskette may be even trickier, and there are no manufacturer-provided utilties for re-initialization of diskettes, at least as far as I know.

A track-0-writer should be able to write on degaussed removable media, so that eventually any super disk image, even with changes in media type and other info on track 0, can be written back to the physical media of the appropriate capacity. If I have an image, I want to be able to write it back to the media.

It'd be much more useful to have one outstanding utility capable of writing/reading the first sector of an image and creating boot sectors and MBRs there at will. I would concentrate on that.

GRDuw can create image files of probably most removable media, but can only restore a few image types, if it likes track 0 of the image and track 0 on the target media. GRDuw, for example, cannot write back the image of a 100MB zip disk to a de-gaussed 100MB zip disk, err msg: "Checking disk media ... Please insert a disk", even if the de-gaussed zip disk was inserted.

Edited by Multibooter
0

Share this post


Link to post
Share on other sites

AFAIK, GDISK can do it on DOS, Win 9x/ME and Win XP. WinHex can do it on Win 9x/ME (sometimes) and Win XP.

Under DOS or Win 9x/ME, any fully zeroed/randomized device that Windows cannot mount but which respond to SCSI commands can be recovered by Adaptek's AFDISK 3.34. Both AFDISK and GDISK will create an MBR and a HDD structure, but that can be changed afterwards, when Windows is already capable of mounting the device, by using WinHex or any other sector editor. AFDISK 3.34 is free. Did you try it?

0

Share this post


Link to post
Share on other sites
@all

Can you please review the attached version of the spreadsheet?

I've just given your spreadsheet a try:

I found two issues right away:

(i) [minor Bug?] the dropdown menu offers *two* "FREE" options... I picked the 1st, but I suppose the other would have worked equally (I didn't try it). If so, there's no reason for two identical entries. If not, there must be made more clear which is the difference between them.

(ii) [nomenclature issue] "Sectors per Head" everywhere shouldn't be rendered as the more usual "Sectors per Track"?

I liked the way it does not impose, but just suggests sensible values, and that it goes on with the red "Calculated image size from data:", until it considers the paramenters sensible.

post-134642-0-37387700-1312753344_thumb.

I went on to create a 125,960,192 bytes, then copied the batch to notepad, saved it as batch.cmd and run it, and it gave me a perfectly sensible 42 kiB truncated image of the sought after 120 MiB FAT-12 superfloppy, named XLSimage.ima

post-134642-0-35584500-1312753331_thumb.

The batch is quite clever, I liked it a lot! :thumbup

[Caveat:] But it should warn that anything on the same directory named *.bin wil be deleted by it, with no warning...

Moreover ".bin" is a too common extension... Perhaps ".tmp" or something like ".@" might be safer?

I noticed however, that the calculated BPB values are not automagically transfered to the other pages, which do contain the bootstraps. It would be handy, because, then, a simple copy of the whole sector could be used to enable bootability. As it was, I added the first two bytes (0x33 0xC0) of the bootstrap by hand to the image, to get to a paragraph boundary, then copied all the rest as suggested, but using WinHex, instead of TinyHexer.

I then extended the truncated image to full size using WinHex, but probably DCopyNT would also have worked well. I didn't try it here, though.

I liked very much the way the spreadsheet suggests the number of directory entries to be used. :D

I think it might also suggest a Volume Serial Number. Here's a suggestion of how to do it.

The quotation below is taken from Brian Carrier's "File System Forensic Analysys", Addison-Wesley, 2005 (ISBN 0-321-26817-2) Chapter 10, p. 258.

post-134642-0-93518800-1312754305_thumb.

Here's a link to the reference cited in the above quotation: [Wilson 2003].

Keep on the great work! :yes:

You do rock! :thumbup

0

Share this post


Link to post
Share on other sites

AFAIK, GDISK can do it on DOS, Win 9x/ME and Win XP. WinHex can do it on Win 9x/ME (sometimes) and Win XP.

Under DOS or Win 9x/ME, any fully zeroed/randomized device that Windows cannot mount but which respond to SCSI commands can be recovered by Adaptek's AFDISK 3.34. Both AFDISK and GDISK will create an MBR and a HDD structure, but that can be changed afterwards, when Windows is already capable of mounting the device, by using WinHex or any other sector editor. AFDISK 3.34 is free. Did you try it?

I had tried WinHex earlier and it couldn't write to a bulk-erased LS-120 diskette.

GDisk32 requires as parameter a physical fixed disk number (1-8) http://service1.symantec.com/SUPPORT/ghost.nsf/docid/2002112213111525 That sounds more like GDisk32 doesn't work with removable media/LS-120 drives, standalone Ghost 11.0.2, for example, doesn't display removable drives, or the type "3 1/2 Inch Floppy Disk", as indicated for the LS-120 drive in My Computer. I tried "gdisk /status" under MS-DOS 6.22, but the system just hung.

AFDISK v3.34 seems to hang on my Inspiron 7500 laptop under MS-DOS 6.22, the msg "Please wait" kept on flashing for about 20 mins, until I rebooted, although there was some HDD activity. Maybe AFDISK requires an Adaptec SCSI PCI card, or a line in config.sys, or I am missing a file, no idea. AFDISK seems to be the most promising of the three.

0

Share this post


Link to post
Share on other sites

I'd say DOS 6.22 isn't a good idea. MS-DOS 7.10 from Win 98SE would be much safer. When in DOS, the DOS device driver for the LS-120 should be loaded from config.sys. On a windows DOS Box, within Win 98SE this may not be necessary, and it would be the first way I'd try. Never mind that Win 98SE is unable to mount the volume, I bet it creates the virtual SCSI device all right. Do give it a shot.

0

Share this post


Link to post
Share on other sites

@dencorso

Yes, the "FREE" options are used as "separators", to divide three "logically grouped sets":

  1. three common floppy formats (compatible with the El-torito standard)
  2. three max floppy formats (compatible with the rloew's findings on the El-Torito standard)
  3. All the rest (less common floppy formats)

*any* of them can be used, they correspond to "blank" values...

Since Multibooter is also around here :thumbup , I would ask him to post a set of the formats/sizes (and OTHER data) of the hardware he is playing with, like the LS-120/240, the 32 M floppy and the ZIP and clik (PocketZip) discs....

I liked the way it does not impose, but just suggests sensible values, and that it goes on with the red "Calculated image size from data:", until it considers the paramenters sensible.

Yes, that is what I find the most important things and that I hope Drugwash will implement in his nice tool, the problem is not really to create a bootsector BPB, but rather calculating "reasonable" (if not "right" values).

I have changed the .bin to something less common, .t#p :)

Thanks for testing, but I am interested in your (and everyone else's) ideas/comments/corrections on the "naming" and ".ini" idea.

As well, the "Sector per Head" is "intentional", since we have (on hard disks) an addressing convention called CHS (and not CTS) and AFAIK/AFAICR "Track" is used almost exclusively in conjunction with "real" floppies, I thought it to be more descriptive, but this is part of the naming convention that I would like to get a "common agreement upon", just like "Sectors Before" vs. "Hidden Sectors".

About serial, is not a problem to calculate a "random one", I even have *somewhere* a (clever :unsure:) spreadsheet I made to calculate (for forensic scopes) the probabilities of a serial to be an actually "kosher generated" one or a "random" (please read as "counterfeited" one.

Since the algorithm is (partially) reversible something can be done in that sense, but this is an alltogether different topic.

jaclaz

FAT_make_08.zip

Edited by jaclaz
0

Share this post


Link to post
Share on other sites
MS-DOS 7.10 from Win 98SE would be much safer... and it would be the first way I'd try. Never mind that Win 98SE is unable to mount the volume, I bet it creates the virtual SCSI device all right.
You were right, AFDISK came up Ok in a Win98SE DOS box, it displayed under Select SCSI Device: "HA #2 - Target 0 MATs***ALS-120 COSM 03". This was the only device displayed, I had a an LS-120 drive connected at the parallel port.

Unfortunately, when I pressed Enter to select the LS-120 drive, the following msg came up:

"!!! Unable to Partition Drive !!!

The ASPI manager controlling this device is returning a Head/Sector translation scheme which this revision of AFDISK does NOT support."

I also connected a USB LS-120 drive and a PCMCIA LS-120 drive, but AFDISK just displayed the msg :"No SCSI drives were found."

When I connected an Iomega zip 100 drive to the parallel port, with a good 100MB zip disk inside, AFDISK listed the drive as as "HA #0 - Target 6 IOMEGA ZIP 100", but when I selected it, the following msg was displayed:

"!!! ATTENTION !!!

You have selected a SCSI drive which is controlled by DOS though the Host Adapter BIOS. Use DOS FDISK and FORMAT commands to partition and format the device.

AFDISK will only allow you to view the devices partitions."

With a bulk-erased zip disk inside the Iomega zip drive, AFDISK displayed the following err msg:

"!!! ERROR OCCURRED DURING IO OPERATION !!!

Read Capacity Command. Check Status Returned. <target 6>

CDB: 25 00 00 00 00 00 00 00 00 00"

If some tool could write track 0 onto these bulk-erased removable disks, GRDuw could subsequently probably transfer the image of a good LS-120 diskette or of a good zip 100 disk to the bulk-erased LS-120/zip disk. By using the image of a virgin LS-120/zip disk, the bulk-erased disk would then be nicely re-initialized and formatted.

Edited by Multibooter
0

Share this post


Link to post
Share on other sites

If some tool could write track 0 onto these bulk-erased removable disks, GRDuw could subsequently probably transfer the image of a good LS-120 diskette or of a good zip 100 disk to the bulk-erased LS-120/zip disk. By using the image of a virgin LS-120/zip disk, the bulk-erased disk would then be nicely re-initialized and formatted.

Probably stupid question, but what happens with a "plain" dd-like tool? :unsure::whistle:

What happens with MHDD?

http://hddguru.com/software/2005.10.02-MHDD/

Or with ZAP?

http://www.digitalissues.co.uk/html/os/misc/ibm-wipe-zap.html

Also, I would try the whole set of thingies here:

http://www.shlock.co.uk/Utils/index.htm

the diskimg and omnidisk for DOS first

Also maybe you can create your own parameters for NFORMAT :unsure:

http://toastytech.com/files/nformat.html

jaclaz

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

And also try AFDISK again in true DOS, after loading the apropriate ASPI drivers.

0

Share this post


Link to post
Share on other sites

As well, the "Sector per Head" is "intentional", since we have (on hard disks) an addressing convention called CHS (and not CTS) and AFAIK/AFAICR "Track" is used almost exclusively in conjunction with "real" floppies, I thought it to be more descriptive, but this is part of the naming convention that I would like to get a "common agreement upon", just like "Sectors Before" vs. "Hidden Sectors".

"Sectors per Head" would not make much sense since that would be half of a entire Floppy Disk.

The concept of Cylinders and Heads, sometimes even Sectors, is meaningless on Hard Disks as they use Zone Recording. Even though Floppies have "Tracks", you do not address them as such in the controller. You select a Head that can access the desired Range of Tracks. This is why you have CHS not CTS.

About serial, is not a problem to calculate a "random one", I even have *somewhere* a (clever :unsure:) spreadsheet I made to calculate (for forensic scopes) the probabilities of a serial to be an actually "kosher generated" one or a "random" (please read as "counterfeited" one.

Since the algorithm is (partially) reversible something can be done in that sense, but this is an alltogether different topic.

Typically the Volume Serial number is generated from the Current Date/Time.

@all As far as the problem with Formatting LS-120 Disks, there are at least Four different situations, listed here in increasing severity:

1. Disk accessible and Mounts.

Access: Interrupts 0x13, 0x21, 0x25, 0x26

Format: Nearly any Formatter will do.

2. Disk accessible but does not Mount.

Access: Interrupt 0x13

Format: Track 0 Writer, my RFDISK.

3. Disk low level Formatted, not accessible by BIOS or Windows.

Access: Direct Port I/O

Format: Low level Disk Utilities, SCSI Tools, My RFDISK (raw mode maybe). For SCSI devices, use Command 4 (Format).

4. Disk blank, bulk-erased, or headers corrupted.

Access: Direct Port I/O maybe or Manufacturer only Connector or Rig.

Format: Depends (see below) Same as #3 if SCSI Command 4 works (A).

Possible Solutions for SCSI:

A: SCSI Format Command (4).

B: Undocumented SCSI Formatting Command (?). Manufacturer's tool may work.

C: Manufacturer's Formatting Rig.

D: Neighborhood Recycling Center.

I do not have a LS-120 so I don't know what is required but the previous Posts are not encouraging. Maybe a SCSI Mode Select Command followed by a SCSI Format Command would help.

A Track Zero Writer is not going to work on a bulk-erased Disk. Even if it could low level Format the Track you would still not be able to write anything to the rest of the Disk.

Low Level Formatting capability is built into the Floppy Controller so FORMAT can do the Low Level Formatting on the entire Disk before writing Track Zero. This is not generally the case with other

magnetic media.

Edited by rloew
0

Share this post


Link to post
Share on other sites

Perhaps DISKEDIT.EXE (from Norton Utilities 2002 ..10E) with the /M switch for the ATAPI/IDE LS-120 drive (if it's recognized by the BIOS) on true DOS or (even more delicate) on a Win 98SE DOS box, after telling it to proceed, regardless of its dire warning.

Another idea is either HDD raw Copy Tool or HDD LLF from HDDGuru. There are many possibilities with those tools, but I'd bet on SCSI mode.

0

Share this post


Link to post
Share on other sites

Even if this is nowadays not more than an intangible metaphor, for floppy disks and very old hard disks (winchester disks, remember them?) a sector is the minimum transferable data packet, a track is a collection of sectors on the same side of the disk, which are at the same distance from the center, and a cylinder is a collection of tracks of the same number throughout the different heads, so that they delineate an imaginary actual cylinder. So, a cylinder is made of tracks and a track is made of sectors. That's why it must be "Sectors per Track".

post-134642-0-74799000-1312837774_thumb. post-134642-0-45700700-1312837350_thumb.

The left-hand Figure shows reasonably well the relationship between cylinders and tracks, while the one at the right hand highlights in yellow a full track (with its respective sectors) and in blue a single sector within another track.

Now, floppy that have two sides do actually have cylinders: they are composed of the tracks of the same number on each side. Only sigle sided floppies "don't have" cylinders, or, more precisely, are in a situation where tracks = cylinders.

... of course, this is just a model, and as such, not more than a thought-aid, with little or no compromise to reproduce reality (for floppies, for instance, the actual tracks on one side are not exactly below those on the other side, but interleaved instead, in order to minimize the magnetic "print-through"), which always is more "complicated".

0

Share this post


Link to post
Share on other sites
Under DOS 6.22, with an LS-120 drive connected at the parallel port and a good LS-120 diskette inside, err msg at program start:

"* * * CATASTROPHIC FAILURE * * *

<Message>

MH_SCSIP.SDRV_INQUIRY FAIL

<End of Message>"

I guess MHDD didn't get along with the parallel port driver of the LS-120 drive, or with the IDE/ATAPI to parallel bridge by Shuttle Connection in the drive enclosure.

The manual of MHDD lists as supported hardware "Any SCSI removable media such as tape, CDROM". I would generalize that any formatting software which does not specifically mention the type of superdisk drive (e.g. LS-120, Iomega zip, Iomega jaz) in the program description or in the program menu, will not work with that particular type of superdisk drive.

@dencorso

I had tried HD LLF from HDDguru earlier, but it doesn't see an LS-120 drive at the parallel port. HD LLF is my tool of choice for wiping HDDs, that's why I tried MHDD, also for download at HDDguru, first.

Edited by Multibooter
0

Share this post


Link to post
Share on other sites

"Sectors per Head" would not make much sense since that would be half of a entire Floppy Disk.

The concept of Cylinders and Heads, sometimes even Sectors, is meaningless on Hard Disks as they use Zone Recording. Even though Floppies have "Tracks", you do not address them as such in the controller. You select a Head that can access the desired Range of Tracks. This is why you have CHS not CTS.

OK, I'll try again.

In a typical hard disk with a CHS geometry of nx255x63 in the MBR there are two fields that are normally called (see also my old page here):

http://jaclaz.altervista.org/Projects/USB/USBstick.html

bHead	
BHd
Starting Head
Starting Head
Starting Head

and

eHead	
EHd
Ending Head
Ending Head
Ending Head

in populated entries, and with the "old" alignment standard, in the "BHd" field there is normally 1 (in first partition, because of the hidden first Track ;)) or 0, whilst in the "EHd" one there is 254 (as heads are numbered in CHS starting from 0).

In the corresponding bootsector, the field "Number of Tracks" or "Number of Heads" is 255.

And two called:

bSect	
BSec
Starting Sector
Starting Sector
Starting Sect

and:

eSect	
ESec
Ending Sector
Ending Sector
Ending Sect

in populated entries, and with the "old" alignment standard, in the "BSec" field there is normally 1, whilst in the "ESec" one there is 63 (as sectors are numbered in CHS starting from 1).

In the corresponding bootsector, the field "Sectors per Track" or "Sector per Head" is 63.

To me in this context of bullding volumes that can be either a volume on Hard disk or represent a "superfloppy", a Head or a Track are exactly the same thing, for which two different names are used, one for floppies and one for Hard Disks.

The size of the volume in bytes is given by:

Bytes_per_Sector*Sectors_per_Head*Number_of_Heads

or:

Bytes_per_Sector*Sectors_per_TracK*Number_of_Heads

No problem whatsoever in naming the field "Sectors_per_ Track" :), but then also the "Number_of_Heads" should become "Number_of_Tracks", thus losing any logical connection with the MBR. :unsure:

Typically the Volume Serial number is generated from the Current Date/Time.

Sure :), dencorso already posted the algorithm used and the little spreadsheet I was talking about was a reversing of that algorithm to check if the Volume serial had been tampered with, by detecting possible dates/times that may have generated the serial and verify if they were within a possible timeframe.

This applies to DOS but NOT to NT systems, for which the algorithm is not AFAIK known.

Here are some details:

http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=2134

jaclaz

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.