 For those of you who don't know me, let's just say you can't hear me. I'm not loud enough. You can't hear me. I'm not loud enough. Okay, got it. That's the first time in my life anybody's ever told me I wasn't loud. I've been screwing with computers for 23 years. I started with HP 3000, seven column paper tape. I've programmed on punch cards. I've done client server. I've done mainframes. I've done assembler and mainframes. I've done assembler on PCs. I've been around a long time. The purpose of this talk, which is called Building a Backdoor Binary, my animated slide, is a step-by-step walkthrough of, this is going to be a lot of fun, of how to program your way back into that box you just worked so hard to root. The motivation behind this being I consider hacking to have essentially five steps, figuring out what it is you want to get into, figuring out how it is you're going to get into it, actually doing the exploit. Number four, my most important point, cleaning up after yourself. And number five, making sure that you don't have to go through steps one through four the next time you want to get back in. This talk falls under number five, namely setting yourself up a way to get into an allegedly secure system after you've already got back into it. So that essentially you have access, which may or may not be legitimate at this point, but the end user base doesn't think they've been owned. Okay. So this is featuring SecureCel SSH.2.0.13. I know 2.1 is out. I actually wrote this several months ago. I am working on a 2.1. And I'm Wrangler. So the point here, the first point I want to make is that security, the heightened level of security in the community has made it such that people are actually paying attention. You may not necessarily have a clue, but they're paying attention. So a lot of the obvious stuff that you used to be able to use to get into things is gone. You're not going to just tell it into somebody's machine with certain environment variables set and boom, you're a root user. People are actually, they know what Nmap is. They know how to download it. They know how to run it. They may not do much more than that. But you're not going to find the obvious ways into a system anymore. So if you want to get into something, you actually have to pay attention. And I mean, other than just going to Root Shell and downloading the latest exploit and running it and seeing if it works. Most of the time, remote access has been turned off for non-essential services. You know, I mean, you may find, you're going to find a lot of sun boxes with RPC turned on, okay? But if, you know, a good StarNix box is going to have maybe FTP, probably FSH, definitely not Telnet. Maybe SMTP, maybe DNS, maybe web. And that's it, you know? And of course, then there's the NT world and we're not going there. So for the most part, what I'm trying to say here is that Secure Shell has become the de facto remote access protocol in systems where people are actually paying attention. And again, there are exceptions to this rule. There are Telnets out there. I've got a whole frigging web page of over 3,000 classes of Telnets. But if you're going after, shall we say, a worthy target, the likelihood is you're going to have to actually think a little to figure out how to bust in. So this is a coding example. This is an example of something I actually sat down and did and spent quite a long night doing. And I wanted to go through it in a methodical way and explain some of the pitfalls because essentially when you think about, okay, backdooring SSH, you would think it's a fairly trivial exercise. Go in and define some password and then say, if my password is this, then branch around all the validation code and let me in. It's not. So the first thing I'm going to cover is the design, which is understanding the code and what you intend to accomplish with it. The next thing, coding, the factors that you have to consider when you're modifying the source code, namely how to do it so that you don't break it. Building, which is emulating the original as closely as possible, just because you can gain access doesn't mean the entire user community should be locked out. They might notice that. Installation, which is actually going in there, doing the dirty work, and that too turned out to be non-trivial. And finally, my favorite, share the information, which I hope is why we're all here today. Oops, that was...here we go. There we go. Plan what you want to accomplish. In essence, my theory and my philosophy, I won't burden you with it too much, but just to say that a hack is a statement that cannot be ignored. If you're going to go to the trouble of gaining illegitimate computer access, there's a reason for it. And you should think it through, because there are repercussions that are associated with it. If you're going to do this kind of thing, think about what exactly does you intend to accomplish? Do you want to be able to snag those HR records? Or do you want to be able to read a certain person's email because you think that they're cheating on you or whatever the hell it is? I understand what your motivation is. If you're playing what I call sport hacking, where you're essentially trying to see how many boxes you can have root on at the same time, I don't know what your motivation is, but you need to know that up front because that is going to influence what you do later on down the line. And what is involved in replacing the files on the system? Unix, there are a lot of different aspects of this to be considered. The size, the checks on the ownership, the times, the log entries that are going to be generated by your legitimate or illegitimate access, security tools that may or may not be in place to monitor what it is you're doing or something that you think you might do later on. And the fact that you want the behavior of the system to remain within expected parameters. You don't want to give a system administrator or user, clueless or otherwise, any kind of red flag or even a yellow flag that might make them start to poke around and discover that actually there's something going on there. Just to give you an idea, I did this on a lot of different platforms. And for this, this is just Solaris 2.7. I did 1.2.27 and 2.0.13. I actually have a lot of comparisons for other ones for like BSD and Linux and all. But just the difference between the stripped binary and the unstripped binary, you've got quite a lot of range here. On this slide you've got between 600K and 2600K. I've seen the binary get up to 760K. So there's file sizes on there I'm going to touch on a lot here because that's something that tools look at and something that people can eyeball. I need to turn off my radio. Here we go. File check sums. I've actually got this in a slide later, but I think it bears sufficient weight that I should say it earlier enough now. Tripwire will ruin your whole day. Everybody who's not running Tripwire on your system right now, raise your hand please. All the rest of you, please raise your hand too. Come on, raise your hands. I'm not going to go after you later. Yeah, there's a few. Binary check summing is a really nice tool for tracking trojans. If somebody gains illegitimate access to your system and they change the binary indiscriminately, and unfortunately a lot of people who hack systems nowadays are indiscriminate. They don't really pay attention to the fine details. A binary check summing is going to spot it and hopefully generate the appropriate reg flag, not in tomorrow morning's email, preferably on the console that's up there on the wall. The CRC32 bit check sum algorithm, I can and will go into that, but I'm not going to do it during this talk because quite honestly, I could do a whole talk on check summing. If you want to get into the differences between the different platforms and the different binary formats and the check sums and stuff, let's go drink beer. File access timestamps in Unix. You have three timestamps. You have the time that the file was last accessed, the time that the file was last modified, and the time that the file attributes excluding the above were last changed. Last time I checked, two of those could be modified by user commands and the third one was a programmatic challenge. Still, if you're going to screw around with files and you're going to screw around with file attributes, it's best to make note beforehand of what the original ones were and what the ones are going to be after you change it. Hopefully, those two values will be the same and that way, if somebody does decide to do something cute like diff their entire file system tree overnight, that won't show up in the listing. Understanding the source code and its behavior, and this one's going to take two minutes instead of one. SecureShale is a client server protocol. It creates an encrypted communication channel between the hosts. It performs authentication against the encrypted password. It stores the password in the user credential for the privileged user only. This actually is a special case. The encrypted hash does not get stored for anybody except UID0. Since we have no one UID0, that's your main. You can configure this thing. There are two configuration files. There's actually the client-side configuration file and the server-side configuration file. The configurations actually dictate what parts of the code are traversed during normal execution. It's important to understand what configurations are set up. For example, you can disable root login. You can do reverse mappings. Those things, if you turn all that off, a system administrator who's looking through the login doesn't see that for a day or two or a week or two, might actually get a clue that something's not behaving the appropriate way. You can do debugging and event logging. The bill generates a library, well, libsshsession.a and several helpers, the SSH agent, the key generation. One point I'm going to make here is that I'm leaving as an exercise to the reader, quote-unquote, doing pass phrases. I set this up to do pass words. Most of the implementations, in fact, all of the implementations of SSH I've ever seen do pass words, but you can also do pass phrases. That would involve other binaries and more coding, but just to simplify it and keep it into a fairly narrow spectrum. And conditional compilation within the code supports various Unix variants. There's AIX code. There's a lot of if-defs in the code. So when you're actually physically going through the code, you need to know what your platform is. You need to understand where the branches are going to go and how the conditional compilation is going to work. Okay, real quick animation of the protocol. The server sends a public key over the wire and it goes to the client. The client encrypts a random session key and returns it to the server. The server decrypts the client's session key and then using that, the server sends a client an encrypted challenge which the client can decrypt, and then you have your session established. So it's a three-way handshake, a la TCPIP, but it's utilizing encryption and it's not sends and acts so much as it is, challenge and response. And okay, one more for the password validation, which is going to be a little more detailed as far as how the logic in the code actually validates the password that the user enters. Oh, I'm sorry. It sucks to be tall. Okay, the password database on the system has the encrypted password hash. Everybody understand, of course you understand encrypted password hash. That's stored in a structure. It's called SSH user rec. That's the credential structure that gets built on the server side and that has the name of the user, the directory, the home directory, the shell they're doing. It's the G-Cos fields and a couple of other things. Okay? What happens in SSHD, SSHD being the demon portion of SSH that runs on the target machine, there are a couple of pieces of logic that get tested even before the password comparison begins. The first one being the number of password guesses, which is configurable in the configuration file. The second one being whether or not root logins are permitted. Okay? And we'll address that later. The password comes in across the wire. It's clear text password. The password is checked for size to see if it's less than or equal to 64, so no buffer overruns here. There's a couple of checks. They're actually pretty amusing because they're for RPC and Kerberos passwords and they're both empty blocks. I think that's actually got code in it in 2.1. And then the clear text password gets encrypted and a stir comp happens. So the password hash is compared against the encrypted password that the user entered. And if that comes to zero, if you've got a comparison that matches, then you authenticate at that point. Okay? So that's just the password validation scheme that the SSHD itself uses. This is a piece of the configuration file. The config file itself would not fit on a single slide, so I just chopped some of it out and put it up here so we could talk about a few points. Port 22 is the default port for SSH. Of course, if you're setting up your SSH and it doesn't happen to talk on Port 22, they might notice. Forward Agent and Forward X11 are two things that allow you to do tunneled X sessions through SSH. I routinely turn those off. I could go into it. I could probably do a talk on why that's a good idea to do that. If you want to talk about that, we can do that offline. Password guess is to set to three. Some places set it to a smaller number. Permit root login. There's a check in the code that says if your UID is zero and permit root login says no, you get kicked out. We will circumvent that. Let's see. Require reverse mapping. That's a lot of fun. That's basically DNS lookups. If you're on a netted network and you have an internal DNS, then those DNS lookups will work. If not, you might find that your SSH doesn't work. But regardless, you need to know what these config settings are. Because, again, you want your Trojan to behave identically to the target code, the existing correct target code. Understanding the vagaries of the software, the flow of control within the modules, the scope of the variables within the source code, and that's actually germane. There's actually a very good separation of scope between the modules in SSH, the supported functionality, and the crypt function. I spent about two hours really late one night trying to figure out why crypt wasn't working. And with caffeine and all that, I just wasn't doing that well. And all of a sudden, I remembered that there's this notation in the man page under bugs that says, oh yeah, crypt returns a pointer to a static object. So you call it multiple times and you get the same hashback. It was good once I figured that out, but I really missed those two hours. Maintaining the core functionality, understand how the untainted code responds. Again, the point here is to have a trojan that behaves identically to the accurate and replaced source code, with the one exception being that you can get in using it. That includes the configuration stuff that we just talked about, logging, and choosing a special case. In this case, I said we're choosing the passwords. We're not using the past phrases. If you can pick a special case, it's less obvious, like logging in is rude. And don't gut the code and expect that no one is paying attention, but again, once you build your binary, you want your binary to be as close to the correct size as possible. One of the things you can do is you can modify logging that will give you a way. Your conditional compilation code for TCP wrappers, if they're not running wrappers, you don't need that code. The DNS lookups, I don't think administrators really pay that much attention to whether or not DNS lookup failures show up in the logs. If they have fascist logging enabled then fascist logging is actually an option in the config file. And what it is, is it's verbose logging. It logs the entire connection of the session and the setup of the connection. You want to keep that for obvious reasons. Again, if people are checking the logs, failed login attempts should show up. Administrators might get suspicion if they notice that everybody's logging in, no problem whatsoever. And if root logins are disallowed, failed attempts to log in as root should show up in the logs. Suspicion. Don't add stupid variable names. It's amazing how many root kits I've run into where people name things hack and 31337. That stuff will show up when people start doing forensics. Even just high-level forensics, like running strings on the thing. So don't make bad choices. And be careful of how much code you add. If you want to do something really clever, like you want to collect a bunch of passwords from all the SSH users and you want to mail them to your hotmail account or whatever, you're going to put a fairly significant chunk of code into this binary to do that, and it's going to bloat the thing. You can strip it, you can do all the optimization you want, and you're going to have this big fat thing, and you're going to have to figure out how to shrink it down. Understand that there are boundaries within which you can work and try to stay within those boundaries, because if you generate a 10 meg binary and the original one was 6 meg, it'll probably get noticed eventually. The thing you want is to not be noticed here. Do this in as much of a stealth mode as possible. Commenting your source. I won't even talk about it. We all know that. The importance of coding exceptionally well. If your Trojan binary crashes, they're probably going to catch you. So even though it's really tempting to be clever when you're doing the code, it's probably a good idea not to do that and just code straight and make sure that your functionality is real clean. And also people that you pass the code onto are going to review your efforts and they're going to judge you on those efforts. And picking a password that is not hack or 31337 that doesn't show up as a recognizable, you know, root George is a bad password in any case. It's especially bad in this case, because if they string the binary and they see George, they're going to notice. And don't use your regular password, okay, because if you distribute your source and you put your regular password into source, people are going to pay attention to that and they're probably going to go and try it on your IP, alright? This is my little diagram for the scoping issue. There actually is really tattoos not here and I'm really grateful. The scoping between the library portion of the code and the demon portion of the code is exceptionally clear cut. You cannot see the password in the SSHD code the way it's written. You can only have it within scope in the library. So you've got these two different components of this code and a complete and total schism between where the encrypted password hash is and where you want to access it, namely in SSHD. So what do you do? You add a new subroutine to the library, namely give me the password out of the user cred. Okay, so you therefore defeat the scoping issue. Another logic diagram. I'll add the earlier one. Are you going to change the password yes or no? Is the length of the password greater than 64 yes or no? Is the password valid? Yes or no? Is the user ID greater than 0 yes or no? And are root logins allowed? Yes or no? That's the linear progression of the logic within the authentication module itself. Okay, so this is just a block diagram of the logic within the pertinent module where the validation actually happens. All that coughing is making me thirsty. So, given that that's the logic that things are checked in, if it's necessary for you to reorganize the logic, you want to retain that functionality, but you might find that what it is you want to accomplish requires you to redesign the logic in some way. Reorder things, don't break the functionality, but maybe do checks in different orders or maybe put some go-to's branches in there so that what you can do is, if you don't want to check if root logins are allowed, and I suppose you don't if you're trying to get in as root, you can probably branch around that code, except you might want to keep the log there because there will be logging in there. If that check fails, it'll spit out a log entry that says somebody tried to get in as root with a valid password and that's not allowed. If you make the decision that you don't think that's important enough for it to stay in the logs and you need to gut your code just a little bit more to get it down to where it needs to be, throw it out. Okay, but these are the kind of decisions that you're making while you're going through the process of changing this code. Configurable features will restrict the individual access attempts. The permit root login is one, the DNS lookups is another. This is my little DNS cloud drawing for those of you who you know, if you do a lookup on an IP you get the host name back unless it's not resolvable in which case you get the IP back and the code does check if IP equals host name and reverse lookups are set. Deny. So you got to circumvent that within the code. If you want to not be denied on a reverse lookup, you've got to comment that out. In this case I did something really simple. It returns true if the lookup fails, so I just always have it return false regardless of whether or not the lookup works. You won't see any of those messages in the logs anymore that say DNS lookup failed. My take on that was most sysadmins won't notice those missing. And again, the logging is associated with altered functionality. This is the same principle essentially of just saying there's your log entry that you're going to see if your log fails. The other way of doing it is just to remove the log statement. If you don't care whether or not the lookup fails and it doesn't impact what you're trying to do, you can just strip out the logging statement, actually stripping out the printfs gets you about a K off your binary for every statement that you lose because that printf compiles in a bunch of code. It goes back to the library every time. Elective surgery to adjust the resulting binary size. Again, the binary on the original target will have a size and your root so you have no excuse for going and doing an LS on that directory and seeing what the size of that binary is. You have no excuse for not going into Etsy SSH2 and grabbing that config file. You need to understand your target before you do this coding. You want to understand what it is you're trying to replace so that what you replace it with is so close or identical to the original that no one's going to notice. Removing sufficient code to connect the binary size. In this case, I threw away the wrappers code. There wasn't wrappers running on the target system so I didn't need the wrappers code. There's code in SSHD that integrates with TCP wrappers. They're not running wrappers. They don't need that code. I threw that away. I have 20K off binary. And beware of functional limitations and bugs. For those of you who have never seen it, this is Solaris 2.6. This is the crypt function and I was actually hoping that this would give a better illustration of the fact that it returns that static pointer every time. In hindsight, I don't really think it gives you any better, except for the fact there's those consts in comments. But it is in the man page and like I said at about four in the morning, I sort of remembered that from somewhere deep in my memory I went and pulled it off the shelf and went and said yep. So there will be functional limitations in the code and you will run into them and you will want to figure out some way to circumvent those. And probably the most important slide in this entire presentation is test what you're doing. Once you put it there it's there and if you screwed up I hope your door insurance is paid up. That's all I gotta say. It's cheaper than door insurance. Okay, building the binary you want to try to use the compile and link options that are as close to or identical to the target again for the obvious reason that you want the result to come out as close to or identical to the target that you're going to replace. If they happen to have been nice and left you the source tree on the system that you're going to put the trojan on I suggest you go and pull the make file and use it. If you have access to the target which you assumably do since you rooted it. If you don't have access to the target for whatever reason you let your connection time out use the defaults, go for full optimization play around with it experiment a little. You'll come up with something that's close or not close enough. If you use full optimization the worst thing that will happen is they'll get an increase in performance. I don't think they'll complain about that. And use an identical machine in OS obviously. You'd be surprised how many people build a binary on Linux and try to install it on Solaris and wonder why it doesn't work. I'm sorry I'm not trying to pander to the audience but you know it's happened so and size the binary collect correctly. You've got to go to this Las Vegas Hilton man, this is a Star Trek place, it was good. Run a checksum. If you think they're running by now if you've gotten into the system and you haven't figured out that they're running a checksum program you shouldn't be doing this at all. Enough said there. Do it all in your lab check some of the binary. If you have to figure out and we'll talk about it in the next slide how to modify the binary so the checksum works how to size the binary so that it's the appropriate size. Do all this in your lab. I know you are going to root it to C4500 and all you have at home is an Ultra5. If it's running 64-bit Solaris 2.7 it's running 64-bit Solaris 2.7 No it's not running the SMP code but don't worry about that. There's other stuff and you'll be okay. And don't do it on your FreeBSD box. It compiles a hell of a lot faster but it's not going to work. And write a readme file because if you're going to put it out in the community it's nice to just give it to people and let them know what it is you did and give them an idea of where you stopped and what they can do with it. For example, I did the passwords. If somebody in here is going to do one and it's going to be the past phrases okay it's in the readme file so you know okay I haven't done the past phrases but it's on the to-do list. And be paranoid because there's a high assumable risk in what I'm talking about here. Essentially what I'm talking about is doing something that in the United States at least is illegal. So you want to take it seriously. You've already compromised your position you've already rooted a box but you want to take this seriously. Those of you who have had your doors kicked down you know what I'm talking about. The rest of you take my word on it. And the 12 important things to remember before you begin. Number one, fix the size and the check sum. Number two, fix the time differences. This is sort of a checklist for when you're actually going in and doing the install. What are the things you want to do when you're installing the thing on the system? Number three is check for tripwire. You should already know if tripwire and other tools are running. And if they are you shouldn't be at this point in the video. Check for mutable binaries on BSD systems. It's a lot of fun when you go to try to install this on a BSD system and it won't install and you can't move it, you can't copy it, you can't RM it and then you remember oh yeah there's that extra high order part over there in the file attributes. I wonder if it's immutable. Check for cron jobs that run massive diffs across the file system. What I call tripwire wannabes. That's going to catch you if you're not exactly dead on check some. So again check for remote monitoring that tracks disk space and CPU utilization. There's nothing more discouraging than to be sitting there trying to do the install on this thing while somebody's big brother screen has gone red on the left hand side because of all the disk utilization and CPU utilization. Nobody's on that machine. Why is that happening? Check for serial logging to the extent you can. Go into syslog.conf and look and see if they're actually dumping stuff to a PC over a modem cable. If they are you're probably outed already but you might as well know why. Check for other hacks or tools like keystroke monitors. Why are you doing this work on a machine that somebody else has already rooted and giving them all this free information? Let them go download the tarball and figure it out. Don't hump the demon when you're still connected using SSH. Okay good I don't have to explain that one. Remove the source tree if you do build on the target machine and finally no not finally clean up all the logs including syslog and all those logs and avoid the temptation to log on to IRC and brag about your latest hack. So this is my list of the 12 important things to remember before you begin. Once you do the install before you do the install on the target try it on your own system. Circumvent network obstacles if you need to if you're punching through a checkpoint firewall because you went to black hat and you saw that great talk that those guys gave and you just want to try all that stuff. Figure out how long it's going to take. Okay. There's actually you know there's this thing called time and you actually use it up when you're getting into a system copying stuff touching files, chimotting, churning things. It takes a while. I mean I don't care how fast you type. Figure out how long it's going to take. If you're going to be spending one or two hours on their system plan for that or you don't do it you know at three in the afternoon well maybe you want to do it at three in the afternoon because that's where everybody's using it. You're going to be slow but you don't care. They won't notice. If you do it at three in the morning and the utilization has a little spike in it on their MRTGs that might not be good either. And the goal is to anticipate as many points of failure as possible. Okay this is like I said originally when I did this I thought oh I'm just going to put some logic in here build the thing and I'm going to throw it up there but it winds up being non-trivial. Gaining root access this is the third step how to actually get in and in my slide says check bug track because it's more current than this slide. Okay remote exploits I just made a list of some crap that you know was actually on bug track at the time that I wrote this which is back in April so a lot of this stuff is probably already patched but I just said okay I'll just give them an example of some stuff different OS's and different things that are current right now for those of you who are sitting there going well I don't have any remote exploits well there's some on bug track and gaining root access on a system that you've already compromised well you already know how to do that don't you but again I put a few examples up here just for show and circumventing network obstacles scanning for ports, scanning past the firewall all of that you know who here was at Black Hat can I get a show of hands for the people that were in Black Hat yeah did you guys catch that talk Doug Song's talk I love to see a commercial product obliterated in front of an audience it's so much fun poke through the ports you know, passive FTP tunneling there were examples of that in that talk and figure out how long it will take again do a dry run of the thing essentially what you want to do is you want to practice this it's like doing a talk you know although some of you out there may be objecting at this point you need to rehearse the talk you need to rehearse the hack because you want to get it smooth you want to get it to where you can say okay I can do this thing without a lot of I don't want to wind up halfway in the middle of trojan somebody's SSH and find a gotcha that would be a bad place to be and the last part which I call share which is planning for the future post your package discreetly so that others can expand on your work maybe a full blown root kit is what you want to do to this system ultimately okay this is for the target machine that we're talking about once you've actually accomplished this maybe you want to root kit them maybe you're going to put sniffers on there maybe you're going to put other trojans on there maybe you want to put a nice I've got a great little FTPD that's got an extra command added to the lexical analyzer that's called shell SHEL um so yeah plant you know once you're done pat yourself on the back but don't stop there think what else you can do with this and or with other things to expand your access and just to be fair about it I threw in the slide to talk about protecting yourself against trojan binaries again tripwire will ruin your whole day I think it's an excellent tool it costs nothing it installs very cleanly and it does the job so if you have a bit on BSD systems if you're running a BSD system you have that high order eight bits in the file descriptor and it has the immutable bit and you can set that so that your binaries cannot be changed except if you're the root user now of course if they've got root on your box they're probably going to see that and they're going to change it but it will slow them down a little okay the other thing is you can set your whole file system to be read only all right if you put your binaries on slash user slash local slash bin slash whatever people aren't writing to that the only person who's writing to that is the assistant min when he's doing install make the thing read only it doesn't slow it down and again somebody will get in there and they'll try to write over the thing and it won't happen and it will stop them in their tracks proactive auditing diffing your file systems if you can't run tripwire run a find across your whole friggin file system okay it takes about ten minutes on a scuzzy disk on a decent sized machine and you'll get the diffs and you put them in your mailbox if you happen to see that root into password file shows up on that file system diff then it might start to ring some bells for you and you might decide to do a little poking around real hackers are lazy okay enough said know what you intend to accomplish consider the source change as little as possible please please please please test your stuff it is so frustrating I had one break on me it really sucked emulate the original as closely as possible do your homework don't get caught unprepared do a dry run make sure you know what you're getting into and share the information so that the rest of us can learn and where to go to learn more I'm going to post the package up on an FTP site probably not today actually probably not this week at this point it'll probably be next week sometime I will post these slides up on the web page I have not done that but again I will do that when I get back and if you want to contact me it's wranglernetpublishing.com is an email that I will answer where are we for time who's got a watch okay not bad it took me 50 minutes when I did it in the room uh Eric Bloodaxe here yet okay when Chris gets here anybody know what Chris looks like when Chris gets here actually I want to talk to Chris because I want to go drinking later but I'll take some questions in the meantime yeah yeah okay there you go Goggins here yet okay sweet if you want to talk to me I'll be offline over in the corner alright thank you very much