¿Puede el software dañar el hardware?

Mi ejemplo es mucho más mundano que la mayoría de los otros aquí, pero supongo que así es con la mayoría de los problemas técnicos. La mayoría de ellos son molestos, no catastróficos.

A principios de la década de 2000, en mi segundo año con un OEM de computadora, uno de mis clientes, un distribuidor local de alimentos, se quejó amargamente de la constante falla del disco duro que experimentaba con nuestros portátiles. En ese momento, nuestra compañía tenía una de las mejores calificaciones de confiabilidad, pero su experiencia fue todo menos positiva. Hice las preguntas típicas sobre abuso y manejo rudo, pero no describió nada fuera de lo común. Harto, compró dos productos de la competencia para probar su resistencia. Efectivamente, fallaron casi al instante, mucho más rápido que el nuestro. Después de algunas discusiones significativas (los muchachos de TI lo hicieron MUCHO en esos días), nuestros ingenieros siguieron a uno de los vendedores de la compañía en sus rondas para determinar cuál podría ser el problema. Después de un par de horas, el problema quedó claro: ¡ el software desarrollado internamente estaba escribiendo datos en el disco una línea a la vez durante todo el día ! Debido a que el proceso de pedido tardó tanto en completarse, los representantes de ventas rutinariamente dejaron el disco duro golpeando mientras conducían a la próxima cita con la vibración y el movimiento del automóvil simplemente empeorando las cosas. Ese software fue un asesino del disco duro, eso es seguro. (El software revisado resolvió el problema).

Si. Algunos casos me vienen a la mente.

En los primeros días de la PC de IBM (y los clones), en algunos tipos de tarjetas de video, a través del software, era posible ajustar una de las frecuencias y dañar permanentemente el monitor conectado. Aunque no es un virus, esta técnica se consideró un ejemplo temprano de malware, casi una década antes de que se acuñara ese término.

Trabajé en la programación de un implantador de iones en una fábrica de semiconductores, y el manual de programación de esta unidad estaba lleno de advertencias graves de la forma “no envíe al dispositivo esta secuencia de bytes X, o destruirá el componente Y”. De hecho, agregué una capa de código para garantizar que ninguna de estas secuencias se envíe al dispositivo, en caso de que haya un error en otras áreas del código.

También trabajé en la programación de un brazo robótico industrial, que contenía firmware (software integrado en la memoria no volátil) que trataba cosas como calcular la distancia más corta entre la posición actual y la posición final del brazo. Un día, el fabricante “actualizó” el firmware (sin avisarme), y el brazo de repente comenzó a usar una ruta completamente diferente … en este caso, haciendo que el brazo muy pesado golpeara repetidamente una pieza de equipo de fábrica multimillonaria . Cuando presioné el botón de parada de emergencia, había una gran abolladura en el equipo.

Puede leer acerca de las computadoras antiguas y sus “golpes asesinos” (comandos que podrían dañar el hardware) aquí.

Tendré que estar en desacuerdo con mucha gente aquí. Admito que en los años 80 era posible que el software dañara el hardware, pero no hoy.

Es posible que exista un malware que pueda apagar sus ventiladores y estresar su CPU para que se sobrecaliente y se queme, pero hay dos razones por las que esto no sucederá hoy.

1. Programas de seguridad
2. Estrangulamiento térmico

Un simple Anti-Malware como MalwareFox podría detectar y eliminar dicho software malicioso, pero supongamos por un minuto que no tiene un programa de seguridad o que el software malicioso de alguna manera pasa por alto sus defensas.

Luego viene el estrangulamiento térmico. Si su CPU se calienta demasiado, disminuirá automáticamente su frecuencia para que se enfríe y no se queme. Si eso no funciona, se cerrará por completo.

Actualizar

Ayer intenté apagar los ventiladores de la CPU por mi cuenta. Arranqué en Linux, por lo que no hay programas de seguridad ni nada que me impida jugar con esas cosas.

