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._

Glad I could be of help 😁

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

I guess a linux one or are you guys allowed todo userspace drivers too?

Thank you, I really appreciate that 🙏

An replace it with a bloated javascript runtime + web browser?

اشكرك صديقي

Glad it can help! It was the goal to keep this video on the USB level, and not the language level

You mean he used the bad web interface to actually do something even though extremely inefficient but he did.😊

Thanks Piotr!

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 :)

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!

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).

What are the odds that something like that would write to non-volatile memory?

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

It's just the "jonathon" theme

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

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

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.

What you want to do is certainly more complex. I still wouldn't call thus cheating though. This process is what people typically mean when they talk about reverse engineering. You need to be able to poke the system and observe it in order to make reasonable guesses about how it works. Now in your case, the process is a lot harder. It requires way more patience, and diligent notetaking. First you need to get a lay of the land. Using lsusb you can figure out what kind of class this device is, what endpoints it contains, and what kind and how much data you can push or pull from those endpoints. If you're lucky the device is a generic class, and you can use a generic driver as your starting point. In the worst case, the device is vendor specific, and all you can do is to spray bytes at it and hope it responds in some consistent way. Imagine a device that, for whatever reason, requires that you send it some random looking 16 byte packet before it will do anything. That is equivalent to breaking an AES key - not likely to say the least. Thankfully most devices simply aren't built that way, but you see the point I'm trying to make. On both ends of the spectrum, the scientific method is your friend. Form a hypothesis, make a prediction, test it, and write down what you observe. When you start to build assumptions, try to design experiments that break your assumptions; That can feel like a step back, but it's knowledge nonetheless. If you end up going down this road, and are making your notes public, I'd love to take a look. Drop by the discord server if you want to chat more about it.

@@LowByteProductions Sure I would love to tell you more about this once I'll get started, it's a project that might be as complex as you described. It will involved medical devices, let's hope the drivers will be available :)

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).

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.

Hey Laurits, It's terminator, with zsh as the shell, and the "jonathon" theme.

@@LowByteProductions Thanks so much! You just earned a follower!

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: kzfaq.info/get/bejne/mbuGqLdzrZuVd40.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).

Do it urself if its so easy

@@angryman9333 I did!

How? GoUsb?

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.

??????? ?