1
\$\begingroup\$

I was challenged in university to Hack a mouse in the following manner:

system What is happening: computer1 has an optical mouse connected to it, and this optical mouse has been hacked in one way or another so computer2 can send commands to the Arduino which in turn sends commands to the optical mouse that control the cursors movements in computer 1.

Basically all the drivers and all that stuff that the optical mouse of computer1 had is not being changed. I have to hack into the mouse at some point to change the information that is being given. It could be at the sensors (sending predesigned images to them to provoke specific movements) or it could be somewhere after the information from the sensor has already been analysed. Basically computer1 has no idea the Arduino is interfering in any process, very under the radar.

I am not sure however how I would go about doing this... hacking the sensor would require me to design images that would be sent to the mouse.... not sure how the hacking there would work. If I were to hack the end result of the images being analysed, I would have to find out at what point is the mouse sending this information (and over which peace of circuitry) and find a way of intercepting and replacing this information.

Which of the 2 options do you guys believe is more realistic and why?

\$\endgroup\$
6
  • 3
    \$\begingroup\$ If you can find an old-style ball mouse, you only need to drive 2 signals per axis, and the signals are easy to find, they are the phototransistor outputs from the optical encoders. (Plus the buttons, of course) \$\endgroup\$ Commented Nov 27, 2014 at 18:12
  • \$\begingroup\$ I actually looked into mechanical mouses a bit (ball/sphere mouse). Do these optical encoders just send a voltage output when the gear of a specific axis leaves an opening? and I'm not quite sure how the optical encoder knows if the gears that rotate in a ball mouse are rotating in which direction... \$\endgroup\$ Commented Nov 27, 2014 at 18:21
  • 2
    \$\begingroup\$ @rsthegreat12: google "quadrature encoder". Modern mice talk USB, which is a well-described protocol, but not easy. google "usb hid interface". The old PS2 interface was easier, and usb-ps2 converters are cheap, maybe that route is easier. \$\endgroup\$ Commented Nov 27, 2014 at 18:35
  • \$\begingroup\$ @Wouter van Ooijen: Just googled it. I think I'll buy some old-style mouses online tomorrow and start reviewing some theory behind the encoders while waiting. Ty for that. And Brain Drummond, thanks dude, that was a very good suggestion \$\endgroup\$ Commented Nov 27, 2014 at 18:43
  • \$\begingroup\$ Can you clarify: Can the "target" mouse be modified, can the arduino be connected in between the target mouse & the target PC (this would seem easiest - sniff the USB traffic & either pass it or modify it), must you modify the readings the mouse makes or just modify the resulting signals it sends to the PC? \$\endgroup\$ Commented Nov 27, 2014 at 18:43

1 Answer 1

Reset to default
2
\$\begingroup\$

Made this an answer rather than long comment:

Running with Wouter's suggestion that a PS/2 (serial) mouse would be much easier than USB: You read the serial data coming in from the mouse, examine it, and either pass it straight along to the PC or modify it for your own eviiiil ends. As long as the data is valid, the PC has no way of knowing it's not what the mouse is really doing.

This is a classic man-in-the-middle attack: http://en.wikipedia.org/wiki/Man-in-the-middle_attack

Point of interest: I regularly see issues where a serial GPS or USB-to-serial adapter is plugged into a Windows PC at boot, some data (be it GPS NMEA data, serial console output from a development board, etc.) received on a serial port by Windows at boot-time can be mistaken for a PS/2 mouse by the Windows driver and result in a minute of madness with pointers shooting around, things randomly being clicked on, menus appearing, etc. until either cables are yanked out or the machine is rebooted.

\$\endgroup\$
5
  • \$\begingroup\$ Well I understand that your approach is theoretically possible, but I have a concern. How difficult would it be to actually implement? You would have to have a solid understanding of the protocol happening over the PS/2 connection. I am not sure if that would be easier than hacking the optical encoder that was suggested in the 1st comment done on my original post. \$\endgroup\$ Commented Nov 27, 2014 at 20:29
  • \$\begingroup\$ I'd do it this way, MITM is by far the easiest and doesn't require physically interfering with the mouse. \$\endgroup\$ Commented Nov 27, 2014 at 23:48
  • \$\begingroup\$ @rsthegreat12: the PS/2 protocol is well-documented and really quite trivial and would be easy to do, even in a toyduino. I'm less certain about the USB HID protocol, but I'd be surprised if it was particularly challenging. \$\endgroup\$ Commented Nov 27, 2014 at 23:51
  • \$\begingroup\$ @markt: cool, I mean that is an option. Basically I am weighing what would be easier... hacking the optical encoders or being the MITM. MITM requires you to know everything about the PS/2 or USB protocol for a mouse, while the optical encoders should be much easier to digest... wouldn't you say? \$\endgroup\$ Commented Nov 28, 2014 at 20:34
  • \$\begingroup\$ @rsthegreat12 No, I'd say MITM for PS/2 is the easiest of the three. Do some research on the PS/2 protocol, it's seriously trivial. \$\endgroup\$ Commented Nov 28, 2014 at 21:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.