Lo que descubrí es que el BIOS intervendría cada vez y me impediría cambiar cualquier cosa. Cada vez que establecía la velocidad de rotación en 0, oía que mis ventiladores se apagaban durante unos segundos, pero inmediatamente comenzaban a girar nuevamente.

Mi punto es que podría ser posible dañar el hardware con el software, pero hay muchas cosas que te impiden hacerlo.

2da actualización

Si aún no está claro, déjenme aclarar que solo estoy hablando de computadoras. No sé nada sobre el software / hardware de los automóviles y otras cosas similares.

Larga historia de advertencia, pero destruí el embrague en una pieza de hardware.

Hace años, los trabajos se enviaban en tarjetas perforadas. Una empresa de ingeniería en la que trabajaba acababa de implementar la arquitectura VM (Virtual Machine), pero todavía tenía los viejos procesos en su lugar mientras cambiaban las cosas.

El problema era que los operadores ejecutarían algunos trabajos colocando una baraja de cartas en el lector de tarjetas, y los ingenieros ejecutarían otros trabajos enviando tarjetas virtuales a través de punzones virtuales.

Todo esto está bien, hasta que se necesite hacer una restauración de la base de datos a un punto en el tiempo, y todos los trabajos desde ese punto en el tiempo se deben volver a ejecutar, en orden. Por lo tanto, necesitábamos una forma de capturar todos los trabajos enviados, desde lectores de tarjetas reales o virtuales, y retenerlos para su posible reutilización.

Ahora, entramos en el meollo de la E / S en un mainframe IBM 360. Hay una palabra de comando de canal (CCW) de 8 bytes que incluye el comando que debe ejecutar el dispositivo de E / S, una dirección que contiene la ubicación del búfer (entrada o salida), longitudes y varios otros bits de control. Configure un comando de lectura, dirija un búfer, describa su longitud y ejecute el CCW. Aparecerá una imagen de tarjeta perforada en el búfer.

Normalmente, no lee 1 tarjeta perforada, generalmente lee un montón de ellas, y el lector de tarjetas es totalmente capaz de leer un montón de tarjetas en un solo comando de “lectura”. Para lograr esto, establezca el bit “Encadenamiento de comandos” en la CCW y el comando “encadena” a la siguiente CCW. Por lo tanto, tiene 40 CCW seguidas, cada una de las cuales se dirige a los siguientes 80 bytes del búfer de entrada, y activa el bit CC en los primeros 39 CCW. Luego, cuando se ejecuta un Start IO contra el primer CCW, [hasta] se ejecutan los 40.

Bueno, necesitaba escribir un programa para controlar el lector de tarjetas, registrar cada trabajo y luego enviar una copia virtual del trabajo al destino adecuado.

Esto iba a ser una gran cantidad de codificación y depuración, y no podía usar el lector de tarjetas real para el desarrollo, era necesario para los trabajos de producción. Entonces, usé un lector de tarjetas virtuales para escribir el código. Si funciona con un lector virtual, debería funcionar de manera idéntica con un lector de tarjetas real, ¿verdad?

Solo había estado en la programación durante unos años, tal vez 1 o 2 años fuera de la Escuela de Comercio North Avenue, y ese encadenamiento de comandos y el manejo de la memoria intermedia parecía innecesario y confuso. Entonces, me lo salté. Se lee una CCW, una E / S, una tarjeta.

Lo tengo depurado y listo para la producción. Adjuntamos el punzón de tarjeta real a mi máquina de procesamiento de trabajo y lo encendimos.

El lector de tarjetas corrió casi a toda velocidad, pero sonaba un poco divertido. Oh bueno, todo estaba funcionando bien.

3 días después, el lector de tarjetas simplemente dejó de funcionar. Llamamos al técnico de reparación de IBM, y él retiró un gran puñado de polvo de metal que había sido el embrague en el dispositivo. Estaba muy avergonzado de que “su” hardware no pudiera iniciar E / S una tarjeta a la vez, pero sugirió que encadenara mis solicitudes de E / S.

Solo tomó alrededor de 1 hora para cambiar de un búfer CCW y uno de 80 bytes a 40 CCW y un búfer de 3.200 bytes. El lector de tarjetas fue un poco más rápido y sonó normal.

