Bomba de insulina de ingeniería inversa para terapia de bricolaje

Hace unos tres años, escuché sobre un sitio web que ofrecía una recompensa por estar muy cerca de mi corazón: comunicaciones de ingeniería inversa con una bomba de insulina. Ya ayudé a crear un sistema para mi hija llamado Loop , con una bomba Medtronic, para lo cual realicé ingeniería inversa de comunicaciones (Ben West descifró la mayor parte del protocolo de comunicación principal de Medtronic usando el dispositivo USB Carelink, y descubrí las frecuencias de radio e hice un trabajo adicional en protocolo). Pero la bomba Medtronic necesitaba apagarse durante la gimnasia durante varias horas. El diseño sin cámara de esta bomba Omnipod me pareció interesante y tenía todas las herramientas para trabajar.

El sistema Omnipod consiste en una pequeña bomba de un solo uso llamada módulo (pod) y una unidad de control (PDM).



Como el PDM se comunica con el módulo por radio, y el módulo no tiene una interfaz incorporada, esto significa que está completamente controlado por radio. Existe la posibilidad de una integración completa con Loop, utilizando solo RileyLink o su versión modificada.

James Wedding nombró una recompensa, y atrajo mucha atención, y luego a las personas adecuadas que ayudaron en el trabajo.

Radio definida por software

SDR es una herramienta excelente . Él hace visible el mundo oculto de la radio. Hay una variedad de tipos de mensajes que se transmiten constantemente en el aire, y estas herramientas le permiten examinar, ver mensajes y, después de un poco de trabajo, decodificar los pequeños flashes que ve allí. Si está buscando mensajes de un dispositivo específico, necesita saber en qué área comenzar la búsqueda. Aquí es donde los documentos públicos de la FCC son útiles.

La documentación de la FCC para PDM, RBV-019 , dice que el dispositivo transmite en la banda de 433 MHz. Después de configurar el software SDR para escuchar en el rango de 433 MHz, aparecen las siguientes señales al emitir el estado desde PDM:



Como finalmente descubrí, estas dos líneas brillantes indican un cierto tipo de modulación llamada modulación por desplazamiento de frecuencia , o FSK. Esto significa que la frecuencia de la señal varía según la información transmitida. El bit 1 se envía como una frecuencia más alta (línea superior) y el 0 se envía con una frecuencia ligeramente más baja (línea inferior). Usando la herramienta de inspección, podemos analizar los datos para reconocer más claramente 1 y 0. Aquí hay una vista muy ampliada del primer mensaje:



Escribí un script de python para extraer estos bits para que podamos verlos como paquetes completos.



Resulta que este patrón repetitivo es parte del preámbulo . Para ahorrar energía, los receptores a menudo entran en modo de suspensión y se despiertan periódicamente para verificar la señal. El transmisor envía el preámbulo el tiempo suficiente para que el receptor lo atrape durante uno de los cortos períodos de escucha. Cuando el receptor escucha el preámbulo, se despierta hasta que aparecen datos reales.

Debe pasar por otra capa antes de obtener los datos del lote real. No puede enviar sus datos por la radio exactamente de la misma manera que los bits originales, porque el receptor usa transiciones para sincronizar a tiempo cuándo esperar el siguiente bit. Si tiene un conjunto largo de ceros o unos, entonces el receptor puede no estar sincronizado. Por lo tanto, las comunicaciones de radio generalmente usan codificación para verificar que haya suficientes transiciones. Las comunicaciones omnípodas utilizan la llamada codificación Manchester . Cada bit está codificado en dos bits. 1 está codificado como 10 y 0 está codificado como 01.

Tomó mucho tiempo descubrirlo, y había muchas teorías en el canal openomni en Slack mientras intentábamos repetir los bits originales. Mark Brighton , Dan Caron y @larsonlr han logrado cierto éxito utilizando RFCat y Ti Stick para capturar paquetes. Evarist Kurgio finalmente escribió una herramienta llamada rtlomni , utiliza el receptor USB rtl-sdr para escuchar paquetes y decodificarlos, lo que resultó ser muy conveniente y más confiable que los métodos basados ​​en TI Stick.

Decodificación de paquetes

Habiendo recibido los bits reales, comenzamos a estudiar la estructura del paquete. En función de los bits que cambiaron entre los diferentes módulos y los diferentes equipos, creamos una estructura que se ve así:

CRC8

