35C3: A Deep Dive into DOS Viruses and Pranks

Oh, the hijinks that the early days of the PC revolution allowed. Back in the days when a 20MB hard drive was a big deal and MS-DOS 3.1 ruled over every plain beige PC-clone cobbled together by enthusiasts like myself, it was great fun to “set up” someone else’s machine to do something unexpected. This generally amounted to finding an unattended PC — the rooms of the residence hall where I lived in my undergrad days were a target-rich environment in this regard — and throwing something annoying in the AUTOEXEC.BAT file. Hilarity ensued when the mark next booted the machine and was greeted with something like an inverted display or a faked hard drive formatting. Control-G was good to me too.

So it was with a sense of great nostalgia that I watched [Ben Cartwright-Cox]’s recent 35C3 talk on the anatomy and physiology of viruses from the DOS days. Fair warning to the seasoned reader that a sense of temporal distortion is inevitable while watching someone who was born almost a decade after the last meaningful release of MS-DOS discuss its inner workings with such ease. After a great overview of the DOS API elements that were key to getting anything done back then, malware or regular programs alike, he dives into his efforts to mine an archive of old DOS viruses, the payloads of most of which were harmless pranks. He built some tools to find viruses that triggered based on the system date, and used an x86 emulator he designed to test every day between 1980 and 2005. He found about 10,000 malware samples and explored their payloads, everything from well-wishes for the New Year to a bizarre foreshadowing of the Navy Seal Copypasta meme.

We found [Ben]’s talk a real treat, and it’s good to see someone from the current generation take such a deep dive into the ways many of us cut our teeth in the computing world.

Continue reading “35C3: A Deep Dive into DOS Viruses and Pranks”

Tiny Ray Tracer Fits In 64 Bytes

Throughout human history, people try to make the biggest, the fastest, and — sometimes — the smallest. [Hellmood] falls into the latter category and proves it with a 64 byte interactive 3D raycasting application for MSDOS.

Why MSDOS? We suppose why not? The .COM file format is lean, and you can take over everything without a lot of work. If the program were huge, it wouldn’t be very impressive. There are 64 shades of gray which is odd looking these days, however there are versions that use various color palettes and each one fits in 64 bytes or less. There’s even mouse control and you can see the results in the video below.

Continue reading “Tiny Ray Tracer Fits In 64 Bytes”

Recovering Data From A Vintage MFM Drive

Even if you aren’t a vintage computer aficionado, you’re probably aware that older computer hard drives were massive and didn’t hold much data. Imagine a drive that weighs several pounds, and only holds 1/1000th of what today’s cheapest USB flash drives can. But what you might not realize is that if you go back long enough, the drives didn’t just have lower capacity, they utilized fundamentally different technology and relied on protocols which are today little more than historical footnotes.

A case in point is the circa 1984 Modified Frequency Modulation (MFM) drive which [Michał Słomkowski] was tasked with recovering some files from. You can’t just pop this beast into a USB enclosure; copying files from it required an interesting trip down computing’s memory lane, with a sprinkling of modern techniques that are sure to delight hackers who still like to dip their toes into the MS-DOS waters from time to time.

The drive, a MiniScribe 2012, has its own WD1002A-WX1 8-bit ISA controller card. [Michał] is the kind of guy who just so happens to have an ISA-compatible AT motherboard laying around, but he didn’t have the correct cooler for its Pentium processor. He stuck a random heatsink down onto it with a rubber band and set the clock speed as low as possible, which worked well enough to get him through the copying process.

Not wanting to fiddle with floppies, [Michał] then put together a setup which would let him PXE boot MS-DOS 6.22 under Arch Linux. He used PXELINUX, part of the syslinux package, and created an entry for DOS in the configuration file under the pxelinux.cfg directory. He then installed netboot which combines a DHCP and TFTP server into one simple package, and configured it for the MAC address of the AT machine’s 3com 3C905C-TXM network card.

With the hardware and operating system up and running, it was just a matter of getting the files off of the MFM drive and onto something a bit more contemporary. He tried to copy them to a secondary IDE drive, but it seemed there was some kind of conflict as both drives wouldn’t operate at the same time. So he pulled another solution from his bag of tricks: using a USB mass storage device on MS-DOS. By emulating a SCSI drive, he was able to get a standard flash drive plugged into a PCI USB card working, which ultimately dragged these ~35 year old files kicking and screaming into the 21st century.

