35C3 - A deep dive into the world of DOS viruses

35C3 Intro music

Herald Angel: OK. So this talk is called
"A deep dive into the world of DOS

viruses" and if you happened to be at the
8C3, that is 27 years ago, you would have

seen a very young and awkward, even more
awkward than I am of the moment, version

of myself, speaking on basically the same
subject. The stage of course was a lot

smaller than this, this would have really
intimidated me back then, but I was

talking about a university project that we
had run for about 3 years at that point,

and our possibilities were very limited.
Meanwhile, 27 years later, our speaker, in

between fighting battleships over the
public BGP network and trying to encode

data in dubstep music, was able to
actually do all of the stuff that we were

trying to do, with a lot of effort,
basically, and I guess 4 hours of CPU time

or something like that. Please help me in
welcoming Ben to our stage, to talk about

a bygone era.
Applause

Applause

Ben: Thank you. Hi, I'm Ben Cartwright-
Cox, as the slide suggests. So I have an

admission to make: So this is a thing to
be aware of.

Laughter
Ben: And you know, things also to be aware

of. Anyway. So what is DOS? To get
straight into it. You can do it in a

bullet points way. You know, DOS is an
upgrade from CP/M, another very old legacy

system, but another thing to be aware of
is that DOS covers a wide range of

vendors. Might not just be like those old
IBM PCs. Some of the DOSes had

compatibility with each other, meaning
that some of the DOSes had shared malware

with each other. But to be honest, most
people know DOS as these lovely old beige

boxes; the same era gave us our loved
Model M keyboard. Hated by some, loved by

others, for the sound. But, you know, most
people's knowledge of DOS came from

computers, a user interface that looked
like this. Pretty basic. Okay so this is

Wordstar, some of you may not know that
Game of Thrones was written on Wordstar.

George R. R. Martin is apparently not a
big fan of modern word processing. he

admitted he had some issue with disliking
how spell checking worked. So just uses,

and I also guess it's a good security
quality, you know, you can't get hacked,

if it literally has no Internet access.
So, also though, for a lot of people this

is also their first experience into
programming. For the some of the older

crowd. This is also the invention of
QBasic, which, you know, gave a very basic

language to program creatively in DOS. For
some people this was the gateway drug into

programming and perhaps the gateway drug
into what they started as a career. For

other people the experience of DOS was not
so great. For example, you know, let's

just say you were doing some work in an
infinite loop and at some point stuff like

this happens. Unfortunately I don't have
sound for this one, but you can just, in

your head, imagine like our PC speakers
playing some small techno music, on like,

you know, but only one frequency at a
time. This might get especially incredibly

embarrassing, if you are in an office
environment, just slowly beeping away. You

can't exit this. It has to finish fully and
if you touch the keyboard it reminds you

not to touch the keyboard, and continues
playing this music. So, you know, this would be

fun, but this wouldn't be fun, especially
in an office environment. But, you know,

ultimately it's not malicious. And that
trend continues. This is another good

example of a DOS virus. This is ambulance,
for when you run it, an ambulance just

drives past and then your normal program
just continues running. I think this is

amazing, it's an interesting era of
viruses. It was all, the history of it was

collected very well by a website called VX
heavens, which sort of still lives, but

unfortunately, at one point was raided by
the Ukrainian police, for what is the

fantastic wording they used. Basically,
someone told them they were distributing

Malware. Unfortunately not malware that
operates in this century. But I guess

that's good enough for a raid. But luckily
for the archivists there are archivists of

archivists, and so we have a saved capture
of VX heavens. This is actually an old

snapshot, there are way more modern
snapshots, but thankfully the MS DOS virus

era doesn't move very quickly. So, but the
interesting thing here is, like, there's

66000 items in this tarball and it's 6.6
gigabytes of code. And these viruses are

like super dense. There's not much to
them, like they are just blobs of machine

code. They are not like your electron app
these days that ships an entire Chrome

browser, and normally an out of date
Chrome browser, you know, this is just

basic, like, you know, how to draw an
ambulance and, you know, some infection