La radio está lejos de ser un medio de transmisión ideal. Hay muchas fuentes diferentes de interferencia que hacen que el receptor escuche 1 cuando se envía 0, y viceversa. Es importante saber cuándo sucedió esto, por lo que la mayoría de los protocolos usan una suma de verificación, a menudo llamada CRC. El receptor calcula el CRC a medida que se reciben los datos, y el último byte del paquete incluye el CRC calculado por el transmisor. Si no coinciden, el receptor descarta el paquete y espera la retransmisión.

El protocolo Omnipod utilizaba el CRC estándar de 8 bits. Cuando lo encontramos, decidimos que estábamos muy cerca de entender los mensajes. Qué poco sabíamos ...

Mensajes, CRC16

Algunos mensajes son demasiado grandes para caber en un paquete, por lo que se dividen en varios paquetes. Comenzamos a reconstruir el formato del mensaje y notamos otro conjunto de bits al final de cada mensaje, que parecía un CRC de 16 bits. Pero fue extraño: 5 de 16 bits nunca se configuraron. Probamos muchos métodos diferentes para descubrir cómo se codifica esto, pero nada funcionó.

Este fue el primer gran problema: pudimos continuar trabajando en otros bits en los mensajes, pero no ayudará mucho entender lo que se está enviando, y no podremos generar nuevos paquetes nosotros mismos, por lo que el progreso se ralentizó.

Varios meses pasaron casi en vano. Finalmente, en el invierno de 2016, un miembro del grupo bajo el apodo de @lorelai informó que había copiado con éxito el firmware de un chip ARM más grande a PDM y comenzó el tedioso proceso de desmontaje: aceptando instrucciones de CPU y convirtiéndolas en código legible para humanos con variables semánticas y nombres de funciones. Hizo un trabajo increíble al descubrir los diversos métodos que se utilizaron para transmitir datos.

Observé una de las rutinas sin título y noté que parecía una implementación estándar del cálculo CRC de una tabla. Y la tabla tenía valores para el CRC estándar de 16 bits. Escribí mi propia implementación en tablas, y se probó como un CRC normal. Luego miré cuidadosamente cómo se escribió la función. Una implementación CRC normal se ve así:

while (len--) { crc = (crc << 8) ^ crctable[((crc >> 8) ^ *c++)]; } 

Su implementación se veía así:

 while (len--) { crc = (crc >> 8) ^ crctable[((crc >> 8) ^ *c++)]; } 

¿Nota la diferencia? Lo que se suponía que era un operador de desplazamiento a la izquierda bit a bit estaba codificado de alguna manera como un desplazamiento a la derecha. Esto es un error No hay ninguna razón para paralizar su propio algoritmo CRC, ya que esto dificulta la identificación de mensajes corruptos.

Estamos de vuelta en funcionamiento! Y reanudaron el trabajo de decodificación de mensajes, grabando sesiones de PDM para la administración de bolos [medicamentos], bases temporales [La tasa basal temporal determina un aumento o disminución en la administración de insulina - aprox. carril], suspensión de archivo, etc.

Número de un solo uso

Todos los equipos de administración de insulina tenían una pieza de datos de 4 bytes al comienzo del mensaje, que parecía una forma de criptografía. Nuevamente, probamos muchas formas diferentes de interpretarlo y analizarlo en el contexto de los mensajes en los que se envió, pero no era CRC (a veces vimos los mismos 4 bytes incluso en mensajes diferentes). Y a veces vimos la imagen repetirse. Parecía, tal vez, como parte de un protocolo para evitar la reproducción de datos. En otros protocolos, una función similar se llama nonce .

Una de las opciones que consideramos fue grabar una base de mensajes para reproducir comandos dados. Incluso si la dirección de cada módulo fuera diferente, ahora sabíamos cómo generar un CRC, para poder tomar la copia anterior del comando, poner la nueva dirección en el mensaje y volver a contar el CRC. Solo este nonce nos impidió usar esta estrategia. Independientemente del comando, el módulo solo aceptó el siguiente nonce en la secuencia, y no sabíamos cómo generar el siguiente nonce.

Pero! Después de todo, tenemos un firmware PDM descompilado, ¡podemos mirar allí! Entonces, estudiamos el firmware PDM, rastreamos la generación de mensajes en el código y encontramos dónde deberían estar estos cuatro bytes. Pero en lugar de un método que calcula algunos nonce criptográficos, acabamos de encontrar cuatro caracteres INS. . ¿Qué tontería? Bueno, de alguna manera este área de mensajes debe actualizarse más adelante en la tubería.

Había otro chip en el PDM, más cerca de la radio. Era el mismo chip que se utilizó en los módulos, con el identificador SC9S08ER48, que no estaba documentado en Internet. Probablemente se hizo por encargo para el Insulet. Tal vez podamos eliminar el firmware de este chip. Desafortunadamente, el chip fue bloqueado, lo que impidió la copia del firmware.



