Cable USB "inalámbrico", vía RF/3G

Estoy investigando la viabilidad de un proyecto para desarrollar un dispositivo USB sobre RF para compromisos de pruebas de penetración física . La idea es que nuestro probador pueda conectar un dispositivo a un puerto USB en una máquina dentro del entorno de prueba, luego salir del edificio y conectar dispositivos USB arbitrarios de forma remota.

diagrama de proyecto

Los requisitos son los siguientes:

  • Compatibilidad con USB 1.1 como mínimo, pero la compatibilidad con USB 2.0 sería muy beneficiosa incluso si la velocidad está muy degradada.
  • La capacidad de conectar dispositivos arbitrarios es obligatoria. El teclado, el mouse y el almacenamiento USB son nuestros objetivos principales.
  • No se puede cargar ningún tipo de software o controlador especial en la máquina de destino. El transceptor del cliente tiene que funcionar "fuera de la caja" en un sistema al que no tenemos acceso.
  • El transceptor host sería preferiblemente nada más que una caja llena de dispositivos electrónicos en la que conectamos un concentrador USB.
  • Suficiente velocidad e integridad para ejecutar un adaptador USB VGA sería increíble, pero somos realistas acerca de que esto es potencialmente imposible.
  • Se puede alimentar desde un enchufe si es necesario, pero sería mejor ejecutarlo desde el host.
  • Necesita una señal lo suficientemente fuerte para atravesar al menos una pared externa.

Tengo algunas ideas en mi cabeza sobre qué tipos de tecnologías podrían usarse, por ejemplo, Arduino Mega + USB host shield + XBee para el transceptor host y una configuración similar (con cliente USB en lugar de host) para el transceptor cliente. También consideramos TCP/IP sobre 3G como un medio de transmisión potencial, aunque me temo que puede ser demasiado latente/lento.

¿Crees que esto podría lograrse con el tipo de tecnología que he mencionado? ¿Qué problemas puedo encontrar al enviar USB a través de una conexión latente como esta? ¿Hay una solución más fácil que me he perdido?

Para aclarar, considere nuestra tarea equivalente a colarse en un edificio e instalar un dispositivo en una computadora, similar a la escena al comienzo de Sneakers . La restricción se debe al hecho de que es probable que la máquina se bloquee o se apague, por lo que no podemos esperar tener ninguna interacción con el sistema más allá de conectar un dispositivo USB. A menudo, también tendremos menos de 30 segundos a solas con la máquina. Esto descarta la instalación de controladores/software, emparejamiento bluetooth, etc.

Debería funcionar un XBee en una placa de microcontrolador que admita HID, en el extremo remoto, y otro XBee en una placa de microcontrolador que admita el modo de host USB (no el Arduino Mega, quizás el Arduino Due) en el extremo operativo. Un adaptador USB a XBee como el XBee Explorer USB podría cumplir con el requisito, tendría que verificar los detalles específicos.
@AnindoGhosh No creo que el XBee Explorer USB haga el trabajo. Me permitiría tomar señales del XBee en el software, pero eso no me permite registrar el dispositivo remoto como un dispositivo USB nativo. Sin embargo, el Arduino Due es una buena decisión para el anfitrión. En todo caso, preferiría traducir directamente la señal D+ y D- en una transmisión por RF, pero tengo la sensación de que será muy propenso a errores.
Sí, la codificación de nivel de señal en RF será problemática: con una validación digital en cada extremo, al menos no se transmitirán señales basura.
La latencia va a ser un problema serio .
Pensé que podría ser el caso con 3G, pero seguramente XBee no será un gran problema. Me imagino que el almacenamiento en búfer haría maravillas.
El almacenamiento en búfer aumenta en lugar de disminuir la latencia. Habiendo dicho eso, parece que hay productos que hacen esto: amazon.co.uk/Wireless-USB-Transfer-Data-Adapter/dp/B00942RDN2/…
@ pjc50 El problema con eso es que requieren que se instalen controladores no estándar en el sistema de destino. Esto es especialmente problemático en los objetivos de Linux.
@ pjc50 Re: almacenamiento en búfer, me refería al tema de la velocidad. ¿La latencia es realmente un gran problema siempre que los comandos del protocolo USB se envíen y reciban en orden?
El protocolo requiere que se envíe un ACK dentro de un tiempo muy corto de una transmisión desde el host (no puedo encontrar el lugar exacto en la especificación para esto en este momento).
Claro, pero el controlador local podría enviar el ACK y reenviar los datos.

