search

RoganDawes / LOGITacker

Enumerate and test Logitech wireless input devices for vulnerabilities with a nRF52840 radio dongle.
GNU General Public License v3.0
663 stars 118 forks source link

feature request: add mouse injection support #52

Open PlasmaHH opened 4 years ago

PlasmaHH commented 4 years ago

It would be nice to have support for mouse injections (in my case only movement is necessary, but it would probably be nice for completeness to be able to click arbitrary buttons too).

RoganDawes commented 4 years ago

It’s a nice idea, but it would have to be a proprietary extension to DuckyScript, as there is no defined syntax for mouse movements in DuckyScript as yet.

PlasmaHH commented 4 years ago

I see, however DuckyScript isn't an ISO standard and maybe they will adapt to whatever you invent? ;) I have my doubts that many people will try to interchange these scripts much... For button presses I imagine its sufficient to have special keywords for them so you can do press BUTTON1 or so. Maybe in the same way (a bit ugly I think) one could implement a press X+10 Y-20 or so, that would at least not occupy any potential keywords that DuckyScript might later introduce. (PS: I wish logitracker would support dell keyboards/mice too)

RoganDawes commented 4 years ago

Sure, I could imagine supporting a MOUSEMOVE x y, MOUSECLICK BUTTON1, and MOUSEPRESS/MOUSERELEASE BUTTON1 commands. Given that the mouse is a relative motion device, you'd probably want to do something like MOUSEMOVE -10000 -10000 at the start to get to a known origin point, and then use appropriate values from there. One problem to deal with is mapping between mouse reports and actual pixels on the screen. And things like pointer acceleration. We may also need a MOUSESPEED x setting, to prevent triggering acceleration thresholds.

w.r.t supporting Dell mice/keyboards, what do you actually mean by that? Ability to change the VID:PID that LOGITacker reports?

PlasmaHH commented 4 years ago

Haven't thought about the whole acceleration thing, but that probably makes sense. My main thought was to use mouse wiggling by 1 pixel to prevent the automated screenlock to kick in. Actually moving the mouse to a specific point is going to be hard, probably one could move way too far to 0;0 and then start from then on...

With the Dell remark I mean the series of Dell "universal dongles" with that blue logo. They use ESB too but from a quick look its quite different data. There is this mousejack project from years ago that uses nrf24 based logitech dongles and some python code to capture and send data compatible with those.

Especially when there are lots around (open floor office) then logitracker sees a lot of those packets but doesn't seem to be able to understand any of it (comparing with a capture from an nrf24 dongle its seems to see only a fraction). It seems that there are still a lot around with older firmware that possibly accept unencrypted keystrokes on the mouse device, on my todo list is to test exactly that, hence it would have been nice if this could talk dell too, as it seems similar enough.

RoganDawes commented 4 years ago

If it is just the lock screen you are trying to avoid, implementing a Jiggler is not too complicated. This was done in USaBUSe 3+ years ago, for instance. It would not be difficult to add this to LOGITacker, I'm sure. Implementing support for the other ESB protocols supported by MouseJack is probably also not too complicated. At least as far as injecting keystrokes goes! Achieving the covert channel with other receivers would be a different story, I'm sure! I'd welcome a PR :-)

PlasmaHH commented 4 years ago

Yeah, the covert channel is quite an advanced nice feature, and even though use case for this thing is mostly kind of red-teaming so far I think there has never been the need for this. Don't count on a PR, I guess you know how much time everyone has these days ;) I have another feature request incoming though, they are quick to do ;)