[Drugwash]

Multibooter, on 05 August 2011 - 04:01 PM, said:

would it be possible to turn BootMaker into a track-0-writer for removable media

That'd be my intention but it'll take quite some time before I figure out all the tricks. The big problem is, I don't have access to any of those pieces of hardware you're talking about., so actual testing would have to be performed by people who do. All I have at hand is a floppy drive removed from an Atari before throwing it away; no idea about it since I never managed to properly connect it to a PC. The boot disk seems to be OK and I just made an image of it; it's in German though.
Don't hold your breath on the direct boot manipulation with BootMaker.

[Multibooter]

Drugwash, on 05 August 2011 - 05:07 PM, said:

Multibooter, on 05 August 2011 - 04:01 PM, said:

would it be possible to turn BootMaker into a track-0-writer for removable media

That'd be my intention but it'll take quite some time before I figure out all the tricks. The big problem is, I don't have access to any of those pieces of hardware you're talking about., so actual testing would have to be performed by people who do.

I would be glad to do some testing on my old removable drives/media, just send me a PM.

@dencorso: I posted my 5 cents at http://www.msfn.org/...post__p__973019 so that postings stay focused.

This post has been edited by Multibooter: 05 August 2011 - 06:42 PM

[dencorso]

I think, with all that's been said about it, till now, that the best divide between floppy and superfloopy remains 4.0 MiB (and no MBR nor partitions, of course).

This little beauty arrived by snail-mail yesterday. Yay!
Its true size is 125,960,192 bytes, and it's not quite empty, as there are some patterns written to many sectors, besides the skeleton MBR, PBR and FATs (which are FAT-16). The attached .7z contains a full image of it (acquired with the write lock set, so forensically sound), and a fully blank image of the same size, to help finding fast the non-zero regions, for those using Beyond Compare or analogous utilities.

Attached File(s)

•  128MB_SD.jpg (23.95K)
  Number of downloads: 3
•  20110805_128MB_SD_Card.7z (35.8K)
  Number of downloads: 6

[jaclaz]

Multibooter, on 05 August 2011 - 04:01 PM, said:

Drugwash, on 05 August 2011 - 02:12 PM, said:

Obviously, I will try my best to create a good editor... For now it can edit and save .ima images of either floppy or hard disks. ... If anyone has other suggestions, please speak up; I'd be glad to comply, if and when possible.

I like the screen shot of BootMaker. It is a little OT, but would it be possible to turn BootMaker into a track-0-writer for removable media, so that it could, for example, write/re-create track 0 on a bulk-erased/de-gaussed removable media disk, e.g. a bulk-erased LS-120 diskette? Such a tool could be very useful for re-initializing the rare special removable media of dual-format drives in general (e.g. also Floptical, Sony HiFD, Caleb UHD144).

Unless I am mistaken, we then need to draw another line.
Are we talking of a DOS track-0-writer (which is doable) or of a Windows NT one (that will get us into the drivers trouble)?

@Drugwash:
http://www.msfn.org/...98/page__st__60
and:
http://alter.org.ua/...oft/win/floppy/
JFYI.

jaclaz

This post has been edited by jaclaz: 06 August 2011 - 01:45 AM

[dencorso]

There are too many utilities that deal with reading/writing the first sector of physical devices. 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. The ability to create custom images from scratch, in a user-friendly way would also be welcome. Just my 2¢, of course. mkdosfs is limited in that it doesn't bother with creating bootable images.

[jaclaz]

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

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

• access (or any other database format)
  
• xml
  
• java
  
• .net

jaclaz

Attachment removed, see a few posts below.

This post has been edited by jaclaz: 08 August 2011 - 02:41 AM

[Multibooter]

dencorso, on 06 August 2011 - 02:18 AM, said:

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.

Quote

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.

This post has been edited by Multibooter: 07 August 2011 - 02:55 PM

[dencorso]

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?

[dencorso]

jaclaz, on 07 August 2011 - 10:43 AM, said:

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

 Clip2.jpg (60.97K)
Number of downloads: 4

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

 Clip1.jpg (40.7K)
Number of downloads: 3

The batch is quite clever, I liked it a lot!
[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.
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.

 Carrier258.jpg (63K)
Number of downloads: 7

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

Keep on the great work!
You do rock!

[Multibooter]

dencorso, on 07 August 2011 - 03:14 PM, said:

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

[dencorso]

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.

[jaclaz]

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

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

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

Since Multibooter is also around here , 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....

Quote

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

Attached File(s)

•  FAT_make_08.zip (52.18K)
  Number of downloads: 6

This post has been edited by jaclaz: 08 August 2011 - 02:54 AM

[Multibooter]

dencorso, on 08 August 2011 - 01:21 AM, said:

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.

This post has been edited by Multibooter: 08 August 2011 - 02:58 AM

[jaclaz]

Multibooter, on 08 August 2011 - 02:46 AM, said:

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?

What happens with MHDD?
http://hddguru.com/s...005.10.02-MHDD/

Or with ZAP?
http://www.digitalis...m-wipe-zap.html

Also, I would try the whole set of thingies here:
http://www.shlock.co...Utils/index.htm
the diskimg and omnidisk for DOS first

Also maybe you can create your own parameters for NFORMAT
http://toastytech.co...es/nformat.html

jaclaz

This post has been edited by jaclaz: 08 August 2011 - 03:50 AM

[dencorso]

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

[rloew]

jaclaz, on 08 August 2011 - 02:39 AM, said:

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.

Quote

About serial, is not a problem to calculate a "random one", I even have *somewhere* a (clever ) 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.

This post has been edited by rloew: 08 August 2011 - 01:23 PM

[dencorso]

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.

[dencorso]

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

 Cylinder-Sectors.jpg (8.62K)
Number of downloads: 1  HDD1.jpg (13.73K)
Number of downloads: 1

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

[Multibooter]

jaclaz, on 08 August 2011 - 03:25 AM, said:

What happens with MHDD?
http://hddguru.com/s...005.10.02-MHDD/

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.

This post has been edited by Multibooter: 09 August 2011 - 12:54 AM

[jaclaz]

rloew, on 08 August 2011 - 01:15 PM, said:

"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.alterv...B/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.

rloew, on 08 August 2011 - 01:15 PM, said:

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.forensicf...iewtopic&t=2134

jaclaz

This post has been edited by jaclaz: 09 August 2011 - 06:24 AM