 Okay. So it is with great pleasure I introduce a good friend of mine. FX and I have known each other since. Was it DEF CON 9 where we ran into each other out in the pool and I was trying to keep him supported while he was telling me about his talk and I discovered he's a really smart guy. So you're going to learn a lot from him but we have to start with a couple of shots of the Jaeger Meister so thank you. Oh yeah bring more Jaeger. So today we're talking about safer sex online how to get not owned by watching porn. Because the problem being the porn comes in flash fights. So just in the beginning it's a defense talk. So I'm not semantic so I'm not telling you this is going to protect you 100% because defense and security is actually just about making shit happen less often. You can't really prevent it from happening all the time. So this is what I want to talk about here. We're going to quickly go over the motivation of this work. So the five of you that probably said there go like Cisco and then flash what the fuck. This explains why. And then the flash attack surface and who actually has issues with flash security. And I'm getting to the tool demo pretty quickly so you can either switch talks or then sit through the residency how it works. So the idea and this whole thing was actually initiated by a project from the German federal office for information security. In contrast to your NSA our office actually also cares about the citizens and the citizen security. Now they and that's actually their official mission partially. So they care about things like flash and client side security. And so we looked at a couple of rich internet application platforms and flash essentially turned out to suck a lot more than all the others in terms of security. And we tried to figure out how to fix that and unfuck flash without firing everyone at Adobe. Because that just simply wasn't in our reach. Not that I would have not considered it. And then we also discovered that the traditional detection methods actually don't work too well. And I'm coming to this in the talk. And we also we see a shit lot of new flash exploits all the time. And we didn't want to build yet another antivirus engine. So we wanted to build something that is signature free. That is if the code is actually working doesn't require any attention anymore and not constant updating and stuff. So that is the higher theoretical goal behind this work. What type of attack surface are we looking for when we load a flash file into a flash player? Well, the things that usually like didn't break in software when you try to exploit it are pausers like the piece of code that actually takes apart the protocol or file format. And now the file format is actually a container format that contains vector graphics, picture graphics, fonts, sound data, video data of all types and virtual machine code. What can possibly go wrong? Pretty much everything. So let's say 80% of the software is pausing and it's all written in C by people from Adobe. And hence we have a problem. So the first type of person that has problems is end users. Like you get owned by surfing porn. What commonly happens is you have a malicious flash file somewhere in the web page or malicious flash is loaded up while you're watching the porn in the background. And then your flash player plug-in in a browser gets popped and well, you get owned. And this is in almost all cases by modifying the flash file format in a way that when it is parsed, the parser breaks like integer overflows and buffer overflows, basically. You also have functionality-based attacks like DNS rebinding, CSRF style attacks where you essentially use flash to speak UPNP to your home router and open a port so it gets forwarded. Or it is used in exploit toolkits. The problem is 97% of all browsers have flash. And a quote I heard someone saying was telling people not to use flashes like telling people to not smoke. That doesn't work. So what the end user actually wants is something that does Adobe's job, which is validating that the file he is about to load in the flash player is actually valid and well formatted because if it's valid and well formatted, then it's probably not going to make the flash player fall over. And if you can guarantee that it's well formatted, then you probably have a file that you can watch without getting popped. The thing here is that you actually really want to have that in your web browser on demand. And for end users, performance of such a method for protection is actually critical as a v-vendor to snow all the time because people hate to wait for their porn. So if it loads slowly, then it's not cool unless you grew up in a mailbox times, then yeah, you were used to seeing people in pieces. The other group of people that actually really suffer from flash attacks are website owners and ad networks. Interestingly enough here, it's not file format based attacks that they're concerned with. It's actually functionality based attacks. So, you know, there is program code and flash files. And of course you can program your banner to go to a non-malicious URL. Hello. To go to a non-malicious URL. And then it gets uploaded into the advertisement network and they click on it, they test it, they see it's fine. They put it out into the content distribution network and then your banner changes behavior and forwards users' browsers to malicious sites. That happened to a couple of news media sites including the New York Times. So it's an actual problem for them. Their requirements on flash security are somewhat different. Share well formatted files is also of interest to them because it helps the people testing the flash files not getting owned. But desired is also the ability to say, well, contractually we give you banner space to forward the users that click on your banner to this particular URL. If you're diverting it, if you're forwarding them to a different URL, you're violating the contract. The problem is today they can't verify that they have to trust the code because they get pre-compiled flash files. And it would be nice for them to say, well, we enforce that the code actually cannot do anything else. That, of course, is more computational expensive, meaning you need more CPU power. But that's not a big problem for them because they will run at server site. They will actually run a verification process the moment the flash file gets uploaded. So we have flash provides its own security. Not. There is some configuration, right? There's very limited configuration options. Like you can turn on and off the camera for whatever that helps you if you got owned. And there is the possibility to disable a lot more things like disable file uploading or downloading. The problem is that sits in some configuration file that nobody actually uses. What the hell is going on in that next door? Do they have naked chicks or something? And another thing that flash simply doesn't have in terms of security is proof of origin. So there is absolutely no way that you can tell what a flash came from. There is no signature mechanism whatsoever. And then there is AVs. So here's the thing about AVs and flash. Flash files can be and most commonly are zip compressed inside. Like the whole thing is zip compressed. They can be uncompressed, functional equivalent. It's just that it's compressed. So when you take the most common malware, Gnita, it is called, no idea who came up with that name. If you upload that to virus tool, you get a coverage of about 70%. Now this is the compressed file. If you simply uncompressed the file, it's still the same file. It's just unzipped. And you upload it again, only 8 out of 40 AVs even detect most common flash malware that we've ever seen. So AVs are an epic fail when it comes to flash. Okay, I'll scratch the part when it comes to flash. So we had an alternative approach on this. So what we provide is a straight command line program similar to command line AV. And what it does is you give it a flash input file that is potentially malicious and you will receive an output file that is hopefully not as simple as that. The idea here is that we actually run complete format verification on the file and then produce a new file for you. And how do you use that? Well, we figured that we first with the release are going to target people that are security conscious anyway. So I thought if you're surfing with the IE6, then you probably don't care about flash security because you have other problems. But if you're surfing with Firefox and NoScript, then you're probably aware of a few of the things that happen on the internet. And so you're probably more helpful as a target customer group. So Georgie Omo, the author of NoScript, was nice enough to build an external filter interface that I proposed to him. So you can hook up other programs. You can write your own programs now that will do filtering of specific mind types. And then you can hook them into NoScript with no coding whatsoever. But he built it actually for us so we can integrate our BlitzApp later into this NoScript thing. It required a lot of work on his side and it's currently up and running. If you're up on the latest version of NoScript, you already have that option and you can configure it. And at this point, we would like to thank Georgie very much because it's not like we had to back him or something. It was sending him one email proposing this and he's like, it's cool. And then he started writing code. I think I forgot to mention one thing. The name of the tool BlitzApp later is a German word intentionally. Just to make it harder for you guys. It is the term that we use for lightning rod because it turns dangerous lightning into pretty flashes that don't kill anyone. So that's for the name of it. So here's how the NoScript integration looks like. It's really just the external filters tab and then you choose the EXE file. And he also integrated it into the context menu. So for example, if the tool will not allow you to see a certain piece of porn and you really want to see it, it's one click away to say for this side, don't run a filter. I want to get owned. The shake is just too hot. So if you want to integrate BlitzApp later into web pages, that's also a trivial thing since it's command line. You're just running it on the web server when the upload happened and check the return value, the operating system exit value of the program. Works the same way every command line AV ever worked. Depending on the feedback we get, we're going to set up a XML RPC or a SOAP or whatever service so you can use Ajax or whatever to send flash files first to us and then get the flash files from us into your web platform. If you want to have such a service being implemented, then please contact us, drop me an email, something like that. It would be easily doable, but I'm sick of doing stuff that nobody wants to use. And it's open source because I don't believe in black or yellow boxes that promise to make me secure and someone else rich because they usually only fulfill the second requirement and that is not good. So I believe that we should actually start applying Kerkos principle from the cryptography world to the defense world saying if you use a defense mechanism you have to be able to verify that it actually does what you're expecting it to do. And for this the source code is very helpful. We would also love to see integration into other pieces of software so you're welcome to sign up and get the source bomb. That's the URL but it's going to be on the last slide anyway. And now I'm going to show you the thing in order for you to judge whether to listen to the second part of the talk or not. Now how do we do that? Yeah, there's a window coming. So this is my very, very small version of the internet. It has a glass martini and two exploits. So let's first look at the glass of martini. This is what NoScript is supposed to do right? Like it prevents the shit from even executing. But if I choose to actually want to see that it is loading flash and it's taking like on this shitty laptop network it takes about like nine seconds until I get my glass of martini. So this is you can verify this is flash but seeing the options that I don't see right now. Yeah, I don't have it on my screen here so it's kind of funny. Are you, is that the back button? Cool. So here's an in the wild exploit. For relatively recent vulnerability as you can see I'm going to fire this and so nothing happens on your site but on my screen which is the primary screen I get a pop up that looks like this. And it explains that this exploit didn't even bother to set the length fields in the first header like the first length field ever in this entire file to set that one right. Which speaks volumes of like the flash player parser because that would be accepted. So you see two buttons you can just hit escape and it disappears but to the left there is also a button that says like tell the people they suck. Which sends us this lock because if we filter the porn you really wanted to see then you can complain by pressing this button. So and then you get a replacement file. You can actually configure the replacement file so if you want to flip the finger at exploits you can do that. Let me see that button. Cool. And here's another one I actually like had to figure out what the vulnerability was and write this trigger for the vulnerability myself. So this one actually cares about setting the length fields correctly. And here you see a well first I see it. A more concrete example of how far we go down. I'm going to mark this here. Yeah well I had to mark it first. So this is where we actually go down into the byte code and one of the individual byte codes had an invalid argument which will exploit the flash player but the format verification would have caught it and would have caught it before the vulnerability was found because we are verifying the entire format. So this is what you get. Are you impressed? Now let's see if I can get this back to presentation mode. Awesome. Didn't work at Blackhead. So now that you know what you get let me explain how it works. So what is flash in the insight? Other than fact. As I said it's a container file format. But it is heavily version dependent. Every data structure in this file format is extremely version dependent and the version is set right in the beginning in a header. So the file declares what version it is which influences a lot of things how the flash player behaves but also how the data structures look like. The problem with flash or one of the problems with flash is it's all the way backward compatible to version three of the file format. So as someone said trying to be backwards compatible is like trying to stay close best friends with all your ex-girlfriends and we know how good that works. So that's a real problem. I already mentioned that you can compress flash files but that really doesn't matter too much. In principle the file format is composed of tags and tags are simple type length value data structures like containers in which then specific data structures for this tag type reside. A few example of tag types. You have control tags. You have essentially like start and end the movie and set label symbols. Then you have things that display objects and we're going to talk about these more later. You will actually notice that those tag types here they have something like they have numbers behind them sometimes. So place object and place object two are two different tag types. In place object two actually doesn't place two objects as you would first assume but it's their second attempt to get the data structure right. By the fact that we have a place object three you see how well that went. And that's a reoccurring pattern in Adobe's design is like even op codes have second and third versions. We also have bitmap data. You see there is a defined bit JPEG two and three. I don't know like how hard can it be to not fuck up a JPEG data structure. But anyway. And they have a special tag type that is a button which is nothing else than a shape but it has functionality connected to it. Here's an example of a data structure. So they tend to lend themselves very nicely to buffer overflows and integer overflows because they have a shitload of length and counter fields and they're all 32 bit long. And they can easily contradict each other by design. Which they well if you said in this case if you said one of the line fields on a negative value as marked out demonstrated in 2007. You can exploit the flash player. One of the many ways you can do that. So what BlitzApply data does is what I call normalization through recreation. So we ensure we parse everything that we find. In the greatest detail we can possibly do. Based on the specification we're really strict on enforcing that all the cross references and all the relations between length fields, pointers, indexes all that are really, really completely tested and completely understood. Once we did that and code makes sense of the porn, we throw away the original file and create new porn based on the information we parsed out. That has the benefit of providing perfectly clean porn to the flash player so you don't get owned. It also makes writing stable exploits a bitch because all the offsets change all the time. And that's essentially what we do and that's essentially what I call normalization. How do we do that? So first of all we're writing yet another parser for flash so we don't want to increase your attack surface. We want to decrease it, right? So we better not write the parser in an unmanaged language. We're using the .NET runtime to ensure that things like out of bounds and integer overflows will be called by our runtime and not by our code. If we would check for all the possible integer overflows in a file format manually and C code, we A would fuck it up. Well, I most certainly would. And B, it would be a lot of code. Why would I do that? There is a runtime for that. It also means it runs nicely on Linux and BSD because it targets .NET 2.0 so it's perfectly binary compatible with Mono 1.2 which is currently shipping on most Linux platforms and, you know, Mac users can kiss my silly ass. It was their choice when they bought it. So for all the TRV data structures that we have, not just attacks but everything that is like type length and then block, we just move it into individual memory streams and operate on those memory streams because then every out of bounds operation will actually throw an exception and it does. The parser only accepts data structures that are documented in this file format specification which unfortunately is not very commonly updated. So if there is undocumented op codes or any other bullshit going on, we're going to reject the file. And the parser also verifies all the version dependence so you cannot claim to be a Swift version 6 file and then use some advanced functionality from version 8. Here's an example on why running on a .NET CLR is so cool. The exploit I mentioned before, 270071 from marked out. If you're trying to read this into Blitz App later, this is in the code where the actual exception is triggered for the negative value of the scene count. So the run time caught it right there when we parse it and that is fantastic. And this is what you get as an output later on. Let me tell you a little bit about the Adobe virtual machines within Flash. This is fun and also a history lesson on how to not do stuff. So the Flash player actually contains two virtual machines, completely independent two virtual machines. They're respectively called AVM 1 and 2. AVM 1 is a historically grown thingy that they came up with in Flash version 4. And something about like 80% of the Flash on the Internet are still AVM 1. AVM 2 is a virtual machine for ECMA 262 JavaScript specification. But of course the VM is completely by Adobe's design which is not necessarily good. AVM 1 is programmed in action script 1 and 2. That's what most web designers use. In action script 3 is what is closer to JavaScript. And it's not so widely used in a, you know, I call them RGB caspers like people that make blinking web pages. So they struggle to understand OOP. So the whole JavaScript object and event handler idea just escapes them. They stay with AVM 1. That's the reason why we have so much code there. So I said it was introduced in version 4 of this web file format. It was already a Turing complete stack machine with very abled stuff. But someone must have left university after the first course. Because all the data and like the only data type it could do was string. So if you would add two numbers you would actually push two strings onto the stack and then the add instruction will try to make sense of them to a number and then add them and then push back a string. In version 5 they realized that's actually the idea. Introduced type variables. And also introduced a constant pool. Someone must have made it through the first 20 pages of the Java specification. And they introduced objects and methods. Which, is that good? Yeah. Which then in version 6 they discovered that objects actually need to be initialized before they run. So they introduced attack type for that. And they actually, since they introduced versions they now discovered that it would be called to check, they introduced types and now it would be called to actually check what type a variable is. So they introduced that. And in version 7 then they added new functionality to their objects. For example they discovered exceptions. And type casting. And object inheritance. Version 8 never happened. I don't even want to know. And version 9 then brings in the AVM 2 with a complete file format within the file format. So they have a complete new file format that is called the ABC file format that goes into one new attack type. And so you have yet another file format in the file format. And then version 10 is what we're currently watching the porn on. Now keep in mind this is all still supported. Back to destroying additions. So where would you actually look for code within a flash file? There is a type called do action. Sounds like one. The majority of the AVM 1 code is supposed to be there. And then there is the do in action attack which I said is used for the initialization of objects. But can contain pretty much any code you want. Like there's no restrictions that are put into place by the player. Then there's the buttons I already mentioned. So the define button 2 tag contains a button record to data structure that can carry conditional button count actions which is actually blobs of code. So you have a graphical element in a file format, a vector graphic element and you attach a piece of code to it. Now they obviously really like this idea. Then went back to their fridge with psychedelic drugs, took some more and specified the same behavior for shapes. So you can actually have two shapes like a star and an asshole. And if they overlap, they clip. So clipping is when one of the shapes is not completely shown. For which you do clipping calculations. If those clipping calculations happen, the asshole can actually have code attached to it that is executed when it gets clipped. Isn't that nice? So you actually have to parse the entire vector graphics definition, sorry, to get to the code that is executed when someone like moves the mouse over it. Many security tools that we found and other tools actually don't parse that part of the code. They only parse the main part that is in the do action attack. So you can totally smuggle code away. The code itself, like the AVM-1 code, is variable length instructions. We all know how great those are. It has signed branch targets, 16 bit branch targets, which pose a problem. And then there is the two sickest things I've ever seen. So if you want to define a function in every other executable format that has the notion of a function, you will have a separate area where you say this is where I define my functions, this is what name it is, this is where it starts, this is where it ends. In AVM-1, it is an instruction for the virtual machine. So functions are defined by executing them. There is an instruction that says I'm a function and the next like 20 bytes is code of me. And then the interpreter just like the virtual CPU just like goes over the 20 bytes, reads them in and there is a new function. This of course can be nested and they can be executed in line so you didn't find a function as right way executed anonymous functions. So this is just totally off the record sick. They liked it so much that they implement their try catch finally blocks the same way. So there is an instruction that defines try catch finally in line when executing. This is obviously has a lot of design weaknesses. So to verify code the first thing you want to verify is it doesn't jump in the middle of an instruction. Many of you have probably seen that in X86 code being done for obfuscation. You can totally do that in flash as well. The funny thing is you can also just jump into the tag right before you in the flat file and execute some code in your MP3 or whatever. Like hide your code in the nipples of the porn and then jump right there in the image data no problem. They do that. The 16-bit branch offset is also an interesting design decision. So I was wondering when you have 16-bit signed you can only jump over like 32K right because then your bits run out. And so I was wondering what they do if you have an if statement with a large buddy. So I took the official Flash Player development environment latest version CS4 and made an if statement with a large buddy. It perfectly never complained. It produced a flash file. It is perfectly invalid code because it jumps as far as it gets and executes the rest of the body. The various length fields in the instruction set allow you to hide a lot of data in the tail of the instruction. And that's commonly done in flash code obfuscation software. So, and as I said, the order of code execution is highly dependent on where the shape of the asshole currently is. So this is where BlitzAppLighter comes in and disassembles the whole thing and verifies a lot of things. So what we do when we disassemble it, the first thing we do is we go from byte offsets to instruction indices. So all the disassembly is an array and if your byte offset actually doesn't resolve into a index in our array, then you're jumping somewhere you shouldn't jump to. And they are verifying the code flow stays within this code block and we verify all kinds of crazy shit about like this function declaration bullshit. So you're not overlapping and, you know, all of that. And down to things like our all instruction, only part of exactly one function. Stuff like that. We just make sure it's good. Now, once we make sure it's good, we still have that problem that remember when I talked about the ad networks and people that receive flash files. For them it's not a male found flash file but functionality that can be implemented in flash AVM. So how do we actually get functional attacks to not work anymore? Now we have a nice entities with file. We could run static analysis on it but static analysis provably will not resolve all possible cases. So it can be shown that we cannot possibly predict what the code is going to do. It's called the halting problem. Look it up. If we try to emulate it, we will run into the problem that our emulator does something and the flash player does something. And if our emulator isn't sick enough to be Adobe compliant, then we're actually like going two different ways with the code. So that's also not a good approach. However, when you do runtime analysis, like if you have the specimen, what you usually do runtime analysis anywhere in disassembly, you set a break point at the point of execution, let's say the sys call. And no matter how much obfuscation was going on before and how complicated the argument was compiled together, at the point of the sys call, you just set a break point and you see what the argument was. So we want to do the same thing with the flash files. The problem is we're not part of the show anymore when the porn gets played, right? We already produced an output file. We are not debugging the flash player. But what we can do is we can actually patch the AVM code to do the check we wanted to do right at the point of execution. And this is what we do. So here's an example. There is action get URL to second attempt in getting the opcode right. That actually is the most common function that forwards your browser to a different URL and is used by most of the downloaders, like the flash downloaders that just download like scareware onto your machine. So when we handle the flash file, for example, we know its origin. We know where it came from. No script passes this on to us. So we can actually patch more strict same origin policy checks into the flash code itself than the player would actually do. And this is how it looks like in a code flow graph. So on the left-hand side, you see a basic block graph of AVM 1 code. And pretty much in the middle of it there is a block with the ID 31. And this is where the actual execution of the action get URL happens. And before that, he's pushing the arguments on the stack. In this case, for example, it's pushing arguments out of the constant pool on the stack. So I'm coming back to those cases in a minute. But just notice that there's this one block where the actual action is fired. All opcodes start with the word action. So don't feel silly or like a movie producer when you work with this shit. It's totally normal to say action every five minutes. So when we patch it, this is what comes out. So you see that the one basic block with the ID 31 was split into three. The upper one, doing the validation and a string comparison, a string comparison between where the flash file came from and where it wants to forward to. And then if it's happy with the comparison, it forwards the browser. If it's not happy, it's just cleaning up the stack and not doing it, which is what we wanted. So just to give you a feeling, there is a complete assembler for AVM 1 and 2 in Blitz Upliter. You can write flash assembly and text files and use that as replacement. So you have a pretty high level of freedom. So this is the assembly for AVM 1 to how it calls methods. And on the right hand side, you see all the instructions you need to execute to even figure out which method of which object is called. So you see it's a lot of code that goes into just finding out what the method of the object was. And if you actually decide to not call the method of the object, that's the amount of code that you need to clean up the stack and do stack unwinding in AVM 1. So when you apply this to a piece of malware, example, Gniter, you see two, this is the complete code of Gniter. The one to the left in blue is the original code. The one to the right is the same code and all the red dots and places you see there. This is where we patched in additional checks automatically. You see it's quite a code inflation. So we're looking at 250 percent code inflation just to check that it's not doing something evil. I mean, it's still nice because it totally protects you. Every single call is protected, but it inflated the code way too much and so maybe the porn starts no longer being fluent. And you also run into problems with the signed jump targets because the stuff you patch in is too big so you can't jump over it anymore. So therefore, we introduce static analysis into it. We can provably not determine every single call argument, especially not to dynamically generate it, but we can try to prove the static generated. We can prove staticness for individual arguments. For that, we just need stack tracing. So what we do is we trace the stack back on the individual instructions and if we can tell it's a static argument, then we do the check right there and don't patch the check code into the flash file. In order to determine the values, we actually need to obtain a code flow graph as well because of course the constant pool is not part of the file format, but it is another instruction. So since the constant pool creation is an instruction, you can actually overwrite your own constant pool in your own code. So we actually have to do a complete code flow analysis in order to figure out which constant pool currently is on. On top of that, we're still a bit working on, but it's already part of the code, on higher level verification. So you can essentially say, this is the object, this is the method, and I want to have the following string comparison with the second argument of this method call, no matter if it's AVM one or two. And how that works right now is we have our own virtual machine, actually two, which get executed with individual parts of this question, like give me the second argument to this instruction here. So, and there's two possible cases. It's a static analysis engine, so it executes this step and tries to figure out the second argument. If it cannot provably figure out what the second argument is, or it can prove that it is a dynamic argument, then it will emit the respect, then it will stop execution, and then we run the same process again, but in a different mode. Instead of trying to prove staticness, it will actually emit the steps that it took in the first run as AVM one code, or AVM two code. This allows us to have very small pieces in those steps and ensure that our static analysis tests we do in the actual AVM one code are functional equivalent, because otherwise we run into the problem that we test something different here than there, and that's not very useful. So, we recently introduced AVM two into Blitz Sublighter, so both AVMs are now covered. There's an interesting bit about the AVM two specification, the ABC file format that I said they put complete file format into the file format. So, there's an interesting thing here that was apparently one eyed guy between all the blind, and he wrote this back, so he tried really hard to be smart, and he actually had a good trick to prevent all his less talented colleagues at Adobe from having integer overflows. He will actually put all the length fields and counter fields at 30 bits, not 32 bit. So, if you're an untalented programmer, you can add four of them and still not have an integer overflow. That is actually pretty smart. However, when you take the official entamerine is the open source implementation of AVM two, and it's pretty much the official thing, so it's Adobe people writing it. When you look into that, how they parse it, this is their C code, of course they've write it in C, nothing can possibly go wrong. This is how they parse the 30 bit field, and if I may direct your attention to the third line at the bottom, they're actually parsing 32 bit. So, this one guy was actually pretty smart, but yeah, he was pretty alone. Other than that, AVM two is design wise a lot closer to its predecessor as it should be. They finally figured out that you should have one constant pool, and they finally figured out that you should not define functions by instructions. I'm very grateful for that. The stack tracing is a little bit harder, but it's, yeah. So the end goal is to really have it all unified for whoever wants to enforce rules in the code that the definition is high level enough for them to model their contractual requirements into actual code patches. So, what happens when we use our tool? So far, not a single exploit that we have a specimen of actually managed to pass through the BlitzApplyter tool. Most exploit code I've seen in a demo doesn't even bother to set the line fields right, so we cache it very early. But even those fixed actually never went through. There's two where I don't have an actual exploit which pretty recent from this year that exploit JPEG parsing, so they even managed to fuck up the JPEG parser. This one will, stayed right now, still pass through because we're still not validating media content within the flash file, but all the others were blocked. And all the recent vulnerabilities that came out were automatically blocked because we don't need fucking signatures. We're using it for a while already. It does play porn, YouTube works, U-Porn works. Yeah, and just in case something doesn't work, you can also turn off individual tech type parsers. So if you find that the tech type parser for funds misbehaves on you, you just turn it off in a configuration. And remember, there's also the complain button. Flash files with code obfuscation employing like hulu.com will get rejected because we cannot prove that the code flow doesn't do anything shitty. And this is why you can configure exceptions in NoScript. Many third parties with generators produce plain other bullshit simply because the flash player doesn't care. We do, so yeah, if you have third parties with generating code anywhere in your company, I would be grateful if you would try whether it's eaten or not. And if it's eaten, then go beat up the people that create this flash. At this stage, we really need people reporting compatibility issues. So if the tits are green instead of blue, complain because that's something we cannot automatically test for. And there's just so much point you can watch per day. And it's also highly annoying. So we only, like it's HTTP, you can sniff what we log when you press and press complain but it's just what you see in the dialogue. But I would ask you if you're trying out this tool, really complain if shit doesn't work, otherwise we can't get it to the perfect stage where we want it. If it does this to you, I also want to know. But the complain button was sent to Microsoft so you actually would have to send me an email or go to the website where you can file a box against me. Oh, I'm already at conclusions, great. So essentially, we're pretty confident that Blitzablighter, by principle, first and foremost shows that signature-free recreation is a valuable way and alternative to detection paradigm, to AVs, by enforcing, by having secure parsers in managed languages and enforcing a structure that is documented and is tricked. You make it a lot harder for people to get through this to the broken parser at the end where you feed it to. We also think that automated code property verification and enforcement will be really, really interesting and useful for people that have that requirement and are also more applicable to other file formats. And we hope that this tool will actually decrease your attack surface and will allow you to not get owned when you surf porn. Here's a couple of people working on this. Robert is one of our interns. He works on this code quite a lot. He hates Adobe as much as everyone else who wrote parsers for their file formats. Dirk is the guy who actually managed to free time for me so I can work on it. And Mumbai is just general awesome and actually placed tonight at the freak show. So if you want to hear some good electronic music, come by. And that was it. And I think I even have time for Q&A. And I have one more Yega Maistat. Okay, first question gets it. Gets it. What's the question? Proxy integration for Squid is trivial. It's just command line. It really runs, you know, you can put it into Squid and to filter interface because it takes input and output. That's absolutely trivial, but you can also link it into other code. It's a library. More questions. Did the goon just steal? Flash Block is another browser plugin. What browser is it for? Oh, totally. Well, the point of giving this talk is I want feedback and people that want to integrate it, that's the whole reason we make it public. And believe me, it's a lot of code. So I would love to have anyone who wants to integrate it anywhere, even in their, I don't know, pocket lot. So you think we should actively go out and seek them out? Okay, yeah, I try it. More questions? Any Yega Maistats for me? Did we have issues with the Adobe documentation of the Fire Format? Are you fucking kidding me? Of course we have. They have like the IRATA for the Fire Format specification for ABC for AVM2 sits on a fucking Mozilla Viki without being linked to from anywhere. Like it requires some real Bing Voodoo to actually get there. And then it contains things like, oops, those were actually indexes and not full strings. Yeah, I noticed when trying to parse it, fuckers. Yeah, so that's my biggest thing with Adobe right now. I'm trying to get them to collaborate so we can tell them where our reading from the spec and the reality goes like this way. Because for example, on Adobe's site on the DevNet for Flash, where they showcase Flash in the samples, half of the samples violate their own specification by not declaring the exception handers they call. Does that answer your question? Do you wanna go to a Q&A room? No, no problem. Okay. Do we have time for one more? You have time for one more question. Do we have one more question? No? Well, let's say like get the accurate specs to expect to be able to maintain this long term. We're expecting to improve the relationship with Adobe and get more specs. Okay, thank you. Let's get drunk.