 All right. Thank you very much everybody for coming. We have a lot of slides, so we're going to go right into it. My name is Wayne Huang. And we have our colleague, Roman, with us, Fernandez. We work for Armourized Technologies. I'm co-founder and CTO to Armourized Technologies. So today, we're going to be talking about dry-sploit, circumventing automated and manual detection of browser exploits. What's up there is the Chinese wording for drive-by-download, which actually assisted for many years before the term drive-by-download came about. Because this type of attack was quite prevalent in Asia. I was doing research. I was doing black box scanners at that time. And we weren't able to crawl a lot of the web pages because of the dynamic content. So we started to embed IE. And then we wanted to have mass crawling and SQL injection results. We had many crawlers crawl for many days. And then the end result was all of the boxes ended up with malware in it. All right. Oh my gosh, so what happened? So actually, we submitted a paper to the WW conference in 2002. In the paper, we described how we embedded IE. And because we had to embed IE, we had to sandbox IE in order to prevent these exploits from attacking our IE. So that was how this technology started. The slides are not in your CD. Apologize. It's right now on Slideshare. So if you go to www.drive-sloid.org, or you follow the Twitter, you can download it right now. So today, we're going to be showing one type of browser exploit, which is the Drive by Downloads. Let's define that. So hackers distribute malware by poisoning legitimate websites. And what's typical is they inject malicious iframes into legitimate HTML content. And the affected websites essentially become a delivery mechanism for malware. They appear normal, and the victims do not need to click or agree to anything. And simply connecting to the infected website executes the attack. Recent incidents include the Aurora incident, which began sometime in June last year, until February of this year when Google reported and the news went to the media. It was a targeted attack. It used the IE0 day. And it was confirmed publicly by Google, Adobe, Juniper Networks, and Rackspace. And a total of 34 organizations were targeted, according to coverage on media. A recent one, DNF666. If you haven't heard of this, you can go to our blog, just Google for the keyword. It started since March 2010 initially, leveraging an Adobe 0 day. The victims included Wall Street Journal, Jerusalem Post. And then we later found out that all of that effort was just to steal accounts to online games in Asia. So the second wave and the third wave targeted only Asian websites. Well, the first wave hit Wall Street Journal and Jerusalem Post. And it happened to CNN, GameSpot, US Treasury, Sony PlayStation, Washington Post in the past. So let's dissect drive by downloads. What happens is very simple. The visitor links to an exploit server. The exploit server serves him a legitimate page, but it includes a browser exploit and also a payload or what we call downloader. The exploit in this part is usually obfuscated. So when it executes, it will obfuscate itself. And then we'll exploit the browser. And at this time, the dropper will execute, which is the payload or the show code. And it will cause the browser to link back to the malware server. And the malware server, which is usually different from the exploit server, will distribute malware back. And then finally, the malware will link to a CNC. And that's basically the attack. It's very simple. But now the key is, who would visit a exploit server? Nobody would. So the key here is traffic. And actually, why these two servers are usually separate is because, at least in Asia, it's two ecosystems. There are groups responsible for developing the browsers and then devolving the browser exploits. And then there are groups responsible for getting traffic to the exploit servers. And then there are groups responsible for developing the actual malware, which is quite hard. Because that malware has to bypass antivirus. And so what happens is you would typically, the attacker would try to infect one of the very high-traffic websites, what Google calls the landing website. And then so from there delivers a URL generator, which is a piece of JavaScript that generates iframes or JavaScript sources, typically. And this iframe would then cause the browser to start loading content from the exploit server. Recent incidents, DNF666. And then in May to June, there was mass shared hosting compromise, which included GoDaddy, Rackspace, Network Solutions, Bluehost, and Dreamhost. Some of these, after being compromised, wasn't used to serve drive-by downloads, but instead other types of malware, such as fake antivirus. But some were, after compromised, were serving drive-by downloads. And then this is a part of a very typical continuous targeted attack, the same incidents to Aurora that basically is a persistent threat, that's a continuous threat. And when this happens nowadays, it's very easy. It's very hard to remove, because a lot of times the URL generator is inserted not into just a plain PHP file, but it would disguise itself as a legitimate WordPress or Joomla file, or it would insert itself into a WordPress store procedure or a Joomla somewhere in the Joomla database. So it's going to take you a lot of time and a lot of SQL commands to dig that out. And then all throughout this time, you wouldn't know how to remove that malicious iframe or malicious JavaScript from your website. And that makes you look very bad. And that was always talked about so far. It's only one type of malicious JavaScript injection, and that is when they physically tamper your data. Another type is when they don't physically tamper your data. Typically, what happened many years for many years in the past in Asia is attacks coupled with ARPS spoofing. So for example, the ZX ARPS tool is very immature, very robust. If the attacker is able to compromise other machines on the same lane segment as your web server, they may not choose to infect the web server directly, because it then is very easy for you to find the injection and fix it. They would compromise another machine that can do ARPS spoofing and then would use a tool like ZX ARPS to act as man in the middle. And then it would become the man in the middle. And then it would just basically be passing traffic through. But for every HTTP response that it gets from the server, it would inject a malicious script or iFrame and then pass it back. So in that case, your visitors tell you that your website is compromised. You go in, you dig the database, you dig the files, you don't find anything. Well, because they haven't tampered anything. In March 2009, what happened was websites like tw.msn.com and taiwan.sina.com and other sites was attacked and embedded with malicious content. And down there, you can see a Cisco advisory regarding it. The incident lasted a total of 12 days before it was totally contained. Because what happened as we figured out was the injection was in the middle of the route. So it wasn't on the lane. It wasn't on the web server itself. But it was on one vendor's equipment that was a layer 47 equipment in the middle of the route that was compromised and that was used to inject the iFrames. So this is the second type of this type of attack. So now we're going to do a live demo. Using dig, using a persistent cross-site scripting, vulnerability in dig. They have fixed this vulnerability already. But our link is still there. So let's go to dig first. Firefox, where are you? Oh, lovely Firefox. OK, there we go. So far. OK, so usually when you view one of the dig pages, what you see is this. You would see the digged link and the description and people who dug it, this kind of thing. But let's look at the source code. And here you would see that, that includes www.zcrack.org slash g. And it's included as an iFrame source, as you see here. Which shouldn't happen, so it's a very simple persistent cross-site scripting that exists in dig and the attacker, who is us for the demo, has used that to inject that iFrame. So let's start our DriveSploit. So we've implemented the DriveSploit framework on top of Midasploit. So now I'm starting Midasploit. This one is a little smaller. The victim machine. Visit the dig URL. OK, so as you can see, Midasploit is serving. And we've chosen to use Metorporator as the payload. And now Metorporator is starting a new process in my notepad and migrating itself into notepad. It's completed. So as you can see, the internet explorer is gone. But we now have an open session. Connect to it. Seal the processes. So we basically have now a shell into the victim's system. So let's just kill ourselves. And it's attached to actually another process, notepad.exe. So that even though IE is dead, it's all right. So I'll kill myself. OK. So that's basically a very simple demonstration of a typical drive-by-download process. So what happened was, Dig had a persistent cross-site script invulnerability. The attacker used that to inject the iFrame. And in the back end, Midasploit or DriveSploit was used to serve the JavaScript exploit. OK. The motivation behind building this, we provides solutions that monitors websites and detect malicious content 24 by 7. We use multiple behavior, heuristic, and signature-based technologies. Most technologies are developed on our own. But we also integrate in a virus because behavior-based technologies that we use are very, very costly. And when you have to scan millions and millions of URLs a day, you end up paying hosting companies a whole bunch of money. So we started a while back looking if we can find some antivirus solutions that can be coupled with our behavior analysis. But they're very, very expensive. And so we spend a lot of time testing our own technologies and also selecting antivirus technologies. And the key to this type of testing is how good are we and them at detecting new drive-by downloads instead of old ones? But how do you get new drive-by downloads that don't exist? That's the problem. So we ended up getting the old exploits and then mutating them by hand to generate new exploits and then testing out all these antivirus technologies in our own. And we ended up writing big messes of code. It was very hard to debug. It was just taking us a lot of time. So we needed a good framework to help us replicate, manipulate, and mutate exploits found in the wild. We didn't say obfuscate. There's a difference. Because when we say mutate, we're changing the raw basic JavaScript exploit in its raw form and not in its obfuscated form into new derivatives. So DriveSploit is born on top of Metasploit. Initial findings, antivirus capabilities differ greatly. Desktop and API versions differ greatly in performance, meaning that an antivirus technology which really performs well for its desktop version may perform very poorly for its API version, which is the version that we want to use. It's basically a library or a console or API for us to call. And also cost is not equal to performance. Surprisingly, the most expensive ones may not be the ones with the best performance, at least according to our testing. And so antivirus versus DriveByDownloads. So we ended up getting quite confused. And we started calling these antivirus companies. And we were like, the results don't make sense, blah, blah, blah. And they're like, well, what are you testing? We're testing JavaScript. And then they don't want to answer the call. And we call again, and we're testing JavaScript. Well, can you give us some explanation? Well, JavaScript is sissy stuff. We don't. So JavaScript to them is not hardcore stuff. Maybe it's true. I mean, yeah, PEs and everything and assembly, these are very hard. But unfortunately, we have to deal with JavaScript when we deal with DriveByDownload. And so according to their explanation, as you can see in our DriveByDownload process, the euro generator is JavaScript. The exploits are JavaScript. The malware itself is the PE binary. And that's why they said, well, we'll detect this part. So during the DriveByDownload detection process, in the end, that's going to exist. And we're going to detect that. But unfortunately, that's not the case. Why? Because usually a malicious domain serving that piece of malware is going to be taken down two, three days later. But the injected domain, such as dig.com, the injection is still going to be there for a long time. And although that piece of malware is not valid anymore, is not active anymore, we still want to be able to detect that. The other thing is nowadays a lot of DNS, a lot of ISPs, when they find out that that domain is malicious, and serving malware would block that domain, even though that domain is still active. And then sometimes it's just in the economy, the subscription period is over. You bought us, you paid us to serve for two days. It's now past the period, you haven't paid up, so we're temporarily shutting it down. That doesn't mean that we're not going to reopen again. And so we want to focus on all of the JavaScript. And that's why we can't just rely on PE detection. So the deal here is ECMA scripts, which is JavaScript, VBScript, Adobe.js, and ActionScript. And so we want to take this part out. Okay, we want to take this part out, and we place the exploit server with meta-sploit, and use metterbiter or something similar as payload, which basically does memory injection, instead of trying to download a piece of malware, and writing it to disk, and have that malware do the malicious stuff, we want a payload such as metterbiter, which also exists in the wild. And so that we can test this out, and we can test out the abilities of technologies just detecting the injected JavaScript, or the JavaScript exploits. So drive-by downloads, what do you want to do? They want to avoid detection at the victim's desktop. They also want to avoid detection by UTM's gateways, and they also want to avoid detection by automated monitors, which are services like those that we provide, or live for as long, and they basically want to live for as long as possible. So conclusion, what are you gonna do? First, reduce exposure, and you do that by selectively, serve selectively. For example, you can serve to each IP only once, and you lock the IP that you've served to, because if a visitor visits you for the first time and your exploit doesn't succeed, forget about it, right? But don't serve to him the second time because he might be somebody working at an antivirus company. Avoid detection and analysis. Then you gotta mutate well. So drive-sploit basically is trying to mimic these true goals of drive-by downloads. Serve selectively. So at the HTTP level, this is what we implemented into drive-sploit. Serve only to fresh IPs. Serve only to particular referrers. This happened to the Gumbler Mass Equal Injection that happened in Japan. And few security vendors were able to detect this on the spot when it exploded because Gumbler was very selective about the referrer. It only served to referrers from Google. And in our case, in our example, for example, since we've infected dig.com, we can also specify what we are going to only serve to referrers coming from dig.com. Makes sense, right? If you're connecting to us directly, sorry, you're not somebody that we want to infect. We want to keep our zero-day for a bit longer. Particular agent strings so that we only serve, if this exploit is for IE7 only, we want to serve to IE7 only. If you connect with the Firefox, we want to serve to you. If you're a Google crawler, if you're a Yahoo crawler, we don't want to serve to you. Blacklist, blacklist of security vendor, well-known crawler IPs and security vendor IPs, we don't want to serve to those. And that basically covers the first part, which is serve selectively. The second part, script mutation. This part is for both the exploit and also for the payload. The goal here is not to obfuscate. A lot of JavaScript exploits has been using existing JavaScript packers, but that's very easily picked up by end of virus. So the new ones, oh, don't. The goal is not to obfuscate, but it is to mutate the raw form and bypass signatures. So we want to try not to have fixed components when we generate the JavaScript code or the new mutated JavaScript code. And we want to try to use common operations. So we don't want to use rare operations that nobody use because end of virus can say, well, this operation, you know, only 0.01% of JavaScript use those and they're mostly exploits. We don't want to have those. So this is basically what makes up of a JavaScript exploit. There's a show code, there's the memory correction part, heap spray and trigger. This is how a piece of show code looks like, basically just a very long list of strings, which converts to bytes. This is the memory corruption part. We're using IEPers as our example here. Memory corruption part and we're using the exploit that's provided by Metasploit for IEPers vulnerability. And this is the heap spraying part and finally this is the trigger. This is the actual trigger that would execute the piece of malicious JavaScript. And then usually this whole part is sometimes, especially in the old days, obfuscate it into a big blob and then de-obfuscate it. So there's the obfuscated form and there's the primitive form, as we've mentioned in a previous slide. And so you would start with the trigger within cause, the de-obfuscator to de-obfuscate the blob and then execute the heap spray and then the memory corruption. So with this entire part, the primitive or raw form, we want to mutate and then for the triggering part, we want to prevent in case we are inside a sandboxed or detection environment. So we want to know if we're inside a sandboxed environment, then we want to prevent ourselves from executing anything. So mutation features implemented so far. We've implemented five main features so far. One is JavaScript random variable auto replacement. It accepts a piece of JavaScript. It parses the JavaScript according to the JavaScript grammar. It identifies old names, including variable names and function names and it auto replaces those variable names and function names with random names. There is already a class in metasploit called obfuscate.js that does similar things, but you have to identify all the names yourself for it, which is very error prone in our testing process because sometimes we just miss some variables or function names. And also when we do that, it just creates a big mess. So we want to have one function call and say this is a piece of JavaScript. We place all the variable names and function names with random variables of our definition. We want every random variable to be of four to 10, 10 characters in length. So right now it's all random. We're thinking by adding a dictionary to it so it doesn't look strange. If you're dictionary of, I don't know, a thousand words, that may work. And passes back the new JavaScript and the vector of old new name mapping. So you know which of the variable is replaced with which name. And this is how you actually use it in DriveSploit. The second one is very, very commonly used. It's called JavaScript concat string obfuscation. So this is how you use it. Basically you call it and you give it a piece of string which can be the shell code. And this is metasploit as you know has a lot of encoders already. But when you're putting shell code inside JavaScript you have a lot of ways to further obfuscate that piece of shell code because you can execute JavaScript. So this is a very commonly used but very effective algorithm. And that is I give you a piece of show code and then you split the strings and then you generate JavaScript that add the strings back and pass me back the JavaScript. So I'll show you how this works. This for example is our show code string. We would randomly chop it according to how you want us to chop it. So for example chop every four to eight characters. We randomly chop it into segments. We would then assign the segments to variables. Okay, to layer one variables and then we would scramble these assignments so that they look like this. All right, so now as you can see the middle section appears first. This makes it very hard for heuristic based pattern based detection algorithms. So that's layer one. And then we would do layer two, right? We would then add these two together into layer two variables. And then we would then again, scramble these. Okay, and we'll continue until we added everything together. So finally, this is a script that will be passing back to you. Of course all the variable names are gonna be randomized. They're just put this way for easier reading. And D one is underlined because we're gonna give you this whole new chunk of JavaScript and the variable name so that you know that that variable name in the end contains your show code string. The third one is JavaScript random text insertion. And what it does is it's also very commonly used in the wild. What we wanna do here is not just, the goal is not to beat end of ours. The goal is to simulate what's been used in the wild so that we can compare technologies. So this function call would ask us to generate, ask DriveSport to generate a random four character string and then insert into the original string for every six to 10 characters. And then we'll return you the new string. And number four is numerical literal mutation. A lot of times JavaScript end of ours is sampled by these fixed numeric literals. And so we'll have a function that's a slack space. So basically you pass us a numeric literal or hex code and we will then generate randomly generate a computation that computes back to this hex code or byte, to this byte, right? So that your JavaScript, every time you serve, every time you serve to a new visitor, your JavaScript is gonna look different every time. Well that's basically what happens in the wild so we wanna simulate that. And so before your JavaScript code would look like something like this, the line above, now your JavaScript looks something like the line below. And then for the triggers, so we finished, we've covered DriveSport for the first part, five features for mutation and now for trigger prevention. So we wanna know if we're in a sandbox environment and if we do and if we're not in a real humans browser we don't want to execute. And this can be done, a lot of times you see you see that the trigger function is set on event handlers, diff on load and image on load. You see more image on load these days. Anybody wanna guess which one is more effective? Diff? Who think it's diff? Who think it's image? Okay a lot more people for image. Somebody say why. All right, come on. Why? Yes, yes, the answer is yes. The answer is image on load is more effective but why? It's, yes. And the other reason is, oh the right answer is image load, well image on load is very effective for some of the newest and very accurate technologies, for example ours. Diff on load is very effective for older technologies that do not implement the dome. Okay, so basically you take spider monkey or rhino and use it as your JavaScript interpreter. These JavaScript interpreters don't have the dome. Newer technologies like JS unpack, a very sign, implements the dome objects themselves, right? So if you're only using a JavaScript interpreter, because it's very hard to reuse IE, so typically we use some versions of Firefox, some versions of either spider monkey or rhino, some versions of open source JavaScript interpreter. And diff on load is very effective for that, for the older ones because they don't have the dome, they don't have dome implementation. Image on load is effective for technologies that really sandbox IE and run IE as the detector. Because, and the reason is, well IE has image on load but what happens is when you're calling millions of pages a day, this causes, this introduces a lot of bandwidth and bandwidth and loading big images is just very, very costly. And so there's a feature in IE to disable image rendering, right? You click on tools, options and you can disable image rendering. When you just, and some vendors do that and when you disable that, image on load doesn't fire. Okay, so they pretty much figure it out what each, what these detectors are, what these detectors are doing to detect them. The third one is very, is also very commonly used. Now it's just some do-while loop, some arbitrary do-while loop. But if you see here, what's here is in a do-while, there's an extra semicolon, which is actually a grammatic error. But IE is so smart that it can recover from that and continue while SpiderMonkey or Firefox just throws an exception. So if you're using some versions of SpiderMonkey, it would throw an exception and then it wouldn't execute. Well, if you're a user using IE and if I'm serving you an IE-based, IE exploit, then it would work just fine. Oops, forgot about that. Okay, so we implemented some of these and then we tested it out. So we implemented these in dry-sploit and then we generated the XML files and then we uploaded them to VirusTotal. And we used IE peers as the JavaScript exploit. The plain IE peers on VirusTotal hit 17 detections and randomizing variables, although it was pretty hard to do considering we had to parse JavaScript, it wasn't really effective. So in Taiwanese we call this bocai. It means too bad for us. When we used random text injection into the show code itself, we brought this down to 13. So from 17 to 13, which is good. When we use random variables plus show code string injection plus concatenation, meaning splitting it up, we ended up with 11 out of 42. So from 17 down to 11. So at this point we pretty much thought that since we reduced six of them, we pretty much thought that roughly six of these inner virus detectors were based on the show code itself. Okay, so when we completely scrambled the show code, we only bypassed six of them while the others was also sampling the rest part of the JavaScript, which included the memory corruption part and the heaps rate part and the trigger part. And so when we used concatenation of show code plus the rest of the code, it came down to one out of 62, which was very good. Oh, which one? It's down here. It happens to be down here. So it happens to be down here. And this one, to be honest, is very good. Okay? And when we used injection of the show code plus concatenation of the rest of the code, just these two simple combinations were down to zero and adding random vars, of course, the same. But, and a virus total uses versions that we use, which is the API version or the console version. But in a virus desktop versions is much stronger. Why? Because they can monitor host environment. They hook into browsers. So it's easier for them to get the raw form of exploit. If you hook into the browser, you can see exactly what the JavaScript engine is doing. If you hook deep into the IE JavaScript engine and as soon as you create a new variable with a raw form of show code, then I can say, boom, you're an exploit. And they can go through behavior analysis. For example, a buffer overflow behavior or download to file behavior, which makes detection a lot easier. So this is the result of our limited testing of drysploit against these end of ours. We listed out, we abbreviated, you can guess. And we tried out the big ones. And as you can see, there was one vendor, which drysploit could not be. As we use more features, for example, concatenation of the show code plus concatenation of the code itself or injection of the show code plus concatenation of the code itself, we start to beat more and more end of ours. It was one vendor worth mentioning. And this vendor, as you can see, it has two scores because the static part wasn't that good, meaning that if we put all the HTML files that's generated and we asked to scan the folder, it couldn't find a lot of the exploits. But when we actually run the IE and have Metasploit serve to us, then it's basically using its HIPs, host-based intrusion prevention system. It was able to take every one of them doing buffer overflows. Okay. So we're originally gonna do a demo to show you how, as we add more triggers, we can bypass, add more of these features we can bypass most of them. But I think we're gonna be out of time and we'll leave time for some questions. So finally, again, this is to be triggering behavior-based encryption. When we turn on this feature and we submit to WebPubWet, for example, it doesn't find anything. And what happens is if you change our eval into alert and you alert it in Firefox, it doesn't show you anything. Okay. But you alert in IE and it shows you what we're trying to do, the exploit. So what we did is we said, okay, we're gonna encrypt our exploit with a key. And that piece of key can only be generated if you are the correct target browser. So if you're IE 7, then only IE, if this exploit is for IE 7, then only IE 7 is gonna be able to generate that key. So as you can see, every browser has a lot of different features and different behaviors. The rendering of CSS is very different from every minor versions of browsers. So we implemented a lot of checks based on CSS rendering, based on HTML parsing, based on JavaScript differences, all these, we put all these together and we came up with a lot of checks. So you would say, okay, this exploit works only for IE 6. Give me an encrypted version of my JavaScript exploit and give me JavaScript to generate the decoding key. And the key is only correctly generated if JavaScript is run under IE 6. So what we would do is we would say, okay, in order to correctly detect IE 6, we're gonna use this subset of our checks, one, three, four, six, eight, nine, 12, 14. All right, and we're gonna generate, we're gonna assign them to each variable. We're gonna generate this piece of JavaScript to be served together with the exploit and we would generate the correct answers. If you are IE 6, the correct answers should be those. And then we would scramble it up. So as you can see, the R value is scrambled up but the L value, which is ABCDE, remains the same and that effectively scrambles up the correct bits, which means although we're serving to a lot of IE 6, we're generating a one-time key for every browser. So it's not like IE 6 has always has the same key because of this randomization. And so we'll use this as the one-time key and we'll encrypt and we'll use server side script which in case Metasploit is in Ruby to encrypt the JavaScript using that key. And then we'll generate this piece of decoding JavaScript. Of course, all the variables are again going to be randomized. And so this effectively is very, very effective right now against most behavior-based technologies because unless you're running the exact version of IE or operating system or what have you, then you're not going to be able to decode this piece of JavaScript. So conclusion, why is it so hard for Nerviris? Because Nerviris is designed to install on desktops and notebooks. So desktop and notebooks have very complicated behaviors, strict resource complaints, and therefore AVs and gateway vendors rely on signature-based technology that has been lightweight and accurate. But JavaScript, especially drive-by downloads, are just in disposable JavaScript. They're generated every time that they're served. Disposable PDF script, disposable ECMA scripts basically. And JavaScript packing is the norm. So you can't say every time you see a packed JavaScript, you're seeing something malicious because people love to pack their JavaScript because they don't want their source code to be taken sometimes. Google has JavaScript packer, Yahoo has a JavaScript packer, and ding at words that everybody uses. And so it's very hard to just use heuristics and say, a packed JavaScript is malicious JavaScript. Okay, how about behavior-based? Such as Honey Client, Sandbox, SpiderMonkey, Rhino, JSON Pack, WebPawette, Python Honey Client? Well, use VBScript, for example, is an effective way we haven't demoed it here. Don't serve to detectors, we demo this part. Fingerprint-based encryption, and also very little but effective techniques, for example, sleep for some time, right? Because if you have to scan millions and millions of pages a day, if you're Google, you don't have time to wait for three minutes to see if some JavaScript executes or not. And so that one line can be pretty effective. Oh, it's not sleep, it's set timeout, but it's the same concept, time-locked puzzles. So future work, what we haven't implemented here that is very widely used is randomly chop up scripts and split into individual files, generating VBScript instead of JavaScript, encrypting using data existing outside of HTML, for example, HTTP headers, so that you can't submit that piece of HTML to an revised vendor, because the key to correctly decrypt itself is in the HTTP header, which is not a part of the HTML. So all these are future work, and drysploit is open source, and we really are looking for contributors to join us. Discussion. And the talk that we heard this morning by a cursory of EFF basically said that 94.2% of typical desktop browsers are unique, can be uniquely fingerprinted. As you know, drive-by download is widely used in targeted attacks. So if the percentage is that high, because in targeted, what people don't understand about drive-by downloads is it's not the technology, why drive-by downloads are used effectively in targeted attacks, not only because of the technology. When it's in a, what's a targeted attack? It's targeted, meaning you're a targeted person that the attacker wants to attack. You call your colleague and say, hey, I wanna know this data, can you send me the email right away? The attacker knows about it somehow, immediately, and sends you the email immediately with a drive-by download. That's a targeted attack. And this happens quite a lot. And so in a targeted attack, this actually can be used because you should have enough knowledge about your target to know what his browser is, and then you can encrypt your exploits so that very few browsers other than his browser and his environment can decode your piece of JavaScript. And that ends the talk. I'm sorry we're out of time for questions, but I'll be sure to answer your questions. Thank you.