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!