We love keeping old hardware alive here at Hackaday, and documented methods to not only PXE boot DOS but use USB storage devices when you get it up and running will hopefully inspire some more hackers to blow the dust off that old 386 in the attic.

Microsoft Releases Crown Jewels — From 1982!

If you look back 30 or so years ago, it wasn’t clear what was going to happen with personal computers. One thing most people would have bet on, though, was that CP/M — the operating system from Digital Research — would keep growing and power whatever new machines were available. Except it didn’t. MS-DOS took over the word and led — eventually — to the huge number of Windows computers we know today. Microsoft has released the source code to MS-DOS 1.25 and 2.0 on GitHub.

Microsoft — then another fledgling computer company — had written some BASIC interpreters and wanted in on the operating system space. They paid the princely sum of $75,000 to Seattle Computer Products for something called QDOS written by [Tim Paterson]. Rebranded as MS-DOS, the first version appeared in late 1981 and version 1.25 was out about a year later.

While you might not think having MS-DOS source code is a big deal, there’s still a lot of life left in DOS and it is also interesting from an educational and historical perspective. If you don’t want to read x86 assembly language, there’s also the BASIC source for the samples (paradoxically, in the bin subdirectory) along with compiled COM files for old friends like EDLIN and DEBUG.

Continue reading “Microsoft Releases Crown Jewels — From 1982!”

PC-XT Emulator On ESP8266

Do you remember the simpler times when you had a DOS command line, a handful of commands, and you talked to the hardware through a few BIOS and DOS interrupts? Okay, maybe it was a little limited, but nostalgia doesn’t care. Now [mcuhacker] is working on bringing some of those memories back by getting a PC-XT emulator running on an ESP8266.

For the x86 CPU emulator, he ported Fake86 which is written in C, and created an Arduino IDE environment for it. The MS-DOS 3.3 bootdisk image is stored in flash and is accessed as the A: drive. There’s no keyboard yet but he has 640×200 CGA working with 80×25 characters on a 3.5″ TFT display with the help of a low pass filter circuit. In the video below he shows it booting to the point where it asks for the date.

Continue reading “PC-XT Emulator On ESP8266”

The IBM PC That Broke IBM

It was the dawn of the personal computer age, a time when Apple IIs, Tandy TRS-80s, Commodore PETs, the Atari 400 and 800, and others had made significant inroads into schools and people’s homes. But IBM, whose name was synonymous with computers, was nowhere to be seen. And yet within a few years, the IBM PC would be the dominant player.

Those of us who were around at the time cherished one of those early non-IBM computers, and as the IBM PC came out, either respected it, looked down on it, or did both. But now, unless your desktop machine is a Mac, you probably own a computer that owes its basic design to the first IBM PC.

The Slow Moving Elephant

IBM System/360 Model 30 mainframe
IBM System/360 Model 30 mainframe by Dave Ross CC BY 2.0

In the 1960s and 1970s, the room-filling mainframe was the leading computing platform and the IBM System/360 held a strong position in that field. But sales in 1979 in the personal computer market were $150 million and were projected to increase 40% in 1980. That was enough for IBM to take notice. And they’d have to come up with something fast.

Fast, however, wasn’t something people felt IBM could do. Decisions were made through committees, resulting in such a slow decision process that one employee observed, “that it would take at least nine months to ship an empty box.” And one analyst famously said, “IBM bringing out a personal computer would be like teaching an elephant to tap dance.”

And yet, in just a few short years, IBM PCs dominated the personal computer market and the majority of today’s desktops can trace their design back to the first IBM PC. With even more built-in barriers which we cover below, how did the slow-moving elephant make this happen?

Continue reading “The IBM PC That Broke IBM”

Hacking a parallel port flash memory programmer

[Pulko Mandy] doesn’t use his flash ROM programmer very often, but he does use it. When he tried to get support for a new chip and the manufacturer suggested he just buy a newer version he decided to hack the programmer and it’s software instead.

This device connects to the parallel port and was intended for use with MS-DOS systems (no wonder there’s no longer support from the company). The board uses logic chips to add read and write function. So the first step was to analyze how they connect together and come up with a set of commands. While at it he also made some changes to the board to bring the voltage more in spec and ensure the logic levels on the parallel port met the correct voltages.

His plan was to use the board with a Linux system so the parallel port interface can stay. He used what he learned from the hardware inspection to write his own interface in C++. It works with a chip he was able to use under the MS-DOS software, but he hasn’t gotten it to work with the chip that sparked this adventure. If you’re familiar with how the AT29C040A works please consider lending a hand.