El trabajo se ralentizó de nuevo ... fue como un verdadero callejón sin salida. Ponemos todos nuestros esfuerzos mentales en este nonce, y no teníamos ninguna buena pista en las matemáticas detrás de esto. Y el chip ER48, que (posiblemente) guardaba secretos, estaba bloqueado, y es difícil encontrar información pública que ayude a descifrarlo.

Rayos X

Tratando de entender ER48, algunos miembros de la comunidad Slack sugirieron tomar radiografías. Fue realmente genial, pero, desafortunadamente, no abrió nuevas oportunidades.


Tiro general


Tiro detallado

Autopsia y tiro

Dan Caron decidió recurrir a un investigador, el Dr. Sergey Skorobogatov de la Universidad de Cambridge en el Reino Unido. Dan leyó que tenía experiencia extrayendo código de chips bloqueados, y lo convenció de echar un vistazo a nuestro problema. El Dr. Skorobogatov realizó una investigación en el campo del uso de SEM (microscopio electrónico de barrido) para la ingeniería inversa de microcircuitos. Sugirió que es posible, pero será costoso, requerirá equipo costoso y no garantiza un resultado. Joe Moran , quien recientemente comenzó a usar Loop después de que nos conocimos en el hackathon Nightscout en el otoño de 2016, aceptó ayudar con el proyecto. Estuvo de acuerdo con una empresa de Silicon Valley, Nanolab Technologies, para abrir y fotografiar los chips, y también financió amablemente el trabajo de Nanolab y el Dr. Skorobogatov (así como sus módulos personales).

El Dr. Skorobogatov le pidió a Nanolab que aplicara varias técnicas de imagen para descubrir si es posible romper la protección con métodos conocidos no invasivos o semi-invasivos. Como resultado, aparecieron muchas imágenes, algunas de ellas muy hermosas. Estas son imágenes microscópicas ópticas de una matriz de silicio.


Vista general del microcircuito bajo un microscopio óptico.


Vista general del microcircuito bajo un microscopio óptico.

También se tomaron imágenes de áreas específicas de la matriz usando un microscopio electrónico de barrido. Con diferentes voltajes, diferentes preparaciones de superficie y diferentes equipos.


Imagen SEM de células flash. No muestra datos

Desafortunadamente, ninguna de estas imágenes mostró el contenido real de la memoria flash.

El Dr. Skorobogatov tenía un último método, que puede usarse solo en caso de falla. Este era un método patentado, cuyo uso tenía que obtener el permiso de la universidad. El Dr. Skorobogatov hizo la prueba inicial y confirmó que podía leer datos en este chip. Pero antes de continuar, era necesario firmar el NDA y, por lo tanto, se llevaron a cabo negociaciones sobre quién recibiría el contenido del firmware extraído.

Finalmente, la NDA firmó la fundación Nightscout y se responsabilizó por evitar la divulgación no autorizada de métodos y resultados de extracción de memoria.

El resultado de este acuerdo y trabajo fue un artículo increíble escrito por el Dr. Sergei Skorobogatov, así como el código de firmware. Desde la primera vez hubo bastantes errores en el código, pero esto fue suficiente para comenzar. En el Nightscout Spring Hackathon, Joe recurrió a los chicos si a alguien le gustaría desmontarlo. Nadie levantó las manos. Convertir las instrucciones del procesador en algo comprensible es un trabajo arduo, y muy pocas personas saben cómo hacerlo. Traté de profundizar en el ensamblador utilizando la documentación de la CPU, pero logré muy poco y me decepcionó. Otros pidieron optimistamente el código del firmware con expectativas de progreso rápido, luego se dieron cuenta de la escala y la complejidad de la tarea, y se cayeron en silencio.


Ejemplo de desmontaje de instrucciones SC908

Resulta que Joe también tenía una amplia experiencia trabajando con ensamblador, y comenzó a llevar a cabo esta difícil tarea. En julio, el Dr. Skorobogatov completó una segunda operación de extracción de memoria con muchos menos errores. Durante el verano, Joe Moran trabajó incansablemente para mostrar una gran cantidad de instrucciones de procesador e integrarlas gradualmente en la imagen general del pseudocódigo del módulo.

Al final, Ken Shirriff , un experto en ingeniería inversa de hardware, se unió a nosotros y aceleró enormemente el proceso. Juntos, Joe y Ken terminaron traduciendo suficiente código para encontrar una función que codifique nonce. Esto sucedió en septiembre de 2017.

RileyLink y Loop