routines. The normal distribution also
changes with it as well. For example, the

normal lifecycle of an MS DOS virus is,
you know, you download, or for some other

reason run an infected program that
presumably does nothing; to you it looks

like it does nothing, so, you know,
remains roughly undetected. Then you go

and run more files, the DOS virus infects
more files and at some point you're

probably going to give one of those
excutables to some other computer, or some

other person, whether it was by giving
someone or copying a floppy disk of some

software, maybe some expensive software,
so they didn't have to pay for it, or

uploading it to a BBS, where it could be
downloaded by many people. So the

distribution mechanism is a far cry from
the eternal blues of this era, where, you

know, we can have a strain of malware
spread across the world very brutally,

very quickly. So most DOS viruses are
pretty simple: They start, they say "have

my payload conditions been met?" If not,
then they'll go on display, if they are

met they'll go and display the payload.
And the payloads are definitely more,

I don't know, nice. You know, you have stuff
like this, which is pretty and it uses VGA

colors and all sorts of pretty nice stuff.
You get also some very demoscene vibes

from this. Another good example is this
like VGA, like super trippy thing, which

is really impressive, 'cause this is
really small. This is less than 1 kilobyte

of code. It's in fact way less than 1
kilobyte, it's like 64k. Or you just get

like interesting screen effects as well.
For example, it's quick, but like, you can

just watch the entire computer just
dissolve away, which also might be quite

worrying, if you weren't expecting that.
Alternatively, if the payload conditions

are not met, then, you know, you hook
syscalls and you, or alternatively, if you

want to be way more aggressive, as a
malware offer, you scan for files on the

system to infect proactively. And the way
you infect DOS programs is pretty simple:

Imagining you have like one giant tape of
all the code you have for the target

program. Most of them work like this: They
replace the first 3 bytes of the program

with a x86 jump. They append their malware
onto the end of the executable, and so the

first thing that you do, when you run the
executable, is it jumps to the end of the

file, effectively, runs the malware chunk,
and then it optionally will return control

back to the original program. But there's
also the thing about hooking syscalls, right?

So, you know, MS-DOS is an
operating system, it does have syscalls,

programs can reach out to MS-DOS, to do
things like file access and stuff, so as

you expect, you run a software interrupt
to get there. Thankfully though, MS-DOS

does also allow you to extend MS-DOS by
adding handlers itself, or even

overwriting existing handlers, which is
very convenient, if you are trying to

write drivers, but it's also incredibly
convenient, if you're trying to write

malware. For some of the examples of the
syscalls, most of them relevant towards

DOS virus making. Here's a decent example
of the things that DOS will provide you. A lot

of them are just very useful in general
for producing functional executables the

end users want to use. This is what an
average program looks like. This is almost

the shortest hello world you can make,
minus the actual hello world string. In

fact, the hello world string might be the
largest part of this binary. It's a pretty

simple binary. Here we we're moving a
pointer to the message we just set. We

then set the AH register to 9, or hex 9.
That's the syscall for printing a string,

and then we run a software interrupt, 21h,
which is short for 21 hex, and we continue on.

We then set AH again, to 4C, which is
exit with a return code, and the program

will return. So, in the meantime, this is
roughly the loop that just happened.

You have your program code, that calls an
interrupt and that gets passed over to the

interrupt handler. In the process of doing
this, the CPU has quickly looked at the

first 100 bytes of memory in the interrupt
vector table, IVT, as it's abbreviated,

and then it's effectively a router. If
anyone has written like a small piece of

code to route HTTP requests, or anything,
it's basically like that, but in the 80s,

with syscalls. So it's just basically
saying "Compare this, compare that, jump

there, jump there." Then the thing gets
passed to the call handler, it goes and

does the syscall, the thing that was
required. Normally it will leave some

registers behind, a state, or results of
actions it has performed, and it returns

control back to the program. So,
theoretically speaking, if we wanted to go

and look at what a program actually does
we need to set a break point here, because

this is the only place that we can be sure
the location exists, because this is way

