Ejecutando un comando que puede destrozar un ordenador Spectrum de los ochenta
HTML-код
- Опубликовано: 5 фев 2025
- A finales de los años ochenta del siglo pasado, fue publicado en medios especializados unos comandos en lenguaje BASIC que se afirmaba que podían acabar con el hardware de un Inves Spectrum+ basado en el Zilog Z80.
#inves #investronica #randomize #retro #ordenadores #8bits #historia
Enlace a publicación original:
parceladigital...
10:50 Un software si puede dañar hardware, por ejemplo los que hacen algunos virus informáticos, el virus en un software, y el daño al final es en el hardware, aunque técnicamente hablando el daño no es hecho "directamente" por el software, de todas formas es consecuencia del software ejecutado. El virus puede usar el mismo hardware para dañar al hardware. Por ejemplo se podría crear un programa malicioso que mueva de forma descontrolada el cabezal de lector de discos de un disco duro haciendo que se raye y se produzcan daños físicos irrecuperables en la superficie de los discos que normalmente guardan información
Para que un virus pudiera rayar el disco, tendría que dar ordenes directas a los circuitos qué controlan a la cabeza del disco, cosa que ni el sistema operativo puede hacer, este se comunica a través de un protocolo, cada fabricante lo hace de manera diferente y además entre varios modelos del mismo fabricante puede variar. Además ni el fabricante pudiera hacer qué se raye la superficie del disco, la cabeza no toca al disco, una fina capa de aire las separa. Los virus nunca han dañado al hardware, lo más que pudieron hacer, fue borrar el contenido de la memoria flash bios, pero con volver a programarla, la computadora vuelve a funcionar
En 40 años que llevo entre ordenadores, todavía no he visto ningún software que haya provocado un daño de hardware irreparable. Puede provocar cosas que "parecen" daños de hardware, pero al final son de software, y reparables.
@@parceladigital Bueno, para muestra un botón: El Caso de un ataque a una planta nuclear en Irán el 2010 por el virus Stuxnet (Stuxnet es un gusano informático avanzado diseñado específicamente para sabotear sistemas industriales, y se cree que fue desarrollado por Estados Unidos e Israel.) y solo para resumir diremos los efectos y consecuencias del ataque. EFECTOS: Modificaba el funcionamiento de las centrifugadoras de uranio, aumentando o disminuyendo su velocidad de manera anómala y dañándolas FISICAMENTE. Simultáneamente, el malware enviaba señales falsas a los operadores, mostrándoles que todo estaba funcionando correctamente.
Este sabotaje resultó en la destrucción de aproximadamente 1,000 centrifugadoras. CONSECUENCIAS: Retrasó el programa nuclear iraní por meses o años. Marcó un precedente en el uso de malware como arma de guerra cibernética. Puso de relieve las vulnerabilidades de los sistemas SCADA (Control de Supervisión y Adquisición de Datos) en infraestructuras críticas.
Aunque de momento es el único confirmado y ampliamente documentado del que tengo conocimiento, pero, basta que haya 1 solo caso confirmado para que se pueda decir con seguridad que siempre habrá una posibilidad potencial de que un ataque por software termine haciendo un daño físico al hacer que el hardware trabaje por ejemplo, fuera de sus limites de seguridad o haciendo cosas que no debería pero que potencialmente puede hacer, como el caso de dañar discos duros que mencione al inicio.
Ahora cuando hablamos técnicamente de algo irreparable nos referimos a que se dañe y quede inutilizable, pero eventualmente cualquier cosa puede ser reparada o por ultimo reemplazada, pero el daño igual fue hecho porque, sea como sea, logro su fin, que por lo general es parar o ralentizar algo o hacer que algo tenga un sobre costo para la victima de alguna forma, si se logra eso, se habrá cumplido el objetivo, aun cuando la victima posteriormente repare o reemplace el hardware dañado.
Para ampliar, fue en el apartado consultorio , aquí está el extracto:
"Aprovechamos para avisar a los
usuarios del Inves, que nos ha lle-
gado el rumor de que haciendo:
BORDER5
RANDOMIZE USR 4665
se avería el ordenador. No hemos
tenido aún ocasión de comprobar-
lo (de funcionar, supondría cargar-
se un ordenador) pero esperamos
poderlo verificar en un futuro. En
una ocasión dijimos que era impo-
sible averiar un ordenador desde el
teclado; bien, ésta sería la excep-
ción que confirma la regla. "
Gracias por la aportación.
No os molestéis. No se estropea. Debido al diseño de hardware de Investrónica, hacer POKEs a ciretas direcciones de la ROM sirve para cargar una máscara AND que filtra el bus de datos de la ULA. El efecto de POKEar un valor incorrecto es que los periféricos dejan de funconar bien y la pantalla también. Y al ser algo de nivel hardware, reseteando por software o con el botón no se soluciona. De ahí nace el bulo, o la confusión. Pero no se produce ningún daño permanente, con cortar la alimentación y volver a enceder es suficiente. El RAND USR del ejemplo en realidad no hace nada más que llamar a la ROM a un sitio incorrecto, que acaba derivando en un POKE de estos.
Está claro que es difícil que produzca un fallo de hardware, pero está bien recuperar estás leyendas urbanas del pasado. En el emulador sale lo que sale seguramente por lo que dices, porque en esa dirección no hay nada, y el sistema se vuelve inestable. Gracias por tu detallada explicación.
La instrucción en ROM debería afectar algo programado en EPROM, clavado una impresora ,borrado algo en un medio físico pero no veo cómo se tomó cómo válido el mito de una destrucción de hardware. Bueno,esa fue una romántica era oscura que recuerdo con nostalgia
Totalmente de acuerdo. Para mí esto es como cuando se prueban fármacos en mamíferos roedores antes que en humanos, porque van a haber resultados análogos. Muy bueno el vídeo.
Gracias por tu comentario.
Qué video tan fascinante, se qué es dificil pero estaria muy interesante correlo en hardware real o ver tras bambalinas algo mas.🖥️🙂↕️
Es dificil conseguir un Inves Spectrum+, se crearon y se vendieron en España y no hay muchos. No obstante, en el emulador ya se ve que algo pasa con esos comandos, que el ordenador se bloquea... de ahí a que eso provoque un fallo de hardware, ya es otra historia. Gracias por tu comentario.
@@parceladigital Y si se ejecuta en otro emulador... qué ocurre?
No es que haya buscado muy a fondo, pero de momento no encontré otro emulador. Es importante recordar que se debe emular la ROM de un Inves Spectrum+, no valen otros emuladores de los Spectrum de Sinclair. Al final era un clon español, creado por una empresa española, y que solo se vendió en España.
Yo tuve el Spectrum +2 (el gris) y por aquella época leí de Randomize USR que jodian el Spectrum.
La prueba que has echo es válida porque necesitas un software para jodet el hardware (no se puede meter la instrucción directamente al hardware, necesitas sí o sí un software).
Gracias por tu comentario.
Buenos días. Fui usuario del Spectrum en los años 80. Empecé con uno de 16 Kb que más tarde amplié a 48 Kb. Y, efectivamente, me enteré de cuanto explicas. No recuerdo si leyéndolo en la revista Microhoby o del programa (excelente programa) de radio "Sábado Chip".
Al mítico programa "Sábado Chip" le dediqué un artículo de texto en ParcelaDigital hace unos años. Gracias por tu comentario.
Yo se que la ULA del spectrum era programable, no sé si quizá con BORDER 5 y RANDOMIZE habilita la escritura a la ULA y se ejecuta una rutina en ensamblador en la dirección 4665 que ecribe algo incorrecto en dicha ULA y hace que quede completamente inservible.
O sobrecargue electricamente a la ULA y haga que ciertas puertas se quemen... el Spectrum era un ordenador artesanal y tenía fallos de ese tipo. Ese ordenador Inves no era completamente compatible con el Spectrum.
El ordenador Inves, independientemente de que fuera más o menos compatible con los Spectrum originales, adolecía de algunos fallos en el funcionamiento. Gracias por tu comentario.
Siempre ha existido el mito del software malintencionado que logra dañar el hardware. No sé si sea posible pero en los años que llevo en esto, solo me ha tocado escuchar la leyenda pero nunca ver nada concreto
Saludos desde México
Saludos para México desde España.
Intenta actulizar cualquier firmware por una versión incorrecta o interrumpiendo el proceso y veras si no te quedas sin hardware.
El virus Chernobyl arruinaba el hardware borrando la memoria ROM.
Pero con volver a escribir en la memoria su contenido original, esta volvía a funcionar, no era un daño permanente
Hay que partir del hecho de que hay ROM, y hay Flash ROM. Una ROM de siempre, no es modificable por software. Una flash ROM sí es modificable por software, para poder ser actualizada. Pero igual que te la modifica un virus, también puedes volver a modificarla de nuevo para restablecer lo que tenía. El fallo del Chernobyl puede "parecer" un daño de hardware, pero al final sigue siendo un daño de software.
@@parceladigital En esa época no había medios para reestablecer el software en la ROM, tenias que cambiar la placa entera. Lo mismo con algunos firmwares.
creo que en el modelo de 48k, hacias un randomize usr 16384 y te daba en audio el sistema operativo, en los emuladores no funciona, saludos
Gracias por tu aportación.