Actualizamos los scripts Python de openomni, pero ahora es el momento de centrarse en RileyLink + iOS, así que comencé a trabajar en OmniKit y actualizaciones de firmware para RileyLink. Creía que teníamos los conceptos básicos del protocolo, y el resto eran solo detalles. Nuevamente, subestimando por completo cuánto está por venir.



Tuve que escribir un nuevo firmware que maneje la modulación y la codificación del módulo. También tuve que reescribir cómo dos chips en RL se comunican entre sí para procesar ceros, ya que en Medtronic los ceros eran el final especial del marcador de paquetes. Gran parte de Loop tuvo que ser rediseñado para admitir múltiples bombas, así como nuevas interfaces para admitir emparejamiento, desactivación y manejo de errores. Afortunadamente, Nate Racklift puso una base sólida en Loop para hacer que todo esto sea posible.

Mientras tanto, el trabajo continuó para comprender el formato de los equipos. Todo fue cuidadosamente documentado en el wiki de openomni , la documentación más completa del protocolo. Joe, Evarist y Elke Jäger han hecho un gran trabajo a lo largo del tiempo decodificando mensajes y actualizando páginas. Varios miembros del canal Slack han contribuido a la captura de paquetes PDM y al módulo para ayudar a los esfuerzos generales de decodificación.

La decodificación fue un trabajo divertido, con muchas pequeñas victorias, ya que cada componente de cada equipo se descifra, y realmente me gustó trabajar en esta parte, agregando gradualmente código a Loop. En abril de 2018, compartí en Slack que hice "la canulación primaria emparejada a través de iPhone + RL de acuerdo con el programa basal programado, y luego 5 unidades se enfermaron".

El firmware RL 2.0 se completó en julio de 2018 y ya se han enviado nuevas entregas. Se esperaba que estas placas pudieran usarse con Loop y Omnipod, pero la antena existente de 915 MHz era demasiado mala para funcionar de manera efectiva a 433 MHz.

La decodificación y la implementación han progresado significativamente durante el verano, y Loop se acerca gradualmente al rendimiento. Joe hizo lo maravilloso al darme fondos, así que dejé mi trabajo diario y me concentré en este proyecto, y finalmente me uní al maravilloso equipo de Tidepool. Por supuesto, en el campo del bricolaje y la regulación legislativa de equipos médicos hubo más eventos que no cubriré, ¡pero fue un verano muy interesante!

Screamers

Cuando aparecieron más funciones en el controlador, lo conecté a Loop, activando la capacidad de configurar automáticamente la entrega a tiempo. En esta etapa, a menudo se obtenían módulos "llamativos" cuando algunas de las comprobaciones internas del módulo encontraron un problema y él dejó de administrar insulina.

Pero esto parecía ser un problema solucionable, ya que continuamos encontrando pequeñas discrepancias en los paquetes Loop y el PDM original al enviar comandos manualmente, y sugerí que si los solucionábamos todos, los "gritos" se detendrían.

Work Loop!

El 3 de octubre de 2018, Joe se puso el módulo administrado Loop y se convirtió en el primer usuario de Loop Omnipod, aunque no me lo dijo de inmediato porque sabía que estaría preocupado. Cuando me lo dijo, todavía estaba preocupado. Vimos cómo funcionaba el módulo y entendimos la funcionalidad, y el algoritmo básico se probó durante mucho tiempo, pero aún así ...



Un mes después, en el hackathon de Nightscout en noviembre de 2018, varios aventureros más decidieron probarlo por sí mismos, y también se convirtieron en parte de un pequeño grupo de prueba cerrado que crecerá a más de 30 personas antes de que se publique el código.

Desafortunadamente, todavía encontramos "gritos" de módulos, que a menudo ocurren antes de completar los tres días completos de uso, y comparamos cuidadosamente los comandos Loop con muestras de PDM. En este proceso, Elke fue especialmente útil: escribió un script para verificar automáticamente los comandos con versiones originales. Comencé a preocuparme de que el funcionamiento intermitente de los módulos fuera causado por el aumento de los requisitos de batería para las comunicaciones cada cinco minutos.


Grifos del regulador de voltaje en el módulo, perforados a través del plástico del panel posterior, en superpegamento

Por lo tanto, comencé a medir el voltaje de suministro del módulo usando Arduino, escribir datos y guardarlos en una base de datos local para su visualización. Comparé PDM y Loop.


Cambio a largo plazo en la tensión de alimentación del módulo.

Desafortunadamente, esto también resultó ser un callejón sin salida; usando PDM e inyectando una gran cantidad de insulina, pude llevar el módulo a un voltaje más bajo que durante toda la vida útil del módulo Loop, y no pude hacer que el módulo "gritara". Parecía que el estrés no era un problema, debe haber algo más.


