I've inserted a NEW, FRESH HDD, installed DOS from CD. And now MEM says 640K.
So... It is was a virus, right? A 6K virus.

Guess I'm gonna need dd soon.

Malware...whether virus or rootkit, who knows? Glad you got it figured out though!

Whatever media you used to install the infected DOS needs to be doused in lighter fluid and made into a bonfire.

Thanks a lot, really.

Hey, where exactly such viruses can "live" except HDD in 486 systems?
Can they "save" their code somewhere in CMOS or something like that?

Master boot record. That would be a rootkit.

Just an idea, but 6KB sounds like about the ballpark RAM usage for a drive overlay . Could it be that possible that the drive you were previously has a rather buggy one ?

clueless1 wrote:

Master boot record. That would be a rootkit.

To be clear, no one called it a "rootkit" back in the day; the concept in general doesn't really seem suited to a single-tasking OS like MS-DOS. I would just call it a boot sector virus.

Generally such things can be safely and quickly disposed of by running "fdisk /mbr", which rewrites the master boot record. I suppose there could be viruses that detect when something is trying to rewrite the boot record, or that infect fdisk.exe. Seems unlikely, though.

Back in the day, there was at least one virus that could potentially attack the BIOS, but there's no way a copy of the virus could actually get stored there.

darry wrote:

Just an idea, but 6KB sounds like about the ballpark RAM usage for a drive overlay . Could it be that possible that the drive you were previously has a rather buggy one ?

This.

I was using EZ-Drive on my previous 486 build. When I upgraded to a PCI 486 board with a 5x86, I didn't bother to remove the overlay because "if it's working, don't fuck with it."

About a year later, I tried to play Space Quest 6, specifically the Windows version. I had no end of problems. Video for Windows would crash, INSTALL.EXE would crash, the game would install but crash on trying to run (and after such a crash, no other program would launch until you rebooted).

I tried swapping video cards, thinking later drivers could contain Pentium-specific instructions. I tried swapping RAM, sound cards, CPUs, you name it.

In a final act of desperation, I did a complete FDISK /MBR, repartition, reformat, and reinstall. POOF. Problem solved.

Jorpho wrote:

clueless1 wrote:

Master boot record. That would be a rootkit.

To be clear, no one called it a "rootkit" back in the day; the concept in general doesn't really seem suited to a single-tasking OS like MS-DOS. I would just call it a boot sector virus.

Good point. Didn't many BIOSes have Boot Sector Virus detection built into them as a consequence? I seem to remember that being a common BIOS option for quite awhile starting in the mid-to-late 90s.

SquallStrife wrote:

This. […]
Show full quote

darry wrote:

Just an idea, but 6KB sounds like about the ballpark RAM usage for a drive overlay . Could it be that possible that the drive you were previously has a rather buggy one ?

This.

I was using EZ-Drive on my previous 486 build. When I upgraded to a PCI 486 board with a 5x86, I didn't bother to remove the overlay because "if it's working, don't fuck with it."

About a year later, I tried to play Space Quest 6, specifically the Windows version. I had no end of problems. Video for Windows would crash, INSTALL.EXE would crash, the game would install but crash on trying to run (and after such a crash, no other program would launch until you rebooted).

I tried swapping video cards, thinking later drivers could contain Pentium-specific instructions. I tried swapping RAM, sound cards, CPUs, you name it.

In a final act of desperation, I did a complete FDISK /MBR, repartition, reformat, and reinstall. POOF. Problem solved.

I seem to recall seeing similar behaviour a few times when I migrated a hard disk from a system where I manually entered C/H/S and brought it up in a system that auto-detected it. A difference in the specified settings caused a lot of weird errors.

clueless1 wrote:

Didn't many BIOSes have Boot Sector Virus detection built into them as a consequence? I seem to remember that being a common BIOS option for quite awhile starting in the mid-to-late 90s.

There was something called "ChipAwayVirus", but I was never particularly clear as to what good it actually did. (If it was particularly effective, I would have expected it to be more widespread.)

I think what the BIOS virus protection option did was write-protect the boot sector, but I think it got in the way of people doing clean installs or setting up a multi-boot system, so they disabled the option by default, then eventually got rid of it.

clueless1 wrote:

I think what the BIOS virus protection option did was write-protect the boot sector, but I think it got in the way of people doing clean installs or setting up a multi-boot system, so they disabled the option by default, then eventually got rid of it.

Interesting. I was always wonder what this "BIOS virus protection" option exactly does.

btw "FDISK /MBR" command in MS-DOS 6.22 / Win98SE installation boot does nothing.

I've cleaned my MBR using this:

C:\> debug
-F 9000:0 L 200 0
-a
0C5A:0100 Mov dx,9000
0C5A:0103 Mov es,dx
0C5A:0105 Xor bx,bx
0C5A:0107 Mov cx,0001
0C5A:0109 Mov dx,0080
0C5A:010A Mov ax,0301
0C5A:010D Int 13
0C5A:0110 Int 20
<press Enter twice>
-u 100 L 12 <check the code matches the above>
-g <executes>

Program terminated normally
-quit

What do those debug commands do? I mean, what are those commands doing specifically?

xstraski wrote:

btw "FDISK /MBR" command in MS-DOS 6.22 / Win98SE installation boot does nothing.

Nonsense.

xstraski wrote:

btw "FDISK /MBR" command in MS-DOS 6.22 / Win98SE installation boot does nothing.

It doesn't produce a visible result on the command line, if that's what you mean. But it definitely does something.

I've cleaned my MBR using this: […]
Show full quote

I've cleaned my MBR using this:

C:\> debug
-F 9000:0 L 200 0
-a
0C5A:0100 Mov dx,9000
0C5A:0103 Mov es,dx
0C5A:0105 Xor bx,bx
0C5A:0107 Mov cx,0001
0C5A:0109 Mov dx,0080
0C5A:010A Mov ax,0301
0C5A:010D Int 13
0C5A:0110 Int 20
<press Enter twice>
-u 100 L 12 <check the code matches the above>
-g <executes>

Program terminated normally
-quit

Whatever works for you, I guess, but I would be gravely concerned about mistyping a single number and torpedoing my entire disk structure.