35 años después, y todavía me divierto con la virtualización.

Si y no.

Sí, porque es posible controlar el hardware con software. Esto significa que tendrá que hacer que el hardware realice una operación perjudicial.

Otras formas en que el software podría dañar el hardware son:

El BIOS parpadea . Algunas placas base le permiten modificar el BIOS. Esto abre una puerta trasera para que el malware muestre el BIOS a algo que dañará el procesador. (por ejemplo, aumentar el voltaje más allá de los límites).

En un segundo caso, algunas placas base proporcionan herramientas de overclocking que le permiten cambiar la configuración de la CPU desde el sistema operativo. Si un software malicioso se hace cargo de eso, entonces, como en el primer ejemplo, configure su CPU en una configuración que sea perjudicial y fríalo.

(Sin embargo, estas condiciones no son realistas en la mayoría de las máquinas modernas, por lo tanto, enfaticé ” potencialmente “).

Tenga en cuenta que aunque el software puede hacer que una aplicación tome el 100% de los ciclos de la CPU, causando calor si se realiza durante un período prolongado de tiempo, pero a menos que también logre dañar el BIOS, los sensores térmicos de cualquier placa base moderna la cerrarán hacia abajo antes de que alcance cualquier temperatura crítica .

El software ciertamente puede dañar el hardware, pero generalmente se agregan una serie de medidas a prueba de fallas para evitarlo.

El proverbial comando Halt and Catch Fire (HCF) se refiere a un comando ficticio de la CPU que hace que el hardware falle por completo. Por lo general, la parte de “prenderse fuego” es graciosa, ya que un restablecimiento de hardware restaurará el sistema. Sin embargo, el uso intensivo de la CPU hará que la CPU se caliente y eso podría provocar daños en ausencia de suficiente capacidad de enfriamiento.

En la medida en que las computadoras controlan las cosas, los problemas de software pueden causar grandes daños.

Algunas de las fallas de software más antiguas incluyen:

• Pérdida del orbitador climático de Marte
• Error de lanzamiento del clúster.
• Stuxnet (aunque una falla inducida, prevista)
• Aceleración involuntaria de Toyota (firmware asesino de Toyota: mal diseño y sus consecuencias)
• En Ye Olde Days, el uso de software para configurar modos de video no compatibles en algunas pantallas de tubos de rayos catódicos (CRT) mal diseñados podría dañarlos.

No se supone que el software dañe el hardware, pero, como dicen, sucede una mierda.

Hay muchos ejemplos En general, intenta diseñar hardware para que el software no pueda dañarlo, pero a veces es inevitable. Para los CCD que se utilizan en astronomía, el software controla los diversos voltajes necesarios para desconectar el detector. Si los voltajes están mal configurados, puede destruir un detector muy costoso. El movimiento excesivo puede desgastar el hardware. Intenta configurar interruptores de límite y paradas mecánicas, pero los interruptores pueden fallar y, a veces, el software es lo único que protege su hardware. A veces, la geometría es tal que no se puede proteger todo mediante interruptores de límite, por lo que, nuevamente, confía en los límites de hardware.

En los días originales de PC / AT, el adaptador de pantalla monocromo tenía un chip controlador de pantalla 6845 y gran parte de la señal que producía estaba controlada por software. Para que pueda ajustar cosas como la velocidad de escaneo.

Podría programar mal el 6845 de tal manera que manejaría algunos monitores monocromáticos lo suficientemente fuera de su rango operativo, de modo que quemarían uno de los circuitos de accionamiento en el monitor. IIRC (y ha pasado mucho tiempo), el monitor “real” IBM 5151 era susceptible a eso, pero muchos clones no lo eran.

Lo desagradable fue que hubo una falla en algunos de los primeros kits de desarrollo de OS / 2, que usaban un segundo monitor (el MDA) para el depurador, y ocasionalmente reiniciaba la pantalla y, lo adivinaste, programaron mal el 6845 en el proceso. Personalmente maté a varios monitores con esa “característica”.