before the era of ASLR, address space
randomisation, and this is way, way before

the era of kernel space randomisation, in
fact, MS DOS has almost no memory

protection whatsoever. Once you run a
program you are basically putting the full

control of the system to that program,
which means you can happily also boot

things like Linux directly from a COM
file, which is handy if you want to

upgrade. So, if we look at certain files
we can go and see what they do. So in this

case, here is one example. This is a goat
file. A goat file is like a sacrificial

goat. It is a file that is purely designed
to be infected. So what you do is you

bring a virus into into memory in the
system and then you run a goat file, in

the vague hope that the virus will infect
it, and then you have a nice clean sample

of just that virus and not another program
inside the virus, which makes it way

easier to test and reverse engineer. So,
we can see things are happening here. For

example, we can see it opening a file,
moving like where it's looking into the

file, reading some data from the file,
just 2 bytes, though, and it closes a

file. We see the same sort of thing repeat
itself, except at one point it reads a

large amount of data, moves the file
pointer, writes another large amount of

data, does some more stuff, and yeah, we
pass some filenames, we display a string,

which is almost definitely the goat file
message and yeah, we pretty much exit

after that. So, there were a few syscalls
here that we would really like to know

more about. So, for that, it's the open
files, we'd really like to know what files

were being opened. We would also want to
know what, we'd like to know, what data

was being written to the file, rather than
having to fish it out of the virtual

machine later, and we'd also, just out of
curiosity, really want to know what

filenames it was asking MS-DOS to parse.
Display string is also a nice test to

know, whether your code is working. So to
do this you're gonna have to look a little

bit deeper into how the MS-DOS runtime
and, by proxy, how x86 in 16-bit mode

works, or legacy mode, I guess. This is
basically all the registers you have in

16-bit mode, and some nice computations at
the bottom, to make it easier to read.

So, as we mentioned, AH is the one that you
use to specify, which syscall you want,

and you'll notice it's not there. AH is
actually the upper half of AX. AH is a

8-bit register, because sometimes people
really just wanted only 8 bits. It's very

obscure that we were saving that much
space. And so, this is what a, this is the

definition of the syscall of a print
string. So you have AH needs to be set to

9, this is once you, in order to call the
syscall for printing string, you set AH to

9, and then you need to set DS and DX to a
pointer to a string that ends in a dollar.

And that doesn't make a lot of sense, or
it didn't make a lot of sense to me, when

I first read that and so, to do this,
we need to learn a little bit more about

how memory works, on these old CPUs, or
the CPUs that are probably in your

laptops, but running in an older mode. So
this is effectively what it looks like.

They have a 16-bit CPU, 2 to the 16 is 64
kilobytes, and we have a 20-bit memory

addressing space. 2 to 20 is 1 megabyte,
so if you ever see an MS-DOS machine like

limiting at 1 megabyte, or some old
operating system, saying like the maximum

memory you can have is 1 megabyte, it's
because it's running in 16 bit mode. And

the maximum it can physically see is 20
bits. So the question is: How do we

address anything above 64K? If the CPU can
only fundamentally see 16 bits. So, this

is where segment registers come in. We
have 4 segment registers, actually we

might have more, but they're the ones who
need to care about. There's the code

segment, the data segment, the stack
segment and the extra segment, in case you

need just another one. So anyway, with
that in mind, let's have a quick crash

course on segment registers. So, imagine
if you have a very long piece of memory,

and we can only see 16 bits at a time. So,
however, we can move the sliding window

around in the memory, to go and see, like,
to move our view of where it is. So, we

can do this and put data around the
system, and we can use the final pointer

to specify, how far in to the memory
segment we should go. So the DS and DX

really just means a multiplier. So, where
the data segment is 100, you need to just

move 100 times 16 to get to the correct
place in memory, and then DX is the

offset. This continues on, so, where we
have a 16 bit cpu, we have a bunch of

general use registers or general purpose
registers. They're quite useful for

ensuring, you don't need to touch RAM too
often. x86 actually has a fairly small