RileyLinks con antenas de bobina de 955 MHz (izquierda) y 433 MHz (derecha)

En algún momento, noté que si fallaba el intercambio de mensajes con el módulo, el módulo a veces seguía intentando finalizar el intercambio volviendo a enviar paquetes una y otra vez. Los registros de los probadores también mostraron muchos problemas técnicos, así que comencé a experimentar con antenas. Ambos problemas deben estar relacionados con la calidad de la comunicación. Planeaba probar diferentes antenas y las ordené en diferentes lugares de Internet, pero no tuve tiempo de probarlas hasta que esto se convirtió en una prioridad.

Tenía varias antenas flexibles de 433 MHz que se pueden conectar al interior del gabinete RL. A menudo muestran un mejor rendimiento en algunos escenarios, pero no en otros; Demasiado poco confiable. Cuando llegué al carrete, mostró un buen rendimiento de manera muy consistente y en rangos muy sorprendentes. Es hora de presentar un nuevo caso para RileyLink.

Con una nueva antena y algunas optimizaciones que redujeron la mensajería mientras se realizaban ajustes cada 5 minutos, los gritos se volvieron muy raros. Probablemente comparable al uso habitual de módulos con PDM. En las últimas 7.500 horas de pruebas en tiempo real, el 94% de los módulos se completaron sin fallas.

Pruebas y documentación.

El grupo de pruebas creció lentamente: los nuevos usuarios se unieron constantemente al sistema, quienes con una nueva mirada podrían evaluar qué partes parecen confusas. Estos probadores soportaron muchos módulos llamativos e hicieron una gran contribución para mejorar el rendimiento de Loop con Omnipod. Básicamente, enviaron informes de problemas y registros de trabajo.

Estos informes tienen un registro de mensajes que pueden analizarse utilizando una herramienta hecha por Elke. Da una idea si obtenemos comandos distorsionados, y también le permite recopilar estadísticas sobre ciertas partes de la interacción de Loop con los módulos.

Marion Barker se unió al grupo de pruebas y agregó informes especiales y estadísticas adicionales sobre el progreso de las pruebas, y pudimos usar sus estadísticas de módulos exitosos contra fallas para tener una idea del progreso de alto nivel.

Al final, Katie DiSimone se unió al grupo de prueba. Comenzó una importante reestructuración de loopdocs.org con documentación sobre el uso de Loop con múltiples dispositivos. La espera de la versión de Loop que funcionó con Omnipod fue increíblemente alta, y sin una buena documentación estaba claro que nos veríamos abrumados con las mismas preguntas.

Nuevas características de bucle

La integración con Omnipod requirió un replanteamiento de algunos de los elementos de la interfaz y la adición de nuevos controles. El módulo no informa la batería, y el usuario puede hacer poco con una carga baja si esto sucede, por lo que mostrar el widget de nivel de batería no tiene sentido. Además, sin una interfaz de usuario en la bomba, el usuario debería poder cancelar rápidamente el bolo. El icono del tanque representaba el tanque Medtronic, por lo que queríamos rehacerlo. Gracias a Paul Forgione por desarrollar el logotipo del módulo, que ahora muestra el nivel del tanque.

Agradecimientos

Gracias a todas las personas que nos ayudaron a recorrer este largo camino para que nos demos cuenta de la meta que establecimos hace mucho tiempo. Sé que no mencioné todos los eventos involucrados y no todos. Esto no es posible en un artículo, y solo tengo experiencia personal. Es difícil imaginar cuántas horas tardó. Si los agrega todos juntos, estoy seguro de que es una cifra impactante. Sin mencionar el trabajo en la creación del Omnipod en sí, que, me parece, eclipsa todos estos esfuerzos. Así que gracias a todos. Además, muchas de estas horas se habrían pasado con las familias. Realmente aprecio la comprensión de mi esposa e hijos por el tiempo que pasé en eso, y también quiero agradecerles.

Notas

Debo mencionar a Joachim Ornstedt como uno de los contribuyentes a la decodificación de openomni, así como el creador de probablemente la primera integración con omnipod. Construyó un dispositivo que utilizaba el reconocimiento óptico de caracteres (OCR) para extraer datos del PDM, y conectó los botones numéricos al PDM físico a través de otro microcontrolador. Este enfoque es difícil de escalar, pero es muy inteligente y evita muchos de los problemas que tuvimos que enfrentar con una solución basada en RE. Realmente admiro cómo lidió con el problema y configuró el trabajo durante una pequeña fracción del tiempo que tardó en hacer que el dispositivo funcione con Loop.