This brings back fond memories. It's been a _long_ time since then, and I was about 14yo. This was pre-internet, the BBS era. My computer, an old PC XT, 8086 based. I was getting new software via mail order from various specialized magazines, or from BBS's (to which I did not have access directly at that time -- not particularly relevant to this story).
One day, I got something infected with a virus named Romania.856 (I will always remember this name), a COM infector, as I found out from F-Prot Antivirus (which came with a great db with information about viruses -- such a great read for the young me!).
The tools available to me were still very limited; I had not yet discovered TDD (Borland Turbo Debugger). But I was dead set to understand how the virus worked. There I was, using the very limited `debug` tool that came with MS-DOS. I've learned x86 Assembler from various texts downloaded from BBS's. I reverseengineered Romania.856, and learned how it worked, and did my own experiments. That's how I spent my summer vacation that year.
This was the beginning of some of the most beautiful years of my life, with regard to computers. It lasted for a bit over half a decade, time in which tech evolved fast, I got an internet connection (still dialup back then), I discovered IRC, met people with similar interests and so on. What I miss the most now is the feeling of everything being new, the possibility for exploration and discovery.
> I got something infected with a virus named Romania.856 (I will always remember this name)
For me it was Tai-Pan.438.A. I printed out(!) the disassembly code and studied it for weeks. I remember the stack modifications (not matching push/pop instructions) were super troubling for me to understand because such tricks were not really explained it the normal books.
It was doing push/ret, ie. pushing stuff (addresses) and then returning to the pushed address. Or popping stuff without pushing before (saving the return address of something) and storing it somewhere.
That is of course perfectly legal, but not something you see in normal programs. In the end, it really helping me to understand how the stack works, but the first time I saw it, it was super confusing.
What a great talk, loved everything about that era.
When I was 14 I made my first virus/prank. It would increment a counter every time input was sent to the PS/2 port, ie. keyboard. Once it hit 2000 strokes it would switch to 80x50 textmode, print "This is a shareware keyboard. You have used all of your free keystrokes" and then close the PS/2 connection until a physical reboot.
I thought it was hilarious, but it did have some unintended consequences. Especially because that the IT guy in charge actually believed the message. So, also my last virus.
I did write some DOS viruses back when I was a kid, including a "stealth" one (invisible when reading the infected files via int 21h) and another one polymorphic (encrypted with dynamically generated decoder). I've never spread them, although I did upload another simpler one to an antivirus vendor BBS as a "new virus", so now it's known as "Areopag-480" and such. I thought all of the sources of things I wrote back then were lost when I typed an extra space in "rm -rf ~/something" back around 2000, but recently, while looking through some old books, I've found a piece of code of the stealth virus I wrote around 1992-1993: https://twitter.com/ivan4th/status/1434625057553330178/photo... I didn't have a PC at my grandparents' dacha back then, so I was writing code on paper instead during the summer
I did some of the same things back in the day, just because viruses seemed like such a neat idea. There was a book that came out, The Little Black Book Of Computer Viruses, that was very helpful in learning such things.
I've often wondered-- if you want to learn low level C and/or hacking techniques, would it make sense to start by hacking Ms-Dos? It's easy, there is little to no protection, even for system calls, and you can do a lot with little code.
Of course, there is no "practical" use, but it would be really interesting as a learning excercise.
I often thought of creating a few tutorials about this, but not sure if anyone cares... (or if anyone else has done so).
There's precisely zero protection; it behaves a lot more like an embedded system. It might be nice to reuse some of the old tutorials for this, but I'm not sure if that wouldn't be too specific.
Most of it would cross-apply to embedded. Some of it would directly apply to whatever legacy SBC-level embedded applications out there are still running on DOS. Most people don't want to be in embedded, and even fewer want to do maintenance programming in embedded.
yeah, but embedded is another beast. Lots of different boards/architectures, plus not all embedded devices use an OS, it's mostly (usually?) bare metal programming
It wasn’t intended that way originally, it was the developers of the time who started hitting the hardware directly. Software written to use the BIOS and DOS interfaces could run on other non-IBM-compatible MS-DOS computers that existed. But that didn’t offer the performance that demanding tasks like gaming required, and that’s the genesis of the difference between “IBM-compatible” and “MS-DOS compatible”.
Complementing sibling answer, the architecture used in CP/M, and somewhat mimicked by MS-DOS, allowed very high portability of the system.
Ideally, no user space program should access the hardware directly. All its interactions should be through int 21h. The kernel implemented filesystem access and other system routines, occasionally making bios calls. Bios calls were very simple calls to a jump table in a predefined location that implemented lower level hardware accesses. So, when a program wanted to, for example, access a file, it called the BDOS with specified register values and the kernel, if required, made bios calls to satisfy the request.
This, of course, incurred some latency. For performance critical applications like games this approach was just too costly. Since IBM-PC was just very very common, apps started accessing the hardware directly. It was more performant but non-portable.
For classic CP/M apps, that never accessed the hardware directly, if you could build a machine with a compatible bios, you instantly had access to all CP/M software library available.
My first experience with an MS-DOS virus was in the
late 1980s with the Jerusalem virus. We wanted to play Nethack during programming class (PASCAL) in the computer lab, and so brought a disk with a downloaded version (1200 baud) from home to install on the school's computers. Needless to say, someone had an infected copy, and before long it spread to most of the machines. It would cause weird things to happen like little blue rectangles to randomly appear. At that time, nobody was familiar with viruses (the computer teacher was actually a math teacher picking it up on the fly), and so the computers stayed infected for months until someone figured it out.
for those interested in the polymorphic libraries which became prevalent in the early 90s, I've got a disassembly of MtE at https://github.com/bnjf/mte/
I'll be interested to look at that MtE disassembly in detail. Thanks for doing that work.
If you enjoyed MtE you might enjoy the polymorphic engine from Natas (published in 40Hex[0]). It's not as complex as MtE. It's a bit oddball in that it appends the decryption routine to the payload.
My fascination with viruses actually brought me to programming. After reading a lot about them, one evening I said to my father (who was a programmer) that I want to learn how to write a virus. So, he gave me a book called “The C programming language”… But I never actually wrote one :)
I really admire techniques that were used on DOS viruses. Resident viruses that could hide themselves (stealth) and able to use boot as a transmission vector were very advanced. This combined with polymorphic techniques made the virus very resistant, basically reboot resistant.
Amiga viruses (especially earlier ones) had a much easier time of resisting reboot, as they could simply hook the CoolCapture vector to remain running. This was an otherwise officially supported mechanism - Commodore’s own “recoverable ramdisk” (RAD:) hooked CoolCapture to allow the OS to even boot from RAD: (useful on floppy-only, high-RAM systems to enhance system performance by literally diskcopying the boot disk onto RAD:, as it was usually set up to be the exact same size as a floppy, although this could be changed). Popular virus scanners like VirusX and VirusZ quickly became able to detect these hooks and optionally restore the vector to the OS default (which would kill RAD: on the next reboot if one was using it, but as hard drives became more common, fewer people used RAD: in this fashion, so it was less of a problem).
One day, I got something infected with a virus named Romania.856 (I will always remember this name), a COM infector, as I found out from F-Prot Antivirus (which came with a great db with information about viruses -- such a great read for the young me!).
The tools available to me were still very limited; I had not yet discovered TDD (Borland Turbo Debugger). But I was dead set to understand how the virus worked. There I was, using the very limited `debug` tool that came with MS-DOS. I've learned x86 Assembler from various texts downloaded from BBS's. I reverseengineered Romania.856, and learned how it worked, and did my own experiments. That's how I spent my summer vacation that year.
This was the beginning of some of the most beautiful years of my life, with regard to computers. It lasted for a bit over half a decade, time in which tech evolved fast, I got an internet connection (still dialup back then), I discovered IRC, met people with similar interests and so on. What I miss the most now is the feeling of everything being new, the possibility for exploration and discovery.