amount of general purpose registers. Some
architectures have way more. I think more

modern chips like GPUs have hundreds, well
hundreds, maybe thousands. However, this

doesn't really change over time in x86
because we have to force backwards

compatibility. So, really what actually
ends up happening, when we move up the

bittage, is that the same registers just
get wider, and we add some more ones for

the programmers, that want them, and the
exact same thing happened to 64 bit: The

registers just got wider. So thinking
about it, we have a lot of malware now,

what if we want to know everything that's
happened in this entire archive. So we

kind of want to trace all of these
automatically, but we might not know what

we're looking for, so let's go through the
checklist of what we need to do, to trace

all of this malware. We need to break
point on the syscall handler. When we get

that breakpoint, we need to save all the
registers, so we know which syscall was

run and potentially what data is being
given to the syscall. Ideally, we're going

to save one hundred bytes from that data
pointer, not especially because we need

it, but it's quite handy in a lot of
registers in a lot of syscalls. It's for

example what you use to get the open file
path, when you're opening files. We should

also, probably, record the screen for
quick analysis, rather than just staring

at HTML tables, and so we can do that, we
burn a lot of CPU time and probably cause

some minor amounts of environmental
damage. And we get nothing. We just run a

bunch of stuff and most of them don't
return anything. At best they return a

goat file string. They just do nothing.
So, if we look deeper into the reason why,

it's sort of a smoking gun here, so we can
see the syscalls that run on this file

that does nothing, and the smoking gun
here is the date. So it's asking for the

date from the system, and this sort of
flags out the first issue, is that a lot

of MS-DOS viruses don't really have a lot
to go on, because they have no internet

connection, and there's not really any
other state they can decide to activate on.

So the date syscall is pretty simple.
The get date and get time just return all

of their values as registers. And, you
know, some using the 8-bit halves, to save

space. So, a naive way of doing this, is
what we do, is we would run the sample,

we'd wait for the syscall for date or
time, we would just fiddle the values,

'cause in this case we're using a debugger,
so we can automatically change, what the

state registers are, and we can then
observe to see, if any of the syscalls

that the program ran changed, which is a
pretty good indication that you've hit

some behavior that is different. And then,
you know, we can say "Hooray, we found a

new test case!" The downside is: running
every one of these samples takes 15

seconds of CPU-time because MS-DOS, well,
15 seconds of wall-time, which,

when you are emulating MS-DOS is 15
seconds of CPU-time because of the fact

that MS-DOS doesn't have power saving
mode, so when it's not doing anything, it

just goes into a busy loop which makes it
very hard to optimize. Or we could take a

cleverer look. So when we think about it,
we are in the interrupt handler where all

we ever see is the insides of the
interrupt handler because we don't know

where the program code is. The interrupt
handler is the only place that we know is

consistent because MS-DOS could
potentially load the code for the malware

or the program anywhere. But we want to
know where the code is. It would be really

handy to know what the code is that we'd
be about to run. So for this we need to

look towards the stack. Just like the DSN
DX registers the stacks are located on a

stack segment, on a stack pointer.
Luckily, the first two values is the

interrupt, the interrupt pointer in the
stack segment so we can use that to grab

exactly where, what the code will be run
afterwards. So we just need to add a few

things to our checklist. We need to grab 4
bytes from the stack pointer and then

using that, we can calculate the
destination that the syscall will return

to. And if we look at some of them - we
can look at an example here - well, this

is what a piece of what one of the calls
returns to us. So we see we running a compare

on DL against the HEX of 0x1E. And then
if that comparison is equal it will

jump to 1 memory address. And if not it
will jump to another. So if we look back

at the definition of those syscalls we can
see that DL is the day. So with this we

can conclude that D if 0x1e is 30 and DL
is the day this malware effectively is

saying if the day of month is 30 we need
to go down a different path. If we run

these all over time across the whole
dataset what we see is roughly this as a

polydome bar chart. We see out of the 17.500
samples we have around 4.700 of them

checked for the date and time and these
are the ones that are really tricky