Si. Accidentalmente escribí algunos. Cuando instalé la planta de circuitos impresos Austin Texas de IBM en 1980, escribí el software para controlar la placa de cobre. Esta cosa tenía cinco polipastos de 500 libras en un lado y siete en el otro. En el proceso de depuración, mi código ejecutó dos de estas cosas entre sí a toda velocidad. Se requieren algunos ‘ajustes’ del mantenimiento antes de que funcione nuevamente.

Te doy Stuxnet.

Ejemplo fascinante de malware que infecta una máquina sin red utilizada para controlar centrifugadoras en una planta nuclear.

Los rotores de la centrífuga corrían el riesgo de romperse a velocidades críticas, por lo que el malware aumentó la velocidad de “164 centrífugas o múltiplos de las mismas”, simultáneamente, a un tercio más de lo normal. Luego corrieron a casi nada, luego de nuevo a la velocidad máxima nuevamente. Por 50 minutos. Divino.

El gemelo secreto de Stuxnet

https://en.wikipedia.org/wiki/St …

¿Qué es Stuxnet, quién lo creó y cómo funciona?

Sí. El software controla el hardware, por lo que si el software pone el hardware en un estado no válido, puede destruirlo.

Uno de los principales problemas que tuve al ensamblar una impresora 3D fue cuando el software se atascó, abrió el calentador al máximo, lo que significa que, en lugar de regular una temperatura específica de alrededor de 200 ° C, el calentador se calentaría a la temperatura máxima de la que es capaz, que para el calentador de 40W estaba en el rango de 600C. A esa temperatura la cabeza de metal se derretiría. Hasta que estabilicé el software por defecto para apagar el calentador cuando el hardware no lo controla, tuve que operar la impresora 3D con un interruptor de apagado.

Otra cosa es el nuevo estándar usb-C en teléfonos. Usb C es capaz de proporcionar y recibir energía, de manera predeterminada el teléfono recibe energía, pero si configura el teléfono para enviar energía y lo conecta a una PC, puede dañar tanto el teléfono como la PC.

Seguro. El virus Stuxnet fue diseñado para dañar hardware: centrifugadoras. Escuché de un error de programación que condujo un montacargas automático a través de una pared.

Hardware de PC normal, es un poco más difícil. En la década de 1980, podría hacer que un modelo se incendiara con el programa adecuado.

Absolutamente.

Al escribir código para una computadora de nave espacial, seguimos teniendo una parte en particular muere. Era un híbrido de control de motor muy costoso ($ 25K en dólares de 1985). Y, volaríamos de 1 a 8 de ellos aproximadamente cada 2 días. Finalmente, los chicos de HW vinieron y preguntaron qué estábamos haciendo. Les mostramos, y luego dijeron: “¡Oh, no! ¡No puedes hacer eso! ¡Dañará los híbridos! ”A lo que preguntamos,“ Entonces, cuando preguntamos hace semanas, ¿hay ALGO que podamos hacer en SW o desarrollo que pueda dañar el HW, y usted dijo que no, entonces estaba mintiendo? ”. murmuraron algo sobre un componente de muestra y retención y se escabulleron.

Resulta que teníamos una solución realmente fácil en forma de un archivo de comandos para iniciar la computadora en tiempo real, luego, cuando la deteníamos, restablecía el hardware específico y protegía los híbridos. Tomó unos 10 minutos.

Nunca asumas que los chicos SW son idiotas, o no pueden dañar al HW. ¡Di la verdad! Conoce tu HW.

Sí, ahora es más difícil cuando tienes un sistema operativo real en el medio entre el usuario y el HW. Nunca asumas que no puedes hacer daño.

Google el virus Stoned de principios de los 90, así como la variante del virus 1575 llamada 1591/1592.

El virus apedreado golpearía constantemente el ensamblaje del cabezal del disco duro.

