Cómo hacer ingeniería inversa de una app con Claude Code

La ingeniería inversa consiste en estudiar una pieza de software terminada para entender cómo funciona, por lo general sin tener su código fuente original ni ninguno de los documentos de diseño que se usaron para crearla. Observas qué hace, cómo está construida y con qué se comunica, y a partir de eso trabajas hacia atrás para llegar a un modelo de su comportamiento.

La gente lo hace por razones que en su mayoría son poco glamorosas y en su mayoría legítimas. Los investigadores de seguridad hacen ingeniería inversa de programas para encontrar una vulnerabilidad antes de que lo haga alguien con peores intenciones. Los desarrolladores hacen ingeniería inversa de formatos de archivo y protocolos de red para que un programa nuevo pueda interoperar con uno antiguo que nadie les va a documentar. Los archivistas y aficionados hacen ingeniería inversa de software antiguo para mantenerlo funcionando una vez que tanto el hardware original como la empresa que lo creó ya no existen. Y a veces la razón es simplemente que un programa del que dependes hace algo que no está documentado, y necesitas saber qué, antes de poder confiar en él o encontrar una forma de evitarlo.

Nada de esto es nuevo. Los investigadores de seguridad y los archivistas de software lo han hecho durante décadas con desensambladores y depuradores, mucho antes de que existiera ningún agente de IA. Lo que ha cambiado es la velocidad: un agente puede leer un listado de desensamblado o un método descompilado y resumirlo en segundos, un trabajo que antes le tomaba horas a una persona capacitada. Esa es una ganancia real de capacidad, y es precisamente por eso que el límite legal y ético que se trata más adelante en esta guía importa más ahora, no menos, ya que el cuello de botella que antes frenaba a la gente entre la curiosidad y la copia prácticamente ha desaparecido.

El resto de esta guía es específico: recorre una herramienta, llamada REA, que conecta a un agente como Claude Code con este tipo de análisis, y los hábitos que conviene tener establecidos antes de apuntarla hacia algo.

La distinción que más importa aquí es la que existe entre estudiar cómo funciona algo y copiar su expresión protegida. Hacer ingeniería inversa para aprender una interfaz, un formato de archivo o una parte del comportamiento es, legalmente, un acto distinto a trasladar el código o los activos de otra persona a un producto propio.

La práctica construida alrededor de esa distinción se llama clean-room design (diseño de sala limpia). Una persona o una sesión estudia el original y escribe una especificación sencilla de lo que hace: sus interfaces, sus formatos de datos, su comportamiento, con sus propias palabras, sin copiar código original en el documento. Una persona o sesión distinta, que nunca vio el original, construye después una implementación nueva a partir únicamente de esa especificación. La idea es que se pueda demostrar que el resultado final proviene de una descripción escrita, y no de la obra original en sí.

Dos decisiones judiciales estadounidenses más antiguas se citan a menudo sobre este punto, y vale la pena conocerlas, aunque ninguna constituye una licencia general para hacer ingeniería inversa de cualquier cosa. Sega Enterprises Ltd. v. Accolade, Inc., resuelta por el Noveno Circuito en 1992, trataba sobre una empresa que hizo ingeniería inversa del sistema de bloqueo de una consola de videojuegos para que sus propios juegos funcionaran en esa consola. El tribunal determinó que la copia intermedia implicada en esa ingeniería inversa, realizada para llegar a elementos funcionales no protegidos necesarios para que los juegos funcionaran en el hardware, constituía uso justo (fair use) según los hechos específicos de ese caso. Sony Computer Entertainment, Inc. v. Connectix Corp., resuelta por el mismo tribunal en 2000, llegó a una conclusión similar cuando una empresa hizo ingeniería inversa del software de arranque de una consola para construir un emulador para un tipo distinto de computadora, tratando de nuevo la copia realizada en el proceso como uso justo al servicio de un producto interoperable escrito de forma independiente.

Trata ambos casos como contexto histórico, no como asesoría para tu situación. Son dos decisiones de apelación específicas sobre hechos específicos, el uso justo se decide caso por caso, otros países trazan estos límites de forma distinta, y las leyes posteriores dirigidas a la elusión de protecciones contra copia reducen esto considerablemente para el software vinculado a DRM. Cualquiera que planee construir sobre este tipo de trabajo, especialmente algo destinado a lanzarse o venderse, debería consultar con un abogado real antes de confiar en nada de esto.

REA traza su propio límite con independencia de lo que un tribunal pueda eventualmente decidir sobre un caso particular. Según el DISCLAIMER.md del proyecto, REA no admite ni ayudará a eludir DRM, verificaciones de licencia, sistemas anti-trampas u otras medidas técnicas de protección, ni a copiar software propietario o su código y activos protegidos, y el proyecto afirma claramente que el resultado del análisis no otorga ningún derecho sobre el programa original. La regla práctica que se deriva de esto: analiza solo software que te pertenezca, que hayas escrito tú mismo o que de otro modo estés autorizado a examinar.

La versión de Node.js importa aquí. El propio README de REA indica su requisito exactamente así: Node.js 22.x (>=22.23.4), 24.x (>=24.22.1), o 26.12.1+, además de npm. Verifica esto contra el README vigente antes de instalar, ya que este tipo de requisito cambia entre versiones.

El comando de configuración es npx rea-agents setup. Según el README, te guía para elegir con qué agentes registrar REA, te muestra los cambios que propone hacer antes de que los apruebes, y conserva copias de seguridad de tu configuración existente. Reinicia tu agente después para que detecte el nuevo servidor MCP; las propias instrucciones de REA lo dicen claramente.

Para una instalación persistente de línea de comandos en lugar de una ejecución puntual con npx, el README describe npm install --global rea-agents, seguido de rea --help para ver qué está disponible. A partir de una instalación global, rea update te lleva a una nueva versión según tu propio calendario en lugar de automáticamente, y ejecutar después npx rea-agents@latest setup actualiza el registro del agente para que coincida.

Antes de apuntar REA hacia algo que no te pertenezca por completo, pruébalo primero en una pequeña aplicación que tú mismo hayas escrito. Con REA configurado, pídele a Claude Code que abra esa app pequeña y describa lo que ve, función por función, y compáralo con lo que ya sabes que escribiste. Ese único ejercicio confirma que la configuración realmente funcionó, y te da una idea de cómo se lee en la práctica la evidencia de REA (un archivo, una función, una llamada) antes de que dependas de ella para algo importante.

Pon en práctica concreta la idea de clean-room mencionada antes usando dos sesiones separadas de Claude Code. La primera es una sesión de especificación: apunta REA hacia el software que estás autorizado a estudiar, y pídele al agente que escriba una especificación en lenguaje llano de sus interfaces, sus formatos de datos y el comportamiento de sus funciones principales, completamente con sus propias palabras, sin copiar textualmente código original ni pseudocódigo en el documento.

La segunda es una sesión de construcción, iniciada desde cero, sin memoria de la primera. Dale únicamente el archivo de especificación, nada más: no el binario original, no la transcripción de la primera sesión, no el resultado sin procesar de REA. Pídele que construya una implementación nueva e independiente que cumpla la especificación, y que te avise cuando algo en esa especificación sea ambiguo en lugar de suponer en silencio qué debía hacer el programa original.

Mantener estas sesiones como sesiones genuinamente separadas, y no como dos fases de una sola conversación larga, es la parte que importa. Una única sesión que haya estudiado el original y luego escrito el reemplazo ha difuminado exactamente el límite que el diseño clean-room existe para mantener nítido, ya que no hay forma de demostrar, después del hecho, que la segunda mitad no se apoyó en la primera.

Sé realista sobre lo que esto te da. Un flujo de trabajo disciplinado de dos sesiones es una práctica que respalda un argumento de clean-room posterior si alguna vez alguien pregunta cómo se construyó algo. No es, por sí solo, una garantía legal, y no sustituye que un abogado real revise cualquier cosa que planees lanzar o vender.