because they're really hard to activate.
They're also the most interesting though, because

those are the ones trying to hide. So, with
that in mind, we need to, we have the code

segment that we're about to run, when we
return and we can't really brute force

because it takes a little CPU-time and we
can't brute force it inside a 'real' or

emulated machine but we can brute force it
in a significantly more interesting way.

We need to build something: we need to
build the world's worst x86 emulator so

dubbed BenX86, it's 16-bit only. Any
attempt to access memory effectively ends

the simulation. It's got a fake stack if
you try and push something onto the stack

it says sure, fine if you try and pop it
it's like oh actually I never held any of

that data anyway so we are ending the
simulation. 80 opcodes, most of them are

jumps. Because that's the primary
purposes, comparing and jumps. The

difference is it logs every opcode every
address that it went trough and it can be

run with just a small x86 code segment and
a register snapshot. This means that we

can test old age from 1980 to 2005 and are
roughly about 100 milliseconds and most

programs ended up having just 3 different
code paths on average so that yields us

with 17.000 virus samples and about 10.000
of samples that had date variations as in:

Once you exploit the complexity. So I'm
going to now use my final remaining time

to go through some of my favorites. So
this is an example of a virus that just

doesn't do anything on the 1st of 1980.
However if you'd happen to be running this

on New Year's Day you would get this.
Laughter

No matter what you do, every program you can't

exit out of this, your machine is hung. This
might be great, right? You might be like:

'Oh cool, I don't need to do work anymore
because my computer will literally not let me'

This also might be terrible, because
you might need to do some work on New

Year's day. Here's another example. This
does nothing as well just another innocent

.com file. Of course reminding these
pieces of malware will be wrapped around

something else. Almost anything could be
infected in here. In this case though

these binary is a nice and shaped down.
However instead we get this, which I think

is super interesting and is basically the
author is aware - they're telling you they

are actually like self disclosing in
saying the previous year I've infected

your computer. And for some reason it's
being nice. They're just saying. Actually

you have been infected. And as a - I guess a
pity - I'm just going to remove myself now.

I don't really. For some reason it's also
encouraging you to buy McAfee. This is

back in the day when John McAfee himself
actually wrote McAfee. Interesting times.

Definitely interesting times. Here is
another example. This one I found

particularly obscure. On the 8th of
November 1980 or any year I think actually

it turns all zeroes on the system into
tiny little glyphs that say "hate" if

anyone understands this I'd really like to
know like I've been thinking about this a

lot. What does it mean? Is it an artistic
statement? Is it. I wish I knew.

Someone in the audience: it says MATE
Ben: There could be a CCC variant says

MATE. Another good one in that it's the
last thing I ever want to see any program

tell me is this one here where you run it
and it says "error eating drive C:". I

never ever want an error in any program
unexpectedly just says 'Sorry almost I

failed to remove you root file system,
don't know why, could you like change your

settings so I can remove it?' Cheers. And
finally this is one of my absolute

favorites in that it's just brilliant in
that it also stops you from running the

program you want to run it exits
prematurely. This is the virus version of

the Navy SEAL copy pasta. Says "I am an
assassin. I want to and I shall kill you."

"I also hate Aladdin and I also will kill
it. I will eliminate you with ...". You know where

this is going. It says fear
the virus that is more powerful than God.

It only activates on one day though, so
it's fine. Thank you for your time. I know

it's late and I will happily take any
questions or corrections if you know this

topic better than me.
applause

Herald: This totally brings tears to my
eyes with nostalgia. So if there is any

questions, we have microphones distributed around
the room, there is like 1,2, 3, 4 and

one in the back. We also have questions
perhaps from the internet if you want to

ask a question come up to the microphone
ask the question just as a reminder a

question is one or two sentences with a
question mark behind it and not a life

story attached. So let's see what we have.
I'm going to start with microphone number

1 just because I can see it easiest, let's
go for it.

Microphone 1: Hi Ben, thanks for the talk.
Really interesting. My question would be