El virus 1592 afecta a una placa base del sistema Melrose 0 y reescribe el código, machacando que crees que hay un problema de hardware o un virus del sistema, pero al reescribir la BIOS, la placa madre se destruye permanentemente si la BIOS se suelda por encima de la placa madre y no se puede retirado para ser relanzado o reemplazado. A finales de los años 90, cualquier sistema que todavía estuviera en garantía y que sufriera este virus no fue aceptado bajo el soporte de la garantía. ¡Agradable!

Es tan fácil como programar un bit que tiene una señal como un bit de salida, incluso en las últimas CPU. La CPU no tiene “conocimiento inherente” de qué dirección se encuentra, incluso si solo programó un puerto paralelo programable para tener, por ejemplo, el pin 1 como entrada. Si el circuito pone 5 voltios en el pin (un valor alto, o 1), entonces el programa le dice a la CPU que programe ese bit como un pin de salida y lo eleve a 1 (5 voltios), dependiendo del chip del puerto, podría volar los transistores (dentro del chip) que manejan ese pin, haciendo que el chip del puerto sea prácticamente inútil.

El software puede conducir tarjetas gráficas para hacer cosas para las que no fueron diseñadas.

El software también puede causar condiciones de carrera de hardware, dañando el hardware.

Probablemente la IA no permitirá cosas así, pero todavía no tenemos una IA real (y no lo haremos por un tiempo).

Sí, es posible hacerlo, aunque es bastante raro.
El malware y las aplicaciones mal escritas pueden dañar el disco duro. Esto se logra evitando la seguridad al nivel de hardware. Además, la sobrescritura de valores de basura puede causar daños en los datos.
Por ejemplo, algunos virus escriben los primeros 1 millón de bloques de memoria rápidamente con basura. Dado que los primeros bloques son los que contienen su información de arranque, la corrupción aquí puede hacer que el disco duro sea inestable y, a veces, no arrancable.

Uno de mis desarrolladores pensó que había conseguido una oferta realmente buena en una tarjeta de video recientemente: un especial de “caja abierta” de un minorista local por ~ 20% de descuento en el comercio minorista.

Puede jugar su juego preferido durante 30-40 minutos antes de que se cuelgue con fuerza, lo que requiere un período de apagado y enfriamiento antes de poder usar su PC nuevamente.

Una inspección minuciosa revela que los ventiladores funcionan significativamente más lentamente que el otro y el plástico deformado y agrietado en la cubierta del disipador térmico.

Es probable que el 99% haya sido parte de la plataforma de minería criptográfica de alguien que fue devuelta al minorista cuando comenzó a ser poco confiable …

(Y Google, el minorista en retrospectiva reveló que no era el único comprador con problemas similares).

Afortunadamente, recibió un reembolso completo (después de solo una pequeña discusión y una amenaza de llamar a su compañía de tarjeta de crédito …)

Absolutamente, todo el hardware con partes móviles, por ejemplo. Las unidades con brazos de actuador, cabezales de impresión, etc. dependen del software para posicionarlas.

He visto software de utilidades que “ejercita” las unidades de disco utilizadas para sobrecalentar los dispositivos y hacer que fallen durante las pruebas.

Las impresoras de línea y las impresoras de matriz de puntos podrían convencerse de imprimir sobre las planchas de goma y aplastar los carros en el costado de los dispositivos si supiera qué hacer.

Más recientemente, las “salvaguardas” del software y el firmware más inteligente parecen haberse ocupado del software malicioso, sin embargo, estoy seguro de que se pueden anular si sabe cómo hacerlo.

Sí, en los días del 8088PC escribí un pequeño programa en lenguaje ensamblador que llenaba la pantalla con números. Finalmente descubrí la interrupción de la transmisión, lo que me permitió transmitir pantallas completas de datos. ¡Solo enviar 10 pantallas de datos haría que el monitor emitiera un fuerte crack! Aparecería un destello blanco brillante en la parte superior de la pantalla. Lo que sucedió fue que envió toda la pantalla de datos y provocó una actualización de la pantalla cuando el cañón de electrones estaba solo a una pulgada de la pantalla. Haga esto 10 veces y obtendrá una barra de luz brillante y el monitor crujirá. Póngalo en un bucle y el monitor se incendiará.