 So this will be a talk on LibratVac. LibratVac is for supporting gaming mice like what I have here. It's the gaming mice today are quite advanced actually, where you can push settings directly onto the device. It has onboard memory where you can configure like the LEDs, the colors, the patterns. You can set different mappings, you can put macros on there, and then once you take the mice to another computer, you still have the same settings on it. Gamers typically have also where you have different profiles on the mice so that you can quickly switch between specific sensitivities for different parts of the game. So that's the profiles, and then there's the resolution and there it is. So the problem with these gaming mice is that the software to configure them is mostly only released for Windows. So we don't have much official support, and every vendor has their own protocol that they talk to the mice with, and typically also different protocol versions depending on which device they use. So the RatVac was created by Peter Hüttere and Benjamin Tisouan. It meant to unify the support for all of these mice because there were a lot of projects scattered around, delivering support only for certain models and brands. So to create one unified interface, to look at all the mice and say, okay, what's the common features that we want to support? Not everything is supported on all models. Then to deliver that in a way that you can integrate nicely into a desktop environment. So there's already been a few talks on Lib RatVac, one at XTC, and one in Aquatic that ended with a note saying we need help with reverse engineering all the mice. So that's going to be the focus of this talk on how to do that so that people can hopefully help. So the basic architecture that's used for in Lib RatVac is that you have user interfaces that the user will use. It could be Piper, which is this one. The user interface talks to the RatVac Demon, which is running, you communicate with the debus. It uses Lib RatVac to have the overall functionality. Then for each mouse or brand of mice, you have different drive-up backends, and these are the ones we will be implementing or we need to implement. The first thing that Lib RatVac will do is that when you start it up, it will start by discovering which of the connected devices can it operate with. It will do this first by matching the vendor and product ID on the USB, and then it will probe the device, try to just make sure that everything is in complete order, that it has this expected features. Then it will internally say, okay, which capabilities does this mouse have? Does it have LEDs? Can I switch profiles? Can I map buttons? Things like that. Then it loads the full onboard configuration that's stored on the mouse, if possible. Then the user will, through the interface, the graphical interface will also some of the state that Lib RatVac now has loaded into its own memory, and when you're done, you say you want to push it to the device, and then it writes everything to the device for you. So you have this middle thing in Lib RatVac where you store a buffer of the changes. Coming back to how we do the matching, the first step you'll do if you want to support on your mouse, is to run LSUSB or similar to get the vendor and product IDs. You put that into the device match, you give it a name, it will just be for showing in the UI, and then you specify which driver you want to use. In this example I took here, it's a SteelSeries driver, and you also have an SVG which will be like a view of the mouse that we'll be looking into a bit later, and you can also put extended information in there if you cannot query it on the device itself. So the basic data structure within Lib RatVac is that you have a device, on the device you have multiple profiles, at least one, in that you can have different resolutions which are that you can switch between where you say one has a DPI of 800 and the other one 2,000 or whatever you need, and you have your button mappings and your LED settings. The capabilities that you will want to put on the mouse are defined within Lib RatVac with some definitions, you can see there are many of them, but these are the things that you will, kind of when you buy the mouse or you have it, you can see from the device pretty much, okay, does it have LEDs? Can I switch between the profiles and things like that? So these are the things that you would start by adding onto the device, and so that's what you could peer out of just by looking at the mouse. Then you will need to start reverse engineering the protocol that it talks to the device with. So since we only have the vendor software for Windows, we will need to install that in a virtual machine. You will install their configuration, software, then redirect the device that you plugged in to the virtual machine and then use Wireshark to listen on the packets. And it's a good idea to set Wireshark to decode things as USB, a hit. So then you basically just start by opening the configuration software, setting something like changing the button mapping, changing it back again perhaps, and then looking into the packets to try and figure out what every byte in there means. So that's the next step to then have a good overview of what all the things that they communicate with what they mean. It's worth noting that some of the data will sometimes change, sometimes they put checksums in there so that you, to verify that it's not random data that they're getting, so look out for that and also consider the Indianess that typically big Indian. So it's a quick demo. For the VM, I prefer to use GNOME boxes. It has a feature where, oops, that means that, nope, sorry, here we go. Normally boxes will not allow you to redirect the mouse that you have connected because then you will not be able to control it outside anymore, but in this case we want. So specify that and it will allow you to do it. Start that up, yeah. Live demos are always a good idea. Okay, in the meantime we'll try to, oh, no, no, no, no. Okay, so maybe this will not work. Okay, that's unfortunate. Okay, so I would have started Wireshark as well, but just to say here, I know now, I didn't know from running LS USB that this is on the USB bus three for my computer, so I could go in here. Hopefully the boxes is coming up behind. So go for that, oops, and I can't see the top, okay? So I can't click on the toolbar in the top where I would start the capture, but okay, sorry about that, yeah. But you would go into that loop, poking at it all the time and looking, okay, I was going to change the LED colors on this one to show, okay, now I changed it from blue. We can see which parts of the message it sends that be set to this value that we know. So I suppose this is not going to be working. Okay. Okay, so, well, once you have done that, then now you know which messages you will want to send. You know the length of the stream that you'll send or the packet and where each individual parts go. So you want to create a new driver and within the source folder, there are already multiple drivers in there. So you just maybe just copy one of them. Then you want to register it. There's just a structure you put them into to have the bread bag consider that one. And then you put in the device file that we saw earlier. So the driver that you will write will have three function pointers where you need to give it an implementation. One for the probing. This is what the bread bag will call into you when it checks to see if the device that you were matched on is actually correct. You can make some basic checks for it by just either sending it a message checking if it has the correct report descriptors. And then you pull the full configuration into the structures. Then there's the commit. Oh, yeah. Sorry. The commit where you push everything back, basically just loop over the profiles, loop over the resolutions, write all the messages you need. Each of the parts in the data structure you typically have a dirty field. They say, okay, did the user actually change this? Can we skip sending this specific packet? The one for set active profile, some mice will allow you to change the profile from from the client. So if you're working with Piper, if you change the profile in the dropdown, then it can move it as well. And the remove function is just to free any new memory you allocated. Libradback has some helper functions that are worth taking into consideration, especially for the NGNS, if you have some fields will be 16 bit. And then you'll want to use the helper functions to do the conversions for you. There's also tables for the hit keys so that you don't have to do all that lookups yourself. So take a look out for those if you're going to write one. So there is also this nice Piper UI that Jente Hitzkes, if I managed to pronounce it correctly, he worked on it as part of the sum of code this summer, turned out to be a really nice interface I think. It communicates with Libradback demon and you use it, it's very general in it and then you supply it with SVG and then it knows how to set up the interface based on the SVG. The SVGs are supplied by Libradback so any client that you write will be able to use them. They supply a basic layout of them, how the mouse looks, where are the buttons, where are the LEDs? Then it has some leader lines going out to the side saying, okay, out here if it says button one then there's a line going in and you can place a button out there to configure it. Once you do a SVG, you want to use some light colors to fit into the theme and there are a full list of rules about how specifically the SVG should be. You must have three specific layers, one called the device and where you basically draw everything from the mouse and then you have two extra layers for buttons and LEDs where you have these leader lines going out to the sides. I'll show an example in a few seconds. The easiest way to do this with these is basically to just take a picture of the mouse from above, put it into the lowest layer of the SVG, put another one on top, make that semi-transparent and then start drawing on top of that so you get the right shapes. And then you name, where if you draw a button, then you name it button zero, that's the left click button and button two for right, et cetera. And also for the LEDs, then that is what Piper will use to figure out what to change. And yeah, you put a small square at the sides, like it's just a tiny seven by seven square, that's again the indicator of where to put the Piper's own buttons. And you also give it an extra information of whether Piper should place the button for configuration on the left or right side of it. So, another attempt at a demo and again I can't see what I'm doing. I'm trying to hit the menu so I can move it myself, but. I'm sorry? Maybe any of the neurodoodle? Yeah, that would be good. Thanks. Okay, so I'm just opening a mouse here, one that I drew recently and you can see those are the lead-aligns. Click on a button here, that's button zero, so you just basically give it those IDs. And then it will use that to set up the whole UI. So, I think if we should have any questions, it should be now, otherwise I would have gone to the demo of Piper as well. That would be nice for the living spirit community, like opening the port of Austin. Yeah, okay, so the question is if there is any vendors who are playing nice with the community, Logitech certainly are, and G-Skill as well. But otherwise you're mostly just getting ignored. So, that's also why I mean that there are so many things, so many devices out there. We need help to people who have access to the devices to go in and start doing the reverse engineering and the hope for this talk was to give some hints about how to get going and hopefully if you wanted to try out then give it a go and get in contact if you need help or for anything. The question is if there is a risk in doing it, if you risk breaking the device and yes, that's always a risk. I think I have seven or eight devices and I've put them through all kinds of things and then they haven't broken yet, but I mean, do this on your own risks certainly, yeah. So, the question is what about keyboards and they have similar configurations. That is true, but in trying to come up with an API that is somewhat consistent and decided to just go for mice, they have a pretty common set of features and so, but yeah, most of the protocol can actually be the same. So, how did I get involved in the project? I saw a blog post about it and I had a mouse and then I started poking at it and suddenly I bought a lot of mice. Basically just checking if there's any cheap used one for sale and then yeah, that's how support comes. If we're building a mouse or similar input device, how do we make your life easier? Okay, so the question is if you were building it, how you would make it easier? Yeah. Supply documentation of the protocol. Basically all we need, or end the device, to test on it. Is the time for more questions? One minute. One minute, okay. Yeah, yeah, sure, sure. And the question was if we could have help from people who just wanted to draw the images and certainly yes because that actually takes quite some time to get right. Okay, that's all the time it is. Thanks.