 So here who here likes coffee? Excellent, right. So this talk is going to combine a few of my favorite things, coffee, hyphen, mic, that's not turned on, okay? So it was turned on for the testing before. Is that better? Yeah, okay, right. So it's going to combine some of my favorite things which is coffee, which comes from 20 years of programming. So now I've got a coffee addiction. I didn't have one when I started coding. Pikes and USB analysis. So this is actually two talks for the price of one. The first half of the talk I'm going to be showing you this coffee roaster and Coretto style coffee roaster. I want to explain all about how to build your own coffee roaster and how to then control it using a Python application. Now in building this coffee roaster it turns out that I had to do a bit of protocol analysis. And I love protocol analysis. I love working out new devices and writing Linux drivers for them. It's great fun. So I thought that this would be a great opportunity to teach you all a little bit about some simple techniques for protocol analysis of simple USB devices. So the second part of the talk is going to be showing you how to take a cheap USB connected multimeter like this and write a Linux driver for it. How to work out the protocol and then write yourself a driver. And it's really very, very simple, very simple techniques. Okay, so let's start off on the actual coffee roasting. So how does coffee roasting work? Well, coffee roasting starts with these things over here. And if I press this fancy little document camera, you might see them beans. There's some green, oh no, they're not there. There they are, some green coffee beans. So it starts with these green coffee beans and then you need to roast them. And there's a few inputs to it. There's the green coffee beans themselves. There is heat. You need to get them very hot. Anyone tell me what sort of temperature you need to roast coffee roughly? Around 210. Yeah, that's right. It's even up on the slide. There you go. Around 210 between 200 to 210 depends on the beans, right? The optimal temperature. There's lots of discussions on the precise temperature. There's lots of online forums for discussing coffee roasting. The best of them I think in Australia is a place called coffee snobs. So if you're into coffee roasting, anyone else here a coffee snobs member? Yeah, up you. Excellent. Good stuff. So coffee snobs is a great place to go for all the information you need on building your own coffee roaster, home brewing, etc. Okay, you need some way to stir the beans to distribute the heat. You don't want all the heat going into the top layer of beans. And you need a bit of time. It typically takes about 15 minutes depending on the size of the batch, etc. to switch from having green beans to having roasted beans. So the output is roasted coffee, hot roasted coffee. You then need to cool the beans as quickly as possible. And this is a part of the whole build your own coffee roaster that I haven't really got into yet, which is building a mechanism for cooling the beans really fast. Because true coffee snobs know that if the beans are cooled fast, they taste better. So currently, I just stir madly in a big colander. And today I didn't even bring the colander. So they're going to cool pretty slowly. So I'll give the beans to someone else. Now, rule of two, some people say rule of three in coffee beans, this is one of the motivations for why people roast their own beans. Green beans, like I've got in this sack of green beans here, last on the shelf about two years. And they're still good. Once you've roasted them, they're good for maybe two weeks. I reckon they're best in the first week. After two weeks, they're getting a bit iffy. Longer than that, and they're supermarket beans. Once you've ground them, once they're actually in the powder form, they're fresh for about two minutes. At that point, you chuck them out. That's why you don't buy the pre-ground stuff. And that's why all the good cafes, they have a grinder there and they grind on the spot. I think that's also why decaf has such a bad reputation in cafes. Because most cafes have the one grinder for their caffeinated beans. They're decaf, if you ask for a decaf flat white, they grab out the pre-ground stuff out of the fridge, which has been there for a week, and they give you that. And it's completely stale. You can make really good decaf at home if you roast your own decaf beans. And then you grind your own decaf beans. What I've got is two grinders. Caffeinated grinder, decaf grinder. And that way you can have really good decaf coffee for late at night when you actually want to sleep, when you're not coding all night. Okay, I don't get through much decaf. So, Coretto Roaster. Now, I didn't invent this idea for a coffee roaster like this. Not at all. Lots of people have come before me doing this. I've just added a couple of twist sites with the help of Paul McCarros and Hugh Blemings, primarily Paulus over there. So the original idea for this particular style of home coffee roaster, cheap home coffee roaster, was come up with by somebody called a person called Ms. Coretto on the coffee snob site. And that lady worked out that if you took a bread machine, a bread machine is designed to take high temperatures and it has a built-in stirrer. It stirs the bread when it's folding the dough. So you've got yourself a stirrer and it can take great temperatures. You've got the basis for a coffee roaster. You just need to apply a lot more heat because a bread machine doesn't supply nearly enough heat. So what we need is something like this, a heat gun. This is a couple of kilowatt heat gun. So point that in at the beans and the beans get really hot. Then what we need to do is we need some way of controlling the heat into this roaster. Now the original Coretto was done just by, you listen to the roast and you listen for the sounds of the beans as they're cooking. And they go through a stage called first crack. We hear this sort of snap, crackle and pop. And then second crack where it has a slightly different, more subtle pop as the beans get hotter. And you listen to that and then you adjust the temperature using either adjustable temperature heat gun or moving the heat gun further away or whatever. And I thought, oh, we've got to do better than that. We've got to have computer control over the heat gun. And so that's the basis of this thing that Paulus and I have built. So what I've done is I've got myself this bread machine. I'll just show you the bits and pieces of it. This is an ordinary bread machine. I've assured my wife that it could actually be used for bread sometime in the future again, right? Maybe. There's a couple of holes in the pan. But hey, we'll use thick bread that won't leak out too much. So it's got a metal stirrer. I did try and use the plastic stirrer that came with it. Not a good idea at 210 degrees. It's discovered that it melted quite badly. This stirrer I have stuck, a drill didn't put a wire through it to stop it flopping over. This is one of those stirrers that flops out of the bread at the end. I don't want it to flop over. A little wire through it. Very simple. Couple of holes here, you'll notice. That's where the thermocouple goes in. Because if you're going to get your computer to control the roast, you need to know what temperature it's at. So that's what this little thermocouple is for, which pops in that hole there through the side. My original design had the thermocouple sitting inside here, inside the wall of it, and going straight into the pan. What do you think happened? It got too hot, and the plastic all melted, it ended up buying two or three thermocouples until I suddenly realised, just drill a hole through the outside of the whole thing and go right through, and the plastic is then outside the bread machine. It doesn't get as hot, it doesn't all melt and fall to pieces. Okay, so we then need to pour a bunch of green beans. So I'm just going to give you a bit of a demo. Now I was originally thinking I'd have to run this whole thing at low temperature because I was concerned about the smoke alarms in this room and setting them off and being hit with a massive fire or whatever, but I've been assured by the good organisers of LCA this year that the smoke alarms are turned off. If it starts raining and hail on gas comes in or whatever, then it's not my fault. Nothing to do with me. So we've poured a bunch of beans in there. You can fit between sort of five, 700 grams roughly or basically a bunch of beans, stick it in there. I'm then going to point this heat gun in at these beans and I've got my digital multimeter hopefully set to temperature. Some of you should be able to see that there. Hopefully it's saying about 23 degrees C, which is not going to last long. And then what we're going to do is fire up a little Python script. So I've got this little Python script called PyRost. And so fire up PyRost and notice I'm giving it an argument. P control equals dev TTY USB 0. That's talking to this little device over here. Now this is perhaps the most important part of the whole setup and it's really the only unique component that was added on top of the basic design from Coretto. And I didn't build it. This bit was built by Paulus. So let me just show you. In fact, I'll show you back here what it looks like inside. These two little pictures you can see here, this is the Mark 1 versus Mark 2 power controller for a home coffee roaster. That's the guts of this one here, which is this little silver box. Coming in on one side is a normal household power 240 volt. Coming out the other is household power 240 volt. Coming in here is a serial port. And in the middle is magic. And the bits of magic in the middle, that's Paulus' design. And those bits of magic basically allow me to send some ASCII commands down here. I can either send like 67% and it means that it just chops the waveform so the 67% of the power gets through. 99%, whatever, I can choose the percentage. Really convenient for a non-hardware geek like myself and very much a software person. It was great. Or you can send a number between 0 and 26. And it'll similarly produce a scaled amount of power coming out there. And so that power then goes into the heat gun, which means that I have this serial port to control the amount of power going into that heat gun, which is great. Now Paulus' second version of it over here, which unfortunately we don't have here today, the second version is a bit fancier. It incorporates the thermocouples, in fact two thermocouples, directly into the power control device, which means you can read the temperature directly out using the serial connection. And because it's got two thermocouples, you can do averaging of the temperature in two parts of the pan, which is much more accurate. You can get a much better result. You'll notice that when I start doing the roast, I get some fluctuations in the temperature. And the primary reason for that is this particular bread maker, which just happened to be the one I had at home. When you set it to the mode that's closest to what you want for roast, which is just continuous stir, it reverses direction every two minutes. And that means the beans that were cold get shoved over different parts of the pan, the other ones hot, et cetera, and you end up getting a bit of fluctuation in the power. Okay, so let's try and fire it up. So let's see, if we fire up this little coffee roaster, then what we're seeing here, hopefully you can see that, you see the temperature there showing 23.2 degrees C. It shows the rate of change there, 0.0 degrees C per minute, the elapsed time, and you've got buttons down here for choosing when you hit first crack, so you listen for it, because then you keep all your roast profiles and you exchange them with your friends on coffee snobs. That's the idea. And you say, this one tasted really good. You can also load a previous profile and use that as the target temperature profile for the Python controller, which has a bit of a modified PID loop. Can anyone tell me why, you know what a PID loop is, don't you? Roughly control loop, basic computer science control loop. Why isn't the basic PID loop exactly what we want to control the heat going into this? Anyone guess why? Lag. Exactly, hand up there. Excellent, that's the lag. There's in fact a huge amount of lag. If you up the heat here, then the actual temperature won't start rising considerably for about 15 to 20 seconds. It takes quite a while for the heat to penetrate through the bean mass. And so the solution I came up to, because I haven't actually done any control theory and things, I just thought, I'll put a PID loop at the end of a bucket brigade, right? So I just created like a little cascading one-dimensional bucket brigade where it simulates heat transfer from bucket to bucket to bucket to bucket, done on half-second averaging between the buckets. And at the end of it, there's a PID loop controlling with a delay, and that produces a basic model of the heat propagation, a one-dimensional model of heat propagation through the beans, and that works pretty nicely. In fact, the whole thing can run in simulation mode where it simulates the actual, the full roast, allowing you to tune the PID loop by matching the simulation to real roasts, which then allows you off-line to sort of experiment without ruining quite as many, you know, wonderful beans. Okay, so what we're seeing there is a little graph there. You can see the little pink line very faintly in the bottom left corner. The temperature's been sitting right at about 23.2 degrees, and what we're going to do is we're going to temporarily turn off auto power control and set a target temperature. Now, as I've been assured that the smoke detector's off, I'm going to set it at 210, which is what I would normally do for these sort of beans. These particular beans, by the way, are Bolivia Green Mountain Estate beans. Another reason why a lot of people get into home roasting initially or the excuse they give to their wives is that coffee's much cheaper as green beans, typically about nine bucks a kilo. So you can drink a lot more coffee for the same amount, but that's really just an excuse because then you spend it all on the other bits and pieces. Whatever. Okay, so I'm going to fire this thing up and then put it on auto power control, and I'll also clear that graph so just reset the graph. So what you'll see now is that this little it's getting quite warm here. If any of you want to come down, by the way, oh, I need to actually turn on the stirring or it's going to get really bad. Right, so I'm now going to start to stir the beans. You've got to make sure you have the stirring. I would have burnt the beans quite badly if I'd left it on too long. So the temperature, you should see it starting to rise there. My apologies for the small size of the graph. Everyone still see it okay? If you can't come down the front and have a peek. So the temperature will start rising and it'll take about 15 minutes for a full roast. I may not do the full roast today because we're going to probably run out of time. I want to get into the USB protocol analysis, but it's very simple and maybe we could take it to first crack and see if you can hear the beans popping for first crack. Okay, getting quite warm. This little tile here, by the way, is just to try to keep more of the heat inside the pan. You just need a heat-proof tile covering part of it and the exact orientation of the heat gun and things probably matters. Just reverse. After two minutes, it reversed direction so you'll see a bit of a fluctuation in the temperature graph there. Okay, so that's our basic roaster. Now, maybe I should show you... Shall I leave that running? Can you actually hear me give the talk while I talk the rest of the stuff and leave it roasting? You're all happy with that? Okay, so then I'll go back and talk a bit more about some of the other things that... Right, so that's a power control device. So what I'm going to be talking about next is one of the interesting things that I think... that I need to work out for this particular task. So I had this USB multimeter and Paulus' solution, of course, was just to build a thermocouple himself directly in his power control device so he didn't need to work out the protocol to talk to his own device because he was able to convince himself to give himself the protocol. Whereas in my case, I got this, you know, cheap Victor Chinese digital multimeter so I need to work out what the protocol is. Now, what's happening is this multimeter, it's got a little button on it's marked RS232, right? It was originally a serial multimeter in design and then the manufacturer has then converted it to be a USB multimeter. Put this little bit in the top. It gives me a USB cable. But there is no documentation on the protocol. This thing talks from the multimeter across to the computer. So you need to work that out. Now, how would you normally work that out? I mean, this technique I've got up on the screen is the usual technique. That most people use. What they do is they think, okay, I've got a Windows driver for this thing because if you go to the website of the manufacturer of this multimeter, you'll find that there is in fact a device driver for Windows which will display whatever's on the multimeter up on the Windows box, right? And then there's lots of software out there for capturing USB packets. For example, Wireshark can do it. How many of you have used Wireshark for USB sniffing? For USB sniffing? A few? Yeah, everyone's used Wireshark. I knew that. So Wireshark, it turns out, actually supports USB sniffing. The kernel has the ability to capture data using DebugFS. So there's instructions in the kernel documentation. Grip for DebugFS and USB. You should find it. And it tells you how to mount the DebugFS file system and then you end up with some text files. You can just cap them and those contain the raw USB data. And that's great, except there's a slight problem with this technique. Who can tell me what the difficulty with the technique of just capturing all the data going between the Windows driver and the devices? What would you do? Okay, how would you go about it? Say you could just capture all the data. What would you do with that data to then write a driver? Sorry? You want to know what it's saying. That's right. You don't want to know what that data meant. Now, it's fluctuating all the time. The temperature's jumping up and down. At any particular point in time, you don't know it's hard to capture the precise timing and what it's displaying. Plus, you can't test theories with this method. You either write the right device driver or you don't. But what you really want to do is to feed arbitrary data to the Windows device driver. Let's see how this roaster's going, by the way. So we're up to about 120 degrees C now. Does it keep it warmer? Can you smell the coffee? Yeah, excellent. Now notice the other thing you get here. Chaff. I didn't actually warn the organisers about this, but it's a bonus. You get a lot of this chaff and normally what you do is you have a great big fan, room fan, blowing it out over the audience. But in among the... my laptop instead. So I've got a great big pile of chaff where it builds up. The chaff is the husk of the coffee bean. And as it gets roasted, the chaff starts coming off. You get a lot of it. It builds up in your garage, but you just sort of vacuum it up or whatever or sweep it out. Anyway, the other problem is without a fan to blow the chaff out, we are probably going to get a little bit of ignition of some of the chaff in the heat gun. You'll get to see an occasional spark here as it gets up to higher temperatures with the chaff because the actual heat gun itself is 6 to 700 degrees. It's quite hot and it's quite happily we'll burn the chaff. I haven't burnt down any lecture theaters yet although this is the first attempt. 43 degrees C so far and we haven't got anywhere near first crack. So we'll go back to what I was discussing a minute ago. USB protocol analysis. Okay, into leaving the two talks here bit of a balancing act. So what you really want to do is find a technique for being able to modify the data as it goes between the USB device the multimeter in that case and a Windows device driver. So the technique that I recommend is this basic arrangement. So you've got yourself your Windows driver displaying what's on the display on the USB connection and you've got yourself a packet rewriting filter of some sort of program. In my case Emacs. So you know universal programming tool is Emacs. So you want Emacs to be sitting between smokes getting a bit more now, between the Windows driver and your USB device then you have the USB device. So how do you actually arrange for this and the particular technique that I use for this project is the following. So what you have is virtual box 4 which by the way one of the good things came out of the whole Oracle something is Oracle released virtual box under the GPL. Excellent. So I'm running the GPL base release. There's proprietary add-ons but the base version is full GPL which is great. So virtual box 4 the Windows display, a little driver that displays what's on the multimeter. Then it goes into an LD preload. I love LD preload. I'm sure that Eric hates my guts as a result of it. He's always trying to kill off LD preload type Hacks. Anyway, LD preload is a wonderful hack. You can preload into virtual box. Now of course I've got the source code to virtual box. I could just hack virtual box. It's much easier to write a preload. If you line preload it would take me hours to work out where the USB code is inside virtual box and hack it. Much easier to write a little preload. Much more fun. So write an LD preload and the idea is to the LD preload writes all the data that it gets from the real device, the USB device to a log file. So you get the raw data going into a log file, preferably nicely formatted for human use. You want it in a nice hex stump type format, one line per packet sort of thing. Coming down into a log file really easy to use. Then what you want is your LD preload needs to also take input. And so what I've got is a control file. And that control file, if the control file is there, then the LD preload, when the control file data size matches the packet, it will replace the data packet on the way through with whatever is in that file. So it will read the control file and replace the data on the way through. That means you can just have Emacs open on that control file, edit the hex bytes and whenever you hit save, the Windows driver starts seeing different data. That means you can experiment. You can very very quickly say, oh, it's sudden temperature. Let's watch this. Back to the other talk. 172 degrees C getting up there. And notice the fluctuation, the two minute oscillations. That's what's sold by Paulus' second device of two thermocouples. With the two thermocouples you can average between the two and Pyro's supports that. Yeah, Paulus. Probably take what? I get too much smoke. Oh, I don't have a smokey, do they? Oh, there you go. Okay. So I will remove the tile at this point. Hoping not to burn myself. All right. Oh, one hot tile. Yep. Okay. Okay. So the beams will get less smoky that way. Okay. Good. That will take a little bit longer. Right. So what that hasn't quite reached first crack yet. Okay. So we got the control file, then you got EMAX, the USB device, and that's the basic technique. And the thing I'd really like to emphasize when you're trying to work out a new protocol, spend some time to get your work environment set up to have a quick development cycle. You want to be able to try and experiment with testing a theory of how the protocol works in seconds. You say, oh, I wonder if the seventh byte, the high nibble of that is that segment of the display. Test, test, done. You know the answer. Because that fast development cycle makes all the difference. I've seen too many people using a technique where they have to reboot the windows box each time they want to try a new experiment. Right. No good. Yet a really fast development cycle because it does take a lot of thought to work out a new protocol. Particularly one as bizarre as this one. It's really quite bizarre. Okay. So how are we doing now on the must be getting close to temperature. 181 degrees C getting up there. Now for the next part of the talk we're actually going to work out the protocol for this multimeter. The problem is that I need the multimeter disconnected from the coffee roaster to do that. So I might just wait, let this roast go a little bit longer and then we might actually stop the roast at a time in the USB protocol analysis part of the talk. It means these beans won't be so good because we're stopping it way too early. But I think that's probably the best thing to do. So I'm going to stop this roast at this point and turn off auto power force the power down to zero I'll save that roast and right. Let's stop this thing. But you get the idea. The problem is we would have run out of time I think and I'd really like to move. I'd definitely like to move on to the second part of the talk which is let's actually do some protocol analysis. Now what I'm going to do I'm going to try and put this display we don't need that power control device going to try and put this multimeter on the this display over here so that you can actually see what's going on with it and let's see what this thing does. That's a bit zoomed in how do I zoom out zoom out no other way more more it only zooms a tiny bit at a time keep pressing okay so that's my multimeter right and there's a little firmer couple sitting there okay so what it's doing is displaying 50 degrees C at the moment now this test oh bug in that program isn't that terrible imagine a coffee roasting application with a bug okay so what I'm going to do now is flick across to this application I'm going to bring up this is a Windows virtual machine I'll just flick it back to the laptop display for a moment okay now it doesn't like the mouse so here we got Windows 7 and this is Windows 7 running the digital multimeter application that came with the that you can download from the website okay so what I'm going to do is in virtual box you can tell it to well supposedly if this thing actually it won't take mouse clicks so let's see whether it'll take it from here no I can't click the mouse on this menus and things at the moment maybe I can do it up via this it's not seeing any USB devices whatsoever well there you go demos LS USB doesn't hang let's unplug it and plug it back in again which is the usual technique alright and see if any kernel developers in the house ah come on come on USB there you go now let's see if this thing has recognized that it's got nope so what we're going to do is we're going to reset the virtual machine and it's failed to save state and let's try and just power it off and let's see if we have any luck so we may not be getting an awful lot of luck here so I'll show you the little script I use um ah let's see junk code preload usb start win 7 and ld preload let's get to the right there it is ok that's the command I'm running there I'll just up the font a little bit here so is that just about readable yeah ld preload equals full path to my preload.usb.so and then I'm directly running the virtual box application now I'm running this as root the reason is that preload and non-root applications when they start switching UID while they're running doesn't work so you need to actually start up your virtual machine as root so this is in this case running it as root it's easiest way you can instead put the whole thing and etc the ld.so.preload everyone know what a ld preload is anyone not know ld preload ok a few people right ld preload is a hack you basically create a shared library say you've got a function that you want to replace in an application virtual box so virtual box I've actually got a slide about this would you believe virtual box controls the usb devices by opening the device with an open call in fact it uses open64 then it calls IOCTLs IOCTLs control functions and it has two main IOCTLs it uses one is called usb devfs submit herb and the other is ufs devfs reap herb end delay they're the two primary ones you can guess what it does the end delay means don't wait so submit herb takes some data and squirts it at the device then reap herb returns the reply from that data packet back to the application ok and it tells you what pointer it gives you back your original pointer to the structure this usb herb structure gives you back that pointer so you've got your original structure back with filled in data replied from the device so what you can do with an ld preload is create a little shared library that implements your replacement functions for open and IOCTL and close when you see an open and the path to the open is the usb device that you want to intercept then you remember what file descriptor you do the real open right because you can ask the c library for a pointer to the real open then what you do is you get that real one and you remember it then when you get an IOCTL if that IOCTL is on that file descriptor you got earlier then you've got an operation on that device so in this case you can read the data that's going out to it and you can see the data that came back and you can start replacing the data before you return to the application so that's what you do with ld preloads very simple technique really it's not much code so if I start this I hope the virtual box will start and not crash on me I've had various problems with my usb oh it's going to reboot windows how about that ok so once this thing starts up then I will be able to give it the usb device patch that into this windows virtual machine and hopefully that will work there you go so there's all my usb devices and I'm going to patch in the shenz and victor high tech multi meter which is now patched into that windows virtual machine like that so if I now run this dmm app and tell it to go start yes 20.7 that's the correct temperature off here so it's now currently reading this multi meter my ld preload is passing the data through to the windows device driver and it's doing one additional thing it's as I said mentioned before it logs everything so if I do tail minus f slash chump slash usb log you'll see all the data there flowing between the multi meter and the windows device driver ok so now as an audience we will now work out the protocol for this device right so let's first of all what we're going to do is temp usb log open it up there's our log ok now we want to know we first of all got to get some examples of what the bytes might mean so what we need to do is take one of these rows and put it into this usb.data and now what happens is my log is now saying that it's replacing this data with that fixed line right and so now I can read off what is on the windows display which is I'll just make this window a bit smaller so you can see it 20.8 so we can now put a comment on that 20.8c in fact it's 0 20.8c but those bytes are 20.8c now we need some different bytes ok what do you do well you stick this in your mouth ok and this is the version from you know having the data in my mouth and we see that that temperature if I now put that as the top line my preload just takes the first line it now reads 27.7c so that line is 0.7c 0.27 right now what we ideally want is an example with only one digit different so we can start we want really minimal differences in data and then we try to work out which bytes correspond with what digits on the multimeter so here's a couple of examples that I just grabbed earlier from sticking into my mouth less aggressively and so this one here 2 degrees centigrade read by windows and windows interpreting those 14 bytes is 24.2 whereas if I put this one it's 24.1c so all of you now have a good stare and tell me which bytes are different between those two the first byte is different and the third byte is different is anything else different no just the first byte and the third byte ok let's start saying can we construct a temperature so we think that last digit the one and the two is the first byte and the third byte and notice that the second nibble of those two bytes hasn't changed only the top nibble top four bits has actually changed that could matter you've got to notice these things so let's see whether we construct 20 let's see if we can make 20.2 so let's take that 20.8 and try to make this 20.2 what we need to do is take this 1b there and take that 3d there 20.2 there you go we've now constructed a new temperature we've fed it to the multimeter it's displayed it ok so that means we are now in a process where we can start sending bytes to the windows display testing our theories and we take our notepad for our emacs buffer and take a note that the first and third byte appears to be that fourth digit so you keep doing that you find other digits that's different you write little one line orc things we take your usb data log and you see what possible patterns were there in my log if I do something like let's say cat usb data log grep minus v equals and orc print dollar one space dollar three like something like that and sort minus u right that's all the bytes that's all the variants of byte one and three that we've got now how many are there one two three well wc minus l you know why count when you can get a computer to do it 12 examples there's 12 different things we've had in that digit now that's quite plausible because there's 10 digits and there's also cases where there's a dot there it's quite plausible that 12 possible digits we could start shoving in some of these so let's take one of them bb4d ok and throw that into our example data so bb 4d and that's now that's interesting right what we've done is scrolling this is no longer updating its temperature graph what's happened invalid input data now this is where things get interesting because a lot of windows drivers will just keep displaying some of them will just stop some of them will log an error it's great if they log an error and tell you what's wrong but the most common thing is they just don't display something when they get invalid input so that tells you that that combinations of bytes isn't valid and that's interesting data right ok now because I'm running a bit low on time what I'm going to do now is show you the second stage of this when you're doing analysis so this is the basic stage first stage start with existing data blobs edit and watch the results on a windows display try to work out the patterns done excellent theory testing write a tool to produce what you think is the desired data and test your tool well that's easy right so what I've got here is a little tool called set lcd and it's just a tiny little c program and what it does is it takes a what I think and it sends it writes it to that file which the preload reads and displays and windows says yeah I got it right 1 2 3 4 c or once you've looked a bit further you realise how to put decimal points in you get 1.234 c or 2.34 c 1.2.3.4 c etc so and you play a bit further and you work out how to do you know change the display amps and I've started giving it amps it'll actually get unhappy about some of that because it doesn't like changing mode so I'll put it back to degree c you can work out all the different display modes because this thing can flick around between different display modes right hertz voltage amps micro amps and it's the same technique you can work out the entire thing so after that of course you now know exactly what the protocol is now all you do is you detach your little USB here wait for virtual box to be happy about the fact you pulled the USB cable out while it's reading from it a few more seconds and then you can write yourself your own reader and you end up with something like this is now it's sometimes it has to reset the multimeter a couple of times let me just try it again come on pull it out and try again occasionally the multimeter just gets stuck and stops sending data alright so I'll see whether I can kill this and start it again hopefully it'll come up still waiting for it to come up there we go okay that's now reading the same temperature off here and we've got ourselves a Linux device driver right click it to DC micro-amps or I can pick it to amps or to hertz or all the different range settings and it's like you know 100 lines of python and it works so you got yourself then you can do graphing and all the rest so that's basically the technique for working out the protocol for a simple USB device like this this particular one is output only you have no inputs makes it particularly easy if you need input and output you may need more advanced than emacs on a text buffer but that's fine the basic mechanism that I'm suggesting you use is set up your tools your protocol analysis tools so when you're testing a theory it's quick okay so that's it for coffee roasting and any questions if you're just doing hot air roasting why not use a popcorn maker okay popcorn maker is a very popular type of home coffee roaster one problem with popcorn makers they take very small batches of beans typically a couple hundred grams of beans second problem is lots of people on coffee snobs reckon you don't get quite the depth of flavour with a popcorn maker but I've never tried it maybe it's better flavour I don't know the larger mass of beans and the more even temperature you end up with this supposedly ends up with slightly better roast plus I already I didn't have a popcorn maker I did have a bread maker um with virtual box my understanding is that it doesn't have usb pass through on the gpl so I'm assuming it does the gpl version has this is pure gpl except windows image so you're not actually using the binary extension thing no I'm using the virtual box version 4 has usb 1 1.1 or whatever pass through built in the gpl version doesn't have usb 2 pass through so if you're doing video capture devices you either have to use the proprietary add-on or you'll have to use a different technique but most of the stuff I play with is over usb 1 lots of stuff does work to some extent over usb 1 I've even managed to do a video device and actually get it to play a simple bit of video a tv capture card I managed to do that successfully you can do some stuff quite a bit of stuff over usb 1 as long as you're willing to put up with lousy frame rates and missed images and that sort of thing occasionally for protocol analysis and if you've got a device that actually needs usb 2 for whatever reason then you do have to use those you have to use the proprietary add-on and the great thing is the ld preload will work with the proprietary add-on fine because you're not actually requiring the source code I didn't have to actually hack virtual box for any of the stuff I'm doing yep no worries so who's going to build their own coffee roaster now a few people go for it yeah so join the coffee snob site you can end up with a little coffee snob membership card which also doubles as a somewhere here I've got my coffee snob membership there it is and it comes with a little guide to roasting showing the different color so right now that is don't drink this because it hasn't been roasted nearly enough but you get this little membership card like that and that doubles as your guide for roasting and you get people discussing like a CS9 roast I'll put it on the document camera yeah okay everyone we're out of time yep just like to say thank you Tridge this is a small gift from Linux Australia thank you very much thank you for a fantastic conversation