Cómo verificar que un emulador es seguro antes de instalarlo

Esta guía sirve para quien va a instalar un emulador o a preparar el archivo de firmware que le pide. No convierte un .exe en algo infalible: ayuda a detenerse antes de ejecutar un archivo cuya procedencia no se puede explicar.

La razón no es teórica. El 1 de febrero de 2021, ESET documentó Operation NightScout, un ataque que comprometió el mecanismo de actualización de NoxPlayer y distribuyó tres familias de malware a víctimas seleccionadas. El caso importa porque el aviso de actualización podía aparecer al abrir el programa. No hubo que ir a una página obviamente dudosa.

También pone un límite útil a la alarma: el expediente disponible no documenta malware escondido específicamente en un núcleo de emulador ni en un archivo BIOS para emulación. Tampoco demuestra que ese riesgo haya crecido tras la retirada de Citra. La página de Citra dice que yuzu y su apoyo al proyecto se discontinuaban de inmediato y que retirarían repositorios y otros canales, pero no prueba ese aumento. La comprobación tiene que partir de lo que sí se sabe, no de ese salto.

1. Detén la descarga si no puedes nombrar su origen

Primero identifica la página exacta desde la que bajaste el instalador, el núcleo o el firmware. Si llegaste por un acortador, un espejo o un servicio de intercambio de archivos, no sigas con la instalación hasta encontrar la publicación original del proyecto. No es un prejuicio contra todo archivo compartido; es una forma de no perder la pista que después permite contrastar qué se descargó.

Hay una regla concreta en Libretro. Tras un incidente de 2023, el proyecto indicó que sus descargas confiables para Windows proceden de sus dominios buildbot o bot, y que no sube archivos a servicios de intercambio de terceros. Si el historial de descarga muestra MediaFire en vez de uno de esos orígenes, el propio aviso pide revisarlo. Ese criterio es más útil que decidir por el diseño de una página o por el número de comentarios.

No confundas «parece oficial» con «deja de requerir revisión». NightScout fue un ataque de cadena de suministro: según ESET, al detectar una versión nueva NoxPlayer ofrecía instalarla y el actualizador entregaba el malware. La investigación señaló infraestructura de BigNox comprometida y, en algunos casos, payloads adicionales desde servidores controlados por atacantes. Un dominio conocido reduce una duda; no borra todas las demás.

2. Separa el programa, el núcleo y el BIOS antes de buscar nada

Un instalador de emulador, un núcleo y un archivo BIOS no son el mismo tipo de archivo, así que no conviene tratarlos como si fueran una sola descarga. El caso de NoxPlayer afectó al actualizador del programa: Malwarebytes explicó que se manipularon Nox.exe y NoxPack.exe, y que este último era el vector de infección. No permite afirmar que todos los núcleos o BIOS escondan malware; sí obliga a revisar el ejecutable y su actualizador con la misma atención que el resto.

Con los BIOS, empieza por distinguir el archivo de emulación del firmware de la computadora. La publicación de NIST sobre modificación maliciosa del BIOS trata del BIOS o UEFI del sistema y de su posición privilegiada dentro de una PC; no habla de archivos BIOS descargados para emuladores. Usar ese documento para asustar sobre un archivo de consola sería mezclar dos problemas distintos.

Para entender por qué algunos emuladores piden ese archivo aparte, sirve esta guía sobre el BIOS en emulación. Y si la duda es qué se está copiando, no lo mismo un cartucho que un disco, está la explicación de ROM e ISO.

3. Cuando haya hash publicado, compáralo antes de usar el archivo

Un hash no sustituye el origen, pero da una comprobación concreta de la copia que ya tienes. La guía de firmware de BizHawk indica que sus BIOS no se distribuyen con BizHawk ni con su instalador de requisitos; dice que es posible volcarlos desde el propio hardware y que los hashes publicados permiten comprobar que se tiene una copia correcta. También explica que, dentro de EmuHawk, el apartado de firmware muestra información de cada entrada.

El orden práctico es simple: conserva el archivo separado, abre la lista de firmware del emulador y consulta la información o el hash que el proyecto publica para ese caso. Si no coincide, no lo arregles cambiándole el nombre ni lo pruebes «a ver si abre». Detén el proceso. Lo único que el hash permite concluir aquí es si la copia coincide con la referencia indicada, no de dónde la obtuviste ni qué hará un programa distinto al abrirla.

La parte importante es que esta verificación no exige comprar otra cosa. BizHawk plantea el volcado desde el hardware propio y la comparación con sus hashes como alternativas prácticas dentro de su documentación. Si el emulador que elegiste no publica una referencia comparable, esa ausencia no prueba que sea malicioso; sí elimina una comprobación que sí existe en el caso documentado.

4. Revisa el canal de actualización antes de aceptar su primer aviso

No instales a ciegas una actualización sólo porque apareció dentro de la aplicación. En NightScout, ESET observó tres variantes de actualización maliciosa. Una tenía capacidades de vigilancia; otra terminó desplegando Gh0st RAT con capacidades de keylogger; una tercera descargó PoisonIvy RAT desde infraestructura controlada por atacantes. Es un caso específico, no una descripción de cualquier emulador, pero basta para cambiar el hábito: un aviso interno también necesita procedencia verificable.

Después de la investigación, BigNox dijo a ESET que adoptaría HTTPS para actualizaciones, verificación de integridad mediante MD5 y comprobaciones de firmas; también dijo que NoxPlayer revisaría archivos instalados al arrancar. ESET añadió expresamente que no asumía responsabilidad por la exactitud de esas declaraciones. Por eso la lección no es «tal medida ya resolvió todo», sino verificar qué publica el proyecto y qué se puede comprobar desde fuera.

Qué no hacer

• No bajes un archivo desde un tercero cuando el propio proyecto identifica sus dominios de descarga y niega usar esos servicios.
• No uses el caso de un BIOS o UEFI de PC para afirmar que un BIOS de emulación trae el mismo riesgo.
• No presentes un hash como certificado total de seguridad: sirve para contrastar una copia con la referencia publicada.
• No supongas que el cierre de Citra convirtió cualquier descarga alternativa en malware. El expediente no sustenta esa relación.
• No aceptes una actualización sólo porque viene dentro de un emulador. NightScout demuestra que ese canal también puede ser el vector.

La mejor defensa no es buscar una lista eterna de emuladores «seguros». Es conservar una cadena corta y comprobable: origen identificado, archivo separado por tipo, hash cuando el proyecto lo publica y cautela ante cada actualización. Para el contexto de cómo se distribuyen los componentes, puede ayudar la guía de Libretro y los núcleos.