did you do any analysis on what ratio of
the viruses was more artistic

and which one actually did damage.
Ben: So most of them surprisingly don't do

damage. I actually really struggled to
find a date varying sample that

specifically activated on a certain day
and decided to delete every file. There

are some very good ones in some of them
are like virus scanning utilities that just

don't do anything on certain dates and in
one day like while they're telling you all

the files they are scanning is actually
telling you all the files they're

deleting. So that's particularly cruel but
it's actually surprisingly hard to find a

virus sample that actually was brutally
malicious. There was some, that would just,

you know, infect binaries is but it's very hard
to find one that I think was brutally

malicious, which is a far cry from the days
well from the days that we live in right

now, where we're taking down hospitals with
windows bugs.

Herald: as everybody is leaving the room.
Please do it quietly. I see a question at

(microphone) 3, on that side.
Microphone 3: Yes. Since a lot of

industrial control systems still run DOS.
What's the threat from DOS malware that

might be written today.
Ben: It's probably unlikely than an

Industrial Control System that's running
DOS, would come into contact with DOS-malware.

The only way I can think is if one vendor
was like or a factory or supply or

whatever it was basically downloading all
basically wares onto industrial control

boxes. I wouldn't be surprised but it
would be pretty irresponsible. But it

would be quite surprising to find MS-DOS
malware today on industrial controllers

that was installed recently and not just a
lingering infection from the last 20

years.
Herald: Microphone 2

Microphone 2: Did you find any conditions
that weren't date based. Some of them do

attempt to some of them try and circumvent
the date recognition. Unfortunately it's

very hard to brute force those. Some of
them install themselves as what's called

TSR or Terminate and Stay Resident which
basically means that they will exit out,

run in the background and continuously ask
the actual system time what time it is.

It's a bit of a more risky strategy
because the system timer might not exist

which would be unfortunate for the virus.
So definitely there are viruses that have

way more complicated execution conditions.
I observed one sample that only activated

after I believe it was something silly
like 100 keypresses which is very hard to

automatically test. Those sort of viruses
require static analysis and statically

analyzing 17.000 samples is a time
consuming task.

Herald: So we have a question from the Internet.
Signal Angel: Do you have the source? What

is the source of the malware that you
analyzed here, is it published somewhere?

Ben:You can still find dump's of VX
heavens, and more modern dumps of VX

heavens on popular torrent websites.
But I'm sure there are also copies

floating about on non-popular torrent
websites.

Laughter
Herald: Over to microphone 1.

Microphone 1: Hi Ben. I'm Jope. Thank you
for your talk. I was wondering: did you

learn anything from your studies of these
viruses that should be taught in modern

day computer science classes like more
efficient sorting algorithm or some hidden

gem that actually should be part of
computing these days.

Ben: My primary takeaway was x86 was a
mistake.

Laughter & applause
Herald: So I'm not seeing any more

questions. Oh no there is. OK one more
question from the internet.

Signal angel: Have you found malware
samples that did like try to detect dummy

binaries or whatever, to avoid easy
analysis?

Ben: Oh actually, that's a really good question.
So it is it's complicated:

So some viruses would so, maybe let's be

dangerous let's try and go backwards on my
home written presentation software. So

humming Too many slides. I have
regrets. Yes. OK. Here we are. This slide.

OK. So you know here I'm saying that the
malware infection goes to the end. Well

some samples are really cool. They don't
change the size of the file. They just

find areas in the files that are full of
null bites and just say this is probably

fine. I'm just going to put myself here
which may have unintended consequences. It

may mean if a program is like a statically
typed, statically defined byte array of

like a certain size and the program is
relying on it being zeros when it accesses

it for the first time it may get very
surprised to find some malware code in

there. But generally speaking as far as
I'm aware, this deployment

procedure works pretty well and actually
is very good at avoiding antivirus of the

era which would just be checking like
common system files and its size. And you

know the size increases of COMMAND.COM
then that's clearly bad news.

Herald: We have a question on microphone
1.

Microphone 1: Are there any viruses that
try to eliminate or manipulate virus

