Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR

From: Andre Hedrick (andre@linux-ide.org)
Date: Wed Mar 07 2001 - 17:35:56 EST


So basically you are pointing out that there is now a sequencer reject in
linux? Because this used to effect and wipe drives, but you are showing
that Linux now does scsi commands check for execution on the /dev/sdxx?

On Wed, 7 Mar 2001, Craig Ruff wrote:

> On Wed, Mar 07, 2001 at 01:15:46PM -0800, Andre Hedrick wrote:
> >
> > Then run this and see if you live.
>
> Well, I ran it, the disk lives. The typescript is appended below.
> Interestingly, scsikiller didn't cream the partition table like I
> expected. However the dd if=/dev/zero of=/dev/sdc certainly did.
>
> I've been using dd to copy entire disks for 18 years. Not just SCSI,
> but SMD, IPI and IDE. I've never had a problem with multi-sector writes
> starting at any sector on drives. Unless there is a bug in the
> drive's firmware, about the only thing you can do software wise to
> a SCSI disk is to interrupt a format command, which can leave things
> messed up a bit until the next format.
>
>
> Script started on Wed Mar 7 14:55:00 2001
> bells# fdisk /dev/sdc
>
> Command (m for help): p
>
> Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
> Units = cylinders of 16065 * 512 bytes
>
> Device Boot Start End Blocks Id System
> /dev/sdc1 1 553 4441941 83 Linux
>
> Command (m for help): q
>
> bells# dd if=/dev/sdc of=sdc.part bs=512 count=1
> 1+0 records in
> 1+0 records out
> bells# cat scsikiller.c
> /* scsikiller.c */
> #include <sys/ioctl.h>
> #include <sys/fcntl.h>
> #include <scsi/scsi.h>
>
> struct cdb6hdr{
> unsigned int inbufsize;
> unsigned int outbufsize;
> unsigned char cdb [6];
> } __attribute__ ((packed));
>
> int main (int argv, char **argc)
> {
> int fd;
> unsigned char tBuf[526];
> struct cdb6hdr *ioctlhdr;
>
> if (argv != 2) exit(-1);
>
> fd = open (*(argc+1), O_RDWR );
> if (fd < 0) exit (-1);
>
> memset(&tBuf, 0, 526);
>
> ioctlhdr = (struct cdb6hdr *) &tBuf;
>
> ioctlhdr->inbufsize = 512;
> ioctlhdr->outbufsize = 0;
> ioctlhdr->cdb[0] = WRITE_6;
> ioctlhdr->cdb[4] = 1;
>
> return ioctl(fd, 1, &tBuf);
> }
> bells# cc -o scsikiller scsikiller.c
> bells# scsikiller /dev/sdc
> bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
> 100+0 records in
> 100+0 records out
> bells# fdisk /dev/sdc
>
> Command (m for help): p
>
> Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
> Units = cylinders of 16065 * 512 bytes
>
> Device Boot Start End Blocks Id System
> /dev/sdc1 1 553 4441941 83 Linux
>
> Command (m for help): q
>
> bells# dd if=sdc.part of=/dev/sdc
> 1+0 records in
> 1+0 records out
> bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
> 100+0 records in
> 100+0 records out
> bells# dd if=/dev/zero of=/dev/sc bs=512 count=100
                         ^^^^^^^^^^
I assume typo ??

> 100+0 records in
> 100+0 records out
> bells# fdisk /dev/sdc
> Device contains neither a valid DOS partition table, nor Sun or SGI disklabel
> Building a new DOS disklabel. Changes will remain in memory only,
> until you decide to write them. After that, of course, the previous
> content won't be recoverable.
>
>
> Command (m for help): q
>
> bells# dd if=sdc.part of=/dev/sdc
> 1+0 records in
> 1+0 records out
> bells# fdisk /dev/sdc
>
> Command (m for help): p
>
> Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
> Units = cylinders of 16065 * 512 bytes
>
> Device Boot Start End Blocks Id System
> /dev/sdc1 1 553 4441941 83 Linux
>
> Command (m for help): q
>
> bells# ^Dexit
>
> Script done on Wed Mar 7 14:57:35 2001
>

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035 Web: www.aslab.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Mar 07 2001 - 21:00:24 EST