Pregunta

El desafío : Tengo un dispositivo de mano de Linux, que registra los datos y lo almacena al disco. Debe intercambiar estos datos con una aplicación de Windows a través de USB. Cuando estos datos son accesibles por el usuario - E.G. A través de USB-MASS-Storage, tiene que ser cifrado. Debería trabajar fuera de la caja, con una variedad de sistemas operativos, también para sesiones de terminales de Citrix, etc.

El plan : creo un sistema de archivos en el espacio de usuario con fusible y ofreciéndolo a Windows a través de almacenamiento en masa. Cada vez que Windows accede a un archivo, recibo una devolución de llamada y cifra los datos sobre la marcha. Además, podemos tener un contenido dinámico, por ejemplo. Cuando alguna contraseña se escribe en un archivo, se muestra más contenido.

El problema : cuando se usa el gadget de almacenamiento de masas (por ejemplo, g_file_storage ) solo acepta archivos o Bloques-dispositivos, pero sin sistemas de archivos (directorios). ¿Por qué?

[...] Proporciona una interfaz simple para leer y escribir sectores de datos, al igual que la interfaz de bajo nivel utilizada para acceder a cualquier disco duro [...]. Los sistemas operativos pueden tratar la unidad USB como un disco duro, y pueden formatearlo con cualquier sistema de archivos que les guste. (de wikipedia )

Entonces, no hay posibilidad de tener un sistema de archivos dinámico a través de almacenamiento en masa ... y esta parece ser la razón, por qué mi teléfono móvil Android no monta todos los datos en el teléfono, cuando lo conecto a la PC.

opciones :

  • Crear un ' Dispositivo de bloque en el espacio de usuario ': similar al fusible (necesita un controlador de grasa inversa, Cuando quiero ofrecer archivos dinámicamente)
  • implementar mi propio servidor NBD para crear un dispositivo de bloque (¿necesita un controlador de grasa inversa?)
  • I Guardar archivos encriptados a una partición y aprobar esta partición al dispositivo de almacenamiento en masa (el problema sería el rendimiento y la falta de interacción dinámica)
  • NO OFRECE UN DISPOSITIVO DE MASA-CONUNDADERO Y MIRAR POR OTRAS IDEAS (ETH OUTE USB)

    En este momento, solo la última opción parece ser realista, ¿o tienes otra propina para mí?

    ¡Estaría agradecido!

    charly

¿Fue útil?

Solución

El protocolo de almacenamiento masivo USB es un protocolo de dispositivo de bloques; No funciona a nivel de archivos o directorios. El host de Windows espera ver un sistema de archivos RAW VFAT expuesto por el controlador G_Mass_Storage, y hará que las escrituras y lea a los metadatos VFAT, según sea apropiado para determinar cómo se estructuran los directorios.

Debido a esto, es no trivial exponer un sistema de archivos de fusible al host de Windows. Tendrías que emular VFAT, asignando bloques en el sistema de archivos virtuales a metadatos y a los datos, y dado que el host de Windows es gratuito para almacenar en caché los datos o metadatos que lee, una vez que asigne algunos metadatos o datos, no puede cambiar (por lo que cambia a los cambios a No se pudieron reflejar los datos de su fusible en el sistema de archivos de Windows). El host de Windows también puede retrasar y reordenar las escrituras tanto de metadatos como en los datos, todo es un lío real si intenta emular.

