 All right, so I'm here to talk about Blue Cat. Who's heard of Blue Cat so far? Awesome, OK. So pretty much I'm a, my name is Joseph Paul Cohen. I'm a PhD student at UMass Boston. So I do kind of a side thing based like a cyber security computer science education. I do a lot of machine learning and computer vision stuff. So it's kind of dual tracks, right? So this is the fun stuff. So I want to just have some questions to kind of gauge the audience. So how many of you guys have used the Bluetooth API, whether it's blues or OSX or Windows or whatever? OK, so that's not that many. OK, who's used Netcat to talk to a web server? All right, so that's half. OK, who's created an outrageously complex fast script that to do some task? OK, so these are kind of all going to come together in this talk. So it seems like everyone's kind of well aware of that. So the overview of the sections of this are going to talk about streams and how they're awesome and fundamental, right? And then how you can replace Blue Cat in line with wherever you use Netcat, right? So any situation you can think about using Netcat over an IP address, you can use Blue Cat. You just kind of replace the IP addresses with max, right? And then you just have to be in range. And we also have Blue Cat as a Bluetooth end map. So it's like a we do scanning and I do scanning and service discovery functions, right? And then basically, we're going to talk about RFCOM and L2CAP. Those are the only things that really are understood by Blue Cat because they kind of make sense. You have port numbers and you can talk to them directly. And then we're going to look at some devices with Blue Cat and see how you examine other devices with Blue Cat, how to prototype some stuff really quick, some stats I've generated while scanning. And then if we have time, the architecture of how Blue Cat works on tons of architectures, right? So first, streams are awesome, right? So I hope everyone agrees. You can take something like a file and you can turn it into a stream and you can pipe it into something like VLC. You can kind of abstract everything that has to do on a computer to stream to a stream. So once it becomes a stream, really don't care where it goes. But we use streams every day when we talk to Pal-Talk. So every time you go on, well, Blue Cat was supposed to be on, but I didn't want to broadcast my Mac to everyone, but I did when I was pairing with. So anyway, so you have a computer and it turns into a stream and then you can talk to Pal-Talk. And then back, right? So that's how that kind of communication will work, like most things are based there. So you can put some kind of block in the middle and then you don't care what happens on the other side inside this block, right? The computer just talks to this thing and at the other side, it's going to come out to Pal-Talk. And then from that side, the responses go into this, you know, blob and then come out the other side to you. And you don't really have to care what's inside of that, right? That gets abstracted with all the layers, right? So the internet would work, but you send some stream. It goes through a series of tubes and then it comes out the other side and you really don't care. So you can take some really complicated process like routing all the way across the internet and just forget about it, right? Have someone else kind of take that initiative and you just deal with higher level application stuff. So you can extract really complicated things and just kind of ignore that they exist no matter how dysfunctional they are. Okay, so to really appreciate the usage of just talking to these services, right? We can take a look at HTTP. So I just want to go over the simple, make sure everyone's on the same page. So HTTP is pretty awesome, right? It's simple, it's human readable. You can kind of intuitively know what's going on just by reading like some traces, right? Debugging's easy, you can kind of look right at it in any kind of debugger and you can, you still don't have to read the HTTP spec, you can see all this stuff. You can encapsulate it, right? The stream and anything and you can kind of like add custom stuff, right? So it's not really so picky, you know, with what inputs and outputs it does, right? So it's very forgiving, right? So here's a diagram I didn't make. From a browser, you can send an HTTP request to a server and you get a response and these are just like a, you can think of it as a tiny text file, a bunch of streams, a bunch of strings and then you get back the same thing, right? And that's the basic interaction, right? So you can experiment, you just type the string get and then you get back whatever response in the context. So here's one for DEF CON, right? So we do get forward slash HTTP. We tell we want the DEF CON host and it's gonna send back okay with all these other HTTP headers and then it's gonna send us back the HTML, right? So we can take a look at the underlying protocol by just looking at the ports that it goes over, right? Based on just the port on the server that is for HTTP, right? So that's nice to inspect. And then if you think about it, like, this is the image of the matrix, right? This is kind of true, right? Like everything's just streams that are flowing all the time back and forth, right? So at some point maybe this will be how everything looks when you start looking at everything. So maybe everyone's like that, most likely. So what is blue cat, right? So what is the point of this, right? So there are three main things that I've been able to kind of come up with reasons. Why you have a debugging tool for Bluetooth application. So if you're writing a Bluetooth app, you can use it to debug your own application. You can see what's going on. Like, did you modify the service record properly so that other devices can see that record, right? And then whatever process is handling the socket on the other side, you don't wanna have like a full blown client ready, right? You might just wanna have like a makeshift client to see what is going on. Or if you wanna do some sort of emulation or testing with inputs that you wouldn't normally put into your client application, right? So if you kinda wanna fuzz your own app, right? You can do that with this and it's not a big overhead, right? Device, you can use it as a device exploration tool, right? So other people's devices, other people's services that are written, right? So your phone's services, cause there are tons of them. And they vary on different types of phones. You have old phones with insecure services, new phones with more sophisticated services, right? Then you have varying manufacturers have their own services, right? So you can look at how those services work and like send random data and try to debug the protocol that's there, right? And then you can record nearby devices using scripts. So it's like scan and kind of do it in an end map fashion, right? So kind of output. So I have a format to output this thing to a CSV file so you can kind of just aggregate tons of information about Bluetooth devices, which is interesting and I have some cool graphs later. So you can also use it as a component in building other applications. So you can use the, just like you'd use Netcat to prototype an application, you can actually use Bluecat to prototype an application and you don't have to care so much about the Bluetooth layer, right? Cause you're handling that kind of, well, it's deployed and then your service runs as your own thing and it just cares about like standard in and standard out. It doesn't know that it's talking over the RF. All right, so simple inline replacement for a Netcat example, right? So we have Netcat, some machine name and a port and that's going to connect to some server listening with Netcat on port one, two, three, right? And then you're going to have a pipe going this way and it comes out that side, right? So that's like the main kind of demo of Netcat, right? So we can do the same thing with Bluecat. So we listen on RF.com channel four and then we connect to this MAC address on RF.com channel four and it establishes that same connection, right? And you can do the same thing, like you can send music or movies. The throughput's like 100K, so it's not too good. But it does work with music, right? Maybe not flat. Okay, so then we can compare with Nmap, right? So Nmap's going to scan a bunch of stuff, which is very useful, everyone knows about that. So what's the equivalent for Bluecat, right? So we have kind of two things. We can scan for device names, which is what I was doing earlier, scanning everyone's device names and then you have this kind of output. So here we have a timestamp, the device name, whether we're paired with it and then whether the session's encrypted and then what's falling off there is like I can output the RSSI of the connection, right? All right, so you can go farther in depth, right? You can list the services of each of those devices, right? So it lets you actually expect the stuff that's kind of running on that device. So you can think about these the same way you think about an IP address in ports, right? It's the same thing, you have a Mac address IP and then you have these channel numbers or PSMs for the L2CAP protocol and those are outlaid on the right, too. This thing returns the entire URL, which says that we're going to talk over the B2L2CAP protocol on PSM 19 on that Mac, right? So you can just copy and paste that right back in a blue cat and connect to it. So I'll go over that in more detail. You can also brute force scan. So this takes a long time, the way that I've done it. So maybe it's faster with other implementations but this is the cross-platform version. So if we scan this thing, we can scan RFCOM channels first. We can see that we have a bunch of open channels. So even if they're not advertised in the service discovery, we can still find them this way, right? And then if we scan L2CAP channels, you can actually look at all the channels that are open from every possible L2CAP channel. So even if they're not valid, it'll still try to see if that stack will allow it. And this goes up to a very high number but I've never really seen anything over like a hundred. All right, great. So for the past three days, I've been walking around with my bag scanning all the Bluetooth devices. And these are all their names. I put a nice word bubble thing, right? So all this specific stuff is really tiny but there are a lot of iPhones, MacBook Pros and BlackBerrys. Yeah, do you guys all see who sees their machine on this thing? Who got invited to this talk during the week? Nobody? Nobody's afraid to raise their hand? What? It's the GPS. Oh yeah, I see the scoreboard. I said that was fun. You guys just left your Bluetooth on. Who saw the scoreboard advertised for the Blue Cat talk? One? A couple? Okay. There's a short amount of time. Okay, so I got statistics on this, right? So there are 92 unique names that I found, right? And sometimes the devices won't send names, they kind of lag and then they disappear but you definitely get their MAC address. So I found 126 unique MACs just broadcasting. So there are tons of other ways to find device MACs but this is the blatant one. I didn't even think it would work. I was like, no one will leave their Bluetooth on. Less even discoverable because these are discoverable Bluetooth devices. I thought I was going to find like two and then be at the hotel. Like, you know, just staying, not knowing. So I sent these 126 MACs, 13,000 pairing requests with an invite to my talk. So that was funny. For people clapping, the ones that were invited, okay. So the reason I could do that is because you can script Blue Cat, that's the point, right? So I could write a program and that's a pain in the ass. I could say that here. But so bash scripting just makes everything so easy. You don't need to care so much. So if your name's on here, you have, I think this is the coolest names out of all the names. Just to prove to myself that these are not hotel guests. So maybe the DoD is staying here, right, so I don't know. So, okay, let's talk about URI Monkeys, right? So this little URL that I was talking about before, it kind of says everything that we want to know about the service. So you can think about like HTTP and HTTPS as equivalent design, right? All right, so we pretty much have three that I care about in this program that to use that make kind of makes sense. And then the object exchange is kind of pushing it to what this program kind of does. So the BTSPP, the Bluetooth serial port profile, which is also called RFCOM, makes the most sense for this kind of end cat replacement, right? It's a serial port protocol. It's meant to take stuff that used to run over serial ports and make them wireless, right? So that one's easy. L2cap kind of is a little bit different. You kind of just have fixed width buffers that you send over and you negotiate like a size. So you can achieve the same thing, but it's, you know, it's kind of exactly the same thing. So it's kind of redundant. And then you have an object exchange, which is when you send files back and forth. So these three monkeer things on that, if you have these in the URL string, then that's what they'll correspond to. All right? And you kind of have this weird Bluetooth stack, right? So see RFCOM, which is a BTSPP and then L2cap. So RFCOM sits on top of L2cap. And then you have stuff that's kind of completely out of the range of blue cat, which is like audio. So that kind of stinks. And then the other LMP, I don't know what that is. So you kind of have limited range on the stack of Bluetooth, right? Let's go over these profiles a little bit more. So the SPP profile is designed to emulate RS232 serial ports, right, it's a serial port protocol. So it kind of has the same major attributes of TCP. So you're expected to have in order delivery of all your messages. And if it's not delivered, you'd expect that it would retry or just like kill the connection, right? So you kind of have some guarantees with it, right? It only has about 30 ports. Depending on the stack, this like varies what you can use. And then if you think of, if you know port map, right? Would the old run NIS, right? Would advertise on port map. It kind of works the same way. You can't really be guaranteed that you're gonna have a port. So you can ask for something and then if someone else is using it, it just says no, I'll put you on a higher port. So it's kind of a drawback, which is why you need to kind of do the scanning to like look at what port it actually ends up on, right? But it's the same consistently on a device. So if you run blue cat on a device and you get channel four, it'll probably always be channel four unless you like, you know, reflash the device, put some other services on it. Okay, L2 caps underneath RFCOM. So you can make it unreliable to UDP, but that's not really in the interest of this stuff. And then it has the default maximum packet size of 672 bytes, so you can kind of send them over in chunks. And then RFCOM sits on top of L2 caps. So there's a PSM or a channel number three in L2 cap, which is kind of RFCOM runs over all that. And it has way more port numbers. So I scan up to 65,000, and then at somewhere people advertise like 40,000, and it's all like the odd numbers, which is weird that you just have odd port numbers, but it's a great protocol. Okay, so here's a list out. So you have TCP, UDP, we all know those. RFCOM, we have one to 30, we call those channels. L2 cap, we call it a PSM or a protocol service multiplexer. And then the odd numbered, so you have like a reserved at the base, so these are the interesting ones, most part. And that's 4,000 of them, and then the spec says it goes up to 32. So it's kind of the lay of the land there. So you can just a side note, you can look up MAC addresses the same way you'd look up IP MAC addresses on network adapters. So that's kind of, it gives you more information, but nothing really aligns properly. It doesn't say Apple Incorporated, like it would with the network MAC, so it doesn't really tell you a lot of information. All right, so getting back to Bluetooth a little bit more. We can use the dash E option, which is like from NCAT. So here's an example, so we have two actors in this, we have the green and the blue, right? So we're launching blue cat with verbose dash V, which gives us this pound comment line, dash L for listen, and it's gonna choose any channel, and then we're gonna do dash E for bin bash. And so upon connection, I wanna execute bin bash, and set up standard in and standard out to be wired right there. So we can then act with two, the blue computer will list the services on that first machine. And it outputs that there's something to listen on channel four. So we can connect to that. When we connect to that, I type hi, and it's, it's shove that command to bash and bash that out, you know, it's a program in high. So that's kind of a cool usage. You can kind of have a point to point remote access to some device, which is kind of cool if you like hang a Raspberry Pi in the corner, and then you can just connect to it without a wire. So I'm gonna get a little more in depth on the Bluetooth plumbing, right? How this kind of, other stuff can kind of be put together. So we have this basic Bluetooth connection at the top, blue cat, we connect to some URL, which is identifying the second blue cat process running somewhere else, and they're gonna change the standard in and standard out like you normally would. So on the left, we have a terminal, and on the right, we did a dash E option. So it's just gonna pipe the standard out from the terminal to the standard in, in bin bash. So you kind of remote control the service. Oh, over Bluetooth. And this works the other way, I just tested it. So you can do a dash E on this side and you can like have one process connect and then launch a service immediately when it connects to the server. And on the other side, it connects the same process or a different process. So you can have two processes talk to each other over a Bluetooth link and they never have to know anything about Bluetooth. All right, so when we start, so I'm gonna go through a bunch of devices that we just kind of like, you know, give a brief overview of how they would work. Bluetooth has profiles, so when we kind of look at this stuff, you can see profiles in these certain types of devices. So we're looking from a specific angle with blue cat. But that's not really the way that devices want to look at each other, they want to look at each other and say you're a phone, so you must have these, you must have a hands free mode, right? And then you can identify those with UU IDs and device classes. So device class will say I'm a, you know, a laptop. So I'm gonna have laptop like services that you can see if I have and then go forward to that. So it's really crazy, the way that they look up to each other. But underneath, if you just look at it from a raw implementation point of view, we have RF common L2CAP channels or PSMs that you can connect to for these services. And like in the case of like an audio gateway, sorry, it'll go to another service that has like voice. So it's kind of a collection of services on Bluetooth that can pose a profile. So if we start looking at something like a printer. So we scan this thing, we get a Mac and it's an Office Strip 6300. And we can see that it has a micro link nicking it on the Bluetooth. So that doesn't tell us anything. So unless you know that micro link sells to HP and then you can tell us it's HP or something, right? They probably don't exclusively. So it's hard to get the gain information that way. But we can look at the services that are listed here. So we obviously know it's a printer because we can just read the name. And then the device class will be, we'll say I'm a printer. And we can see that it has a serial port listed here, right? So it's a on channel one. So we can just try to connect to that with BluGaN, type some stuff and see what kind of error it gives us. Bluetooth really isn't good for giving errors. It, when people implement Bluetooth services they just don't respond instead of give like an error message. So it's a little bit tougher. So we can type BluGaN-URL and just put that URL in there with the Mac and the channel number. And connect directly to this thing. And it turns out this printer, so BluGaN launches and it doesn't ask for authentication. It's usually the other side. So you would, you'd connect to this printer and the printer would be like, all right, that's fine. I don't need to pair with you. And it will just let you connect to the socket and print out. That's not the case with a lot of devices, but printer is completely anonymous access, right? So I messed with people with this first. I found out when like a bunch of stationery was used and people were kind of mad. So let's look at the next phone. So this is Alcatel, right? So let's take a look at BluGaN. It was a device name, some audio gateway, object exchange, dial-up networking, right? So we can use it as a modem. And then we just have a serial port. So if we just connect to the serial port, this wasn't as easy as this, but you can connect to it and let's say, let's say, so I had to pair with this phone, right? So we're pretty safe unless we pair, but I guess there are pairing flaws that people have been telling me for the last couple of days. So we can just type the AT-Haze connection or the commands to this thing and we can get the device manufacturer, the model. So those are all easy. Or you can just look at it from the name and we get the third one, it's kind of as a date that it's talking to me. And at this point, I could have put more in, but the guy that I was playing with this phone, he like shot off his phone once he started it. Once I got excited, I was like, these commands are working. This is awesome. Is this hard to find phones that you can actually do this to? Cause this was a really old phone. New phones aren't friendly to people who want to just poke around on them, probably for good reason. All right, so we can look at anything that's Bluetooth, right? So if you look at a Wiimote, we see that it's service records kind of weird, so it returns these records, but they're empty. It doesn't say any information. So maybe it's trying to hide those things, but we can see up there that we have three services listed and one's obvious. I think it's the channel 11, or PSM 11. I know when we scan it, we actually find that it's one, 11, and 13. So one's kind of a default one. So 11 and 13 are the ones we can talk this thing on. But people have kind of completely reverse engineered the Wiimote stuff. But if you were starting from scratch, you could do it like this and then kind of start sending stuff to those ports. All right, so we can take a look at the Nexus 4. All right, so we list the services on this and we see we have a headset gateway, no serial port protocol, so we can't have fun with it, no dial-up modem, so we can't mess with that either. So the fun ones to look at are these BTSPPs. They're usually text-based, right, ASCII-based. Except for an example, I'll show it in a minute. So we can try to connect to one of those. So let's do the hands-free one. It's the only one I could really find anything to look at. So if you kind of Google that in, you can find profiles and the profiles will tell you kind of what some sort of established protocol for it is, but the documentation's pretty bad and not uniform across all the manufacturers. So I got this thing, I kind of connected to it and the first thing I type now when I connect those serial port protocols is I type AT or AT plus and have it give me an error, right? And then if you say something really weird, like AT star, it will just kick you off. So to get it to give me an error is a first sign that there's somebody on the other side listening that we can try to, there's some commands that must do something. So after reading this, reading all the profile stuff, we can see that the hands-free profile has a lot of AT commands, like the one that's the coolest one is dials a number. So this actually works on the Nexus 4. You can do ATD and then like 5555 whatever, or I don't know, maybe an expensive phone number and it will call it, right? So you can also list the number and then list all the services that are there. So there is a way to talk to these things, they're just obscure and they don't really advertise all that stuff, right? So it's a little bit difficult to kind of get information from these things. So a thing that I did with Alex Whitmore, like an hour ago, two hours ago, was look at the YAP, so I didn't know what it was, I thought it was access point, that's like kind of intuitively how I thought it was and I guess it's the iPod accessory protocol, so I don't like, I don't like iPhones, but. So the goal is like how can you play Stop, Start and control the auto tracks on the phone, right? Like that would be pretty cool if you disconnect from your computer or like write a full-fledged app. It was all software-based, it wouldn't interact with us. And it turns out that there's a chance that it could be the same interaction as the standard UR in the Apple Connector, so if you just wire it up into that. So that's kind of the hypothesis and it turns out so that there are the regular way you do this over the hard wire, right? This is the same packet thing for saying I want you to play, right? I want you to stop. So that's like well-documented for the hard line stuff. But sadly it turns out that Apple has like a weird authentication co-processor that's required to attach to this process so that makes it different than the actual wire line, which makes it kind of undoable with Buget, unless we can kind of process this stuff fast enough. But more research will be needed for this stuff. All right, so the next section is rapid prototyping with BlueCat. So if you just want to make something really quick with bash bits, right? So how to prototype. So this presentation was supposed to be given with a Bluetooth Presenter that all the only thing on the phone would be an app that just sends characters over a socket. So I press a button, it just sends a B or an F, right? And on a laptop there's something that's listening and it goes into a script that's dispatching all the characters as they come in and will respectively press back or forward to move my slides. So that's the basis of it, so we can go over how this works, it's like a few lines. So we launch BlueCat, we do a keep alive verbose to stay on, to connect to this URL, which is on my phone on channel four. And then when we receive a connection, we just throw it to dispatcher.sh, which simply looks like this, right? So we just well read input. If the input's an F, I go forward and then press the key for forward. So it did work great all weekend. So you can do other stuff, you can say on any input, you can filter on different words and have it do anything. So it's kind of like, this guy's the limit with anything you want to control on this device. So that's kind of the basic way of prototyping, right? So you can, any way you can think of in the future to kind of use that stream in that kind of same concept, it's pretty easy to do. So I scanned for like over the course of three months from the same desktop next to a computer lab every five minutes. And every single Bluetooth device that was at the visible, I captured and stored and then wanted to run data analysis on it later. So I happened to write BlueCat, so it outputs in a CSV format. So we just ended up having tons of CSV files and you can just import those in a database or an R which I did and analyze some stuff, right? So kind of a shout out to R, it's awesome. So we can just read this file and then filter based on the date to convert them all to dates and then you make a histogram based on dates and break them all up by into a hundred bins, right? So we get this thing. So this is a February table where we can see this should be numbers, but I didn't go back and regenerate this thing. So this is in the upwards, it's pretty high. This is like 2000 scans, the magnitude of this stuff. So you can see this dip. So why is there a dip around March 23rd, right? So like you can say why are people not walking around here? So we can take a look, filter more just in between those date ranges for the month of March, right? We can see that it's really close around the 21st to the 25th. All right, so I was like why would my script fail or something that was running? And then I looked and it's spring vacation. It's like towards the end of spring vacation. So it kind of made sense, you can align some data collection with the fact that students were not coming to school. So this was at university. All right, and then so the more scary of pieces I can look at just me. So this is when I was in my office, right? So you can do that for, I can do that for anybody and you kind of know their name because it's their MacBook or their phone, right? Like so-and-so's iPhone, right? So this is, I guess I'm a slacker in March especially. So, so now we can get into the kind of architecture and design of BlueCat, right? So one awesome piece of it is it runs on, I've only really tested on Mac and Linux, but the BluCov library, which it sits, runs on tons of different platforms, like Symbian, Android, and Windows, if you wanna use that. So it works on blues, great. So this is like the main advantage over using a different library like this, like pie blues, but then you're stuck with blues. And you can't really use it on a Mac, which, I mean, or any other thing in the future. It doesn't have this good abstraction layer because you're stuck in the blues libraries. All right, so it's pretty small. I mean, there are like a bunch of Java files, it's Java-based, so you can brew appropriately, but I don't know, I like Java. So, and then it kind of gets off-loaded to a series of different jar files that contain native libraries for whatever platform you're on, right? So that the business logic, right, is all contained in the Java stuff, and then we just call based on the different platforms, different libraries, and kind of arrange everything appropriately. So there's one main file, and it'll run on like ARM Linux, Mac 64-bit, Linux 32-bit, 64-bit, Ubuntu, Fedora, a lot of stuff. All right, so here's one kind of diagram of how this stuff kind of will interact with everything. So you run a blue cat, it sits on top of a blue code, it makes all those calls, and then if it's Mac, it just off-loads it straight to the Apple API, or it outputs everything in the blues, if blues is available, which will hit the Linux, you know, Bluetooth D, and the kernel modules, and then whatever Linux is running on, that implemented blues, it'll work fine on, right? And then that, that'll actually work fine on. And then that'll actually hit the actual hardware. So it's very reversible, which is about the design, so like a lot of people can use it. All right, so this is a iChart, it's just a blue-cove stack, the way it interacts with everything. I don't really want to go over it too much, but I want to talk about how the JNI libraries work. All right, so blue-cove specifically off-load stuff using JNI libraries. So who's sort of JNI libraries before? All right, so I think they're pretty awesome, because you can do all the business logic in Java, and then, hmm, sorry, time, oh no. Okay, so first of all, how the fuck is that on the screen? Holy shit. Lots of people want to talk about lots of things, but we're not going to let that happen. Oh my God, is that boring. Oh wait, it has a Bluetooth controller on it, never mind, that's cool. You all know the drill, somebody, holy shit. All right, get up here, man. Hey, wait a second, were you just in the last track we were in? Is his name Sarah? Are you Sarah? All right. Maya, what's your name? Atomic Waffles. What, holy what? Atomic Waffles. Oh, thank you, this is, everybody, this is Atomic Waffles, Atomic Waffles, this is everybody, hello. I'm lonely over here. I'm sure you are. I'm still, hey, wait a minute. Where did you come from? That's Atomic Waffles, Jesus, don't you pay attention? I can just take the bottle. Okay, slow down champ. And, what, you're going for a second one already? All right, everybody, you know the drill, welcome to DevCon, we'll see you soon. He's going to go back to the slide now. Waffles got off the stage, I just, what's the time? Okay, okay, we're on time. All right, so we have all this stuff that J and I, and the way that that gets set up to actually run all these platforms, it's really just a script, so it's kind of like a dispatching script. So we just kind of weekly match the OS type of Starwood and Linux architecture and spit it out. So if you want to use Bluecat and it's not supported on the architecture, I can just build all these libraries on your architecture and wire it in if you want to use it, right? Okay, so send me an email if that is the case. All right, and then we simply attach the libraries and then run this main driver for the stuff. And then one problem, so if you look at this file and you're like, why is he filtering out the standard error, it's because some stacks output tons of debugging information to standard out and there's no way to shut it off. So I just filter it in some NS auto release, no pool, auto Mac, it's just a spam thing. So this just fixes that. Cool, so how does J and I work inside the libraries? All right, so somewhere in this Bluecode program, when it runs at the text the OS that it's running on and then loads the specific native libraries for it, it's going to search everything in the load library path which is in default inside the jar file to find whatever stack that it should be running on, right? So once that's loaded up, it then has these extra native functions and they're ready to call, right? So you make a call to this, our RF server get channel ID impel, right? So this is something, it's a pretty low level thing you have to handle for the specific connection and that gets offloaded to the C code or whatever C++ code they wanna use in the native library which is declared like this with like a J and I header to actually interact with that specific stack that you're running on, right? So you'll have to do this on every platform that it runs on. So I didn't do this, this is all the Bluecode people which I don't have, their logo is on a different page. So they've done tons of work and it seems like they all work for big companies anyway so they're probably getting paid. So that's good. And thanks. Any questions?