Test de detección de emuladores.

[mcleod_ideafix]

La pregunta es: ¿cómo puede un programa "darse cuenta" de que está siendo ejecutado en un emulador de Spectrum 48K y no en la máquina real?

He visto algún que otro test al respecto: algunos se basan en el comportamiento del bit 6 de EAR, otros, en el famoso IN 255, y otros, en la temporización de un programa que se ejecuta en memoria contenida. Poco a poco, los emuladores han ido perfeccionándose de tal forma que estos tests no detectan la presencia de emuladores tales como Spectaculator, RealSpec y algún otro...

En un post del área de Hardware en el que hago experimentos con la memoria, he dado con un sistema, que seguro que se habrá mencionado aquí, o en ECSS o en CSS. No he visto nada al respecto. Sea como fuere, allá va.

Si cargais este TAP en un Spectrum 48K "de verdad", detectará que efectivamente es un Spectrum de verdad. Si por el contrario, lo usáis en un emulador, os lo dirá.
No sé si sirve para detectar emuladores de 128K,+2 y similares. Sólo garantizo la detección en un Spectrum 48K (gomas o Plus, da igual).

DESCARGAR TEST

El principio de funcionamiento:

Se basa en que los 32K superiores de RAM son refrescados por el propio Z80A. Para ello, se usa el registro R como contador de filas de la DRAM. Este registro se puede forzar a un valor usando LD R,A.

Pues bien, la cosa consiste en rellenar los 32K superiores con un patrón de bits (10101010). Luego, entramos a un bucle que dura bastante tiempo (unos 10 segundos), en el que basicamente, estamos ejecutando LD R,A todo el tiempo, con A=0. Esto hace que sólo se refresquen las primeras 8-10 filas (R se incrementa en cada instrucción, así que cuando el bucle llega a la parte en la que hay que ver si hemos llegado al límite de cuentas y se vuelve a ejecutar, R ha llegado a vaer 8 o 10 por las instrucciones ejecutadas).

