4
\$\begingroup\$

I'm looking into the feasibility of a project to develop a USB-over-RF device for physical penetration testing engagements. The idea is that our tester could connect a device to a USB port on a machine within the test environment, then leave the building and plug in arbitrary USB devices remotely.

Diagram of project

The requirements are as follows:

  • USB 1.1 support at minimum, but USB2.0 support would be greatly beneficial even if speed is heavily degraded.
  • Ability to plug in arbitrary devices is mandatory. Keyboard, mouse and USB storage are our primary goals.
  • Cannot load any form of special software or driver onto the target machine. Client transceiver has to work "out of the box" on a system we've got no access to.
  • Host transceiver would preferably be nothing more than a box full of electronics that we plug a USB hub into.
  • Enough speed and integrity to run a USB VGA adapter would be amazing, but we're realistic about this being potentially impossible.
  • Can be powered from a socket if necessary, but running from host power would be better.
  • Needs a strong enough signal to go through at least one external wall.

I have a few ideas in my head about what kinds of technologies could be used, e.g. Arduino Mega + USB host shield + XBee for the host transceiver, and a similar setup (with USB client rather than host) for the client transceiver. We also considered TCP/IP over 3G as a potential transmission medium, though I fear it may be too latent / slow.

Do you think this could be achieved with the kind of technology I've mentioned? What issues am I likely to run into with sending USB over a latent connection like this? Is there an easier solution that I've missed?

To clarify, consider our task equivalent to sneaking into a building and installing a device into a computer, similar to the scene at the start of Sneakers. The restriction is due to the fact that the machine will likely be locked or shut down, so we cannot expect to have any interaction with the system beyond plugging in a USB device. We'll often have less than 30 seconds alone with the machine, too. This rules out installing drivers / software, bluetooth pairing, etc.

\$\endgroup\$
10
  • \$\begingroup\$ An XBee on a microcontroller board that supports HID, at the remote end, and another XBee on a microcontroller board that supports USB host mode (Not the Arduino Mega, perhaps the Arduino Due) at the operating end, should work. A USB to XBee adapter like the XBee Explorer USB might serve the requirement, you would have to check for specific details. \$\endgroup\$
    – Anindo Ghosh
    Apr 19, 2013 at 13:26
  • \$\begingroup\$ @AnindoGhosh I don't think the XBee Explorer USB would do the job. It'd allow me to take signals from the XBee into software, but that doesn't allow me to register the remote device as a native USB device. The Arduino Due is a good call for the host end though. If anything I'd prefer to directly translate the D+ and D- signal into a stream over RF, but I have a feeling that's going to be heavily prone to errors. \$\endgroup\$
    – Polynomial
    Apr 19, 2013 at 13:30
  • \$\begingroup\$ Yeah, signal-level encoding into RF will be problematic - with a digital validation at each end, at least junk signals won't be going across. \$\endgroup\$
    – Anindo Ghosh
    Apr 19, 2013 at 14:08
  • 1
    \$\begingroup\$ Latency is going to be a serious problem. \$\endgroup\$
    – pjc50
    Apr 19, 2013 at 15:20
  • \$\begingroup\$ I thought that might be the case over 3G, but surely XBee won't be too much of an issue? I'd imagine buffering would do wonders. \$\endgroup\$
    – Polynomial
    Apr 19, 2013 at 15:22

2 Answers 2

Reset to default
1
\$\begingroup\$

Having looked at this, I think it's worth looking at Wireless USB "wire adapters": http://www.usb.org/developers/wusb/docs/presentations/2006/Taipei06_RI_Wire_Adapter_Model.pdf (lots of detail)

However, I don't think those are transparent. If you can't find a transparent one, and it's an absolute requirement, I think you'll have to settle for proxying. Plug in a device on one side, have a "host" read its descriptor and pass it over the wireless, have the proxy present that descriptor on the other side. Store and forward requests; do link-level acknowledgement on the proxy. This should work for HID devices and you can probably make it work for mass storage devices. You will probably have to do special interpretation of some types of message, so build that into your software from the start. This is basically Anindo's solution. I'd estimate it as a good few weeks of software development; once you have the basic XBee devices working you might get better answers on the software stackexchange.

Normal USB hubs are non-buffering and have a very small latency limit of a few 12MHz ticks.

\$\endgroup\$
1
\$\begingroup\$

Have you checked USB over IP to see if it meets your requirements ?

I do not have extensive experience with the technology, but I've tried the Windows USB/IP software for the remote USB cam usecase few years back. Whether it'd be able to support a USB hub, I am not sure.

  • This sourceforge project USB/IP for MS-Windows
  • On Linux this how-to should help

So anything that supports IP communication (WiFi, Bluetooth etc.), should, at least in theory help do USB over IP (over wireless). A Bluetooth Class-1 (example Bluegiga) module or adapter, should help do this over a longish range.

\$\endgroup\$
6
  • \$\begingroup\$ Doesn't this require specialist software or drivers on the target endpoint? My primary requirement is that it's plug-n-play with no software access to the system. \$\endgroup\$
    – Polynomial
    Apr 22, 2013 at 16:09
  • \$\begingroup\$ From what I remember, it does require installation of some software, and it was quite a bit work to get it working, things could be better now. However, if your target system is MS-Windows, then unless the USB device you are plugging in, is a common kind, adhering to the common device specifications, Windows asks you for a driver anyway. Also, mode-switching USB devices (like most 3G dongles), initially identify themselves as block storage with driver installation autolaunch (possibly unattended), and then switch to the other mode (e.g. serial modem). \$\endgroup\$
    – bdutta74
    Apr 22, 2013 at 16:15
  • \$\begingroup\$ That is one possible approach, i.e. if you willing to create the USB dongle, and design it's firmware. \$\endgroup\$
    – bdutta74
    Apr 22, 2013 at 16:16
  • 1
    \$\begingroup\$ Perhaps I do not understand "penetration testing" modalities, but I am guessing plain bluetooth mouse and bluetooth keyboards are not an option ? All it requires is inserting a well-supported/tested BT dongle on the PC (assuming that it is not a laptop). Yes, it does require the act of pairing once, and ensuring that the interface is not disabled. Are you saying that apart from pluggin in a USB device on the target computer, you do not want to do anything else ?? \$\endgroup\$
    – bdutta74
    Apr 22, 2013 at 17:02
  • 1
    \$\begingroup\$ That's correct. A common scenario will be that, during a physical penetration test, our tester will have less than 30 seconds to install the device, and that the computer will be locked at the time. Bluetooth pairing is problematic in this scenario, and we need more flexibility and greater range than bluetooth provides. I'd use a hyped-up wireless keyboard and mouse device, but that doesn't offer mass storage or other options. \$\endgroup\$
    – Polynomial
    Apr 22, 2013 at 19:56

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.