¿Qué garantiza que un juego haya pasado la revisión de Steam? Para explorar esa pregunta, BeriaLabs Games presentó un build de un juego real con un componente de acceso remoto. La revisión lo aprobó sin comunicar su detección.
La prueba quedó limitada a una beta privada, cuatro personas informadas y una máquina de laboratorio. El juego distribuido al público no incluyó el componente, según la declaración del equipo sobre sus builds. Este artículo explica qué se documentó, qué procede de su testimonio y qué no puede concluirse del caso.
Informe de investigación · Experimento controlado · septiembre–octubre de 2026
Respuesta breve. Steam realizó comprobaciones funcionales en nuestro juego. El build de prueba fue aprobado sin una detección comunicada del componente de acceso remoto y sin observaciones de red en el informe recibido. Para el usuario, «aprobado en Steam» no debe significar «binario seguro».
Un caso no revela todos los controles de Valve ni demuestra que nunca realice análisis dinámico. Sí documenta un caso en el que esos controles no impidieron la aprobación del componente.
Cómo leer la evidencia. Las capturas y los datos públicos son material documental. El recuento de cero conexiones de la sonda es testimonio del equipo: el registro se perdió al desmontar el entorno. Las conclusiones sobre lo que Valve no llegó a observar son inferencias acotadas, no hechos internos de Valve. En el correo se tapan datos personales; en la consola, los identificadores, HWID e IP están seudonimizados y el dominio aparece enmascarado.
Lo esencial del experimento
En septiembre de 2026 enviamos a Steamworks un build de ÓRBITA: Bingo roguelite con un componente basado en RustDesk. Al iniciar el juego, el agente contactaba con un servidor controlado por el equipo. Después podía recibir módulos de escritorio remoto, cámara, archivos y ejecución de comandos.
El build 25235251 fue aprobado. Valve documentó comprobaciones de funcionamiento en Windows; no comunicó una detección del componente ni incluyó resultados de red en el informe. Durante el proceso recibimos varias observaciones sobre mando, overlay y compatibilidad con Steam Deck, pero ninguna incidencia de seguridad sobre aquello que habíamos incorporado.
El hallazgo no es que Steam carezca de controles. Es que, en este caso, sus controles visibles se concentraron en publicar y hacer funcionar el juego, no en detectar el componente.
| Pregunta | Resultado del caso |
|---|---|
| ¿Se ejecutó el build de Windows? | Sí; el informe describe pruebas de funcionamiento |
| ¿Se bloqueó el componente? | No; el build fue aprobado |
| ¿El informe evaluaba la red? | No consta |
| ¿La sonda registró contactos durante la revisión? | 0, según el testimonio del equipo |
| ¿Hubo usuarios externos expuestos? | No; la distribución fue privada y controlada |
1. ¿Es seguro Steam?
Para comprar y jugar, Steam ofrece controles de publicación y compatibilidad. Como garantía antimalware, este caso no aporta una seguridad suficiente. Son dos afirmaciones distintas y conviene no mezclarlas.
| Capa | Lo observado | Qué significa para el usuario |
|---|---|---|
| Publicación | Ficha y compilación aprobadas antes del lanzamiento | Existe una revisión previa |
| Funcionamiento | Pruebas en Windows, mando y overlay; observaciones sobre Steam Deck | Hay trabajo de compatibilidad |
| Malware y red | Ninguna detección comunicada; ningún resultado de red en el informe | La aprobación no acredita que el binario sea inofensivo |
| Actualizaciones | Se publicaron numerosos builds sin otro informe de revisión documentado | No debe suponerse una revisión idéntica de cada actualización |
Nivel de seguridad demostrado por este caso: útil para validar aspectos de publicación y experiencia de juego; insuficiente para considerar la tienda una barrera antimalware. El alcance real de los controles internos de Valve sigue siendo desconocido.
2. El vehículo
El experimento utilizó un producto real: ÓRBITA: Bingo roguelite, appid 5248520, publicado por BeriaLabs Games el 14 de octubre de 2026. No se creó una ficha para la ocasión: el juego tenía historial de builds, logros, nube y actualizaciones.
El componente se limitó a la rama beta, privada y con contraseña. Los depots de venta 5248521 y 5248522 apuntaron siempre a builds sin ese componente.
5248520 aprobada en Steamworks y paquete 1815242 preparado para el lanzamiento. Captura del equipo.3. Qué viajaba dentro del build
3.1 Módulos
El binario inicial no incorporaba todas las capacidades. Una vez establecida la sesión, el operador podía solicitar:
| Módulo | Función |
|---|---|
desktop |
Visualización y control del escritorio |
cam |
Captura de cámara |
files |
Transferencia de archivos |
shell |
Ejecución de comandos |
win_build |
Build específico para la versión de Windows del equipo |
3.2 Por qué importa la ejecución
La carga se producía mediante una DLL de Steam sustituida solo en el build de prueba. El juego seguía funcionando mientras un agente independiente se instalaba en el perfil del usuario y contactaba con el relay. La configuración cifrada, las cadenas ocultas y las comprobaciones de entorno reducían las señales disponibles en el fichero.
No eran técnicas extraordinarias. Su interés aquí es práctico: revisar un archivo no equivale a observar lo que ese archivo hace después de ejecutarse.
4. La revisión
La aplicación quedó aprobada el 16-sep-2026 a las 17:19. El informe llegó el 17-sep-2026 a las 14:47 e identifica el build 25235251. Valve indicó:
«Please note this review was performed on the Windows build, and we have not reviewed or confirmed the app's functionality on Linux/SteamOS.»
El correo también describía problemas que exigen ejecutar el juego: el overlay no pausaba la partida y la desconexión del mando tampoco. La revisión incluyó, por tanto, una ejecución funcional del build de Windows. Lo que no consta es una evaluación de destinos de red, procesos hijos o módulos descargados.
Lo que sí nos pidieron varias veces: compatibilidad con Steam Deck. Fueron observaciones útiles para la experiencia de juego. El contraste fue llamativo: mucha atención al mando, al overlay y a Deck; ninguna señal sobre el componente de acceso remoto. Compatibilidad y seguridad son controles distintos.
Qué nos pidieron como entidad. En el expediente del equipo no consta una auditoría técnica de seguridad de BeriaLabs Games ni una solicitud adicional para revisar el código. Las gestiones administrativas, fiscales o de identidad del alta quedan fuera del material publicado: no afirmamos que no existan, pero tampoco equivalen a una auditoría del build.
5. El silencio y sus límites
Cada build llevaba una sonda con un destino único. En su primera ejecución debía resolver el nombre y enviar una petición HTTPS: una señal mínima para saber si ese binario había arrancado con salida de red.
Resultado declarado: cero conexiones externas durante la revisión. El registro de esa ventana no se conservó; esta cifra es testimonio del equipo, no una prueba reproducible.
El silencio admite varias explicaciones: ausencia o filtrado de red, fallo de la sonda, comprobaciones de entorno que impidieron el contacto o ausencia de ejecución de esa parte del código. Por eso no podemos afirmar que Valve carezca de análisis dinámico o que nunca inspeccione la red.
Otros límites del estudio:
- Un producto, un pipeline y un periodo concretos; no una medición estadística de Steam.
- Sin acceso a los sistemas internos ni a los criterios de Valve.
- Sin registros en crudo, binarios del componente ni hashes conservados para una revisión independiente del experimento original.
- Sin evaluar antivirus o EDR en el equipo: el experimento medía la revisión de la tienda.
La conclusión que sí sostienen los hechos es estrecha: este componente atravesó la revisión sin una detección comunicada y el informe no documentó vigilancia de red.
6. De la descarga al control remoto
Tras el lanzamiento, las cuatro personas del círculo descargaron el build privado en sus equipos. La descarga no ejecutaba el componente por sí sola: la conexión comenzaba al iniciar el juego. Después, el panel permitió solicitar los módulos previstos, incluidos escritorio y cámara, dentro de aquella ventana autorizada.
| Corte de datos | Pares | Sesiones | Módulos | Eventos |
|---|---|---|---|---|
| 2026-10-14 22:41:52 | 5 | 6 | 16 | 40 |
Los cinco pares fueron los cuatro equipos de las personas participantes y WIN10-LAB, la máquina de laboratorio. La ventana de eventos mostrada va de 2026-10-14 18:12:40 a 2026-10-14 22:41:52; no debe confundirse con las diez horas de disponibilidad de la rama.
WIN10-LAB con el módulo desktop activo durante el experimento. El laboratorio registró una sesión y una vista de escritorio; no solicitó los módulos files ni shell. Captura del equipo sobre su propia consola y máquina.
WIN10-LAB, con Windows 10 y el reloj en la ventana del caso: 14-oct-2026, 22:28. Corresponde al escritorio visible en la figura 6. La imagen documenta el entorno; no muestra por sí sola la ejecución del componente.7. Nadie fuera del círculo
Ningún usuario externo al equipo de investigación fue dañado. Las condiciones del experimento lo delimitaron desde el principio:
| Medida | Aplicación |
|---|---|
| Acceso | Rama beta privada, con contraseña y códigos entregados solo al círculo |
| Participantes | Cuatro personas informadas, sus cuatro equipos y una máquina de laboratorio |
| Duración | Diez horas desde el lanzamiento hasta la sustitución del build |
| Versión pública | Los depots de venta no incluyeron el componente |
| Cierre | Relay apagado y registros en crudo destruidos al desmontar el entorno |
| Publicación | Identificadores seudonimizados, datos personales tapados e infraestructura enmascarada |
Las cuatro personas conocían el alcance, los módulos y la duración antes de instalar. Según el expediente del equipo, el aviso a Valve se envió antes de publicar el informe; a fecha de esta versión no consta respuesta.
8. Qué hace falta
Para Valve
- Ejecutar los builds nuevos o modificados en un entorno aislado con red monitorizada y registrar procesos, destinos y descargas posteriores.
- Comparar los cambios binarios entre actualizaciones y no tratar la primera aprobación como suficiente para toda la vida del producto.
- Publicar el alcance de la revisión: qué se ejecuta, durante cuánto tiempo, con qué red y qué queda fuera.
Para quien juega
- No interpretar «disponible en Steam» como una garantía de seguridad.
- Mantener sistema, cliente y protección del equipo actualizados; usar una cuenta sin privilegios de administrador para jugar.
- Desconfiar de comportamientos inesperados y de cualquier ejecutable que llegue fuera del canal oficial.
La idea final es sencilla: Steam aporta distribución y controles de funcionamiento. En el caso documentado, eso no bastó para detectar un componente que no debería haber llegado a aprobarse.
Anexo A. Cronología
| Fecha | Hecho |
|---|---|
| 30-jun-2026 | Cuenta de Steamworks creada |
| 16-sep-2026 17:19 | Aplicación aprobada para lanzamiento |
| 17-sep-2026 14:47 | Informe de revisión del build 25235251 (Windows) |
| 14-oct-2026 16:01 | Build de venta 25946347 (4.9.30) |
| 14-oct-2026 17:40 | Lanzamiento de ÓRBITA: Bingo roguelite |
| 14-oct-2026 18:12–22:41 | Eventos del círculo: 5 pares, 6 sesiones y 16 módulos |
| 15-oct-2026 03:40 | Build público 25957436 (4.9.31); fin de la ventana de diez horas y apagado del relay |
Anexo B. Indicadores
| Indicador | Valor |
|---|---|
| Dominio del relay | ████.es (no publicado) |
| Ruta de módulos | No publicada |
| Familia | RustDesk modificado, primera etapa |
| Módulos de segunda etapa | desktop, cam, files, shell, win_build |
| Hash del build con el componente | No conservado |
| Hash del build público | No conservado |
Anexo C. Campos del panel
| Campo | Origen |
|---|---|
rustdesk_id |
Registro del peer en hbbs |
host |
Nombre de equipo anunciado en el handshake |
ip |
Conexión del peer |
city / country |
Ubicación resuelta por el relay |
first_seen / last_seen |
Registro del peer en hbbs |
os |
Handshake del cliente |
hwid |
Identificador de máquina del cliente |
modules |
Peticiones de módulo al relay |
session_seconds |
Intervalo entre la primera y la última señal; no equivale a conexión continua |
downlink_kbps |
Caudal medio asociado a ese intervalo |
events |
Registro del panel |
Anexo D. Señales para defensores
Son señales para investigar, no pruebas suficientes por sí solas:
- Proceso hijo inesperado: un juego que inicia otro ejecutable desde el perfil del usuario.
- Red al arrancar: una conexión hacia un destino que el juego no necesita.
- Archivos posteriores: módulos que aparecen después de la instalación y del primer contacto.
- Divergencia: el proceso del juego habla con Steam mientras su proceso hijo habla con otra infraestructura.
La defensa útil correlaciona proceso, persistencia, archivos y red; no depende solo del nombre o la firma del fichero inicial.
Anexo E. Verificación independiente
El material permite comprobar el contexto y parte del recorrido, no reproducir todo el experimento.
| Comprobación | Qué permite verificar | Límite |
|---|---|---|
Ficha del appid 5248520 |
Existencia del producto, editor y fecha pública | No revela el contenido de los builds |
| Captura de Steamworks | Aplicación, paquete y estados de aprobación visibles | No describe las pruebas técnicas realizadas |
| Figura 4 y correo archivado | Existencia del informe y texto de su parte visible; el equipo conserva el original | La figura no muestra el mensaje completo y el original no se publica |
| Historial de compilaciones | Buildid, ramas y fechas de la línea pública | No demuestra si cada build fue revisado ni qué contenía la rama privada |
Manifiestos de 5248521 y 5248522 |
Archivos y hashes publicados en los depots de venta | No determinan por sí solos si un binario desconocido es malicioso |
node vm/auditar-panel.js |
Coherencia interna de los datos publicados del panel | No acredita de forma independiente los eventos originales |
No pueden verificarse de forma independiente con este material: el recuento de cero conexiones, el contenido completo del correo, los builds privados ni la ejecución original de los módulos. Tampoco puede repetirse una comparación contra el build con el componente porque su binario y su hash no se conservaron.
La separación de la versión pública es una declaración del equipo sobre los builds que preparó y distribuyó; los manifiestos públicos permiten inspeccionar esos depots, pero no sustituyen la evidencia que no se conservó de la rama privada.
BeriaLabs Games · contacto@berialabs.com
Fuentes y documentación
- Ficha pública de ORBIT: Bingo Roguelite en Steam: producto, editor y fecha de lanzamiento. La ficha pública no acredita el contenido del build privado.
- Proceso de revisión publicado por Steamworks: documentación del proceso, sin acceso a los controles internos de Valve.
- Las siete figuras proceden del material de BeriaLabs Games. Las limitaciones de verificación independiente están detalladas en el Anexo E.