Se deben refrescar 128 filas, y si ese refresco no llega en pocos milisegundos, las filas no refrescadas comienzan a perder su contenido (algunos 1's se convierten a 0 y viceversa).

Al terminar el bucle, se comprueban los 32K superiores para ver si en todas las posiciones continúa estando el patrón: si es así, significa que la memoria ha conservado su contenido incluso después de haber estado 10 segundos sin refrescar: eso no es posible en un Spectrum real de 48K, sin modificaciones en el hardware, así que se deduce que estamos ante un emulador, o bien un modelo de Spectrum modificado. Si en cambio existe alguna posición de memoria de esos 32K que no ha conservado el patrón, no cabe duda que estamos ante un genuino Spectrum 48K (o un emulador realmente fiel en el comportamiento de la máquina).

¿Existe algún emulador hoy día que sea capaz de pasar este test?

[Gandulf]

Yo casi aseguraría que no hay emuladores que emulen el refresco de memoria. El problema que le veo a este test es el tiempo que necesita para que la ram pierda su contenido, que lo hace poco viable para su uso en juegos y/o aplicaciones. Pero la idea es muy buena, ya que podría impedir el uso de un juego en un emulador (siempre que el usuario no sepa ensamblador y anule el código). Si el test se pudiera hacer en 3 o 4 segundos sería la leche.

[Metalbrain]

Yo diría que el principal problema es que no funcione en 128k. ¿Para que sirve un juego que te obliga a ser jugado solo en un Spectrum de 48k? Y otra cosa es que hay que cargarse el contenido de parte de la memoria para que funcione, lo que obliga a no tener nada importante en esa zona, así que tiene que hacerse antes de cargar todo el juego, o este tiene que caber en un espacio más pequeño.

Un test posiblemente más rápido y compatible sería usando el registro oculto MEMPTR, que hasta ahora no está emulado que yo sepa, pero siempre es posible que lo emulen en un futuro (al igual que el refresco de memoria, aunque el refresco lo veo más dificil, ya que su emulación consumiría una cantidad enorme de tiempo, para no obtener ninguna ventaja práctica. El registro MEMPTR también consumiría tiempo para su emulación, pero no tanto).

[Gandulf]

Joer, es la primera vez que escucho hablar del memptr este. Me leeré con más calma ese hilo, porque en una lectura rápida (y poco precisa) no he visto los opcodes para poder usar este registro, aunque seguro que sí están pero se me han pasado en la visita a vuelo de pájaro.

Puede tener coña para por ejemplo poner un extra o un final alternativo en los spectrum reales.

[mcleod_ideafix]

Yo diría que el principal problema es que no funcione en 128k. ¿Para que sirve un juego que te obliga a ser jugado solo en un Spectrum de 48k? Y otra cosa es que hay que cargarse el contenido de parte de la memoria para que funcione, lo que obliga a no tener nada importante en esa zona, así que tiene que hacerse antes de cargar todo el juego, o este tiene que caber en un espacio más pequeño.

Bueno... yo nunca he insinuado que este test sea para usarse dentro de un juego... sólo es un divertimento que puede servir quizás para medir cuán fiel es un emulador o un clon del Spectrum al modelo original.
Por otra parte, no es necesario rellenar con un patrón toda la memoria superior. Si se quiere usar esto como bloqueo para ejecutar o no un juego (claro que sólo valdría para prevenir la ejecución de un juego en un Spectrum real, y sólo permitirlo en uno emulado... algo raro...), hay otra opción: al ensamblar el código del jeugo, se hace un checksum de los 32K superiores. Se lanza la rutina de test (que está en los primeros 16K de RAM), pero sólo la parte que fuerza el refresco, y al final se comprueba el checksum de la memoria superior con el que tendría que ser. Si no coinciden, es un Spectrum real.

Un test posiblemente más rápido y compatible sería usando el registro oculto MEMPTR, que hasta ahora no está emulado que yo sepa, pero siempre es posible que lo emulen en un futuro (al igual que el refresco de memoria, aunque el refresco lo veo más dificil, ya que su emulación consumiría una cantidad enorme de tiempo, para no obtener ninguna ventaja práctica. El registro MEMPTR también consumiría tiempo para su emulación, pero no tanto).

Anda, pues éste no lo conocía. De todas formas, ya te digo: esto es sólo un efecto lateral de otras cosas que estoy haciendo y lo posteo por si algún emulador que yo no conozca sea tan fino como para haber emulado incluso este comportamiento. No pasa de ser una mera curiosidad...

[Bubu]

Info sobre el MEMPTR ese: aquí

[mcleod_ideafix]

Sí... es el mismo enlace de dos posts más arriba

[Bubu]

Era por si no te habías enterado, jijijiji (qué huevos tengo, a estas horas...)

[decicoder]

ya que podría impedir el uso de un juego en un emulador (siempre que el usuario no sepa ensamblador y anule el código).

Otro método , para el caso de que el juego se carge de cinta, sería analizar en un punto de la carga un tuno puro midiendo semiciclos positivos y negativos.

En un emulador la medida de unos y otros va a ser la misma con muy poca tolerancia. En un real varía más. No es tan fiable como el metodo de la RAM no refrescada pero puede valer.
Otro podría ser medir "ruido" en la entrada EAR. en un emulador nunca habrá ruido. En un spectrum real puede haber transiciones de 0 a 1 a 0 en EAR cuando no hay señal.

[Gandulf]

Pues la verdad es que me parece realmente interesante esto de detectar un emulador de spectrum. Veo que hay unas cuantas formas.

Otra duda, ¿detectado un emulador corriendo, se podría meter un código de la forma que provocara un error en el emulador y ejecución de código PC? Yo creo que estudiando los fallos de código de los emuladores sí podría hacerse, y no os quiero decir nada en aquellos en que están disponibles los fuentes. De todas formas es probable que ninguno tenga un error de ese tipo.

[sromero]

Pues la verdad es que me parece realmente interesante esto de detectar un emulador de spectrum. Veo que hay unas cuantas formas.

Otra duda, ¿detectado un emulador corriendo, se podría meter un código de la forma que provocara un error en el emulador y ejecución de código PC? Yo creo que estudiando los fallos de código de los emuladores sí podría hacerse, y no os quiero decir nada en aquellos en que están disponibles los fuentes. De todas formas es probable que ninguno tenga un error de ese tipo.

Ya tendrían que estar mal programados, ya ... normalmente eso sólo lo podrás conseguir con el tratamiento de cadenas, y en un emulador creo que hay pocas "partes" de la emulación que se traten como cadenas. Sólo se me ocurre tirar por la parte del TAP / TZX corrupto, más que por un código Z80 específico.

Además en Linux con selinux o stackguard o efence activados (el primero en el S.O. y los otros 2 al compilar la aplicación) eso no llevaría a nada. En Windows Vista creo que ya tampoco (en anteriores sí).

Creo que lo que planteas es mucho más complicado de conseguir que todo lo que estabáis hablando hasta ahora...

Lo de la RAM que no se refresca ... ¿no es posible que se haya comentado incluso en alguna MH o en algún foro hace ya mucho tiempo? Recuerdo haber tecleado un loop así hace años

[Gandulf]

Sí, por ejemplo tratando un TZX, un DSK y formatos de ese tipo podría haber errores en el tratamiento de buffers o cadenas. Pero vamos, ya sería un poco paranoico el asunto.

Yo no recuerdo haber visto nada con respecto a provocar la falta de refresco de RAM, al menos en la MH,pero puede ser que se haya tratado en otros sitios.

[sromero]

Yo no recuerdo haber visto nada con respecto a provocar la falta de refresco de RAM, al menos en la MH,pero puede ser que se haya tratado en otros sitios.

Me suena de algún tutorial sobre programación de emuladores o de hardware, para demostrar cómo funcionaba la RAM ...

[decicoder]

¿detectado un emulador corriendo, se podría meter un código de la forma que provocara un error en el emulador y ejecución de código PC?

Un filón pueden ser las instrucciones no documentadas.
En algunos emuladores de Amstrad la instrucción in f, (c) tiene un bug. Con eso una rutina podría funcionar en una maquina real pero en un emulador no. Los emuladores de espectrum que he probado no tienen ese problema.

[Bubu]

Vaya, te gusta a ti lo de in f, (c), jiji, lo tienes hasta en la firma... Por cierto, ¿qué es tu firma?