Ahora, hay algunas cosas que puede hacer:

  1. Puede escribir un controlador IFS personalizado en el lado de Windows para interactuar con su dispositivo Linux a través de un protocolo personalizado que funciona en el nivel de archivo / directorio.
  2. Puede tratar el dispositivo USB como un puerto Ethernet virtual, y habla CIFS al host de Windows
  3. puede crear un diseño de VFAT estático en el tiempo de conexión para exponer al host de Windows; Los datos no descifrados aún no pueden devolver los errores de E / S para evitar el almacenamiento en caché de Windows RAW cifrado.
  4. Puede simplemente cifrar un dispositivo de bloques en bruto con DM-crypt, y exponer todo este dispositivo de bloqueo (cifrado como un trozo) a Windows.
  5. Podría implementar una gadget MTP .

    Estos enfoques vienen con sus propios problemas:

    1. requiere que se instale un controlador de Windows, y para ser firmado por Microsoft, etc. No se puede usar en una máquina sin acceso administrativo para instalar el controlador.
    2. no la reproducción automática; El usuario debería navegar por el navegador de la red para obtener acceso a los archivos. Los ajustes de firewall pueden interferir. Puede tener una sobrecarga significativa.
    3. muy complejo. Manejar las actualizaciones de los metadatos sobre el backend puede ser extremadamente difícil. Sorpresa Los eventos desenchufan pueden ser devastadores. El comportamiento de Windows al recibir un error de IO puede ser un problema si el usuario intenta acceder a un archivo bloqueado.
    4. No hay cifrado a nivel de archivos disponible, pero de lo contrario debería funcionar bien.
    5. No estoy seguro de cuánto soporte para los archivos que no tiene medios MTP tiene; El apoyo no es tan generalizado como soporte de almacenamiento masivo.

Otros consejos

Es posible que le interese que sepa que Android, que se expuso previamente como un dispositivo de almacenamiento masivo USB al host, en su lugar está actuando como un dispositivo MTP (a partir de Honeycomb).

Dicho esto, alguien ya ha implementado su opción 1, aunque con el "Dispositivo" y "HOST" un poco revertido. qemu tiene un pirateo insano llamado vvfat que puede crear un dispositivo de bloque falso que se parece a la máquina virtual que contiene un archivo VFAT de un directorio / archivoÁrbol en el host.Requiere un escaneo recursivo completo antes de comenzar, depende de los detalles de cómo escriben los sistemas de archivos en los sistemas de archivos, y se cae si cambia de forma independiente cualquier archivo mientras esté en uso, pero (de alguna manera) se las arregla (a veces).

Puede ser posible traducir el protocolo NBD a USB, y el USB "BIT-BAG" para aparecer en el host USB como dispositivo de almacenamiento masivo USB.

  • El almacenamiento de NBD y USB MSAs son dispositivos de nivel de bloque, por lo que puede ser posible traducir un protocolo a otro. Sin embargo, eso seguramente requeriría la programación, ya que no creo que esto existe. Sin embargo, http://travisgoodspeed.blogspot.com/2012 /07/emuling-usb-devices-with-python.html se ve bastante útil para el lado USB, y https://bitbucket.org/hirofuchi/xnbd/wiki/home debe darle un buen ejemplo para el lado del cliente NBD.
  • usando VFAT significa que las ventanas pueden verla como una unidad de disco USB normal, sin controladores.
    • Como sugería otro póster, el módulo VVFAT de Qemu podría usarse para automatizar algo de esto.
    • El cifrado del tráfico requeriría túneles el tráfico de NBD a través de SSH o OpenVPN.

      La configuración final se vería algo así:

      +---------------------------------+                +------------------+
      | data collection device          |                | client device    |
      | +----------------+              |                |                  |
      | | collected data |              |                |  SSH -> NBD      |
      | | -> linux fs    |              |                |         client   |
      | +--+-------------+--------+     |                |         |        |
      | -> | qemu vvfat           | SSH +-{some network}-+         V        |--> client PC
      |    | run NBD inside the VM|     |                | USB Mass Storage |    USB port 
      +----+----------------------+-----+                +------------------+   
      

Mirando las opciones, consideraría usar el gadget Ethernet, y hacer la autoconfiguración de IP en el dispositivo, luego ejecutando Samba para exportar el sistema de archivos al host de Windows.Esto le daría el nivel de control que necesitas.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top