Respuestas (2)

Habiendo visto esto, creo que vale la pena mirar los "adaptadores de cable" USB inalámbricos: http://www.usb.org/developers/wusb/docs/presentations/2006/Taipei06_RI_Wire_Adapter_Model.pdf (muchos detalles)

Sin embargo, no creo que sean transparentes. Si no puede encontrar uno transparente, y es un requisito absoluto, creo que tendrá que conformarse con el proxy. Conecte un dispositivo en un lado, haga que un "host" lea su descriptor y páselo a través de la conexión inalámbrica, haga que el proxy presente ese descriptor en el otro lado. Almacenar y reenviar solicitudes; hacer un reconocimiento a nivel de enlace en el proxy. Esto debería funcionar para dispositivos HID y probablemente pueda hacerlo funcionar para dispositivos de almacenamiento masivo. Probablemente tendrá que hacer una interpretación especial de algunos tipos de mensajes, así que integre eso en su software desde el principio. Esta es básicamente la solución de Anindo. Lo estimaría como unas buenas semanas de desarrollo de software; una vez que tenga los dispositivos XBee básicos funcionando, puede obtener mejores respuestas en el intercambio de pila de software.

Los concentradores USB normales no tienen almacenamiento en búfer y tienen un límite de latencia muy pequeño de unos pocos tics de 12 MHz.

¿Ha revisado USB sobre IP para ver si cumple con sus requisitos?

No tengo mucha experiencia con la tecnología, pero probé el software USB/IP de Windows para el caso de uso de la cámara USB remota hace algunos años. Si sería compatible con un concentrador USB, no estoy seguro.

  • Este proyecto sourceforge USB/IP para MS-Windows
  • En Linux, este tutorial debería ayudar

Entonces, cualquier cosa que admita la comunicación IP (WiFi, Bluetooth, etc.), debería, al menos en teoría, ayudar a hacer USB sobre IP (inalámbrico). Un módulo o adaptador Bluetooth Class-1 (por ejemplo, Bluegiga ) debería ayudar a hacer esto en un rango bastante largo.

¿No requiere esto un software especializado o controladores en el punto final de destino? Mi requisito principal es que sea plug-n-play sin acceso de software al sistema.
Por lo que recuerdo, requiere la instalación de algún software, y fue bastante trabajo hacerlo funcionar, las cosas podrían estar mejor ahora. Sin embargo, si su sistema de destino es MS-Windows, a menos que el dispositivo USB que está conectando sea del tipo común y cumpla con las especificaciones del dispositivo común, Windows le pedirá un controlador de todos modos. Además, los dispositivos USB que cambian de modo (como la mayoría de los dongles 3G), inicialmente se identifican como almacenamiento en bloque con el inicio automático de la instalación del controlador (posiblemente sin supervisión), y luego cambian al otro modo (por ejemplo, módem en serie).
Ese es un enfoque posible, es decir, si está dispuesto a crear el dongle USB y diseñar su firmware.
Dado que mis dispositivos de destino son el mouse, el teclado y las unidades flash, deben realizar una instalación totalmente desatendida a través de los controladores de almacenamiento masivo y HID predeterminados incorporados.
Tal vez no entiendo las modalidades de "prueba de penetración", pero supongo que el mouse bluetooth simple y los teclados bluetooth no son una opción. Todo lo que requiere es insertar un dongle BT bien compatible/probado en la PC (suponiendo que no sea una computadora portátil). Sí, requiere el acto de vincular una vez y asegurarse de que la interfaz no esté deshabilitada. ¿Está diciendo que además de conectar un dispositivo USB en la computadora de destino, no quiere hacer nada más?
Eso es correcto. Un escenario común será que, durante una prueba de penetración física, nuestro probador tenga menos de 30 segundos para instalar el dispositivo, y que la computadora esté bloqueada en ese momento. El emparejamiento de Bluetooth es problemático en este escenario, y necesitamos más flexibilidad y mayor alcance que el que proporciona Bluetooth. Usaría un dispositivo de teclado y mouse inalámbrico promocionado, pero eso no ofrece almacenamiento masivo u otras opciones.
Cable USB "inalámbrico", vía RF/3G
RespuestasAquíPolítica de privacidad1y, 0v