This is so cool!!! I'm a web-dev of almost ~10+ years and I recently started a small hardware company and I've had to learn all about low-level USB, hardware development, firmware coding, and communicating over WebUSB. I feel less alone as I watch your video :)
@@LowByteProductions are their known ways to sniff the messages between the OS and the hardware (CPU and GPU)?? Kinda like Canbus sniffing where we watch the conversation to basically reverse engineer some drivers and make an the same OS work with custom hardware
@@FirstLast-tx3yj The short answer is yes, but the long answer is that it's complicated. Disclaimer that I don't work on this stuff directly, so I could be off base with some of it, but this is my understanding: The traditional view of a modern computer is that the CPU is not connected to peripheral hardware directly, but rather to the chipset. The chipset consists of a northbridge, which has a bus to the CPU and manages signals to the GPU and fast buses like PCI-E. However in the last decade or so integration has gotten tighter, and the CPU itself has absorbed a lot of that interconnect, and typically has an internal PCI-E controller. So a modern GPU is connected to the CPU over an integrated PCI-E connection. To put it into perspective, I looked up some numbers for data transfer rates on the latest generation of PCI-E in the highest bandwidth configuration, and it was upwards of 32GB/s. That's an insanely high data rate, and capturing it raw like a CAN bus would be an enormous effort, likely out of reach for anyone without a multi-million dollar lab. Signals at that level are deep into the RF spectrum, and physics really comes into play - even just "tapping in" to a line would probably completely wreck the signal. That said, they way you see people reversing GPUs these days is by getting in at the OS level with custom drivers, or eBPF hooks - much like this video. You write some test case in the black box, watch the exchanges at the OS level, and try to understand what they mean. Then you write your own driver, and construct messages based on what you've observed and extrapolated, and build up an understanding. This is essentially what the folks at Asahi linux have been doing with the M1 GPU. Check out Alyssa's blog rosenzweig.io and the the asahi linux youtube channel. Tons of work being done in the open there.
@@LowByteProductions thank you this is one of the best explanations i got so far. So in the project you mentioned they are building their own drivers to run linux on the M1 and for the hardware to be functional with the OS?? Would you say the opposite, developing drivers to adapt a manufacturers OS to custom PC CPU and GPU, would be harder Or is it the same procedure and thought process?
@@FirstLast-tx3yj Regardless where the GPU is connected to (directly or via a chipset) the device is connected via PCIe lanes to the I/O controller of the CPU. As mentioned these are high bandwidth data transfer. Like for anything (PCIe, RAM & even the CPU itself) there exists specialized hardware for testing and probing the data which is send over. But because these are very fast and high bandwidth while also have strict signaling requirements you can't just probe them. So you need specialized and so very expensive hardware which is likely also hart to get. Like by using a logic analyzer that need at least sample twice as fast as the data signaling frequency is. _Better 4 times to avoid errors._
Dude seriously, THANK YOU! With you help i have been able to reverse engineer my NZXT RGB controller and write a simple pyUSB driver for it which runs on linux! Please keep it going, you are doing outstanding work!
This video should be made as course to teach how to do engineering work. Beside the topic, the way in which it is explained is perfect. No mystic cuts; it is done in realtime, going through the process to learn how the protocol works, how you gather the info, how you decode the info and figure out what to look for, and finally how to piece the info you gather earlier to actually use them. Many other videos give you one of the pieces of this puzzle, expecting you figure things out, but if you have no idea about the whole process (that is why you are here, right? If you knew how to do it you would not be watching a video); you want to see the whole logic behind the workflow and how you get there. In almost 30 years of career this is among the best explained video I have seen, very good job.
Great video! I am a senior undergraduate CS student just taking the OS course. And I have a project to write a device driver. This is really inspiring!
This video was amazingly informative. I’m looking to do almost the exact same thing with a different USB keyboard. Thank you so much for your time and effort !
Nice channel, you do weird things in JS as do I... like writing VMs... it's cool to see different people's approaches. Now I am working on my JSASM which is an instruction set simulator in JS that itself can be assembled to different platforms after it is debugged in native JS. It of course to run, has to use a mixture of internal memory handling (like a simulator/emulator) as well as actual JS constructs. I figured I'm tired of coding separate JS, Z80 and 6502 logic... why not make it work in all cases but... with the benefits of debugging in JS. And anything I code still runs in JS so i can re-use it for my other projects.
Awesome, thanks 😁 Watching that back I'm realising this is one of those times that my brain glitched out and confused bytes with bits. Of course 8 bytes is enough to send any number of keys haha
Don't know if you talked about this, but there is a mode that USB devices can be put in, some of them, some of them only come with this mode, like keyboards and mice, called HID mode, which is easier to write device drivers for, in userspace. They are called filter drivers I think. And the drivers hook into a standard kernel driver on both Windows and Linux, that allows other userspace filter drivers to exchange HID datagrams with the device, instead of custom bytes. Examples include POS devices like scanners and cash drawers. IBM and a bunch of other manufacturers worked to standardise for example the POS HID spec.
- As far as I remember you also need to detach and claim the interface for WebUSB. For HID it's better to use WebHID instead (but that isn't supported everywhere). - It's likely that there are multiple functions specified in the HID report descriptor for the mouse. That way multiple different HID functions can be put into a single interface. In the case these are separated as independent data packages and not grouped up in the same the first byte is the report ID to differentiate them. So the first byte with the 0x04 likely identify the report ID. - It's always worth to have a look in the HID descriptor where the HID functions structure is defined for a faster start. - Byte 2 and 3 seems indeed to be a simple checksum (sum of all elements).
42:10 you can use that information in real cool ways :) Like "overclocking" devices to have them respond faster if they can (e.g. a keyboard that's set to 8ms poll rate when in reality, it can handles 1ms.)
Ah that's really interesting! That's also one of the cool things you can do when you have absolute control on the host side right - you can "break" your contract with the device and see how it responds. Have you tested this out with a lot of different keyboards?
Trying to figure out how to write up a USB descriptor for some custom hardware. While this video wasnt quite what I was after I did learn a fair bit... Also That second byte after 0x04 is deffo a checksum, I guess 04 is start frame followed by checksum maybe 2 byte checksum as byte 3 is 0 in these tests.... the next three bytes are likely commands or sub commands, followed by value. Its interesting there is a checksum in the byte stream as I thought USBhid handled that error correction anyway? Ahhh at 2:10:48 you see it :D
Great video! I have two projects planned and this has helped a lot. While i dont use JS or TS the way you described stuff was still very helpful when i was trying to use hidapi in python
Hey Mario, I managed to figure out what the problem was in the end - apparently when I was clicking through the packets on the first LED mode setting, I skipped over the actual "command" packet and moved to one after - so the data that I copied out and put into the driver was wrong 🤦♂️ In reality, the LED mode setting actually follows the same basic pattern as the brightness - byte 2 is `0x08 + mode`
@@LowByteProductions I'm late to this, so sorry if you mentioned it, but the 0x08 appears to be a checksum - it sums the following 0x06, 0x01, 0x01 bytes as well as the "argument" (and the checksum appears to be a 16 byte int).
device generally generate a hardware interrupt to IO controller... which then notify CPU though it iNIT pin ..on being notify of that CPU will get the interrupt No from IO Controller on data bus. Then will call the appropriate interrupt routine that is mapped for that hardware interrupt. Hardware Interrupt just says that device wants something to say. Now in that interrupt service routine which is generally installed by the OS... the OS will call the appropriate driver routine to handle the device request. That driver routine (or even interrupt routine itself) will then poke the driver about the cause through its registers and will do the whatever needed. I mean read data or whatever. Now all this can be done when the hardware interrupt actually happened or maybe differed to appropriate time if its a lengthy job cause when u enter a interrupt routine other external interrupts are generally disabled depends on how CPU entered the interrupt service routine in protected mode to check nested exception conditions or race problem. And in modern multicore CPUs there are local APIC per processor on die itself which are connected to an IO APIC on motherboard. And I guess APIC can handle 256 interrupts in compare to PIC just 15 though master slave arrangment... and in protected mode those interrupts cant be mapped below 32 cause they are reserved as CPU exception interrupts in protected mode. In real mode they are kinda fixed for legacy reason from 08h to 0Fh for master and 70h to 7Fh for slave.
This was a great watch, tbh I got a little scared when you started firing knowingly broken packets and dangling transaction starts at the keyboard, though maybe I'm underestimating how brick-resistant they are :D
Hi amazing video, can you tell how can use Laptop keyboard and mouse input as hid input to another device very efficiently via connecting both devices using usb or ethernet. I know barriers like software exits but some devices Don't support barriers
@@GyrusAssimi-wb3jw I did not publish it, because you have to change the driver in windows, and use the samsung driver in order to connect to Android Accessory, after that u just stream the images through the usb, and u have to create a program to handle this images and display it
@@obeid_s all right i get, but please Can we get in contact i mean where Can we discuss more i wish to learn from people like you in order to know more about many tpoics for me to succeed in cybersec i want to start, and i like this part of kernel dev contents and lower level dev project that why i got this video
One suggestion to deal with wiresharks inability to use capture filters for usbmon: You have different usbmon devices, which correspond to the different USB busses. usbmon0 captures everything, which is what you used in the video. If you make sure the keyboard is plugged into a different bus than the other devices and capture on the corresponding usbmon device, you get rid of all the spurious packets.
Yeah that's indeed a great point. Unfortunately my computer only exposes 2 buses (though it seems to have 2 more internally). With all the high-bandwidth devices on one bus the capture becomes impossible. My solution (which I'll show in the next stream) has been to use eBPF to capture transactions at the kernel level and filter out the ones I'm not interested in. That's turned out to be a really great approach and I'm surprised that I haven't seen more about it!
I thoroughly enjoyed the video. Is there a possibility to replicate it for the Windows Wifi Driver, similar to how Microtek 7902 supports Windows but not Linux? Can a Linux driver be developed for Microtek 7902 or any other wifi driver by following this method or is there any other method?
Great video. Do you think the same approach could be used to get the current battery level/percentage in Logitech G HUB for the Logitech G PRO Wireless mouse? I'm in the process of attempting to do so and will provide an update if I'm successful.
Is it something that the mouse offers in Windows (or another environment)? If so then I'd say it's definitely possible, you just need to be able to capture the request and figure out how it encodes the response
Thanks! Just gave it enough ram, and only ran a single program at a time. I even managed to solve the crashing issues in next video by changing the USB capturing method
@@LowByteProductions thanks for the prompt reply, I am trying to reverse engineer a touchscreen device, do you have a business or would you be able to do the job for us if yes can we share contacts? thanks
Yes you can do the same, provided its for the control parts and not the audio. Audio requires really tight transmission of data that isn't supported in node (though you can write that part in C/C++ using libusb).
30:31 Okay that seems interesting.... Now I got it... so u don't have a datasheet or specification for your keyboard. So how u gonna figure out what command your keyboard understands I wonder? ...Yep windows driver might have helped but then u wud really have to reverse engineer something to learn about those code or working. Anyway lets see how u go for it... got all the time today.😃
Anyway interrupt type doesn't mean anything to do with poling I guess rather it's the opposite of poling. In USB terms here I mean what I skimed though a lil bit of its specification jus today is out of 4 type interrupt type is where latency is fixed at a certain value. And host (OS or CPU) won't be poling keyboard for data that wud be too much burden for such mundane device. And that's why interrupt type is used for keyboards likes I guess. keyboard controller inside your keyboard will generate a interrupt for IOAPIC or PCH whatever there is. which certainly will go through USB interface since yours a usb keyboard. So once it reached the IO controller it will be forwarded to CPU then your OS through some interrupt routine. There a lot inbetween but lets keep it simple as this. And as u press a key ..key should be notify to OS or user so why its an interrupt generated (hardware). Only host side intiation I can imagine is when it send your keyboard some control commands to change its behaviour like different led styles etc. So basically all input devices are interrupt driven at least that endpoint or pipe which is outgoing from input device to host since they need immediate attention or response.
@@LowByteProductions yeah . The fact that you said you were by no means an expert and your demonstration of it's veracity. So does your reply mean you know of no expert source ?
Maybe this is a cultural thing but I am generally wary of calling myself an expert on anything. IMO it's fine to know that there is a lot of you don't know about something while still being able to talk about and share the things you do know. For example - I know that I know enough about this kind of reverse engineering to share it because, well, I've done it. In the next stream I'm going to be able to share even more, since I've learned some new interesting things since then. I get the feeling that your comments are intended in a hostile sense, but I'm honestly confused as to why. Aside from that comment, was there something else in the video that you took issue with?
@@LowByteProductions the question was blunt . I actually would like a deeper technical explanation . Also you referred to some blogger or something who , to the best of my listening power comes out as "White Quarks " but nothing like that in any search . Who are you referring to there ? Also I haven't quite finished your video but will. It is interesting , I just need to know if there is a supplementary source . Your competition , so to speak ?
In that case no worries. I honestly wouldn't consider myself competition to anyone in this domain! You heard almost correctly - the person in question here is whitequark (on twitter/github etc). If you're really looking to get into it, you can check out Jan Axelson's book "USB Complete". An even longer video, but by a much smarter guy is Marcan's video on getting a MIDI input to work on linux: ruclips.net/video/cUVuTBH51GY/видео.html Obviously there is the spec itself, which is definitely approachable, but kind of annoying for learning purposes because you need to have multiple PDFs open at once, and you're constantly jumping around in them. I would also look at some of the presentations online by Kate Temkin. Shes done a ton of work on the physical side of USB introspection and reverse engineering. Up until quite recently she was writing and maintaining a lot of the USB tooling, as well as working on hardware like Luna and the GreatFET that can allow you to do things like device AND host spoofing (for when the thing you plug your device into isn't actually a computer you control). For the rest you can get a lot of just spending time poking devices and seeing what they spit out, getting familiar with things like lsusb so that you can get to grips with what a device is reporting that it can do, and even reading open source firmware for devices that have usb functionality. There are a lot of them out there, and a lot of chips these days have support (tons of the STM32s for example).
Or I am still not getting what u intend to do... smile But thats I wud have done in case of missing specification for the device and not having some utility to let me do so.
WebUSB is for the browser, so I'm not sure how you would expect it to work when not running through the browser. Admittedly I would never use node for a project like this, so I can't comment on how it interfaces with those bits.
WebUSB is a standard, which while intended for browsers , doesn't actually include anything that would stop it being implemented in other environments.
The reason us filthy gamers want a high polling rate is because of _latency_ not throughput. Nobody's pressing 1000 keys per second. No game engine is running the main loop 1000 times per second. When I press a key, I want it to be available to the game engine ideally instantly, so it's guaranteed to be registered for the very next game loop. With polling, you can't guarantee that. There's always going to be a point where the polling happens too late. That's why we still use PS/2. Interrupts are just better.
And me jus writing all this for what I am trying to understand since me no professional computer guy u see jus a normal ameteur or curious guy. Dont worry I will just delete all these comments in the end. I was guessing whose knows u might be online so wud correct my errors why I am writing these. Cause for my purpose I wanna give a lil real try. If I couldn't handle it I will leave that... this computer thing dont buy me my butter and bread... smile But I have free time so lets give it a try... maybe.. I wud get something done for my problem. Or say hobby thing.... aur mera toh english ka bhi problem hai bhai ...why I have to edit those comments u c. 😂
![[stream] More USB Reverse Engineering + Drivers](http://i.ytimg.com/vi/7Zo3bdaqfbo/mqdefault.jpg)
![[stream] More USB Reverse Engineering + Drivers](/img/tr.png)
This is so cool!!! I'm a web-dev of almost ~10+ years and I recently started a small hardware company and I've had to learn all about low-level USB, hardware development, firmware coding, and communicating over WebUSB. I feel less alone as I watch your video :)
That sounds awesome Daniel -what are you working on there?
It sounds like you would fit in well on the discord server by the way
@@LowByteProductions are their known ways to sniff the messages between the OS and the hardware (CPU and GPU)??
Kinda like Canbus sniffing where we watch the conversation to basically reverse engineer some drivers and make an the same OS work with custom hardware
@@FirstLast-tx3yj The short answer is yes, but the long answer is that it's complicated. Disclaimer that I don't work on this stuff directly, so I could be off base with some of it, but this is my understanding: The traditional view of a modern computer is that the CPU is not connected to peripheral hardware directly, but rather to the chipset. The chipset consists of a northbridge, which has a bus to the CPU and manages signals to the GPU and fast buses like PCI-E. However in the last decade or so integration has gotten tighter, and the CPU itself has absorbed a lot of that interconnect, and typically has an internal PCI-E controller. So a modern GPU is connected to the CPU over an integrated PCI-E connection. To put it into perspective, I looked up some numbers for data transfer rates on the latest generation of PCI-E in the highest bandwidth configuration, and it was upwards of 32GB/s. That's an insanely high data rate, and capturing it raw like a CAN bus would be an enormous effort, likely out of reach for anyone without a multi-million dollar lab. Signals at that level are deep into the RF spectrum, and physics really comes into play - even just "tapping in" to a line would probably completely wreck the signal.
That said, they way you see people reversing GPUs these days is by getting in at the OS level with custom drivers, or eBPF hooks - much like this video. You write some test case in the black box, watch the exchanges at the OS level, and try to understand what they mean. Then you write your own driver, and construct messages based on what you've observed and extrapolated, and build up an understanding. This is essentially what the folks at Asahi linux have been doing with the M1 GPU. Check out Alyssa's blog rosenzweig.io and the the asahi linux youtube channel. Tons of work being done in the open there.
@@LowByteProductions thank you this is one of the best explanations i got so far.
So in the project you mentioned they are building their own drivers to run linux on the M1 and for the hardware to be functional with the OS??
Would you say the opposite, developing drivers to adapt a manufacturers OS to custom PC CPU and GPU, would be harder
Or is it the same procedure and thought process?
@@FirstLast-tx3yj Regardless where the GPU is connected to (directly or via a chipset) the device is connected via PCIe lanes to the I/O controller of the CPU. As mentioned these are high bandwidth data transfer. Like for anything (PCIe, RAM & even the CPU itself) there exists specialized hardware for testing and probing the data which is send over. But because these are very fast and high bandwidth while also have strict signaling requirements you can't just probe them. So you need specialized and so very expensive hardware which is likely also hart to get. Like by using a logic analyzer that need at least sample twice as fast as the data signaling frequency is. _Better 4 times to avoid errors._
Dude seriously, THANK YOU! With you help i have been able to reverse engineer my NZXT RGB controller and write a simple pyUSB driver for it which runs on linux! Please keep it going, you are doing outstanding work!
Glad I could be of help 😁
This video should be made as course to teach how to do engineering work. Beside the topic, the way in which it is explained is perfect.
No mystic cuts; it is done in realtime, going through the process to learn how the protocol works, how you gather the info, how you decode the info and figure out what to look for, and finally how to piece the info you gather earlier to actually use them.
Many other videos give you one of the pieces of this puzzle, expecting you figure things out, but if you have no idea about the whole process (that is why you are here, right? If you knew how to do it you would not be watching a video); you want to see the whole logic behind the workflow and how you get there.
In almost 30 years of career this is among the best explained video I have seen, very good job.
Thank you, I really appreciate that 🙏
The variable length URB structure describes the details of the request and also contains information about the status of the completed request.
MY GOD. I can finally get rid of this terrible keyboard bloatware!!!! I LOVE YOU!
An replace it with a bloated javascript runtime + web browser?
Great video! I am a senior undergraduate CS student just taking the OS course. And I have a project to write a device driver. This is really inspiring!
I guess a linux one or are you guys allowed todo userspace drivers too?
Anyone won't regret after subscribe this channel. Amazing content.
Salute your hardwork.
I wonder if it is easier to decompile the Keyboard control utility and see what it can send to the keyboard then using USB Analyzer.
Daaaammmm! You made something that communicates with a device driver using Javascript? Guy... You are amazing!
You mean he used the bad web interface to actually do something even though extremely inefficient but he did.😊
This video was amazingly informative. I’m looking to do almost the exact same thing with a different USB keyboard. Thank you so much for your time and effort !
Nice channel, you do weird things in JS as do I... like writing VMs... it's cool to see different people's approaches. Now I am working on my JSASM which is an instruction set simulator in JS that itself can be assembled to different platforms after it is debugged in native JS. It of course to run, has to use a mixture of internal memory handling (like a simulator/emulator) as well as actual JS constructs. I figured I'm tired of coding separate JS, Z80 and 6502 logic... why not make it work in all cases but... with the benefits of debugging in JS. And anything I code still runs in JS so i can re-use it for my other projects.
42:50 spot on! I think you're 100% right on your assessment :)
Awesome, thanks 😁 Watching that back I'm realising this is one of those times that my brain glitched out and confused bytes with bits. Of course 8 bytes is enough to send any number of keys haha
Don't know if you talked about this, but there is a mode that USB devices can be put in, some of them, some of them only come with this mode, like keyboards and mice, called HID mode, which is easier to write device drivers for, in userspace. They are called filter drivers I think. And the drivers hook into a standard kernel driver on both Windows and Linux, that allows other userspace filter drivers to exchange HID datagrams with the device, instead of custom bytes. Examples include POS devices like scanners and cash drawers. IBM and a bunch of other manufacturers worked to standardise for example the POS HID spec.
فديو أكثر من رائع كنتمنى يحقق أعلى نسبة مشاهدة لأنك فعلا تستحق التشجيع
اشكرك صديقي
extremely cool. I gotta study this. next weekend
34:00 b is a byte or 8bits or 0xff
Thanks for the video, With this (and the github repo) I've started writing a driver for Cooler Master ControlPad.
Thanks for sharing! had so much fun watching it.
- As far as I remember you also need to detach and claim the interface for WebUSB. For HID it's better to use WebHID instead (but that isn't supported everywhere).
- It's likely that there are multiple functions specified in the HID report descriptor for the mouse. That way multiple different HID functions can be put into a single interface. In the case these are separated as independent data packages and not grouped up in the same the first byte is the report ID to differentiate them. So the first byte with the 0x04 likely identify the report ID.
- It's always worth to have a look in the HID descriptor where the HID functions structure is defined for a faster start.
- Byte 2 and 3 seems indeed to be a simple checksum (sum of all elements).
42:10 you can use that information in real cool ways :) Like "overclocking" devices to have them respond faster if they can (e.g. a keyboard that's set to 8ms poll rate when in reality, it can handles 1ms.)
Ah that's really interesting! That's also one of the cool things you can do when you have absolute control on the host side right - you can "break" your contract with the device and see how it responds. Have you tested this out with a lot of different keyboards?
@@LowByteProductions Not yet but I'm planning on experimenting with it sometime soon :)
Trying to figure out how to write up a USB descriptor for some custom hardware. While this video wasnt quite what I was after I did learn a fair bit...
Also That second byte after 0x04 is deffo a checksum, I guess 04 is start frame followed by checksum maybe 2 byte checksum as byte 3 is 0 in these tests.... the next three bytes are likely commands or sub commands, followed by value.
Its interesting there is a checksum in the byte stream as I thought USBhid handled that error correction anyway?
Ahhh at 2:10:48 you see it :D
Great video! I have two projects planned and this has helped a lot. While i dont use JS or TS the way you described stuff was still very helpful when i was trying to use hidapi in python
Glad it can help! It was the goal to keep this video on the USB level, and not the language level
I think the reason it only switched to one LED mode is because the "checksum" byte, 0x0c, was static and did not change with the mode argument.
Hey Mario, I managed to figure out what the problem was in the end - apparently when I was clicking through the packets on the first LED mode setting, I skipped over the actual "command" packet and moved to one after - so the data that I copied out and put into the driver was wrong 🤦♂️
In reality, the LED mode setting actually follows the same basic pattern as the brightness - byte 2 is `0x08 + mode`
@@LowByteProductions I'm late to this, so sorry if you mentioned it, but the 0x08 appears to be a checksum - it sums the following 0x06, 0x01, 0x01 bytes as well as the "argument" (and the checksum appears to be a 16 byte int).
Great content, thank you for sharing
Thanks Piotr!
This is really interesting topic!
Which font and color scheme are you using in VS Code here?
device generally generate a hardware interrupt to IO controller... which then notify CPU though it iNIT pin ..on being notify of that CPU will get the interrupt No from IO Controller on data bus. Then will call the appropriate interrupt routine that is mapped for that hardware interrupt. Hardware Interrupt just says that device wants something to say. Now in that interrupt service routine which is generally installed by the OS... the OS will call the appropriate driver routine to handle the device request. That driver routine (or even interrupt routine itself) will then poke the driver about the cause through its registers and will do the whatever needed. I mean read data or whatever. Now all this can be done when the hardware interrupt actually happened or maybe differed to appropriate time if its a lengthy job cause when u enter a interrupt routine other external interrupts are generally disabled depends on how CPU entered the interrupt service routine in protected mode to check nested exception conditions or race problem.
And in modern multicore CPUs there are local APIC per processor on die itself which are connected to an IO APIC on motherboard. And I guess APIC can handle 256 interrupts in compare to PIC just 15 though master slave arrangment... and in protected mode those interrupts cant be mapped below 32 cause they are reserved as CPU exception interrupts in protected mode. In real mode they are kinda fixed for legacy reason from 08h to 0Fh for master and 70h to 7Fh for slave.
This was a great watch, tbh I got a little scared when you started firing knowingly broken packets and dangling transaction starts at the keyboard, though maybe I'm underestimating how brick-resistant they are :D
What are the odds that something like that would write to non-volatile memory?
I really love your channel. Keep up the good work.
I wish I came earlier, I just want to say something while you're thinking about bitfields, especially at 2:19:57
Thank you for sharing :) Very cool
Hi amazing video, can you tell how can use Laptop keyboard and mouse input as hid input to another device very efficiently via connecting both devices using usb or ethernet. I know barriers like software exits but some devices Don't support barriers
I created an app to share android phones camera through the usb ( host ) using libusb 😂, Thanks for the video, its time to learn more about usb 👍🏻
Bro amazing, please Can you tell me more like how does it work and what the name of the app
@@GyrusAssimi-wb3jw I did not publish it, because you have to change the driver in windows, and use the samsung driver in order to connect to Android Accessory, after that u just stream the images through the usb, and u have to create a program to handle this images and display it
@@obeid_s all right i get, but please Can we get in contact i mean where Can we discuss more i wish to learn from people like you in order to know more about many tpoics for me to succeed in cybersec i want to start, and i like this part of kernel dev contents and lower level dev project that why i got this video
@@obeid_s if possible could you help me with esp32 CAM programming ? and to understand more on C system drivers developement ?
@@GyrusAssimi-wb3jw I wish i can help you mate, I learned these stuff from internet and i did not go to university.., I really wish i can help you
One suggestion to deal with wiresharks inability to use capture filters for usbmon: You have different usbmon devices, which correspond to the different USB busses. usbmon0 captures everything, which is what you used in the video.
If you make sure the keyboard is plugged into a different bus than the other devices and capture on the corresponding usbmon device, you get rid of all the spurious packets.
Yeah that's indeed a great point. Unfortunately my computer only exposes 2 buses (though it seems to have 2 more internally). With all the high-bandwidth devices on one bus the capture becomes impossible.
My solution (which I'll show in the next stream) has been to use eBPF to capture transactions at the kernel level and filter out the ones I'm not interested in. That's turned out to be a really great approach and I'm surprised that I haven't seen more about it!
URB is USB Request Block
Awesome video, really interesting stuff thank you! :)
Could you share your zshrc as to how you print the dividers and other info between the commands?
It's just the "jonathon" theme
I thoroughly enjoyed the video. Is there a possibility to replicate it for the Windows Wifi Driver, similar to how Microtek 7902 supports Windows but not Linux? Can a Linux driver be developed for Microtek 7902 or any other wifi driver by following this method or is there any other method?
If it’s a usb device probably.
But that will not use type script anymore as that would be way to slow and probably break on timings.
Thank you for sharing.
Can you please link White Quark's USB twitch stream link?
Great video. Do you think the same approach could be used to get the current battery level/percentage in Logitech G HUB for the Logitech G PRO Wireless mouse? I'm in the process of attempting to do so and will provide an update if I'm successful.
Is it something that the mouse offers in Windows (or another environment)? If so then I'd say it's definitely possible, you just need to be able to capture the request and figure out how it encodes the response
Awesome video!
How did you manage to run Windows 10 on Virtualbox without having huge lagging? :)
Thanks! Just gave it enough ram, and only ran a single program at a time. I even managed to solve the crashing issues in next video by changing the USB capturing method
Is it viable to use this aproach on a USB printer?
So u trying to write a lower filter driver for USB device in windows.... is that it? To caputre control code?
but does that let u capture control commands... I dont see it
does this support bulk transfer or is it only for control and interrupt and isochronous transfers only?
Node-usb in general? It supports bulk. What it doesn't support is isochronous
@@LowByteProductions thanks for the prompt reply, I am trying to reverse engineer a touchscreen device, do you have a business or would you be able to do the job for us if yes can we share contacts? thanks
Hey Ahmed, no worries. I'm not really open to that kind of freelance work right now I'm afraid.
Wow what terminal emulator and/or colour theme and desktop environment are you using? That is beautiful!
Anyone else who knows?
Hey Laurits,
It's terminator, with zsh as the shell, and the "jonathon" theme.
@@LowByteProductions Thanks so much! You just earned a follower!
Is there not a way to do this from within Linux using WINE?
If GMMK Pro is fully compatible with QMK Firmware, why you don't get QMK framework and study and make your own firmware for it.
Can you do the same for a headphone or headset? or can someone point me to the right resources to do something like this for a headphone or headset
Yes you can do the same, provided its for the control parts and not the audio. Audio requires really tight transmission of data that isn't supported in node (though you can write that part in C/C++ using libusb).
30:31 Okay that seems interesting.... Now I got it... so u don't have a datasheet or specification for your keyboard. So how u gonna figure out what command your keyboard understands I wonder? ...Yep windows driver might have helped but then u wud really have to reverse engineer something to learn about those code or working. Anyway lets see how u go for it... got all the time today.😃
Hey bro I have a big request from you..can you try to reverse Engineer pantum printer firmware to make it chipless firmware version ? Is it possible ?
1:43:26 where i left off at
Anyway interrupt type doesn't mean anything to do with poling I guess rather it's the opposite of poling. In USB terms here I mean what I skimed though a lil bit of its specification jus today is out of 4 type interrupt type is where latency is fixed at a certain value. And host (OS or CPU) won't be poling keyboard for data that wud be too much burden for such mundane device. And that's why interrupt type is used for keyboards likes I guess. keyboard controller inside your keyboard will generate a interrupt for IOAPIC or PCH whatever there is. which certainly will go through USB interface since yours a usb keyboard. So once it reached the IO controller it will be forwarded to CPU then your OS through some interrupt routine. There a lot inbetween but lets keep it simple as this. And as u press a key ..key should be notify to OS or user so why its an interrupt generated (hardware). Only host side intiation I can imagine is when it send your keyboard some control commands to change its behaviour like different led styles etc. So basically all input devices are interrupt driven at least that endpoint or pipe which is outgoing from input device to host since they need immediate attention or response.
so can you direct us to somebody that does know what they are doing ?
Is this in response to something in particular?
@@LowByteProductions yeah . The fact that you said you were by no means an expert and your demonstration of it's veracity. So does your reply mean you know of no expert source ?
Maybe this is a cultural thing but I am generally wary of calling myself an expert on anything. IMO it's fine to know that there is a lot of you don't know about something while still being able to talk about and share the things you do know. For example - I know that I know enough about this kind of reverse engineering to share it because, well, I've done it. In the next stream I'm going to be able to share even more, since I've learned some new interesting things since then.
I get the feeling that your comments are intended in a hostile sense, but I'm honestly confused as to why. Aside from that comment, was there something else in the video that you took issue with?
@@LowByteProductions the question was blunt . I actually would like a deeper technical explanation . Also you referred to some blogger or something who , to the best of my listening power comes out as "White Quarks " but nothing like that in any search . Who are you referring to there ? Also I haven't quite finished your video but will. It is interesting , I just need to know if there is a supplementary source . Your competition , so to speak ?
In that case no worries. I honestly wouldn't consider myself competition to anyone in this domain!
You heard almost correctly - the person in question here is whitequark (on twitter/github etc).
If you're really looking to get into it, you can check out Jan Axelson's book "USB Complete".
An even longer video, but by a much smarter guy is Marcan's video on getting a MIDI input to work on linux: ruclips.net/video/cUVuTBH51GY/видео.html
Obviously there is the spec itself, which is definitely approachable, but kind of annoying for learning purposes because you need to have multiple PDFs open at once, and you're constantly jumping around in them.
I would also look at some of the presentations online by Kate Temkin. Shes done a ton of work on the physical side of USB introspection and reverse engineering. Up until quite recently she was writing and maintaining a lot of the USB tooling, as well as working on hardware like Luna and the GreatFET that can allow you to do things like device AND host spoofing (for when the thing you plug your device into isn't actually a computer you control).
For the rest you can get a lot of just spending time poking devices and seeing what they spit out, getting familiar with things like lsusb so that you can get to grips with what a device is reporting that it can do, and even reading open source firmware for devices that have usb functionality. There are a lot of them out there, and a lot of chips these days have support (tons of the STM32s for example).
Or I am still not getting what u intend to do... smile
But thats I wud have done in case of missing specification for the device and not having some utility to let me do so.
WebUSB is for the browser, so I'm not sure how you would expect it to work when not running through the browser. Admittedly I would never use node for a project like this, so I can't comment on how it interfaces with those bits.
WebUSB is a standard, which while intended for browsers , doesn't actually include anything that would stop it being implemented in other environments.
I agree
I don’t see a reason why you would make yourself miserable and code such drivers with web api’s.
The reason us filthy gamers want a high polling rate is because of _latency_ not throughput. Nobody's pressing 1000 keys per second. No game engine is running the main loop 1000 times per second. When I press a key, I want it to be available to the game engine ideally instantly, so it's guaranteed to be registered for the very next game loop. With polling, you can't guarantee that. There's always going to be a point where the polling happens too late.
That's why we still use PS/2. Interrupts are just better.
Okay! so using USB monitor in Windows to capture those control codes? ...Smart move! 😂
Do this With Golang! So easy
Do it urself if its so easy
@@angryman9333 I did!
How? GoUsb?
? ???????
??????? ?
And me jus writing all this for what I am trying to understand since me no professional computer guy u see jus a normal ameteur or curious guy. Dont worry I will just delete all these comments in the end. I was guessing whose knows u might be online so wud correct my errors why I am writing these. Cause for my purpose I wanna give a lil real try. If I couldn't handle it I will leave that... this computer thing dont buy me my butter and bread... smile
But I have free time so lets give it a try... maybe.. I wud get something done for my problem. Or say hobby thing.... aur mera toh english ka bhi problem hai bhai ...why I have to edit those comments u c. 😂
node js is horrible
You should read the standard to prepare some explanation before doing any video...
Thank you for sharing.