Raspberry Pi Detener y atrapar … No, Detener

Nora Prieto
Nora Prieto

En nuestro recuerdo, siempre ha habido hacks, exploits y solo una curiosidad acerca de las instrucciones de CPU indocumentadas. El Z80 los tenía. Incluso la calculadora HP41C tenía algunos códigos sin documentar. La instrucción HCF (Halt and Catch Fire) era apócrifa, pero siempre escuchamos que los viejos chips del controlador de video podían hacer explotar algunos monitores. Últimamente no ha escuchado mucho sobre este tipo de cosas, tal vez porque hay menos personas trabajando en lenguaje ensamblador.

[Sergi Àlvarez i Capilla] no solo trabaja en lenguaje ensamblador, sino que escribió una lista de ensamblaje ARM cuando notó algo gracioso. Las instrucciones se construyen de acuerdo con un patrón regular y algunos de los patrones faltaban. ¿Qué hacer? [Sergi] No perdí el tiempo probándolos.

¿Su resultado? Encontró al menos una instrucción que hace que Raspberry Pi se bloquee muerta. En general, eso no es gran cosa, pero la instrucción no está protegida, por lo que cualquier programa de usuario podría bloquear Pi. Un reinicio configurará las cosas, por supuesto. No se produce ninguna quema. Los modelos más nuevos, por cierto, parecen ser resistentes y [Sergi] probó varios teléfonos y otros dispositivos con procesadores ARM sin efecto.

¿Las implicaciones prácticas? ¿Probablemente no mucho? Pero si coloca Pi en un sistema crítico, puede encontrar este resultado interesante. Quizás la mejor defensa contra este tipo de piratería es comenzar con una sola instrucción. Además, el 6502 era bien conocido por su número de códigos operativos indocumentados útiles. Esto se discute en el video a continuación (la parte indocumentada comienza alrededor de las 6:00).

