 Holy shit. Can you imagine two Stego lectures in a row? Who in the hell playing that, right? How many of you have sat through the first one? All right. How many of you have been to sales before? All right. For those of you who have ever bought anything, okay, we got everybody now, right? You got to hear it a lot of times to learn it, so I didn't know I was following a lecture on Stego. This should be fun. I'm going to get to repeat everything that you've already heard. I'll do it quick. I'll try and keep it as unboring as possible and get you guys out of here, because God, is it hot? Who's hot? Feel free to remove your shirts as necessary. It was an open offer. Somebody's got to say it. My name is Mike Rogers. I'm going to be lecturing on Stegengraphic Trojans today. I'm the senior security engineer for exceptional software strategies incorporated, a Baltimore-based security and software development firm. Who's from Baltimore? Suckers. Yeah, me too. What's that? All right, yeah, we'll get to you. When I can hear you, we'll do it again. All right. If you have questions anytime, raise your hand. I'll try and get to all the questions as much as I can. I'll try and go over all the cerebral stuff as quickly as possible and keep you guys entertained to some extent. All right. What is Stegengraphy? You guys should probably already know this courtesy of a substitution, which was great. Really stands for covered writing. That's what it means. Earliest examples date back to 440 years before Christ or whatever else BC stands for. It's lately become a hot topic in the information security world in the last five years, give or take. It's one of those things that kind of has to get reinvented continuously. And since 9-11, this has become an enormously popular topic, primarily because of the use of private communications and et cetera, et cetera. What is Stegengraphy used for? Primarily used for secret messages. If you want to know more about it, ask your school kids or your neighborhood terrorists, because they're the ones who are using this shit every day. It just kind of happens that way. All right. How many of you are parents? Yeah, they're doing it. Yeah, I can tell you right now. All right. The anatomy of the Stego process, fairly simple. Couple of components. These are the things you've got to have regardless. The first thing is a cover document. That's going to be what you're going to hide your information in. You're going to have a secret message, whatever it is you want to get to someone else. And the Stego key. The Stego key is the process by which you're going to perform the encoding into the cover document. And then what you may want to have is a cryptographic key. Now, the idea of steganography in and of itself is not to obfuscate data like cryptography does in that if it's recovered, no one really knows what the hell it means. Instead, the concept is to try and make sure no one really even knows it's there. And so by nature, the material that's placed steganographically into any cover object is typically going to be in clear text. However, because of security issues and because we're now getting better and better at steganalysis, more often than not, we're finding people are beginning to cryptographically change their data. So that way, even if it is recovered, it's pretty much useless, give or take. All right. What this will produce or what this will give you is what's referred to commonly as a Stego object. Couple of steganography protocols. There's three primarily. The first one is called pure steganography. It's a steganographic system which does not require the exchange of a predetermined steganographic key. That means that I'm going to steganographically encode something and I'm going to send it out and whomever my recipient is is going to steganographically decode that without ever having privately communicated with me and tried to understand what my Stego key is. We have secret key steganography. It's very similar to a symmetric cipher. It's a one-way cipher in which we steganographically put the data in in a predetermined cipher method. And then of course the recipient has to be aware of that secret method. We have to try and get that to them through some kind of privatized channel or secure channel. And the following, excuse me, the encoding method is the Stego key has to be known as I said both sender and receiver. The last version is public key steganography. This is becoming the real big topic here. It requires two keys, one public, one private. It's built just like PKI. In fact, a lot of public key steganography is actually structured on or built on the backside of already existing public key infrastructures that are in place. And those public key infrastructures actually are facilitating for all the steganographic data. Steganographic techniques. There are six altogether. There will be a quiz later. No, I'm kidding. Please. This presentation, incidentally, I apologize. I did not mention it earlier. We'll be posted on the internet. Unfortunately, I didn't get into the conference in time to get it onto the CD. I was kind of a latecomer. So it will be available at exceptionalsoftware.com forward slash defcon. But you probably need to give me about a week or two once I get back across the country and get it all put together. But then this presentation will be available. Okay. The first of your six techniques. Substitution systems. Transform domain techniques. Spread spectrum techniques. Statistical methods. Distortion techniques. And lastly, cover generation methodology. So let's get into these in a little bit more detail. The first one, we'll actually talk about tools first. These are almost all substitution tools. The vast majority of what you'll find commercially available are going to focus on substitution. It is far and away the easiest methodology for doing any type of steganographic material. The footprint for any application that runs this is fairly small as a general rule because of the principle of how the stega works. As opposed to getting into some of the other methods which get into much more cerebral and much more mathematically structured programs. So the common tools, a lot of these you've probably heard of stegodos. S tools is another one. Mandel steg. Easy stego. Anything that says easy, probably stay away from. Anybody here write that? Good. Okay. White noise storm is another one. And steganose, that's probably the one that I think most people seem to be aware of. Steganose is not free by the way, but for some reason, lots and lots of people have heard of it. Alright, let's talk about the first method. Substitution systems and bit plane methodologies for dealing with steganography. It deals with the least significant bit substitution as one of the methodologies for which we deal with this. When you're doing the least significant bit substitution, we take whatever our cover document is going to be. Be that JPEG, TIFF, it could be a BMP, it could be an AVI, WAV file, MP3. You get the picture. Pretty much anything that's digital data. And we're going to take the least significant bit of every single byte that's built into that structure and we're going to change it. We're going to modify that bit so that when they're all recompiled it's going to build together our secret message. In some situations we'll actually take two bits, it just depends on the nature of the material that we're dealing with and it depends on the tool that you're using to do this. We also have image downgrading. Now image downgrading is a little bit different than dealing with least significant bit substitution in that we generally just downgrade the entire quality of the image altogether. So we're not going to substitute only one bit, we're going to substitute four bits for every byte and each one of those four bits is going to represent the four most significant bits in whatever our secret message is that we're hoping to get across. So what actually happens is we take a standard picture that let's say maybe 32 bits and we're going to move that down by four to the second, four squared, like 16 bits as far as the quality is going to come down. Pseudo-random permutations, that was just a lot of fun to say which is why I put it on the slide. The way this works is it doesn't actually use a structure. It's algorithmically generated mathematically so that we take random bits and random bytes from all across our document and we're going to replace those with a steganographic material so there's actually no formal structure. Now the benefit to this is so far as using a substitution methodology for Stego is that this provides a less likely to detect statistical analysis. The problem with a lot of steganography and while we look at an image it appears to be completely innocuous and we really can't tell unless we're pretty good at it that that object has been steganographically embedded with something. But computers are really good at it and the reason is because of all these substitution methodologies it's very common to produce a central statistical model that will actually tell you through a steganalysis process where the actual data is. Now you may not be able to retrieve the data but you will in fact know it's there hence why now cryptography is becoming such a big issue. So pseudo random permutations randomly places your secret message across the document by performing some mathematical computations that allow it to determine an appropriate structure. Palate-based images, again it's where we take an image only now we're going to focus on a single color and take any one color you want. Grayscale images probably seem to be the best because you've got 256 shades of gray and if one of those shades changes across the board it's almost impossible to detect for all intent purposes especially through the eye. So that's one of the big benefits to dealing with palette-based images. Binary images would be the last, no maybe not, binary images is on here. Binary images is primarily used when we're dealing with fax data actually for using programs like WinFax and BitmapFax and things at Cheyenne and whatnot. If you're sending fax, the interesting thing about the way fax data is actually transmitted across the wire when it's sent from a computer-based fax station is that it has an enormous amount of redundancy actually structured into the faxed page. As a result of that redundancy we can alternate the black and white pixels that are actually structured in for redundancy purposes and we can encode our message in that without ever actually affecting the text whatsoever. So it produces a fairly difficult way to detect what's going on but it's limited in its functionality to primarily fax communications. And Slack Space, everybody's favorite. If you're not sure what Slack Space is, if your computer allocates 32K for any individual file and you create a file that's 2K, you got 30K wasted space in that memory buffer in that hard drive buffer and that Slack Space. You can actually hide data inside of there and use it for hiding purposes because it'll never show up in the system. The bad thing about using Slack Space, digging it graphically, is Slack Space will ultimately increase the size of the file if we use it and we can go up to that 32K without going into another allocation unit and by doing that we can still hide the existence of our data. But it's probably the least popular way more often than not if you're using Slack Space, typically it's because you're hiding your own stuff stuff that you don't want feds getting a hold of and things of that nature when you're hiding it on your box. Transform domain techniques. These get very, very cerebral so I'll try and keep this very short and very brief. This is a discrete cosine transformation. Basically it takes the coefficient of two binary objects and it calculates the cosine and then it adds them together and multiplies them and subtracts them and divides them and just about any other mathematical computation you can put together. And it ultimately creates a calculation and it will actually use any two objects whose cosine will produce the same leading coefficient in the answer. So it deals with a whole mathematical process for how it's going to encode the data. Again, basically it requires an enormous amount of processing and requires an enormous amount of overhead so it's not necessarily very popular. Phase coding is another, it deals with a similar process where we're actually doing a phase shift on the data. Phase coding is probably used more often than not when you're dealing with audio objects in some way, shape, or form but we can actually produce a phase shift on all of the audio objects that are being sent out and that phase shift will actually carry our message or represent our message. Echo hiding. This also is another audio object. I want to caution you a little bit about steganographically injecting anything into audio, however. It is said, and I don't know, my hearing sucks so I'm not really sure on it, but it is said that the human ear can detect any kind of distortion in audio at one part per 10 million milliseconds or some obnoxiously ridiculous number like that and you can actually detect any discrepancies that are going to be in the volume or in the file that's coming back. So echo hiding and even phase shifting gets very, very tricky trying to actually keep that data secret. So I really try and stay as much away from that as you can. MB3s are kind of changing that because of the compression factor and we're actually working on and developing new ways to hide data that won't affect the quality of the image but we're still in the early phases of that research. Spread spectrum technologies. If you're doing anything spread spectrum, we're just going to do a frequency hop and the frequency hop, actually the change in location through the frequency actually is what represents our data and that can be recompiled as a result of tracing the frequency hopping. A lot of this stuff was used for spies in 1940s and World War I, World War II and stuff like that and a lot of it doesn't necessarily get used heavily today but just a quick overview. Statistical methodologies. This again tries to fight the Steganalysis perspective that what you're dealing with is a statistical model for how data is manipulated. We try and take what's called a one-bit steganographic scheme so that it's not necessarily going to be statistically sound. We extrapolate that into an 8-bit by 8-block structure and then those 8-bit by 8-block structures are actually located randomly throughout the data by using a basic RAND function. Once that's done, almost any statistical analysis on the document itself is not going to detect the presence of the steganographic material. Now there's a downside to this and that is that it doesn't necessarily guarantee the quality of the object that is the cover file. So if you're using a JPEG or a TIF or anything like that there's a very good chance that if someone were to look at that object it may look a lot like it was done by Picasso. Alright? So anybody who knows Picasso got that by the way. Distortion techniques. This is how we actually distort data to produce objects. Line space encoding actually varying the space in text files between spaces or between lines of object can represent the presence of binary 0 or a 1 and the message can be recompiled as a result of that as well. Or we can do distortion of digital images altogether. Now this goes back to the Picasso comment. In this case, what we're actually going to do is blur entire pixels, entire 32 bits of pixel depth in one single object and we're going to pick one color and we're going to blur the entire color everywhere in the document. So what actually happens is we distort the image entirely, completely and totally but that distortion actually represents the information. It's not that the data is hidden in those 32 bits. It's that we change it so that we represent distortion and then we use an on off methodology for where there is and where there is not distortion when we pixelate it out and that rebuilds the binary data. Cover generation methods. Mimic functions. Mimic functions try to represent data that is already known with a statistical model. So if it is statistically analyzed, it's almost impossible to differentiate this file from something else. Again, this is great if we have something that's looking at the file statistically but if someone is looking at it, this really isn't going to produce much of a result for stagnographic functions. We can also do automatic generation of English text. This is to try and compensate for where mimicking goes bad. Unfortunately, it's not necessarily successful because it creates random generated text messages which, while they may follow a logical grammatical sentence structure, make absolutely no sense whatsoever. It'll say things like the blue dog barks at the hallowed moon and no clue. So it gets very obscure. All right, let's talk about the fun stuff. Now that that's over, 15 minutes. How can we use stagnography maliciously? Well, the idea behind stagnography in and of itself is stagnography is designed to hide data and that's all it's really designed to do. It's primarily been used as a methodology for communication and it hasn't been used for the practice of deploying information that is going to be used in any way, shape or form maliciously. We're trying to just be very secretive about our communications or about what data is already on our box. So what we proposed about eight weeks ago, I don't know why I looked at my watch, but eight weeks ago, give or take, we proposed the concept that what if we can take an object, any cover object, regardless of what it is, and we can stagnographically embed into that, not a secret message, but actually functioning code. What if we can embed into that functioning code and can we have that code almost, and it sounds goofy, but what if we can have that code almost fall out of that object when it gets downloaded to another individual's PC? If we can do that and we can compile that data and load it into the stack, we can actually hack anybody we want, not a targeted attack, but we can hack almost anybody we want by accident, which is a very interesting concept for virus distribution or Trojan distribution. So that's one of the things that we really wanted to address and how we wanted to look at it. So if we use it as a methodology for hiding the distribution of malicious code, the opportunities really get pretty vast. The tricky part is trying to figure out how do you stagnographically extract data from inside of that cover object, compile that data, and then launch that data and cause that data to run. So that's where it gets difficult. All right, so let's distribute. What do we want to distribute? As I said, viruses, primary object, and Trojans, that's the thing that we seem to care the most about because that's going to give us the advantage of being able to take over a box. So let's, we'll come back to that. Let's imagine a concept that I take any Trojan. It doesn't matter what it is. You pick the Trojan of choice, all right? I take a Trojan, I break it down, I strip out as much of the unnecessary crap out of that that I possibly can. I take that code for that Trojan and I stagnographically embed that information into an AVI file or a JPEG or an MP3. And then I distribute that through whatever means you like. I'll give you a scenario a little bit later on here in just a few minutes of how I actually would like to see this kind of work and how I'd like to see it come together. But you distribute that information. Now once that information gets distributed out, how can we cause that information to fall out, literally fall out of that object? So we've looked at a couple of objects, we've looked at a couple of options. One of the first things that we've considered is looking at JPEG header files. There's a clear text header portion that gets processed just like any other portion of a JPEG gets processed. And what we're trying to figure out now is how to write script, stagnographic extractors. Now unfortunately, I don't have code to show you we're still on the early developmental stages. But if anybody wants to have suggestions or chit-chat later, come see me. But what we're looking at is taking a basic script file that's going to pull out data from inside of the actual Stagnode object. So if that script file is successful in extracting that code information, it then just becomes a process of loading it into the cache via a web browser or something along those lines. Now what we have successfully accomplished is we've taken an AVI file and we have loaded that AVI file with Stagnographic material. Now we haven't gone with source code yet, but we've gone with comparable size data files and we've had enormous success with that so far. Well with that data, Stagnographically embedded into the AVI file, that AVI file becomes the carrier and it becomes completely innocuous, or at least it seems to be completely innocuous in its distribution methodologies. Now the idea behind this, or how this really gets to be exciting, is the AVI file has the capacity to launch an event. We have an editor that we use at our office. I don't know what the name of the editor is off the top of my head. It allows us to embed an event directly into the AVI file. And primarily the events that we choose to embed have been ASP related. So we can cause the AVI to actually kick off an ASP and we can also force that ASP to run outside of a web browser so it becomes completely transparent to the user. So by doing this, what we're in the process of developing now and I think we'll have it fairly soon and we'll try and make that code available as it's necessary, is what we're trying to develop is a client server ASP based Stagnographic model. So we take the architecture of a basic Stagnographic object or a Stagnographic encoder and decoder. We figure out how to make it run in a client server environment. You have the client and the ASP that's being hosted is actually the server portion of the component. So when the ASP kicks off, you're going to communicate from your box directly back to the ASP outside of a web browser, which is going to force some level of code to execute. Again, we haven't worked out all the bugs, so I don't want to tell you exactly how it's going to happen yet. It forces some level of code to execute and when that level of code executes, it's going to search your drive for an individual file that's going to be actually stagnographically embedded in some way, shape, or form. Now the server portion of this is going to extract the data out of your machine or out of that AVI file or whatever, hopefully other distribution methods will come very shortly. We'll extract that data out of the source file itself and we'll be able to load that data as raw data, sort of like a binary install almost, load that data into the executable stack while it's acting as though it's hiding behind the web browser. The nice thing about this is this will all happen just simply because of cached objects. It doesn't necessarily have to be because you're running the AVI file. If you browse to a web page where the AVI is being hosted, it'll actually buffer into your cache and everything should be able to structure right from there. You don't even actually have to run the object and as we extrapolate this into JPEGs it'll get even more functional in the same format. So as objects become downloaded, we'll kick off background events which will extract the data, the malicious source code, directly out of your machine or off of the steganographically embedded file and it'll place it on your hard drive, load the object actually and force it to go into the executable function. We pretty much have owned your computer at this point. Now why is this a big deal? I'm not the first person to think of this by any stretch of the imagination when I was the first people to begin doing work on this. The Air Force has done work on this in the past. There are folks in India who have done this as actually a thesis paper for a master's project and they actually successfully created a keystroke logger and deployed a keystroke logger through steganographic techniques and were able to retrieve passwords. Where they stopped was the keystroke logger ran local on the machine and the keystroke logger actually acquired the information and then a conventional hack method had to be employed to contact that box and extract that data that those passwords and usernames directly out of the file that the keystroke logger generated. What I propose to do is I'll paint you a picture. Imagine there's some web server out there that is fairly vulnerable. I know, use your imagination. So I'm going to go out and I'm going to take an object that's on that web server. Any picture, JPEG, it doesn't matter what it is. And I'm going to copy it from my web browser and save it to my local machine. And then I'm going to steganographically inject my Trojan source code directly into that picture. Now, if I use the right steganographic method, such as substitution methodologies or even phase shifting if I have to depending on what the object is I'm not going to affect the size of that object. So once I have a copy of that object that's now been steganographically injected I'm going to take that object and I'm going to actually reload it back onto the web server. So it does require one hack, just one. That's the nice part about it. So I load that back onto the web server that is the target. Now the beauty of this is, if the administrator actually is smart enough to know that they've been hacked, figure the odds. If that happens, the odds of them knowing what I've done are slim to none. I've not modified or vandalized their site. Absolutely in their way shape or form modified ActiveX controls. I've not forced the loading of a cookie. I've not changed the size of an object, the location of an object, or the name of an object. So everything appears as though I got in just to see if I could get in and they run scared and they don't change anything and life goes on just as normal. Right? So now once I've placed this information on their web page, any people who view that website will actually, without knowledge, load my Trojan. If they download that and it loads into the buffer, we force that object to run. And again, we're working out some of these bugs. But we force that object to run out of the cache that's going to download automatically. By forcing that object to run, we primarily load that Trojan onto the client workstation. Now one of the other things that's being developed in this process is not just the technique of how we're going to deploy the Trojan, but actually we're looking for a phone home kind of Trojan as well. Something that can actually use encrypted channels in the IP or TCP header either way and can actually send communications backwards through port 80 so it's not blockable on a firewall for all intent purposes. Backwards through port 80 out to me as the master machine or the master computer, which will basically now give me full unbridled access to this random target. The downside to this concept is that I cannot target what I'm going to go after machine wise. So instead I have to target individual organizations or agencies or business structures. For example, let's say in the wake of HIPAA compliance, I decide that I'd really like to get myself into a couple of doctor's offices and kind of snoop around and see what I can find. Well, I can't specifically find a doctor's office that's going to go out and download this object, but what I'm most likely able to do is go out and hack some medical technology company's website where doctor's offices go out and regularly download images and objects, download information and now what I've done is I've attacked an entire industry and it causes an innocuous attack for all intent purposes. So that's the basic concept and that's what we're looking at. We're trying to figure out a very elegant way to try and extract some of that data out. Now as I said about eight weeks ago we started on this research, but we got kind of excited about it so that's why we came out here to share it with everybody and make sure that everybody's aware of it. They haven't worked out all the bugs but by next year we'll have it completely functioning and we'll have source code available for everyone. So that's kind of what we're looking for. That's the idea. Why use Stego simply as a hiding technique? Why not use it as a distribution methodology? And with that I think I've summed it up in 30 minutes as opposed to 40 which I'll try and spare you guys the heat out here. I will just simply show you the cited research just in case anybody cares in that way nobody sues us. Because again as I said a lot of these folks have done research on a similar topic and subject. Stay in a graphic computer warfare by Jordan T. Cochran that provided a great amount of information. He addressed similar concepts. Actually he addressed the issue of virus distribution and didn't deal so much with Trojan and didn't quite take it to the extreme of taking over and owning computers as a result of it. The possibility of a Steganographic Trojan installer that was the paper that was actually produced that downloaded or created and steganographically injected keystroke loggers as well. So we do have some structural function. We have some ideas of how this can work. We have some basic working models. We're just trying to take it a little bit further. So that's some of the things that we use. We use a lot more resources, but these are the primary functions of the data. All right. Questions. The question is do I see any commercial application in this? And actually yes, surprisingly, although it was kind of retrofitted into the concept. It wasn't creative for this perspective, but how many of you have been with digital watermarking? Anybody? Okay, a couple of people. Digital watermarking. For anybody who is not very aware of what that is and what that concept is, it's a big movement that's actually happening with software manufacturers in Hollywood. It's big time on this bandwagon. And it allows them to embed basically Steganographic data into original objects and documents. And that Steganographic data certifies the authenticity of the object. So one of the things that we thought about is it's very possible and it's touchy because I don't... But if we use this technique to deploy the information and actually allow companies to embed information Steganographically through this methodology, we could work out some concepts for how that information could be sent back for registration purposes or how that information could be sent back if in fact the information is pirated or used in some way that's in violation of the license. It was something that was brought up actually by someone else in the office and we thought, you know, that's interesting. It wasn't quite what we wanted or the idea, but if you can make money at it, you know? So that's the answer. Other questions? Yes? Okay, the question is if we're talking about taking Trojans and viruses and embedding them Steganographically into an object and make sure I get all this right. What is it that he's going to put in the MP3 player that's going to cause the Steganographic data to fall out? Is that correct? Right. The statement was, you know, you wouldn't write an MP3 player that takes an instruction code and actually executes it. And that's the idea behind this is that it's not supposed to be dependent upon the application. It's something that's actually not supposed...it's not detectable. And the interesting thing is like for the AVI files, every AVI file player that is out there plays a basic structure of any AVI file. AVI files are multi-layered and coded and you can have one channel of data that includes closed captioning information and another channel of data that includes translation of the English text and there's a lot of channels and layers that structure into that and as a result, a lot of those AVI files, because it's a standard type, will automatically force functions to run and it's not specific to the player. So the player is not specific in the process. It's not a part of the function. What's actually a part of the function is how the file is written and the file complies with whatever the standard format is. Now MP3, because you have more variation and it gets to be a little bit more difficult, but when you start dealing with things like JPEGs and whatnot, you have less open-source people that are writing things to open JPEGs in the business community. Let me say it that way, because in the real world we all know better, but in the business community you're getting less open-source you're getting standard objects you're getting people that are opening JPEGs with PowerPoint or Word for that matter, or they're using Internet Explorer or they're using Microsoft's photo editor or they're using Adobe or something, some variation thereof. So they're going to comply to a basic structure of how the JPEG is supposed to execute. So the object that opens it actually has no function whatsoever in the execution of the code. So it's a little bit of a variation. It's really not dependent upon the execution of or the object which opens the the image. I'm going to try and repeat as much of that as possible. If you take an AVI and you layer a DivEx codec into it and then you're going to launch it, now I lost you kind of after that. Is one of the layers of the AVI for executable code? No. However, it can force other events to run because the AVI has access to the stack. So the AVI can actually force other objects to kick off and unfortunately a lot of spam is distributed that way through AVI's which kick off websites which open up spam. So it can kick off any ASP or HTML based object by default. Almost every AVI in structure can do that no matter what. And there's nothing special about the way the AVI is written and or encoded. It's just a function of the layers that are built into the AVI object. So what we propose is make it ASP based, at least for the AVI, make it ASP based which you can force to run outside of the browser window. No one really even sees it. Now, if there are nothing else going on, yeah, they may detect some activity and if they're a really conscientious user, but like that's really our target, if they're a really conscientious user then they may notice something funny is going on, but by hiding it behind an AVI file, most of your hard disk activity and your processor activity can easily be explained away for even some fairly savvy users that oh, that's the video, and they don't even question what in the hell is going on in the background. So it actually, because it hides behind an object, makes it a little easier. Right, it's an indistinguishable difference, right? Yes, sir. Once I break it, I'll fix it. I've got to understand a little bit more about breaking it because as I said, we're still in the early phases of development. I was hoping to come and present an idea to make people aware of possibilities. So until we actually can take conceptualization through fruition and we can build it, once we build it, we can probably begin to understand how it works and then we will propose defense methodologies for it as well and try and look at it objectively so that it doesn't cause some major internet outage or something along those lines. Okay, other questions? Bueller? Bueller? Alrighty, you guys have a great day.