 Hi. Okay. I'm Monk. And I'm Stoker. And we're going to babble about off-grid communications with Android. So there's us. Two e‑mail addresses for both of us. One is corporate. One is not. Depending on your question or which one to talk about, pick which one to e‑mail us. We both work at MITRE. It's a FFRDC funded to do R and D along with quite a few other things. You probably know us because we do CVE but we don't actually have anything to do with that. Too long didn't read. We're dropping source. It went up around midnight last night. So if you get bored and want to walk out, if I babble too much, which I tend to do, sources up, grab it and have fun. That's really what we're here to do is evangelize Mesh. So I start babbling. First off, there's a lot of people that have played with Mesh over the years. We will mention some of them if you do Mesh and we do not mention you. Please don't get pissed off at me. E‑mail me instead and let me know. It's something that people play with and then they give up and then they play with and then they give up and we try to catalog some of the work that's been done but there's a lot out there of half baked projects, full projects we don't know about. Let us know. We really just want to collaborate. If all you're doing is Wi‑Fi tether, awesome but please don't e‑mail me. It's a little boring. Sorry. So the first problem that we really want to end assault with Mesh is what happens in situations like this. Fukushima, horrible disaster, cell networks went down, Wi‑Fi went down. There was a lot of people that wanted to call their family and just say, hey, I'm okay. Or people that needed emergency help and networks went down. They're basically stuck back in the dark ages. Happened in Katrina, happened in Haiti. Put any recent natural disaster you can think of. Cell networks go down. The towers are designed to handle about an 80% capacity. They go above that and the hardware dies. I mean, it's just what happens. There are other times where networks go down that this is also kind of meant to combat. So why do I care about Mesh? In general, I hate physical infrastructure. I think it's flawed in something we used to have to have. I really don't think we do anymore. As technology progresses, just we don't need single points of failure. They're hopefully becoming obsolete if we get our point across today. Cell networks die. I've kind of already mentioned that. Wi‑Fi networks die. Plus to get a Wi‑Fi network in a remote area, which you've got to have power, you've got to have Internet. All that just to send an SMS between two people is really not necessary. Having said that, with the Mesh that we're dropping today, if you do want to hook up to another network, Internet, whatnot, we can bridge between them. But the main point of the Mesh that we're doing is to be a headless, infrastructureless paradigm. So again, single point of failure. I hate them. I think they're dumb. They're also kind of a single point for sniffing, single point for filtering. Also not really great things. We don't like that. I don't trust someone else being able to basically jack into that single point. So I don't want to have it. There should really be a funny pick below. But I cleared my phone out before I came to DEF CON of all personal information and lost it. But it's a story we'll talk about later. But we actually got flagged as terrorists when we were doing a demo earlier this year that was kind of funny. It's basically a skinny guy in a tree and me in a tree climbing up duct taping phones to trees. Stick around to hear the story. You can imagine how close a phone duct tape to a tree looks like a bomb. Especially with like two battery packs jacked onto it. So I mean, I've been trying to evangelize this for a while. We've all got smartphones and they're pretty cool. Except for the people that are really smart and have flip phones at DEF CON. Y'all guys rock. But I mean, they've got a Wi-Fi chip. They've got basically dual processor. Tons of sensors which I'll babble about later again. Lots of memory and power. And the most boring thing on the smartphone to me is that screen that blinks. I don't know. Once you get to the blinky screen you're writing apps which is awesome but boring. So I'm going to hand it over to Stoker because I've babbled for a while. But basically we've done the boring part of coding all the framework and he's going to go over that. And then I'll come back and babble some more. All right. So I'm Stoker. Before I jump in I just want to say this is my first DEF CON. And it's also my first time speaking at DEF CON. So if anything goes wrong with this presentation, blame the noob. All right. So Monk gave the overview. I will go deep. I am a software engineer by design. And here we have our technical architecture. So in general we're running a span on top of Android. On Android devices. Started with Android you want to eventually branch out to iOS. Windows 8, Symbian, what have you. At the top here you see we've got various apps. You've got a Blinky on a map which many government organizations like they have a lot of maps and a lot of things on maps. You can run like a peer-to-peer chat app, another app like VOIP. And all of those speak IP. So we use the standard Java networking interface on Android. You can speak TCP or UDP. And what happens is using net filter on the device because we've got root. We can actually redirect all those packets to a transparent proxy we have running on the device. And then we can inspect them, take them apart, add things, do whatever we want. The cool thing about this is whatever app you have running, it doesn't need to be programmed against a specific mobile ad hoc network API. It just works transparently. You don't need to change your app whatsoever. And when we went out to Kansas City to test this stuff, we used a government app we won't speak about but it did work. And they didn't need to make any modifications. So what happens is our transparent proxy intercepts these packets and we route them to a Android service, which we call the reliable transmission layer, which takes care of security, encrypts the data, does a public-private key encryption, and manages a TCP session if you want a persistent connection which is kind of something you don't get over an ad hoc network. So there's a lot of trickery involved in doing that right that we're going to be investigating in the future. The thing about our service is the main thing it does is routes the data. So one of our primary concerns with this research is how do you route data reliably in an ad hoc network when devices enter and leave at will? The thing about an ad hoc network is you basically route the data through phones to get to your destination. So if you route it through three phones, then one of those phones in the middle drops out, you've got to replan your route on the fly. So later on in this talk we'll talk about routing protocols and what they are and the good ones and the bad ones and how to make them better. So that's the gist here. There are two kinds of routing protocols we'll get into and our goal is to develop this framework to support any number of routing protocols as long as you implement them to work with our API. So under the hood there's plug and play, change at will. So here's the data flow. You've got one app on one device, let's call it a chat app and another app on another device, also a chat app. Data that goes through the Java networking interface, you know, you've got your TCP, UDP socket, whatever, intercepted transparent proxy, goes to a reliable transmission layer. We route it using our protocol and then it goes back up to the transparent proxy and gets sent over to another device because I call this transparent proxy because the user doesn't even know it's running and the app using it doesn't even know it's there. And the idea is because the data goes through these transparent proxies, it can kind of be called like a virtual VPN or it's something that the app doesn't know about in that sense. So it's just a data pipe which we think is really cool. So any app you have running on your smartphone can run over the man-a. And won't know. So ad hoc mode, this was the biggest trick. These smart phones by design are intended to stay in what's called managed mode which is what they use to connect to an access point. You can imagine that the vendors and carriers don't really want you to put your phone in a mode that allows you to speak directly to another phone because then you don't have to send it over their data network. And that's why there's a lot of controversy around like Wi-Fi tethering. Essentially, we took Harold Moeller's Wi-Fi tether for root user's app, took it apart and used it as the basis for what we have. So thank you, Harold, if you're listening or will ever look at a DEF CON presentation. So what we needed to do is we looked at Harold's stuff. And what he has there is an edify script for putting the phone in ad hoc mode to do Wi-Fi tethering. An edify script is basically used on Android to do like over-the-air updates. So we take the same approach just to sending the phone in ad hoc mode because you could do some cool things inside the script they can't really do from a typical Android app. Harold eventually stopped putting phones in ad hoc mode to do Wi-Fi tether. He started using something called soft AP which allows your phone to act like an access point. That does not work for Wi-Fi. It does not work for the mesh network because the phones actually have to be in ad hoc mode and that is access point. So what we needed to do with some of the phones, specifically the Galaxy Nexus, is recompile the kernel with wireless extension support. So thankfully, most of these, most vendors open source their stuff so that we can recompile it. You know, using typical Linux means, using menu config, selecting the things you want in it. And then we dumped the Z image in the any kernel tree so thanks to the guy for developing any kernel. And from there we flashed the resulting image using clockwork mod recovery. So this is all stuff any Android hacker knows about. What we do want to say is that we love Broadcom. The Broadcom Wi-Fi chipsets are awesome, we think. They work really well for our needs. Have them in Android phones, have them in iOS, have them in Windows phones. That's why we think that eventually we can get this working on a variety of different devices. So here on the left we have a number of devices and they're on the right, the wireless chip. As you can tell, typically a Broadcom, BCM, 4.3, something, something. Tends to work really well. Right here we got an ASUS e-pad transformer. It's running the Azure Wave wireless chip which is actually just a rebranded Broadcom chip. So that works well for us. The thing we don't like in this list is the Motorola Razr Max which uses a Texas Instruments wireless chip. And we tried hacking at that for a while but for the sake of time we kind of gave up. So we currently don't support Motorola devices. Once we got the right chip we need to make sure it has wireless extensions support. So then we can use IW config to set it in ad hoc mode. Galaxy Nexus doesn't have it. That's why we had to compile it in the kernel. The e-pad didn't have it. We had to compile it in the kernel. But the Galaxy S2 did and the Nexus S4G did. So that was awesome. So just a little note to the vendors, you know, please leave wireless extension support in your stuff or provide your kernel source to communities and we can add it back in. I would appreciate that. All right. So here was an interesting pitfall I ran into. When you have an ad hoc network you're constantly broadcasting, hey, I'm alive. And somebody gets that broadcast and they're like, oh, he's alive. I can send info to him and I can add him to my mesh and I can route through him. So your device is always on. It's always sending out these hello messages. And that's really the core of a mesh network. Problem is we're doing this over UDP because we don't want to do the whole SINAC thing with TCP and that just eats up more bandwidth and it's not a reliable network so it doesn't make sense. Problem with the UDP on Android, ICS devices, and lower is that if the screen is off it can't receive UDP. Why? I don't know except that we think it's because they wanted to save battery life. So somewhere down in the Wi-Fi driver level they're actually filtering out UDP messages when the screen is off. So it's the first thing we wanted to do. We'll force the screen to always be on. That makes a lot of sense. It's up a lot of battery but we'll strap on a big, fat battery pack to the back and move forward. All right. So we actually got it to the point where you could press the power button and the screen would come right back on. Which is kind of a cool little hack and we did it using a wake lock and an intent filter listening for the action screen off intent. And it seemed to work pretty well but when we were in Kansas City we realized that the phones would go dead pretty quick and there has to be a better way, right? So second approach. You can actually set this flag so that the Wi-Fi kernel doesn't do that filtering anymore. Which is awesome. I'm glad I eventually found this but I wish I found it like three days earlier. So you can sometimes set this flag when you're actually using InzMod to load the kernel. Some kernels don't have this flag setable via the command line. So you got to actually recompile the driver. So we recompiled the driver. And I'll pass this slide off to Monk. Awesome. So now we basically have the devices ready to go into ad hoc mode. They're in ad hoc mode. We should be able to actually create a network. Okay problem solved. Now routing packets and fast moving dynamic devices. That's painful. We'll babble a little bit more about this now. Basically we wrote, we are going to talk about two open source projects that are doing ad hoc routing and then our headaches with writing another five or so. And where we are. Yeah. So this slide should really not be needed. But if you're asking why you need a network and why you need a routing protocol, there's your list. And please don't e-mail me. All right. So ad hoc network routing. What is it? How does it happen? What are these things called Batman and OLSR? Let's get into it a little bit. All right. So this is a node graph. Basically each node is a phone. They can talk to each other. If there is an arrow between nodes, it means data can be sent from example D to A, but not A to D. Because these links between these phones are always symmetric. Sometimes there's interference or sometimes one phone transmits data at a higher power level than another phone. So you've got to manage all of this in your mesh and it affects your routing algorithm. In the middle, we show a one-hop route, A to B. And on the right we show a two-hop route, A to B to D. And you can keep chaining these nodes together to expand the range of your network. You just keep sending data through relay points. Specifically, we tested it and two Android phones, say a Galaxy Nexus to a Galaxy Nexus, you can send information over the span of about 150 to 200 feet. And we bumped up the transmission power to 32 DBMs which is the most they can support. We're actually thinking about taking off the back panel and hooking up a patch antenna to see if it can get more range. Essentially, these things are turning into little tiny push-and-talk radios, which is kind of what we want. So OLSR, what is this? Optimized link state routing protocol. This is the most popular ad hoc routing protocol to date. It's built into a lot of router firmware directly. So if we're using OLSR and smartphones and your router supports it, such as DDWRT, you can just add that router to the mesh. Which is nice. It's actually an RFC. It has a lot of support. It's been out for a while. It's not the best, we think, and we'll go into why. It's a link state protocol which means that the nodes know who they can talk to. They know the edges in the network, but they don't know, like if Monk had a phone, I don't know what routes he is using. I only know the routes I'm using. I only know that I can talk to Monk. And the problem with this is that each node has to calculate a route to every other node in the mesh. If there's tons of nodes in the mesh, you're going to spend a lot of time turning on that data. It's proactive. And this is one of the most important things in an ad hoc network. It's proactive versus a reactive network. Proactive is where you plan your routes in advance. So when you send data, the route is there, you blast it off. Reactive is, I don't know when anybody else exists until I want to send data. I'm lazy. So I want to send data. I plan my route on the fly. Data kind of gets buffered up for a while. It's a little bit laggy. And then we can send it out once we plan that route. But OLSR is proactive. People like it because when they need to send data, the route is there. It uses Dykstra's open shortest path first algorithm for people that remember their comp sigh. And it works at the networking layer. Some algorithms work at the one layer lower than that. All right. So kind of how do you figure out that your neighbor exists? Well, A constantly broadcasts out hello messages at like five second intervals, which is very quick and you can understand it burns a lot of power. B is eventually going to say, oh, I got a hello message from A. And then B is going to send a hello message of its own and A is going to get it. But in B's hello message, it's going to say, it's going to list all of the nodes that it knows about. So A sends to B. B learns that A exists. B sends back to A. And in that message, B had told A that B knows about A. And then A says, oh, okay, cool. B exists and B knows about me. Let's form a symmetric link. A knows about B. B knows about A. They're best friends forever. So that was like a one hop link. But you can also like do two hop links where A sends to B. B sends to C. And then C knows that through B, it can talk to A. Because B basically rebroadcasts A's message. And so through this series of proliferating broadcasts, everybody knows that everybody exists. You can understand there's a lot of data on the network. You can run into throughput problems, which is why a reactor protocol might be a little bit better. There's also a thing called a multipoint relay in OLSR, which is like you choose one of your neighbors to send all your data to and he sends it to everybody else. Sounds good in theory because now that one guy takes care of most of the work and if he's plugged into the wall, he has a limited battery. He has a limited power. He can take care of most of the heavy lifting. Problem isn't that ad hoc mesh network with smartphones is that guy can drop out. So if you assign a guy to be your oracle or whatever and you send him all your data and he drops out, well now you've got to find another one. And if he's the NPR for multiple nodes, everybody is blasting that guy with all their data and he is a choke point. That's why we don't really like the idea of multipoint relays. What these bullets on this slide are saying is you choose your multipoint relay based on the node you send data through to get to your most two hop neighbors. So C and D in this are the two hop neighbors of A. B talks to both C and D. So A chooses B as its NPR. Wow, I wonder what's happening over there. Okay. OLSR. Pros. Not everybody shares everything. Most of the topology jumps, most of the information about the network is only shared between the NPRs and that's kind of the reason they came up with them is to try and reduce the amount of data dumps of topology which are quite large. And there's been incremental improvements but NPRs are choke points and even though each node plans an entire route in advance, it knows all the hops it needs to go through to get to its destination. When you send that data to the next step in the route, that next guy, he can do whatever he wants with it. He can use a completely different route. So why would you plan your whole route when as soon as I pass it off to Monk, he plans a whole new different route? It gives you warm fuzzy knowing you can get data from point A to point B but after you send it to the intermediary step, you don't really know where it goes. You don't know how it gets there. So Batman. Batman is in advance to OLSR and it was designed by the same guys behind OLSR, came out in 2006. No single point has all the data, no NPRs. Each node still sends out messages, hey, I exist but what's cool about this is that you keep track, so if I send out a broadcast and that hops through multiple nodes, the node that eventually gets it knows how many hops that broadcast had to go through before it received it. So if A sends out a broadcast and I get A's message and A went through 20 hops and A sends out a message and I get that broadcast through a different means, through only 10 hops, I know the best route to use, the one that only took 10 hops and not 20. And I know the last guy who sent me that message so I can blast the data off in his direction so that he takes care of it. So I can blast it off in the direction of the 10 hops instead of the 20 hops because that makes a lot more sense. It's going to get there a lot quicker. So in that sense, you kind of have a very local scope, you don't have to do as much data churning at all. And basically I just said what's on the slide. So where are we today? OLSR is the most popular Batman's gaining traction. We'd like to add you to Batman a lot more but we can do better and so can you. And I'll pass it off to Monk. Yes, so if you want to work on writing protocols with us, because you see flaws in these, please, please, please email me. I think I get to babble about reactor now. Oh yeah, okay. So thinking inside the phone, blah, blah, blah. Smartphones have sensors. We should really use them. Both of the protocols that Jeff talked about, they burn battery like crazy. I hate it. They're also not optimized for the actual platform. So the first thing that we should be doing with writing protocols is the phone itself knows when it's charged. It knows how much battery it has. It would be kind of awesome if the network itself routed around that data. So if I'm plugged into a wall and charging, you know, route through me. It's not like you're going to burn my battery down. If I've got 10% left, please maybe find another route. GPS. GPS is really costly to hit. Assisted GPS is quite a bit cheaper. But it at least lets you start clustering devices. So you know, don't pick routes that just kind of go around in a circle. Try to optimally figure out where your phone is and where two or three other phones are. If you're physically trying to send data from point A to point B, you know, look along that line. And the accelerometer. So GPS is expensive, expensive, expensive to hit as far as battery. Accelerometer is damn near free. And you can get all your vector information out of it. You can get speed. The other bonus of speed if you're looking at routing protocols is if I'm moving fast through an area, don't route through me. That's dumb. Don't build a routing table around me being there. I'm not going to be there. So then on the flip side, if I'm sitting still, maybe prioritize me in your routing tables. So reactive. I love these things. Don't really keep a routing table. There's no reason to map out the network beforehand. I mean, why? We're talking about highly mobile devices, highly dynamically changing topologies. There's just not much point if you're actually doing phones in people's pockets. If you're doing phones taped to batteries, duct taped to trees, then yeah, by all means. But we're moving around. Our protocol should really be cool with that. So once we get into reactive, then we can start looking at the sensors on the phone. We can start playing with motion. We can start playing with location. And start adding these in to actually optimize how the data is moving through the network. We can basically power level the whole network so you're not burning one person's battery a whole lot more than someone else. Which is kind of cool. So downside comes with throughput. We can, every time you want to send a packet, basically you have to build a route to that packet. Which you know, a route from point A to point B. Which means that throughput, at least for initial handshakes and whatnot, is considerably slower. Okay. So delay tolerance, which is really, really, really what I love. There's a lot of times that we are doing network communications where we don't need real-time data flows. I mean, if you're doing voice over IP, yeah, you do. But I actually looked at this RFC, which I love. And you can look it up if you don't recognize the number. It was an April Fools one that I actually thought was really cool. Basically taking phones and saying I want to get a packet to someone else that I'm not connected to on the mesh. But I know a lot of phones. And so let me send my packet to those phones. And when those phones move around the environment, they will hit another phone. That phone will hit another phone. And finally your data will get from point A to point B, even though there's no network connection in between. It's using humans as carrier pigeons, which is fun but really, really laggy, obviously. But it does expand the scope of your network when you don't have one. It also adds some interesting things that we'll get to at the end. Okay. Scale, most of the projects that we've talked about already, Batman does a lot better. OLSR, if you're dealing with the physical products that are being sold on the market right now that support OLSR, they actually scale really, really well. The Android and iPhone implementations that we've seen don't, what we've seen like 20 to 40, we hooked up 40 phones. But I think the limit that we've talked to anyone is about 200. It's not really useful. I'd like to see the thousands or the tens of thousands. We should be able to get there but I don't think we can get there with what's on the shelf right now, which is why we've been spending a lot of time on this. We should be able to scale a lot more with Reactive. And if we mix the two, we should really be able to scale with no foreseeable limit. So that's all you. Okay. So you have your mesh. Phones can talk peer to peer but maybe you want to use the internet or maybe you want to bridge to a larger network. Well, this is really important for an application that we tested out which had a central server. In a mesh network, you kind of want to avoid servers or any phones acting as a server because if they drop out, well, then that service is gone. Or you want to try to make it redundant. That's my aside. So what we have is some managed infrastructure. And we want to get the phones talking to devices on that managed infrastructure. And how did we do it? Well, all right, well, this is going to be a shameless plug for alpha. But this is a wireless USB dongle that we have hooked to the USB port of this ASUS transformer prime. And what that does, it provides the prime with a second network adapter. So it has its internal Wi-Fi and it has an external Wi-Fi now. It uses its internal one to talk to an access point. And it's using the external one to talk to phones on the MAN-A, like this guy. This is the Galaxy Nexus. So because we have two network adapters on two different networks, we can bridge them. And basically, we just use IP forwarding between them. And all data that comes in to the ASUS over the mesh can now be sent out through the alpha wireless USB dongle. And the mesh is netted behind the routing done on the ASUS. So essentially, you can kind of think of this like a VPN where, all right, ASUS is a gateway to the rest of the world. We have cluster of phones. We have a mesh hidden behind the ASUS. It's netted. Well, let's say we have another ASUS in another state. Can we get the mesh on this ASUS talking to the phones in the mesh on the other ASUS? Yeah. Well, because the internet connects them both. So both ASUS's are bridging to the internet. The internet is basically our backhaul to send all that information from one ad hoc network to another. All right. So IP address assignment. Mesh networks, there's still a lot of open questions. And we would appreciate it if anybody here is an expert in this field and has some recommendations. There's a lot of white papers, a lot of college grads looking into this stuff. But IP address assignment, how does it happen on a managed network? Oh, DHCP. What is DHCP? It's a server. We don't like servers on an ad hoc network. So how do we send out IPs? Well, you can do it statically, which is going to work. But what if two phones assign themselves the same IP? Well, then you run into all sorts of problems. Can we generate a unique IP based on the phone MAC address, IMEI, other sorts of information unique to the phone? That's an option. So this is still like an open question. And right now we do it statically, but in the future, especially next year, we're going to be looking to alternative means. One thing I do want to say here is, if you get to the last slide, there's this mesh network in Germany called Fryfunk. And they do IP address assignment by having people register on their web page and then they just give you an IP. So we kind of want to avoid doing that. All right. Security. How can you secure the mesh network? Well, this is still an open question. And we're still looking at best ways to do it. But one of the ideas we had is, well, maybe we can exchange, you know, a symmetric key by doing a bump and using NFC. So let's say it's a crisis situation. Cell towers are down. There's an earthquake whatever. Volunteers show up to the Red Cross. They have their personal smartphones. And they want to set up their own mesh network to stay in communication with each other because the Red Cross guys aren't going to give them radio. They don't have enough radios. So let's say I'm in the mesh and Monk wants to get in the mesh. How does he configure his phone to get into my mesh? Well, let's do a bump. Send that config file over to his phone. He knows the symmetric key. He knows the SSID. He knows the IP range. He knows all that stuff that's in the config file. He hits go ad hack and he's in. We like it to be that easy. We're also thinking instead of using a symmetric key, we can use public private keys and do encryption that way. And we'd also like to encrypt the data in such a way that the backhaul, the internet, or the bounce nodes that we're sending information through can't decrypt and inspect the data. So this is an off-grid network. Only devices in the mesh can look at this information. All right. So we talked about exchanging stuff via NFC. We can do symmetric encryption using the free helming key exchanges, but then again, there's still a lot of overhead with doing that every time. We want to talk to a new peer. I still like the idea of the public private key pair. The thing is we don't want to use a certificate authority or third party to try and manage distribution of the keys because we're in a mesh and you might not have access to one and that's just additional overhead. So there's this project out there called Serval and I really want to give a nod in their general direction. They're in Australia. I don't know where that is from here. But they have really looked at a lot of these tough questions and we have some links at the end of the slide. I don't know if we'll get to. But Serval has come up with a solution where they basically take a 256-bit public key and they generate it and that becomes your IP address. And that IP address is basically intrinsically distributed over the network because that's what networks do. You send out your packets. People know who's on there. And if you get a hello message, you can basically inspect the header, say, oh, I got it from this IP, that's his public key. Now if I ever want to communicate with that guy, I use that to the public private encryption. He uses something called CryptoBox to do the encryption. And he also uses something called CryptoSign so that people can sign the broadcast traffic. Basically, I guess CryptoSign is a way to use some handwritten gesture or something on the device to prove that it truly is you who is sending this traffic. So that's how they sign the broadcasts. So then some guy who just realizes there's a mesh network set up can't just send his own broadcasts and try to get on the mesh. We want to talk about a new features in ICS. Apparently Ice Cream Sandwich has this android.net.wifi.peer-to-peer API. And it's like, oh cool, it seems like something we can use for an ad hoc mesh network. And it's supposed to be an implementation of Wi-Fi Direct, if any of you guys are familiar with that. Essentially Wi-Fi Direct is supposed to bring this internet of things or even your toaster can be in your mesh. To the present day, they're trying to get everything to be on the internet and everything communicating wirelessly. And that's kind of what Wi-Fi Direct is all about. And apparently these devices have a Wi-Fi chip that will support it. It's just the driver implementation or something else is locking out all the features. So it's kind of a lame, partial implementation of the spec. It didn't really work for us. It kind of works like Bluetooth pairing where one guy has to be like in discovery mode and basically it's a very manual process of saying, oh well, I have to be discoverable and Monk notices that I'm available to talk to and then he has to click me on a list so then we can establish a link. It's cool for sharing video and whatnot, but it's very manual, not good for an ad hoc network where you want everything to happen behind the scenes. Maybe this will change in Jellybean. I haven't really looked into it very much. I think it's going to be a few more iterations beyond that to implement the full spec if they choose to do so. Okay. So root is required. We have open source this stuff, but it's not going to work unless you have roots. Your phone sports wi-fi or wireless extensions, those are like the two prerequisites to getting this stuff working on your phone. Why do we need root? Well, because we modify IP tables so we can redirect packets to our proxy and we do things at the low-level Linux networking layer to modify the routing tables which also requires root access. You also need root to put the wi-fi chip in ad hoc mode for managed mode. So maybe to make this more palatable to people who aren't like we are that don't do hacking in their spare time, we could try to wrap like an exploit up in the installer script that will get root whenever needed. Yeah, there's a lot of issues with that, but it was an idea. It worked. So like for an over-the-air installer or something, you need to provide a way to get root on the fly dynamically. And once we did whatever we needed to do as root, we could drop out of it, but there's a lot of trust issues there. So we've talked about Android. I'll chat pretty quickly about the iPhone. Short answer is yes. Black Berry Y. We poked at it. I kind of jumped on the playbook because it was QNX and that's kind of sexy. And maybe, but Black Berry is just kind of mean. The Windows phone, it seems to work, at least the OLSR portion because it's Windows phone. It runs Windows software. It was kind of like download from the Internet and install. Arduino and gumsticks, both yes. The gumsticks are really fun to add to the mesh. Any box you're carrying in your bag will pretty much jump on the mesh right now, today. And your toaster, I guess, if it's running Linux, sure. Basically anything that runs Java or C and has a, I guess I should also specify, has a network or a Wi-Fi card we can get on the mesh. Yeah. So iOS tends to be way more locked down than Android and it's fun that way. But they also gave us these really cool Wi-Fi proxy stuff. Basically in the iPhone configuration utility. So the main issue that we talked about earlier was trying to route all of the data that like any app, Facebook, Twitter, what not, are trying to actually push through the phone and grab that and say, you know, push through us instead. Android we do it by injecting the proxy at that low layer. iOS we can basically just force the phone to say, hey, use your internal proxy. So it's oddly easier because we can just pretty much hard code the APN and Wi-Fi proxy to just point back to a different point on the phone. And we can do it all through this awesome tool that Apple gave us. So there's like no coding involved, which is really, really, really, really, really easy. And this is actually set up to deploy to multiple phones so you can set it up once and then push to like 100,000 phones, whatever. We don't have that many. So what else is the mesh for? This coming year we're playing with security and the other thing that I really, really am looking forward to is pushing the torrent protocol over the mesh. So let's say you're in a situation where you actually want to share data across all the phones, but you're not always guaranteed to get all the phones back to wherever you came from. If you use torrent, you can basically replicate all the data across the whole mesh network and use the mesh kind of as a RAID 5. At which point, let's say you deploy 200 phones and you get 50 of them back. You haven't actually lost any data that you collected out in the field or at an event or wherever you actually had the mesh living and breathing. And I kind of, I mean, the typical network doesn't really use all 100 percent of the bandwidth. So and smartphones have a ton of storage so we can pretty much utilize that. We've also played a little bit with actually doing multi-processing over the mesh, which is kind of cool, spinning threads off on different nodes. Played in enough to know that it's possible, but haven't really poked past then. So we have a demo running. I jumped the gun, but we have like three phones and they're all talking and mesh together, which is a lot of fun. Let's see if I can get some screen sharing actions so those weren't in the front row can actually see what we're doing. All right. Okay. So using the processing visualization engine, we are actually showing you now the three nodes in our mesh. This ASIS and two Galaxy Nexus phones, the blue dot represents the ASIS because that's what we're doing screen sharing from and you can see that there's a line between each pair of nodes, meaning there's symmetric link between them all. Not very exciting right now, but proves to you that we can do this. If I turned off one of these phones, one of those nodes will disappear. You can see they all have an IP and really that's about it at this point in time. It's and go back to the presentation here. It went back to the beginning. So let's get some scrolling action here. What? All right. We were that dumb and the demo did work. These are going to be up here at the end if you want to take a closer look at the app itself. Or you know, you can go to GitHub and try to deploy it yourself. We have really appreciate that. All right. So what else is out there? We talked about Serval. We talked about Fryfunk. Let's give you a little bit more information on what those guys are. We would like to do some collaboration in the future, if that's possible. So Fryfunk, these are the guys we can register for an IP on their website. It stands for German for free radio. As you can read, it's like a grassroots initiative to get open radio networks in Germany. They use specialized open WRT firmware to get OLSR and Batman running over that network. They have tested a mesh with 500 plus nodes. So like Bravo to them. They have proven that this stuff actually does work. And through them, there have been many improvements to these two routing protocols. Serval, these are the guys in Australia. It's led by Dr. Paul Gardner Steven. And their idea was very similar to ours. They started before us and they have some things we don't and we have some things they don't. And they wanted to get an Android ad hoc network up and running in the remote regions of Australia. So they got VOIP working, which is something we're still working on. You can then send SMS over their stuff. They have distributed mesh data called Rhizome. They have a map. They have micro blogging. They have a lot of stuff. Some of it works great. Some of it's still being developed. The thing they have though is a special API for using their services. I don't know if they have a special API for sending data over their network either. But we really wanted to avoid that so that any app running on our stuff can work without knowing about the mesh. I don't know if their stuff supports that at this point in time. So future work for us. VOIP, you got these phones, you like to use them to talk to each other. Using SipDroid, we can pull out a lot of their stuff and get it working over the mesh. IP address assignment still open. Static works. Static is not going to work when you have 500 people on the mesh. There's going to be a lot of collision there, most likely. Evaluate Serval's approach to security. Like I said before, that's using your public key as your IP address. Work more on iOS and Windows 8 supports. So once again, this is the GitHub repo. Monk set it up, so I guess he gets all the credit for that. We got five things up there right now. We got a manager, which is the user facing UI used to set up the mesh. The service runs in the background. You don't really see that. That is a communication, a logger, so you can log info about the mesh. We use it for debugging. Visualizer, which you saw up on screen. And customized version of OLSR running in the background. Eventually we're going to be using Batman. So these are the open source projects used. You can take a closer look. We did the right thing by GNU and we open sourced our stuff too. So we're going to open the floor up for Q&A. And if not, if we have click checking. We haven't carried at that level yet. How about that? So our main focus this year has been providing the low-level network that people can build off on. So I'm worried less about things like click jacking and the higher-level things than I am about spoofing. I guess we could talk more if you want to talk. Anybody else have another question? If not, we'll take them over to Q&A number 4. And you can ask the questions there. Thank you. Thank you, everyone.