scanners of the day.
Oh yeah. So a lot of the samples will

actively go and look for files of other
anti-viruses.

But I am generally under the impression
that it's kind of hard to find them. They

weren't actually that many antivirus
products back in the day.

I feel like, it was a bit of a niche thing to
be running. Microsoft did for a while ship

their own antivirus with MS-DOS. So I
guess you know what's new is old. So there

were antiviruses out there. I don't think
many of them were very effective.

Herald: Any more questions? There, where?
Oh right. Another one from the Internet.

It's interesting that the internet is
querying MS-DOS all the time. Go ahead.

Signal angel: Did you do the diagrams by
hand or do you have a tool?

Ben: So many hours. No. So there's a
couple of good tools to do it.

asciiflow.org. I think is a fantastic
tool. I would highly recommend it. I think

it's not maintained very well, though.
Herald: microphone 1.

Microphone 1: Are you publishing the tools
you wrote?

Ben: I will be publishing the tools at
some point when they are less... when they

are less ugly. I will be publishing all of
the automatic malware runs and the gifs

generated by them so that people can
easily search google for the virus names

and get like actual real time versions.
The hardest thing that I've found is when

looking at virus names was literally just
finding any information about them and one

of the things I really wish existed at the
time of writing this talk, was being able

to just query a name and be like oh yeah
this virus it looks like it does this.

Herald: since I saw microphone 1 first
let's go with that.

Microphone 1: Did you find any viruses
that had signage in them not signage of

today but the name of the author. Like he
was very proud of what he wrote.

Ben: Yeah, there are some notable
examples. Quite a few of them will try and

name - so DOS-viruses do like have
[incomprehensible] sample names in the same way

that we'd still today give viruses names.
A lot of the time you will just encode a

string that you want the virus to be
named, you know, somewhere in the file

just a random string doing nothing. It's
like oh, ok, they clearly wanted the virus

to be called Tempest. So that does happen.
One of the favorite examples is the brain

malware which literally encodes an address
and phone number of the author. I believe

in Pakistan and there's a fantastic mini
documentary by F-Secure where they go and

visit the people who wrote it. It's a
super interesting watch and I would really

recommend it.
Herald: Indeed it is. Microphone 2?

Microphone 2: Did you have any chance to
look at any kind of viruses that did not

modify the files themselves. For example
one of the largest virus infections at the time was a

virus called [incomprehensible] which modified
the master boot record

Ben: Yes, Master boot record, I did
consider. It was more of a time problem

that I had in getting to the point where
you could brute force time and date

combinations and looking for master boot
record changes. It was really hard. I am

super interested in reviewing a fact to be
the root kits of the era. But yes that's

definitely something I will look into in
the future.

Herald: And we have yet another question
from the Internet.

Signal angel: And it's even from the same
guy.

Ben: Oh damn.
Signal angel: is the BenX86 software open-

source or can be found on the web
somewhere.

Ben: It probably will be. I wouldn't
expect it to work in, well, in any use-case

though. It's effectively designed to like
not work correctly, right? Like what

was the spec? It basically like fails at
every single thing awkward. I just went

like oh that's fine. We're probably far
enough down there anyway. Are we? Be aware

this is the feature list.
Herald: So is that a follow up question

from the internet?
Signal angel: No it's a new one. I don't

know how serious it is but would it be
possible or a good idea to use machine

learning to create new DOS malware from
the existing samples.

Laughter & applause
Ben: It would not be a good idea. But I

like how you think.
Herald: Actually I saw somebody trying to

use NLP to generate viruses but ok that's
enough for now.

Ben: you could probably do Markov Chains
with x86 to be honest. Please don't do

that, please!
Herald: Don't try this at home.

Ben: I have seen things I've seen. Just
please don't do that.

Herald: So I think we've run out of
questions. Going once, going twice. Let's

thank Ben for this marvelous retrospective
talk.
Big applause

36C3 postroll music

subtitles created by c3subtitles.de
in the year 2020. Join, and help us!