*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*
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!