https://www.youtube.com/watch?v=_aSc6IlI-iM

  • Joshumax dice:

    Estoy seguro de que las personas responsables de crear Windows ME fueron contratadas para diseñar el ARMv6 ISA …

  • Asa Jota dice:

    El primer día de clases de informática, 1998, mi amigo y yo intentamos monitorear la configuración y lo hicimos explotar. No un kaboom, sino un ruido extraño, una bocanada de humo, y ese es el final de ese monitor.

    • Nuevo dice:

      Todo es posible con los monitores CRT, a veces configurando la frecuencia de actualización demasiado alta o algo puede tostarlo. En su mayor parte, todo es hardware analógico, intentará hacer todo lo que le digas dónde, ya que las pantallas digitales solo dirán que la señal está fuera de los límites.

      • GotNoTime dice:

        Los viejos monitores de sincronización fija harían eso. Si los llevara demasiado lejos de su frecuencia de sincronización esperada, terminaría explotando el HOTS. Los síncronos más elegantes eran mucho más duraderos.

      • PiMaxC dice:

        Empujé mi antiguo punto de vista un poco demasiado fuerte y básicamente reduje a la mitad su vida útil.

  • Dmitry G. dice:

    http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0040d/Chddhfed.html

    El punto de ruptura del ángel
    ¿Quizás BCM olvidó deshabilitar la depuración del núcleo en ese núcleo?

    • Joshumax dice:

      Eh … ¡Buena captura! (sin juego de palabras)

    • googler dice:

      Esto incluso aparece simplemente lanzando el número hexadecimal a Google. Me pregunto por qué OP no hizo eso …

      • asdf dice:

        Porque intentar crear un escándalo y hacerse un nombre es mucho más emocionante.

    • makomk dice:

      Eso parece ser un software para depurar un programa, así que “detente y agarra … ???” es probablemente una descripción precisa del problema. Se supone que algo en algún lugar de la pila de software captura la excepción y luego no tiene idea de qué hacer con ella.

  • Daniel dice:

    Su decodificación de la instrucción es incorrecta. En la línea de comando, especificó una secuencia de bytes, pero los documentos ARM describen las decodificaciones instruccionales de palabras de 32 bits que son little endian en el RPi.

    Esta es la referencia instructiva final (se requiere registro gratuito):
    http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406c/index.html
    En la página A8-758 nos dice que esta instrucción se llama UDF y genera una excepción correspondiente.

    • Luke Wren dice:

      Este es el último comentario requerido en este hilo, todos los comentarios a continuación son inútiles

    • chango dice:

      Eso es rico. Al menos encontró un cuidador excepcional roto en el centro.

      • wren6991 dice:

        Lo siento, esa fue una reacción (rápida) al comentario a continuación que tomó esta publicación como una oportunidad para discutir sobre todo lo relacionado con Broadcom, una reprimenda injustificada, porque como Daniel dice que la instrucción está realmente documentada, OP recientemente se olvidó de RTFM.

        No es como si Broadcom tuviera alguna ayuda para diseñar el núcleo ARM tal como está.

        Pero sí, tiene razón, el núcleo que no maneja esta excepción es definitivamente un error.

        • chango dice:

          La pieza divertida es cuando el OP hace una copia de seguridad del bittex mientras descifra la instrucción. Es un delicioso contraste con la investigación de seguridad del resto de la página y me hizo sentir un poco menos estúpido hoy.

  • Dimitar Tomov dice:

    El día en que una IP cerrada es segura es el día en que se abrieron. Punto y caso arriba.

    Segundo tema: ¿Por qué el SoC R * i principal de Broadcom se considera seguro primero? Es una pieza de tecnología obsoleta demasiado cara. Desafortunadamente, ARM IP puede garantizar la seguridad o la calidad por sí solo. Tampoco puede garantizar nada si Broadcom lo desarrolla o modifica.

    Luego nos dimos cuenta de que el SoC producido específicamente para R * i2 tiene tantos defectos que se podría suponer que la masa dejaría de comprarlo. Pero, obviamente, a nadie le importa la calidad en este momento. Buen marketing, buen financiamiento, sorprendente contrato de Broadcom => luego famoso luego rentable, sin embargo, no significa exitoso, ni más probado que otro SBC. Para nada. Más el mismo precio, mayor calidad de PCB e incluso perfectamente. Existe la otra tendencia de ESP que es opuesta, similar mala calidad a muy bajo precio. Aprender, probar, proyectar, pero para que no nos engañemos de que esto puede ser seguro, ni seguro. Me da miedo pensar que cualquiera de esos R * i o ESP es en realidad domótica 24 horas al día, 7 días a la semana durante un año, lo que queda por 5 o 10.

    • Gryd3 dice:

      Si planeaba usar RPi en una configuración que requería una seguridad muy alta, este es el número uno fallido.
      Olvidas que a pesar de que tienen deficiencias, el Pi comenzó como una forma de llevar informática barata a personas y lugares que no podían permitírselo.
      Es un dispositivo diseñado para su uso en entornos educativos y de pasatiempos. Cualquiera que los utilice en un entorno empresarial debería pensar en sus prioridades.

    • OLD_HACK dice:

      Las personas que ven un chip altamente probado como obsoleto probablemente nunca hayan tenido que hacer construcciones comerciales.
      Me gusta ver los errores a medida que evolucionan los chips porque podemos evitar los mismos errores de diseño.

      Vi un enrutador de fibra de giro púrpura de $ 450k USD con el mismo problema (una cuchilla saca la otra cuando cae). JAJAJA 😉

    • wren6991 dice:

      ¿Podría enumerar los muchos defectos del BCM2836? Sería bueno que compartiera sus conocimientos con nosotros.

      • yetihehe dice:

        Aunque no creo que BCM2836 tenga TANTOS defectos, el kernel usb es EL defecto. Es un punto de venta absolutamente barato y tienen que sentirse mal para usarlo.

        • Vejestorio dice:

          El kernel funciona principalmente bien en modo dispositivo. En realidad, se usa ampliamente en teléfonos móviles y cosas por el estilo. Tiene un modo de alojamiento que casi nadie usa, por lo que probablemente el problema solo apareció cuando se desarrolló el raspado. El núcleo consume significativamente menos silicio que otros núcleos USB más característicos, por lo que puede valer la pena.

        • wren6991 dice:

          Bueno, ese es realmente un muy buen punto. Estaba destinado a ser utilizado para el modo de dispositivo OTG, y operarlo como host implicaba implementar muchas cosas en programas que deberían estar en hardware.

          Que funciona tan bien, como muestra, se están produciendo algunos hacks de software bastante impresionantes en alguna parte, pero sería bueno tener un controlador de alojamiento efectivo a continuación.

          • wren6991 dice:

            Quizás se relacione con el hecho de que el 2835 nunca fue pensado para ser un procesador de aplicaciones, sino un coprocesador de medios para teléfonos Nokia.

            El ARM se agregó entre los giros A0 y B0 del silicio. Por lo tanto, hay muchas rarezas como el proceso de arranque (incluida la lectura del sistema de archivos FAT desde la tarjeta SD) que ocurre en la GPU.

            El VideoCore en realidad ejecuta un RTOS bastante completo (contenido en start.elf) mientras que los núcleos ARM ejecutan Linux.

    • GotNoTime dice:

      El chip Broadcom no se produce específicamente para Raspberry Pi. Todavía es un producto actual, por lo que no está obsoleto. El resto de tu escándalo es difícil de descifrar.

  • Genki dice:

    Recuerdo el comando POKE mortal para Commodore PET. Los primeros piratas informáticos encontraron una manera de acelerar ligeramente el PET mediante un comando POKE. Sin embargo, cuando CBM lanzó PET reestructurados más tarde con mayor memoria, pantalla más grande, etc., el uso del mismo comando POKE podría causar daños graves.

  • tz dice:

    El antiguo 6809 (tandy / RS Color Computer) tenía una instrucción que hacía que el chip entrara en un bucle y se calentara y se derritiera.

    • wren6991 dice:

      Creo que “detente y dispara” proviene de los días de la memoria central. Algunas CPU (o sus ensambladores) realizaron un apagado como un salto a la autoinstrucción. El acceso repetido a los mismos núcleos magnéticos, que implica girarlos hacia adelante y hacia atrás a través de su circuito histérico, disipa una cantidad significativa de energía y los núcleos pueden comenzar a fumar cuando la CPU se detiene.

      • John U dice:

        ISTR era en realidad una CPU específica para militares que tenía un código operativo de autodestrucción específico para la seguridad, incluso puede haber aparecido en HaD. Una gran cantidad de equipo militar tiene autodestrucción incorporada y hay entrenamiento militar sobre cómo destruir tus cosas si el enemigo se acerca demasiado.

        • GotNoTime dice:

          A los equipos militares sensibles se les daba una manta de termitas, que se arrojaba encima y se le prendía fuego. Más tarde sería un charco de metal fundido.

          Algunos equipos comerciales tienen autodestrucción, pero generalmente se trata de borrar la memoria de las criptomonedas si maneja mal el gabinete o la CPU. Los obtendría en cosas como los HSM utilizados para la gestión de cifrado en los bancos.

          • fajensen dice:

            Trabajé con una radio militar. Estas unidades venían con un martillo, una púa de titanio y un área marcada en el gabinete donde al aplicar el martillo a la púa, como se documenta en el manual, se colocaría un orificio de tamaños cuidadosamente especificados a través de la trituradora criptográfica dentro de la caja.

            Apuesto a que “Mr. Hammer & The Spike” también cuesta al menos 5000 EUR. Tenía un conjunto bastante completo de documentos sobre preguntas y respuestas.

    • Alan McCormick dice:

      La CPU 6502/6510 tenía un error en el que algunos códigos de operación no oficiales enviaban la CPU a una condición de crack / bucle. Creo que fue el código de operación 02h, pero un reinicio externo reiniciaría el sistema sin afectar a la mayoría de las direcciones de memoria. La página cero / pila / etc, por supuesto, estaría vacía. Se usaba principalmente en esquemas de protección cuando fallaba el control de protección y querían bloquear el sistema.

    • cbob dice:

      Creo que hubo un problema similar con la ZX81. La idiotez accidental de mi parte parece causar los pequeños problemas de memoria del abejorro que terminaron sus días como mi primera computadora.

      • Greenaum dice:

        Honestamente, probablemente no fuiste tú. El paquete de RAM externo de 16K de la ZX81 era bien conocido. Las soluciones incluían parches de velcro para evitar que se balanceara en el conector de borde de la máquina, para colocar medio litro de leche al lado para evitar el sobrecalentamiento.

        Sinclair era un genio en miniaturización y barato. Fiabilidad, no tanto.

  • Búfalo dice:

    ¿Te acuerdas de esto? 🙂
    https://eo.wikipedia.org/wiki/Pentium_F00F_bug

    • Greenaum dice:

      F00FC7C8 IIRC. Qué útil cadena hexadecimal para haber grabado en la memoria de alguien.

  • Atwas911 dice:

    ¿Construido de acuerdo con la obsolescencia programada? ¿Fin de la garantía y esta instrucción se emite después de la publicación?

    • Luke Wren dice:

      Es una declaración de depuración y está * documentada ‘. OP no entendió el orden de los bytes.

  • DC (@dakotathekat) dice:

    Lo que da miedo es que obtuve un dispositivo médico en nuestra mesa de ayuda que, según los informes, tenía problemas de conectividad inalámbrica … el proveedor de mierda aparentemente revende una Raspberry Pi en funcionamiento (instalada desde Mac con NOOBS) en un contenedor barato de $ 10 y uno barato de $ 10. -fuente eléctrica. y un dongle inalámbrico duro de $ 10 pegado a un adaptador USB-Ethernet de $ 5.

    … se supone que el Pi recopila datos de un monitor de paciente y los reenvía a un programa basado en la “nube” …
    … utilizado por los anestesistas para documentar durante los casos A casos.

    Tampoco hay sellos o tornillos a prueba de manipulaciones …

    • mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm dice:

      en el espíritu de la transparencia, nombre la marca aquí si no está mintiendo.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *