DeepSeek replica el QR del gimnasio y esquiva su app

Un QR que cambia cada 15 segundos y un feed que no se puede apagar

El código QR que abre el torno de un gimnasio cambia cada 15 segundos y la app que lo genera no permite desactivar el feed social que lo rodea. Un desarrollador que llevaba más de 12 años sin usar redes sociales decidió reconstruir ese QR por su cuenta y lo consiguió: hoy entra y sale del gimnasio con una web propia, sin abrir la app.

Para cualquier founder, el caso es una clase práctica de dos cosas: cómo la IA bajó el costo de la ingeniería inversa hasta ponerla al alcance de una sola persona, y qué pasa cuando el producto que construyes obliga al usuario a consumir algo que no pidió.

Qué encontró dentro de la app

La app estaba escrita en Flutter, con la mayor parte de la lógica compilada a código nativo de Dart. Para inspeccionarla usó blutter sobre el código Dart, jadx para el lado Android y las herramientas del SDK de Android para revisar el paquete. Más tarde sumó OpenSSL y WebCrypto para validar el cifrado, y zbar para decodificar los QR de forma independiente.

El hallazgo clave: el QR no era un identificador opaco, era una URL con cuatro componentes —un handle de cuenta codificado, un timestamp de expiración cifrado, un nonce aleatorio y un checksum—. La expiración iba cifrada con AES-128-CTR y el checksum se calculaba con un secreto distinto. Con esos dos secretos, el resto era aritmética.

El primer intento fue dejar que el modelo manejara un emulador de Android para iniciar sesión y extraer las claves. La laptop de diez años que estaba usando no aguantó la emulación. La alternativa fue un teléfono rooteado conectado por ADB inalámbrico: la app registraba las peticiones y respuestas de las llamadas relevantes, y el material de las claves estaba en un archivo de log en texto plano dentro del dispositivo. El propio autor lo resume así: la mitad del proyecto fue ripgrep.

Por qué la IA cambió el cálculo

El autor trabajó con GLM 5.3 y DeepSeek v4.1 Flash. Su conclusión es concreta: GLM consumía entre 10 y 20 veces más en costo de tokens sin avanzar más rápido, mientras que DeepSeek le pareció mucho más ágil. Vale aclarar que es la experiencia de una persona en un proyecto puntual, no un benchmark.

Lo interesante no es el ranking de modelos, sino el método. El autor nunca había hecho ingeniería inversa antes y dirigía al modelo por intuición: cuando sentía que la implementación debía ser más simple de lo que el modelo proponía, se lo decía. Ese empujón humano —decirle al modelo que tenía que haber una forma más simple— fue lo que evitó que el proyecto se fuera por una tangente.

También hubo errores instructivos. La implementación de AES pasaba sus propias pruebas de ida y vuelta: cifraba, descifraba y recuperaba el input original. Pero ambas direcciones compartían el mismo error, así que la prueba no probaba nada. La comparación contra WebCrypto expuso la discrepancia, y OpenSSL con vectores de prueba conocidos lo confirmó. Otros dos tropiezos: el timestamp de expiración iba en milisegundos y no en segundos, y la codificación era base64url conservando el padding, no base64 estándar.

Con las claves extraídas construyó una app web en SvelteKit que genera los códigos localmente. El resultado, con los mismos inputs, producía una URL idéntica byte a byte a la de la app original. Al día siguiente funcionó en el torno, tanto para el check-in como para el check-out.

¿Qué significa esto para tu startup?

Tu token de acceso es tu superficie de ataque real. Si tu app es la única puerta a un servicio físico —un gimnasio, un coworking, un evento—, lo que un atacante quiere no es tu feed: es tu credencial. Y si esa credencial se puede generar sin conexión, el secreto tiene que vivir en el dispositivo, donde alguien con un teléfono rooteado puede leerlo.

Tres acciones concretas:

• Audita tus logs antes que tu código. El vector que rompió todo este caso no fue un fallo criptográfico: fue un archivo de log en texto plano con el material de las claves. Revisa qué escribe tu app en los logs del dispositivo en producción y elimina cualquier secreto, token o payload sensible.
• Prueba tu propia app con un modelo. El mismo enfoque que usó el autor —un LLM dirigiendo la inspección de un APK o de un binario— sirve como pentest interno de bajo costo. No reemplaza una auditoría seria, pero encuentra lo obvio, y lo obvio es lo que se explota.
• Haz que el feed sea opcional. El autor no era usuario objetivo del feed social, pero sí era cliente del gimnasio. Obligar a pasar por una pantalla que el usuario no pidió no aumenta el engagement: en el segmento técnico, aumenta la probabilidad de que alguien construya una alternativa y la publique.

El detalle que casi nadie hace

El autor mantuvo el gimnasio y su propia identidad en el anonimato, y no reveló cuántos días siguen siendo válidos los códigos sin conexión. Tampoco publicó las claves. Es la diferencia entre documentar una vulnerabilidad y entregar un manual de abuso: si vas a escribir sobre un fallo que encontraste, cuenta el método y protege el objetivo.

Conclusión

La historia tiene dos moralejas que se sostienen juntas. La primera es que la barrera de entrada para la ingeniería inversa se derrumbó: lo que antes requería un especialista ahora está al alcance de una persona con un modelo de lenguaje, un teléfono rooteado y bastante ripgrep. La segunda es que los dark patterns tienen costo. El autor no hackeó el gimnasio por diversión: lo hizo porque la app le exigía pasar por un feed que no podía apagar solo para entrar a levantar pesas. Cuando el producto interpone fricción innecesaria entre el usuario y su objetivo, alguien con las habilidades suficientes va a construir el atajo, y probablemente lo cuente en internet.

Nota: no se encontraron datos adicionales verificables sobre este caso en fuentes públicas; el gimnasio y el autor mantienen el anonimato.

Fuentes

• https://shayon.work/blog/reverse-engineering-gym-pass (fuente original)