En la jerga informática , un toque asesino es un método para inducir daños físicos en el hardware de una máquina o sus periféricos mediante la inserción de valores no válidos, por ejemplo, mediante el comando POKE de BASIC , en un registro de control asignado a la memoria . El término se utiliza normalmente para describir una familia de trucos bastante conocidos que pueden sobrecargar la electrónica analógica de los monitores CRT de ordenadores que carecen de comprobación de la cordura del hardware (ejemplos notables son el IBM Portable [1] y el Commodore PET ).
Las computadoras Z1 (1938) y Z3 (1941) construidas por Konrad Zuse contenían secuencias ilegales de instrucciones que dañaban el hardware si se ejecutaban por accidente. [2]
El toque asesino específico de PET está conectado a la arquitectura de los circuitos rasterizadores de video de esa máquina. En los primeros PET, escribir un cierto valor en la dirección de memoria de un cierto registro de E/S ( POKE 59458,62[3] ) hacía que la máquina pudiera mostrar texto y gráficos en la pantalla un 106% más rápido. Esto se lograba deshabilitando una protección de "esperar para imprimir en pantalla" diseñada para reducir la estática/ruido al evitar que la VRAM compartida fuera leída por la pantalla al mismo tiempo que la CPU estaba escribiendo en ella. Con esta protección deshabilitada, los gráficos podían aparecer en la pantalla el doble de rápido, pero también aparecían pequeños fragmentos de estática. A pesar de la estática, algunos juegos diseñados para los primeros PET incluyeron este toque en su código fuente para beneficiarse de los gráficos más rápidos. [1]
Cuando la gama PET fue renovada con hardware actualizado, los circuitos rasterizadores de video fueron rediseñados para funcionar a una velocidad más rápida y sin la necesidad de una protección de "esperar para imprimir". Por lo tanto, el viejo truco POKE ya no resultó en gráficos más rápidos. En cambio, realizar el viejo truco en el nuevo hardware provocó un comportamiento extraño en el nuevo chip de video, que podría causar contención de señal y posiblemente dañar el monitor CRT integrado del PET . [4] Esto se debe a que el pin exacto al que apuntaba el comando POKE solía controlar la sincronización de la pantalla, pero en el chip de video actualizado, ese pin controlaba la sincronización vertical. Por lo tanto, ejecutar el POKE en el hardware más nuevo provocó que los gráficos se comprimieran verticalmente, a veces hasta una línea horizontal extremadamente brillante. Los temores de que esta anomalía pudiera quemarse en la pantalla llevaron al apodo de "poke asesino"; [3] sin embargo, no se sabe que haya causado algún daño permanente al monitor. [5]
El Commodore 64 tenía una unidad de disquete externa opcional de 5-1/4". El Commodore 1541 contenía un microprocesador 6502 que se utilizaba para ejecutar Commodore DOS y también para gestionar el mecanismo de la unidad. Las unidades almacenaban datos en 35 pistas (#0–34), y el motor paso a paso podía controlarse manualmente a través de BASIC mediante comandos PRINT# "MEMORY-WRITE" a la unidad (que corresponden al comando POKE de BASIC, pero escriben en la memoria interna de la unidad y los registros de E/S, no en los de la computadora en sí). Si la unidad estaba en cualquiera de los extremos de su rango (pista 0 o pista 39) y se le ordenaba que continuara moviéndose, no había ningún método de software o firmware para evitar daños en la unidad. El "golpe" continuo del cabezal de la unidad contra el tope desalineaba el mecanismo. El problema se vio agravado por las técnicas de protección de copia que utilizaban formatos de disco no estándar con recuentos de pistas inusuales. El Commodore 1571 tenía un tope de cabezal óptico . En lugar de uno mecánico.
Las TRS-80 y TRS-80 Model III originales tenían la capacidad de cambiar entre una pantalla de 32 caracteres de ancho y una pantalla de 64 caracteres. Al hacerlo, se activaba un relé en el hardware de video, lo que se lograba escribiendo en un registro de control específico asignado a la memoria. [6] Los programas que cambiaban repetidamente entre los modos de 32 y 64 caracteres a alta velocidad (ya sea a propósito o accidentalmente) podían dañar permanentemente el hardware de video. [ cita requerida ] Si bien este no es un "golpe asesino" único, demuestra un modo de falla de software que podría dañar permanentemente el hardware.
El modelo I TRS-80 también tiene un relé de motor de casete similar al que se puede acceder a través de un comando de memoria y que podría dañar el relé.
Algunos modelos de unidades de CD-ROM de LG con firmware específico utilizaban un comando anormal para "actualizar firmware": el comando "borrar búfer" que se utiliza habitualmente en las unidades de CD-RW. Linux utiliza este comando para diferenciar entre unidades de CD-ROM y de CD-RW. La mayoría de las unidades de CD-ROM devuelven un error de forma fiable para el comando CD-RW no compatible, pero las unidades defectuosas lo interpretan como "actualizar firmware", lo que hace que dejen de funcionar (o, en el lenguaje informal, que se " bloqueen "). [7]
Los recursos de la memoria flash son grandes, pero limitados. Dado que escribir en el almacenamiento es una operación esencial, la mayoría de las aplicaciones tienen suficientes privilegios para agotar los recursos de los chips flash en 24 horas, llenando el almacenamiento lo suficiente como para provocar una amplificación de la escritura y reescribiendo continuamente un archivo pequeño. [8]
Systemd monta las variables utilizadas por la Interfaz de Firmware Extensible Unificada en el sistema sysfs de Linux como escribibles por el usuario root de un sistema. Como resultado, es posible que el usuario root de un sistema bloquee por completo un sistema con una implementación UEFI no conforme (específicamente algunas laptops MSi ) usando el comando para eliminar el directorio o eliminar recursivamente el directorio raíz . [9] [ se necesita una mejor fuente ]rm/sys/firmware/efi/efivars/
Hay muchos detalles que el ingeniero que diseña el "microprograma" debe tener en cuenta, de lo contrario los cortocircuitos pueden destruir el hardware. El
Z1
con su diseño mecánico era aún más sensible en este aspecto que el
Z3
. Incluso después de completarlo, había secuencias de instrucciones que el programador tenía que evitar para no dañar el hardware. Una de estas secuencias fue probada inadvertidamente en el
Museo de Tecnología y Transporte de Berlín
, lo que provocó daños leves en el Z1 reconstruido en 1994.(12 páginas)