 Hello, everybody. Welcome to the not-miss-busters talk. So... The only applause. So, everybody, go ahead and look around. Pat people on the back. We are not sheep. So, just don't ask why we all have signatures on our badges. So, we are here today, of course, to talk about some new tools that we've added to the Samurai project. We are the Samurai developers. We do have some other people in the audience that are part of the team. But we have two new tools here that we want to talk to you about today that are great, great tools. By show of hands, how many people in the audience have actually used one of the Samurai versions we've come out with in the last year? Excellent. Everybody knows that this is the one-year anniversary for Samurai. We officially released it last year at DEF CON. Well, we released it in Jackson, Florida. Jacksonville. Jacksonville, excuse me. Because we had one member of our team that happened to be the brainchild behind the project that wasn't able to attend DEF CON. So, we were kind enough to send him a whole bunch of SMS messages and tell him what to add as he was sitting there crying in his office. So, anyway, so here's our team. Okay, so we have Kevin Johnson. He, once again, is the brainchild behind the project. We are all of his slaves. No, we just make him do all the work and we take all the credit. So, Kevin Johnson, if you don't know who Kevin Johnson is, he is the leader of the base project for those that have used Snort. Also, the project that he is working on is Samurai, Ladinem, Yacoso, as well as several other ones that we don't have time to go through in the talk. He is a penetration tester for InGuardians, as is myself, and we have Frank DiMaggio. He is also working on these projects with us. He is project lead for the Ladinem project. And he is a researcher of web application security issues. And so, once again, we have Kevin, Frank, and myself, Justin, Cyril, and we will hand it over to Frank. So, you have injection flaws. Obviously, everybody loves injection flaws. Attackers, pentesters, we live for injection flaws, some of us, some of us not. And we love those applications that trust the user. Trust is fun. Trust is good. I thought greed was good, but trust is good, too. Trust us. Because we don't trust you. With those flaws, you have the different categories. You have the SQL injection, you have the cross-side scripting, you have the CSRF, you have, of course, command injection. Kevin, this morning said there's 12. I don't believe them. I made that up. It's the question. It's not the answer. Everybody should recognize that statement there. That's the query. It doesn't matter what it is as long as it's true, because we're looking for a response that's coming back from that. One's greater than, one's less than two. One is one. It's the truth of it. And why is that 42? It's the question. If you don't know the 42 reference, just get up and leave now. Come on, guys, bring your towel. That, of course, leads us to the injectable exploits. Gestable exploits, of course, fun. One of the same, right? There's many different attacks that can happen. SQL injection, probably the most popular. Probably the most popular. It can do many different attacks. We've got all the different vulnerabilities, right? Frank just ran through some of them, the CSS, CSRF, or XSRF, if you want to go that route. But within each of those vulnerabilities, you've got multiple exploits that you can accomplish, right? For example, with SQL injection, we can start retrieving records, the one that scares lots of people. But let's go even worse. Let's really be evil and start changing transactions. Executing commands, which, by the way, is not a Microsoft-only problem, even though we like to pick on Microsoft for it, XP command shell. Who thought that was a good idea? Come on. Sometimes you've got to look at these applications and wonder if the people that architect them, design them, and develop them are smoking crack. It's just my, maybe I'm judgmental. Okay, no maybe. But they're just nuts. Hey, let's build a database that's supposed to store records and then give people the ability to write to files, execute commands, and port scan internal networks. Don't you ever want your databases to write those files to it? It's as if they're following the Emacs development model. Let's build an operating system and call it an editor. Which leads us to Lawdom. So, Kevin brought up the idea of naming this thing Lawdom, and I'm like, what in the world are you talking about? Actually, there was a gentleman named Nick who came up with the name. So, I heard the name. I had to go to Wikipedia and find out what in the heck is this thing? Also known as an opium tincture. What the hell is a tincture? So, I'm looking through this and I'm like, wait a minute. If somebody would please update Wikipedia with the proper response, that'd be great. The question will be, by the end of the talk, will somebody have edited Wikipedia to mention the project? Of course, they'll then remove it. Worth a try. So, there's methods of injecting the files. So, if you have access to the server, well, web dev, right? FTP, service exploitation. Of course, there's file include vulnerability. And of course, our favorite, SQL injection. Yeah, we've got all of these different ways to inject files. I mean, Justin and I do this on a regular basis. When we're doing penetration tests, we find these servers that people put out there. They expose services. They expose applications. Heck, how many times have you come across an FTP server that has anonymous enabled and can write to the file system? Raise your hand if you're running that server. Ah, I see a contract. Right? Justin? Yeah, tag. Right, oh. So, okay, okay. I'd agree to cover this slide. So, when we're talking about SQL injection, which for Lodnum, which we're going to get to in a second, with Lodnum, any of these methods to inject files can be used to inject the Lodnum scripts. But we're partial to SQL injection. Kind of because it scares people. Well, the people that understand what it is. You talk to somebody who understands you say, hey, your app is vulnerable to SQL injection. And you're like chills, right? And we have to admit that it's the one word that all the people in the company actually know when we're talking about web applications. If you say anything else, you have a vulnerability here or there, and they're kind of like, oh, okay. Tell me what I need to do to fix it. You see my SQL injection. Yeah, there I start watering. Yeah, so with SQL, now remember at this point what we're talking about is not the attack. We're talking about features built in to the query language, which again brings back the smoking crack idea. So we've got the ability within our queries to take the record set and write it to a file. A simple example here, select star from some table into some file. This can write anywhere the database has permissions to. Now let's be very careful there when we say permissions. We're talking about one file system permissions, but we're also talking about permission within the configuration. For example, modern versions of my SQL have configurations that limit down to if it can write to files at all or where it can write to files. But then we have our vendors. How many people here love vendors? Come on guys, they make our jobs easier. Right? I love vendors. They come in, they do their dog and pony show, we get to tear their applications apart. You know, it's kind of fun, but vendors build these appliances. One you boxes that are designed to let me own your network. Now of course that's not in the marketing materials. They're sales people tell you, no, no, it's safe, we'll manage it for you. You don't have to touch it. Don't patch our box. It's ours. Ever. Ever. Yeah. These guys, they build these appliances and most, well, okay, maybe not most anymore or maybe they configure these things so insecurely. I can't tell you the number of one you pizza boxes running my SQL as root with no restrictions as to where it can write the files. Why? Because the vendors help desk somewhere in the world. I'm swearing we're going to start outsourcing the Mars. It is the plan for the moon mission, right? To move help desks up to the moon, but they want to be able to support these systems as simply as possible. And if we have those security restrictions, right? They're so inconvenient. We've got our problem. What do we have to do? Well, you got to go. You have to know routes password and run sudo and do this and do. Oh, no, let's just run it as route that way when we have the problem we can write it. So in this case, right? We can write to anywhere this install of my SQL has. I don't know about you guys, but I immediately start thinking of the temp directory var. No, you could if you want. Yeah, I would personally. Yeah. So I don't know. I personally know with my web server. So it acts as my old file system. It's a lot of fun that way. Nice. So once we start talking about writing files, now let's start talking about another. And I hope you hear the quotes feature of SQL. So what is that feature? Yeah, controlling the output. Oh, you mean that I can actually tell the database to take this output or take this string that I passed to it and just echo it back to me, right? It's not like the echo command since that was such a great idea in the first place. Yeah, we have printf in SQL. It is trusting, you know. Yeah, it is trusting, right? So we've got the ability to do something like select injectable files are cool from table. Now that table has to exist. So you have to know the table. I don't know, sys objects. And it's just going to search for that string inside that table, right? That's the whole purpose for this command. No, no, no, no, no. It doesn't search. It looks like we actually get people to say to us all the time where you forgot to wear. It's like, no, there is no wear there. That's the field we're asking for. Or the column. Or the column. Okay, okay, yeah. You've got to do the semantic game, right? Because us nerds, we come up with multiple words and acronyms to mean the same things. You know why we do that? We were picked on in high school. They now need to ask us what it means. It's lots of fun that way, right? Oh, I guess I'm revealing too much. So we can actually set the record set that comes back from our query to anything we want. Which brings us? Milk and cookies. Let's combine these two ideas. Let's take the ability to control the record set that comes back. Take the ability to write that record set to the file system anywhere we want. So you're telling me you want me to go ahead and tell the database to echo back the string hello world with html tags around it and drop that to a file inside the web root. So that way, when I surf to that file name or that URL, I will then see the wonderful message hello world, right? I wouldn't go hello world. I would just say PHP info, parentheses, parentheses, semicolon. My first guess. Or exec. Right? So we've got this. Let's go to the next one and Justin take it from here. So we have our wonderful project called Laudnum. What Laudnum is, is a set of different exploit payloads that we can use in SQL injection or any other type of injection we can. We need to have some type of file that can be used by a web browser to give you some type of functionality or feature. We now have a set of tools or set of payloads that we can use for that very purpose. So exploit scripts designed for injection. This is the main purpose. Some of the things that we have currently right now in Yucoso, excuse me. Whoa, wrong project. The other project. Wrongs project and one slide ahead. What does it says? Multiple functions right there. What does it say? No, we have Laudnum written. Our payloads are currently written in multiple different languages. Because once again, when you are attacking a web server, you never know what type of language you're going to be encountering. So the idea here is let's go ahead and have several different types of functions such as shells, web-based shells. And we're going to write these web-based shells across every single language that we can possibly think of, or we get bored in our time and decide to go and write. We're never bored. What are you talking about? Bored hackers are dangerous. You don't want bored hackers on your network. I guess we should leave off the word bored. Maybe. Just keep in mind though, one thing that we didn't put on the slide. When we say that these are injectable payloads, keep in mind that with SQL injection, you're injecting around in a lot of cases a text field which in the query has been quoted. So as we've built these injectable scripts, we've been very, very careful to keep consistency across and using single quotes or double quotes that when you pick the file to inject, you're not escaping out of your injection point too early. Right? So we've tried to keep this in mind as we're building forward. And this basically is based on our need as we're doing pen tests. We run into these situations all the time and we've had to create them. Now we've decided to turn around and hand them back out to other people and well ask for help, right? So let's start talking about the different shells we've got. One thing we need to point out though is the idea of base 64 encoding to get past the IDS. No, no, no, don't slip. We're not done. Yeah. Yeah, so with the shells, we've got shell access. But to remember, we've got different types of shell access. This is not a terminal session. This is not telnet. This is not SSH. This is we have a nice little web-based form. We tell it a command to run and it will run that command and echo the response back out to us. So sadly no VI. Exactly. So sad day in the world. Okay, no Emax either. Sorry, Kevin. So with these interactive shells, we can do all sorts of very creative things like hello world, right? No. I'm sorry. We did get him a t-shirt that says hello world. Does anybody know where we can get one? No. So we've got the ability within these scripts to do base 64 encoding of the output of the commands. The idea there is the script is going to run the command. Base 64 of the output, send it down to the browser. The browser, us, has JavaScript running in it to unbase 64 encode. Maybe base 64 decode so that we can see it in our client. But the IDSs we're blowing by aren't decoding that traffic. So they're not going to trigger things like the snort attack responses rules and things like that. We're bypassing IDSs. We're bypassing the monitoring, right? We also have a whole bunch of other scripts in development to do things like DNS query, active directory response, pulling back LDAP information. Because what we recall, we're writing this out to a database on the back end system. Now this database may be running on the web server in the DMZ, maybe on an internal system, whatever. But that system, in most cases, is an internal application. And so it has internal trust. How many times have you found where outside we can't do DNS zone transfers any longer? But inside machines can. So if we write to a file, run that through a web interface, we're able to pull back all of your zone information. Or we're able to pull back your internal zone information if you're doing split DNS. We're grabbing information, pulling all of this in from your internal servers. Now we are looking for help with these scripts, right? This is an open source project, GPL. We're looking for people to jump on board and help writing stuff. And once again, these concepts are not new. What we're trying to bring here is we're trying to bring all these concepts that have been done, all the scripts that have been done, trying to introduce some new minor features and have them in one single location so we can actually access them and update them very easily. And of course, being that we're trying to be responsible, you have to have some scope limitations. Important for pentesters. Not so important for evil attackers. Don't know any of those. So obviously we're going to have some built-in features for that to be protective. You want to allow control to the access. So we're going to restrict the IP authentication. Which some of these are features in the current payloads out there right now, rarely implement. They rarely have ability to be able to control what IP addresses are accessing these tools. So if you upload a shell, they're not checking to see where the source IP address is coming from or some other type of authentication mechanism. If we are doing penetration testing for clients, it's a bit important to stay with inside of our scope. So we need to have these features inside of our tools. And we please. We love all the tools that you guys are writing. Please, as you're writing your own tools, whether they're part of your modem or not, let's add these features in them because they are useful. There are some purposes for them. Now the one unique thing that we've seen, and I'm not saying that nobody else has done it. I've just not found it. One of the features we've got is when you try to access these files, if you fail whatever access control check we do, we don't just give you an error. We actually return a 404 page not found message. And the idea there is that in simple scanning, you're not going to be able to find this file sitting on the server. Yes, there are ways to fingerprint the 404 messages and determine that it's not one sent by the actual server that was being sent by my script. But in simple scanning, you're not going to see these files. The reason we do that is not because we're worried about people accessing the files. That's what the access control is built in for. What we're worried about is if I inject, we're going to do questions at the end? Talking to the mic. Talking to the mic. Okay, I'm sorry, man. So what we're going to do is, that's better? Okay, I thought I was. So what we're talking about is when we put these files up on the server, this simple person coming by with like Nikto or something like that to find these scripts running on the server, they're not going to see them because they don't have access to them. But if they were able to see that the file existed but they didn't have access, well, what does that tell you? It tells you the application is vulnerable to some form of injection. What are you going to do? Start looking for it, right? So because we don't want to weaken the security, because we don't want to open people up, we're actually returning a 404 status code. So our second project that we are working on or releasing today, Yucoso. XSS is actually my favorite vulnerability, right? Cross-site scripting. I love running stuff in your browser. Hope you don't mind. It's 2009 and I'm still being told by really smart people. People that, well, up until this question I respected, what's the big deal? It's a pop-up, right? I hacked myself. An alert box, right? What's good hacking the users? You have to attack each individual user. What's good? You're attacking our user. You're not attacking our infrastructure. Not to mention that the users have access to your infrastructure. What can we find from that user? What information is available on their browser? Not much. I've always liked the idea. You're not attacking me. You're attacking my user. So it's okay if you have a storefront for me to come into your store and just kick every single person that comes in in the knee. I'm not attacking you. It's just what your customers. I don't know about you, but if I walked into a store and somebody kicked me, we won't discuss what would happen then, but I'm going to be pissed at the store. What are you doing letting them sit there and do that? Well, that's just a user. No big deal, right? In client languages, we used to laugh at people when they said they were a JavaScript programmer, right? I actually saw a guy had it on his resume. We just threw the resume away. I know we're talking years ago. He was like, JavaScript programmer. Next year, they tell me you're an HTML programmer, right? But nowadays, JavaScript, wow, I'm embarrassed to say. Well, okay, right? The language has functionality that is incredible, what we're adding to it. And as Sean Moyer and Nathan Hamill said this morning, the feature set that the browsers are adding is just astronomical in fail. Let's add the ability to do this. Let's add the ability to do this, as we'll talk about on Sunday, zombieing browsers, right? Let's take control, hand the control of your browser, now, back to the attacker using JavaScript. All client-side code can do what we want. So enter YOKOSO. The idea of in November of 2007, Japan decided to fingerprint everybody who comes into the country. You're welcome or welcome to our country. Here you are without knowing. And of course, this is after millions and millions of dollars spent over the last five, six, seven years with the YOKOSO project. You know, welcome to our country. If you ever go to Tokyo, you'll see all these YOKOSO signs all over the place. And, yeah, what better way to welcome you is to be able to track exactly who you are and be able to say hello and greet you by name. That's our project. I think you go wrong there. So, YOKOSO, this is not a tool. We want to bring that up right up front. YOKOSO is a set of fingerprints. Okay? Fingerprints of URLs. No, when Jess says it's not a tool, he's right. It is a collection of fingerprints, but the idea is both with YOKOSO, we're including tools and it can be used within other tools. You know, doing things like delivery of these fingerprints via XSS, mapping out internal networks or external applications. You know, one of the things we like the idea about, let's take these fingerprints, reformat them and shove them out into Nikto or something like that, right? So, we can definitely use them with Nikto on the outside, but our primary purpose at this moment and the list that we currently have inside of our fingerprints are focusing on the inside. Okay? We're focusing more on infrastructure web management. Today, in our businesses, we have these systems, these black boxes, or these other types of services coming in and the way that we administer all of them now is web-based interfaces. Please do me a favor. If you can't manage a firewall unless you have a web interface, stop managing firewalls. I saw a guy walking around yesterday not to pick on one guy. Well, she's going to stand up and storm out. But I saw a guy walking around yesterday he had a web bin shirt on. Now, I'm not judging that man. Maybe he knows how to manage his web server and he doesn't need a web interface, but I'm just not sure. I'd want to advertise to, you know, 100,000 hacksaws that his server at home probably has webmin and he probably doesn't know how to manage it any other way, right? It's the way it works nowadays. Let's give you a web interface. You can build it. You can manage it. We can stop paying people lots of money to do cool IT stuff and secure our stuff. So we have a set of fingerprints to help us identify these systems inside of our network. Any of these systems, such as firewalls, you name it, just a whole bunch of different systems with, no, these systems that are used for administration purposes. The way we do this is by identifying unique URLs, either by unique images that the website is pulling up or unique pages that each individual user is accessing on the page. Whatever we can find to uniquely identify this application that is not common across the whole board. Now, as part of this, some applications, the majority nowadays, have authentication. At least according to their salespeople. Well, yeah. You know, passwords, all about the passwords. So we have authentication. We have fingerprints for these applications for pre-authentication and post-authentication. So that way, with the pre-authentication, we can simply identify what's inside of the network. If we're doing this via cross-site scripting, we can use browser-based history attacks to look through and see if those systems exist. If we have some other type of tool inside the network, we can then use that tool to, once again, query something like Durbuster on the inside to query those URLs to try to identify which ones of those administration systems are there. We have a second set of fingerprints that identify post-authentication. So once a user has logged in, what unique pages, what unique elements, what unique images are being seen. So that way, not only can we identify what systems are inside the network, we can also identify who the administrators are. Or at least the users. Hopefully we want the administrators. Yeah, the idea is if you've been to that page, you have access to it, right? You had to get past that authentication form. At least we assume you had to get past it that you don't know of vulnerability we're not sure of, right? So we've got lots of different uses for these fingerprints within XSS attacks. We can do, as Justin was just saying, we can do infrastructure discovery. We can actually find the critical devices. Now, one of the nice ways to do this is, you know, shove down some JavaScript that simply makes requests. Does a host sweep of the internal network finding them? You guys have all seen that code, right? Then after we find all of the hosts, then let's run through the Ocoso fingerprint list and determine if that host has any of the files that we know represent web-based administration. So if it's there, well, if you found an ILO board, I'm gonna guess you've got an ILO board. I now have identified it. We then can flip the coin and start looking at history browsing. The idea, you know, it's been talked about many times. Let's see if this browser right here has been to this page. If you have, well, who are you? If you've been to the web administration console for a database server, you're probably a database admin. Now, depending on who my target is, I don't know about you guys, but database admins are some of my favorite targets. Oh, you mean running with domain admin on the database, right? Yes, yeah, because you need domain admin to run on your database. But they have access to all the data, and what is data? Fun, right? I know, I know, it's money, too. And once again, this fingerprint concept's not new. We have lots of tools out there. We have Nessus, we have Qualys, we have a whole bunch of other tools. Niktu has some in there to identify some of these systems. Once again, we don't have a single location to group all these fingerprints together. We don't have any of these fingerprints but some of the additional types of attacks that we can do with the history browsing attacks where we're actually checking for pulse authentication if they've visited the site or not. Yeah, exactly. So we're going to look for interesting devices. Frank was just talking to me yesterday about an interesting device that's rolling out in certain networks out there. Yeah, I'm sorry we didn't add it, but have anybody seen the power strips that you plug in to the network? How wonderfully smart of an idea that is. IP addressable. I mean, how many data centers do you aware of that they divide up the machines to production and dev and to separate racks? Not many, they're all mixed and matched. So you can take control and denial of servers. Right there. Why do you need a web server on a power strip? Or your fridge, or your washer. My coffee machine. Sorry, spending too much time on the smart security stuff. My wife actually likes the idea of a refrigerator that surfs the internet. It works really well, trust me, I know. So obviously some other items that you're looking at we've already mentioned. HP ILO. That's concept control of the server right there. Same thing with the Dell DRAC. IBM has their version. Obviously remote management, we understand that, but they don't lock that down very well. Other things, IP based KVMs. Avicen. HP, IBM. All the popular brands, they love them, they use them. All your web interfaces for your software, your devices, your CSAs, your PIXs, whatever. All of those devices, web interfaces, we can find them. Then at that point, we start identifying who you are. We can widen our attack. Well, one, we can find out if you're in scope, how many of you have done a pen test where you're only allowed to go after IT people? Because the non-IT people, we've already given up on them securing their systems. Don't pen test them, we'll lose. Sorry, you're going to lose anyways. But, we can identify if you're in scope. You can identify if you have the information we want. We can identify who you are. Once we figure that out, now we start doing some fun tricks. We've identified what infrastructure you had in the previous slide. Now, because we understand the infrastructure, we probably know of different vulnerabilities. These are vulnerabilities in this infrastructure. We've identified you're an admin. Oh, and you did that cool save my password feature. Let's give up the idea of people remembering passwords. Have our browsers, because nothing has ever been wrong with a browser in an Explorer. But that protects you from typing it in. It does protect you. You know, one of the things we're asking for is we need more fingerprints. We've collected a number of them. We're using every day. We're releasing new things. But we're asking for people to provide fingerprints to us. Now, there's a couple ways to do it. The simplest way, if you're lazy, is to go to the page, save you source, and copy the resources. And send them over to us. A better way for us is for you to use something like an interception proxy. You can use your choice. Because we've built parser tools for them. But you serve to the site. You browse out to the administrative features. Then you save that interception proxy log. Now, please remove any private data. I've already had people send me captures from web scarab that included their username and password logging into it. Right? I was very much tempted to include the username and password in the fingerprint file in Ukoso. I didn't. I was nice. Now, don't just delete it, right? Because that placeholder, that password was something that was important. So please insert some type of placeholder. Something as simple as the word password goes here. I guess that would be a sentence. Right? Send us the results of that. And do us one favor. Tell us what the heck we're looking at. Don't just send us fingerprints and say, these are really cool devices I looked at and you might be interested in. Tell us what they're called. What version number if you can get that. Any information you can give us is better than no information. So send that over. And once again, just real fast on me. As you think about it, there's the list. These are some of the things we're thinking about. If you even have other ideas in major categories that we have not mentioned, please pass it our way. So that way we can add it toward us. We can start thinking about these things as well. And that leads us to the final piece. Samurai. Samurai web testing framework. Once again, one year anniversary URL for those that have not been there. Here are a few of the tools that we have on the Samurai CD. So the Samurai is a live Linux CD. You can use it as a USB. You can use it as an installation onto your drive as well. Based on the latest version of Ubuntu. Currently based on what version are we on? What year is it? We're running 904 of Ubuntu. Now remember that Samurai, its main purpose is focusing on web penetration testing. There are some great live environments out there. We're not doing this to dish any of them. Look, I use Backtrack myself. What we're trying to do is find an environment strictly focused on the best web tools out there. We're adding new ones every day. For example, in the version that we're releasing today, we've got burn CDs if anybody wants to grab us and grab a copy of 0.7 we've added a ton of new functionality. Jason Wood sent us some files that actually parse Google searches to pull down LinkedIn profiles and generate lists of potential user names using those search results. Robin from DigiNinja sent us the Google profile scan that's been put into Samurai. So all of these tools are pre-installed ready to go and you don't have to worry about making them work. Now, I will say and you guys can laugh at anybody who writes me this email because I do, username and password to get into Samurai is really hard to figure out. It's Samurai. I say that because some idiot released Samurai 0.1 last year said idiot built a readme file that had the username and password, put the readme file on the desktop, built the ISO and released it. It took about 15 minutes, which I think was the download time for somebody to send me the first email that said how do I log in? Yes, I did reply read the readme. He did. Part of me wanted to say it was a test. You have physical access to the machine and you're telling me you can't log in. You're not allowed to use it. So the next version had the readme as a separate download. I got emails asking me what the username and password was. The next version had the readme as a separate download and a wiki article telling you what the username and password was. And I got emails asking me what the username and password was. The last three versions when you hit the GDM screen it says the username and password is Samurai. I got an email last night asking me the username and password. Stop that. So the new version is officially out. It is on our SourceForge site. You can download it there. We do have a limited number with us in our bags. We can hand them out after the Q&A session in a separate room. By the way, the VMware image is not up on SourceForge yet because Kevin lost his internet connection right before he got on a plane and I wasn't connecting to this network to upload it. So when I get home Monday night I'll start that upload. And Yucoso are on the latest version with us or the latest version that's online at 0.7 which was uploaded what, two nights ago? Well, unofficially it was uploaded and I couldn't figure out how SourceForge's new interface throws me off and I couldn't figure out how to hide the release so it's actually been out for two days. And really briefly, just to give you guys an idea future revisions, future ideas for Samurai, this is where we're headed. Currently it is based on Ubuntu. We're going to Ubuntu because we're selfish and we like KDE better than GNOME. But don't fret, we are working on another solution for Ubuntu for those that do like GNOME. Part of that we're also, towards the future right now we're using Remastered Sys to build the CDs. We are moving over to the official build process that Ubuntu is using so that way we have a little bit better build process, a little bit better login we can have some of the same features that you currently have with KDE and Ubuntu. And then finally the last thing that we're really trying to plan on and we're trying to get this out the door, it's just very, very time consuming. Currently all the software installed on Samurai is hand installed so the way that we are maintaining the distribution is by passing ISOs back and forth. Lots of fun. Yeah, it doesn't work very well with CVS or SVN. We are moving all of our software, all of our configuration over to Debian packages. Once you have Samurai you'll be able to just do an update from 0.6 to 0.7 or if you're short-handed and you just need some new tools on there you can go ahead and add anything else you want that we happen to have added at later distributions. Which lets you add the Samurai tools and all of the other tools that are out there in packages to whatever environment that supports app that you want. So if you've got a system that you like backtrack and you wanted to add a tool that they don't happen to have yet you just pull it down with app. I forgot to make one warning. This is the other email I get a lot of. On the desktop when you boot into the environment there is an install icon. That icon runs the Ubuntu installer to put it to your hard drive and it gives you about 87,000 warnings that it's about to format your hard drive completely and you will lose all data on that drive. If you click that's okay and over and over again and then write me complaining about the fact you lost all of your porn I'm going to laugh at you and then tell other people like here. So obviously our project links laudham.engardians.com yucoso.engardians.com and of course samurai.engardians.com Join one of the projects please we need all the help we can get. If you like the tools and we think you will, please pass the word we're pretty neat, we put a lot of work into them a lot of heart and soul and we appreciate anywhere we can get. Here's our contact information if you want to we're on Twitter I'm still not sure why anybody would follow us but people seem to You can email us Any questions you've got please ask we'll try to get you an answer and if we can't we'll figure it out. Alright do we have any questions? Wow They cut you off Thank you