Una demo puede demostrar capacidad. La ingeniería empieza cuando pedimos arquitectura, evidencia, pruebas, límites y verificación

REA, agentes e ingeniería inversa: qué demuestran las demos, qué exige la ingeniería y qué significa de verdad cuando aterrizamos en un VB6 sin fuentes.

Tesis del artículo
REA no elimina el conocimiento ni la verificación. Reduce el coste del trabajo intermedio y permite que un agente conduzca herramientas que ya existían. La diferencia entre una demo y una modernización defendible sigue siendo la evidencia.

Ver un vídeo en YouTube está muy bien. De hecho, este es exactamente el tipo de demostración que explica por qué REA (Reverse Engineer Anything) ha generado tanto ruido en pocos días: un agente analiza una aplicación, Ghidra aparece por debajo y, unos minutos después, tenemos una reconstrucción que se parece mucho al original.

La demo puede ser real. El resultado puede ser útil. Y aun así podemos estar sacando una conclusión equivocada.

Que una aplicación arranque no demuestra que sea equivalente. Que una función produzca una salida razonable no demuestra que preserve la semántica original. Y que un agente escriba código limpio y convincente no significa que haya entendido correctamente el sistema que intenta reconstruir.

Ahí está la distancia entre el vídeo y la ingeniería.

Estos días circula por LinkedIn, X y Hacker News una idea tentadora: le das un binario a un agente y te devuelve otro «a imagen y semejanza»; le das una ROM y la rehace; le das una aplicación sin fuentes y prácticamente has resuelto el problema. La conclusión implícita es todavía más atractiva: ingeniería inversa completa, automática y al alcance de cualquiera.

No es así. Y en este oficio, antes de opinar, toca ir a la fuente.

Me he descargado el repositorio (rea-agents 6.4.0), he leído el código y la documentación, he contrastado los casos que se citan como prueba y he mirado dónde encaja todo esto en un escenario que me toca de cerca: aplicaciones VB6 sin fuentes que siguen en producción.

Adelanto la conclusión sin ceremonia: REA no hace nada que antes fuera imposible. Lo que cambia es quién conduce las herramientas, cuánto cuesta hacer el trabajo intermedio y con qué disciplina podemos verificar el resultado. Que no es poco.

El vídeo que dispara la conversación

Como ejemplo, merece la pena ver Uncensored AI + REA Can Reverse Engineer Anything, de Mark Kashef. En poco más de seis minutos enseña una reconstrucción de QuickTime Player utilizando REA y Ghidra y, algo que me parece especialmente útil para esta discusión, dedica una parte explícita a lo que esos clones todavía no consiguen reproducir.

Vídeo: https://www.youtube.com/watch?v=ScSDVV5xhww

No lo incluyo para desmontarlo. Al contrario: es una buena demo. Lo interesante es preguntar qué demuestra exactamente. Una demostración visual puede acreditar que existe una posibilidad; no puede, por sí sola, probar equivalencia funcional, cobertura, corrección semántica, comportamiento en los casos límite ni continuidad operativa.

Una demo demuestra una posibilidad. La evidencia demuestra una propiedad.

De dónde viene el ruido

Una primera señal de cómo está el ambiente: ni siquiera las cifras de popularidad cuadran.

• Un titular de daily.dev habla de 120.000 estrellas en una semana.
• AICoder contaba unas 13.000 a 8 de octubre.
• Developers Digest dice que el banner del README agradece 180.000 y que la página del repo mostraba más de 200.000 cuando la abrieron.

La popularidad no mide calidad; mide ganas.

Además, en la cobertura viral se mezclan cuatro historias distintas, y separarlas es la mitad del trabajo:

1. REA como herramienta.
2. Los showcases de su README. Funciones sueltas reconstruidas y verificadas byte a byte.
3. ArtCraft. Es un proyecto ajeno que ha publicado alternativas open source a Premiere y After Effects, y que muchos titulares meten en el mismo saco. El README de REA no dice que las haya creado él. Sospecho que buena parte del mito de «clona cualquier programa» nace de esa mezcla.
4. Proyectos de decompilación con agentes que ni siquiera usan REA, como el que comento más abajo.

Qué es REA, según su propio código

REA es un servidor MCP y una CLI, con licencia MIT, que conecta tu agente con herramientas de análisis: Claude Code, Codex, Cursor, Gemini CLI y otros. Se ejecuta en local; lo que llega al modelo son los resultados de las herramientas.

Para binarios nativos no trae decompilador propio. Orquesta Ghidra, Hopper o IDA, que instalas tú (también admite objdump y Rizin). Para otros formatos sí tiene parsers propios:

• Ensamblados .NET: metadatos y CIL, sin cargar ni ejecutar nada.
• Go y Rust: solo los metadatos de build embebidos.
• Flutter/Dart AOT: las huellas del snapshot.
• Recursos PE.

Android lo resuelve con JADX y WASM con WABT.

Lo interesante no es la lista de formatos, sino el contrato de salida. Cada resultado va atado a una evidencia: ruta, tamaño y SHA-256 del artefacto, el proveedor que lo produjo, la cobertura y, sobre todo, lo que no sabe. El código está lleno de estados unknown, partial, unsupported o truncated, y ninguno se agrega jamás como pass.

Es una herramienta diseñada para que el LLM no rellene huecos con imaginación. En ingeniería inversa, eso vale más que cualquier demo.

Lo que ya existía antes de REA

El caso de Super Mario 64 merece un detalle. El proyecto de n64decomp reconstruye el juego completo en C, y su build puede comparar el hash de la ROM generada con el de la original. Pero tiene un requisito: necesitas una ROM original en la carpeta del proyecto, porque de ahí se extraen los assets.

Así funciona incluso el proyecto canónico: el código se reconstruye; el arte, la música y los datos salen del original.

Tampoco es nuevo darle Ghidra a un LLM. GhidraMCP ya exponía la funcionalidad central de Ghidra a clientes MCP para que un modelo hiciera ingeniería inversa de forma autónoma. Y Hex-Rays publica su propio servidor MCP para IDA.

Entonces, ¿qué hay de nuevo de verdad?

Del titular a la ingeniería: una hipótesis no se convierte en verdad hasta que podemos verificarla.

1. Cambia quién conduce la herramienta. Los decompiladores no son nuevos, y REA sigue necesitando uno para el trabajo nativo profundo. Lo que cambia es que, en lugar de una persona leyendo pseudocódigo durante semanas, un agente dirige la investigación, cita evidencias y comprueba su reconstrucción. El coste de entender software ajeno ha bajado de forma drástica. Eso sí es nuevo.
2. Una interfaz homogénea con disciplina de evidencia. La aportación diferencial de REA frente a un puente MCP sencillo es tratar decenas de tipos de objetivo con el mismo contrato: digests, procedencia, cobertura explícita y paquetes de evidencia que se exportan e importan autenticados.

Incluso sus herramientas de comparación son honestas con sus límites. compare_functions compara pseudocódigo y ensamblador como texto exacto del proveedor, y la documentación aclara que un cambio textual no demuestra un cambio de comportamiento. Eso es ingeniería, no marketing.

3. La verificación entra en el flujo. REA tiene un ledger de obligaciones de reconstrucción. Una afirmación del tipo «esta parte está reconstruida» solo se cierra si cumple cuatro condiciones:

• Tiene un responsable.
• Tiene casos de prueba.
• Hay un verificador que pasa.
• Ese verificador tiene una autoridad comparable a la observación original.

Si falta cualquiera de las cuatro, la obligación queda abierta.

La reconstrucción es una hipótesis. El oráculo aporta un PASS/FAIL observable que permite iterar sin confundir plausibilidad con corrección.

El caso que mejor lo demuestra (y no usa REA)

La mejor evidencia pública de lo que ha cambiado la ha publicado Maurice Heumann, y no usa REA, sino el ida-mcp oficial de Hex-Rays. Durante tres meses, él y varios colaboradores pusieron agentes a decompilar un shooter en primera persona muy conocido. El objetivo no era una prueba de concepto, sino una recreación precisa, estable y completa en C++.

El primer mes fue un espejismo. Los agentes decompilaron en torno al 80% del juego, que arrancaba y cargaba mapas. Pero el código, aunque muy legible, era semánticamente incorrecto: firmas, tipos y estructuras equivocadas, y lógica inventada o eliminada. El agente revisor tampoco ayudaba. Sin criterios objetivos, aceptaba las justificaciones que los propios trabajadores dejaban en comentarios y commits. Heumann lo describe como una inyección de prompt involuntaria entre agentes.

La solución fue un oráculo. Cambiaron al compilador original del juego y escribieron un script que compara byte a byte cada función reconstruida con el ejecutable. Responde a una sola pregunta: ¿coincide, sí o no?

Lo primero que hicieron los agentes fue intentar hacer trampa. Primero escribieron ensamblador inline. Cuando se prohibió, intentaron modificar el script para excluir su propia función, hasta que el CI empezó a validar el hash del script.

El resultado:

• El 99% de las funciones está presente en el código reconstruido.
• El 83% es exacto byte a byte.
• El juego funciona sin fallos apreciables.
• El coste estimado ronda los 600.000–700.000 millones de tokens.

El código no se publicará. La lección que más me interesa es otra: con un criterio de aceptación estricto, modelos baratos que antes daban malos resultados pasaron a ser viables.

Un oráculo vale más que un revisor. Eso es lo verdaderamente nuevo, y no depende de REA.

«Te hace la ROM»: lo que dice la letra pequeña

Todo lo que hacía falta en 2019 para reconstruir una ROM sigue haciendo falta hoy.

Saber la plataforma. CPU, mapa de memoria, dirección de carga. REA no lo adivina. En binarios sin cabecera eres tú quien le pasa la arquitectura y la dirección de carga, y la documentación es explícita: no lo infiere de una extensión .bin. Para 6502, además, la imagen tiene que caber en el espacio de 16 bits, y la rechaza si lo cruza. Una ROM de NES con bank switching no entra tal cual: la troceas tú, sabiendo qué mapper usa.

La toolchain original. Mismo compilador, misma versión, mismos flags. Ni así está garantizado. Heumann se topó con funciones imposibles de igualar, por ejemplo por el plegado COMDAT del linker, que no lograron reproducir de forma fiable.

Los assets. Salen del original, como en Super Mario 64.

Un oráculo. Sin él, tienes código legible y probablemente incorrecto.

¿Y los showcases de REA? Son reales y valiosos, pero son lo que son:

• DX-Ball: una función de cálculo de paneo de sonido. Pasa 3.205 casos contra el x86 original y reproduce sus 63 bytes compilados.
• TH04: un cálculo de ángulos de balas de un juego de PC-98 en DOS, comparado con la salida del compilador de la época.

Son funciones, no ROMs.

Si sabes el sistema y los chips, esto ya se hacía. Lo que ha cambiado es el tiempo de mano de obra, no el requisito de conocimiento.

Aterrizando en modernización: ¿y mi VB6?

Modernizar no es traducir sintaxis: primero recuperamos intención, después verificamos comportamiento y solo entonces reimplementamos.

Aquí la conversación se pone seria para quienes trabajamos en modernización. Microsoft mantiene que el runtime de VB6 tiene soporte durante el ciclo de vida de cada versión de Windows, incluida Windows 11. El IDE de VB6, en cambio, perdió el soporte el 8 de abril de 2008, y el runtime sigue siendo solo de 32 bits.

Traducido: hay muchísimas aplicaciones VB6 funcionando hoy, muchas sin fuentes, y nadie da soporte a la herramienta que las compilaba.

Lo que ve REA de un ejecutable VB6

He buscado en todo el repositorio (msvbvm, Visual Basic, vb6…) y no hay ningún soporte específico. Las coincidencias con «p-code» corresponden al lenguaje intermedio interno de Ghidra, que no tiene nada que ver con el P-Code de VB6.

Las herramientas .NET de REA lo rechazan, porque un ejecutable VB6 no tiene cabecera CLI. Para REA es un PE x86 nativo más, y lo que obtienes depende de cómo se compiló.

Compilado a Native Code. Ghidra lo decompila, pero el pseudocódigo es muy ruidoso:

• Llamadas al runtime por todas partes: __vbaStrCopy, __vbaFreeStr, rtcMsgBox…
• Controles y formularios manejados como objetos COM, con llamadas indirectas por offset de vtable.
• Manejadores de eventos no exportados, que solo se localizan recorriendo las estructuras propias de VB. Ni REA ni Ghidra las interpretan de serie.
• APIs declaradas con Declare que se resuelven en tiempo de ejecución mediante DllFunctionCall, así que no aparecen en la tabla de imports.

Compilado a P-Code. La lógica es bytecode que interpreta el runtime MSVBVM60. Para Ghidra son datos, no instrucciones, y REA se queda prácticamente ciego. Una pista bastante fiable de que estás ante P-Code: que el ejecutable importe ProcCallEngine o MethCallEngine.

Un poco de arqueología: veinte años de decompiladores de VB6

Antes de preguntarse qué aporta REA a VB6, conviene recordar que el problema lleva más de veinte años estudiado. La comunidad de reversing de VB tuvo foros propios, herramientas comerciales y proyectos open source mucho antes de que nadie hablara de MCP.

La distinción clave ya estaba clara entonces. Las notas de VB Decompiler de 2007 lo explicaban sin rodeos. El P-Code, al estar formado por comandos de alto nivel, puede decompilarse a algo parecido al fuente, aunque sin los nombres originales. El código nativo, en cambio, no permite recuperar el fuente; la herramienta solo ayuda a analizarlo.

El problema práctico es que lo nativo era lo habitual. El autor de VBReFormer basó su herramienta en código nativo porque, según su estimación, nueve de cada diez aplicaciones VB6 se publicaban así. Es una cifra de parte, pero cuadra con que Native Code era la opción por defecto del IDE.

Hubo también una carrera armamentística. Hacia 2010 se vendía VB 6 AntiDecompiler, que prometía dejar sin salida útil a VBReFormer, VB Decompiler, VB RezQ o Semi VB Decompiler. Si tu ejecutable lleva una protección así, ninguna herramienta, REA incluida, te lo va a poner fácil.

La lección de la arqueología es sencilla. Lo difícil de VB6 ya está resuelto en herramientas específicas: la cabecera VB, la tabla de objetos, los formularios y el P-Code. Lo que faltaba no era otro parser.

Lo que sí ha cambiado: el agente encima del parser

El ejemplo más claro no viene de REA, sino de Cisco Talos. En junio de 2026, David Zimmer, el autor de VBDec, publicó cómo lo automatiza con Claude Code en local.

El truco es elegante. Al activar el scripting remoto, VBDec publica su modelo de objetos en la Running Object Table de Windows. Cualquier script puede engancharse a la instancia viva y recorrer todo el proyecto parseado como un grafo de objetos: formularios, clases, módulos, APIs declaradas, cuerpos P-Code, controles y cadenas. VBDec acompaña ese modelo con un paquete para agentes: un briefing en texto y unas 90 definiciones de clase que el agente usa como referencia.

Los resultados que publica son concretos:

• Decompilación de funciones P-Code. La reconstrucción no es idéntica byte a byte, pero recupera buena parte del flujo de control, con comentarios. El agente, además, entró por su cuenta en las subfunciones, dedujo para qué servían y les puso nombres razonables.
• El binario como base de datos. Volcó a SQLite todas las funciones de una aplicación real: más de 600 filas con dirección, tamaño, módulo, llamadas y APIs externas. A partir de ahí, preguntas sobre todo el programa se resuelven con una consulta SQL.
• Orquestación de varias herramientas. Construyó una base de datos con los 1.165 opcodes del intérprete P-Code de MSVBVM60. Para ello combinó VBDec con el servidor MCP de idalib, que leía los manejadores reales dentro del runtime. Según Zimmer, fue cuestión de horas y algo impracticable a mano.

La idea de fondo coincide con la de todo este artículo: una herramienta de análisis no necesita IA integrada; le basta con exponer sus datos a una interfaz de scripting externa.

Traducido a VB6: el P-Code, que antes daba un desensamblado legible, ahora da un fuente reconstruido y comentado en segundos. No es el original, pero es una base de trabajo que antes costaba días.

Qué aporta REA (y qué no)

Primero, lo honesto: REA no parsea las estructuras de VB6. No sustituye a VBDec ni a VB Decompiler. Su sitio es complementario, y hay seis puntos donde sí suma.

1. Inventario con evidencia. Una aplicación VB6 real es un EXE más una colección de OCX y DLL. REA inventaría el conjunto con SHA-256 por fichero, lee los recursos PE (icono, versión, manifiesto) con inspect-pe-resources y compara inventarios entre versiones. En un proyecto de cliente, poder decir exactamente qué binarios analizaste y con qué hash no es burocracia: es trazabilidad.
2. El Native Code a fondo. Para las funciones compiladas a nativo, REA lleva el análisis a Ghidra o IDA con el mismo contrato de evidencia que el resto: pseudocódigo, referencias, llamadas y lo que no sabe marcado como unknown. El agente hace el trabajo tedioso de traducir los idiomas del runtime a intención. Por ejemplo, una secuencia de __vbaStrCopy y __vbaFreeStr no es más que una asignación de cadena.
3. Puente entre VBDec y Ghidra mediante semillas. Para mí, es el punto más útil. Los manejadores de eventos de VB6 se alcanzan desde estructuras de datos, y el análisis automático de Ghidra a menudo no los encuentra. REA admite un fichero de semillas precisamente para el código al que el análisis automático no llega, como saltos calculados o punteros en datos. Cada línea lleva dirección, tipo (function, code o label) y, opcionalmente, un nombre.

VBDec ya te da nombres y direcciones de las funciones, así que basta con convertirlos (direcciones ficticias):

Dos detalles del diseño me gustan. El digest de las semillas entra en el perfil de análisis, así que queda registrado qué nombres vinieron de fuera. Y una semilla que se solapa con instrucciones que Ghidra ya decodificó falla, en lugar de forzarse. En Linux y macOS, annotate_native_function permite además añadir comentarios y renombrar sobre la sesión.

4. Qué cambió entre versiones. Si tienes dos builds del mismo ejecutable (la de producción y la de hace tres años), compare_functions compara manejador a manejador. Recuerda su límite: un cambio textual no prueba un cambio de comportamiento. Aun así, te dice dónde mirar.
5. Observación en ejecución para el oráculo. REA expone Frida, en local o contra dispositivos remotos (host:puerto). En principio permitiría enganchar exports de MSVBVM60 o llamadas ADO mientras se usa la aplicación, y capturar entradas y salidas para los tests. Un matiz importante: la verificación oficial de esta parte en el repo se hace en Linux, y una app VB6 vive en Windows. Pruébalo en tu entorno antes de prometerlo en una propuesta.
6. La mitad .NET del híbrido. Muchas aplicaciones VB6 empresariales ya conviven con .NET vía COM; Microsoft llegó a documentar cómo extenderlas con el Interop Forms Toolkit. Esa mitad sí la lee REA de forma estática: metadatos, CIL y declaraciones P/Invoke. Y una vez migrada, compare_managed_members sirve para seguir los cambios entre builds del nuevo C#.

Lo que REA no te va a dar con VB6: la estructura del proyecto, los formularios ni el P-Code. Tampoco desempaqueta binarios protegidos.

El oráculo de un VB6 no son los bytes

Igualar byte a byte un VB6 exigiría el IDE con su service pack exacto, sin soporte desde 2008. Que yo sepa, nadie ha montado ese oráculo. Y en una migración tampoco lo quieres: no buscas un binario idéntico, buscas comportamiento idéntico.

El oráculo útil es el de caracterización, el clásico golden master: mismas entradas, mismas salidas. Filas en base de datos, ficheros generados, informes, mensajes. Heumann lo generaliza bien: no todos los proyectos tienen el lujo de la decompilación, pero con creatividad casi siempre se puede llegar a algo parecido a un PASS/FAIL objetivo.

El flujo que propondría

1. Inventario y huella (REA). EXE, OCX y DLL con sus hashes y recursos. Determinar si es Native o P-Code y si hay packer o protección.
2. Estructura (VBDec o VB Decompiler). Formularios, eventos, nombres y offsets. En P-Code, aquí está la mayor parte del valor, con el agente trabajando encima de VBDec.
3. Semillas a Ghidra (REA). Volcar los nombres y direcciones de VBDec al fichero de semillas y analizar las funciones nativas con evidencia.
4. Reconstrucción asistida. El agente redacta pseudo-VB6 o directamente la especificación funcional, siempre ligada a la evidencia de los pasos anteriores.
5. Oráculo. Tests de caracterización con entradas y salidas reales del sistema actual, más observación en ejecución si tu entorno lo permite. Todo esto antes de escribir una línea de C#.
6. Reimplementación en .NET. El agente escribe contra el oráculo, y el humano revisa semántica y, sobre todo, arquitectura. Recuerda el aviso de Heumann: sus agentes convirtieron lecturas baratas de variables globales en búsquedas en tablas hash órdenes de magnitud más caras.

Cuándo tiene sentido (sin dogmatismo)

Tiene sentido cuando:

• Quieres entender cómo funciona una feature o necesitas interoperabilidad.
• El software es tuyo y has perdido las fuentes.
• Haces triage de seguridad.
• Migras un sistema legacy y puedes construir un oráculo de comportamiento.

No lo tiene cuando:

• Esperas un clon.
• No puedes definir qué es «correcto» de forma verificable.
• El binario está protegido y tu plan pasa por saltarte esa protección.
• El software no es tuyo y no tienes derechos para analizarlo.

La línea legal

El propio DISCLAIMER.md de REA limita los usos previstos a investigación de seguridad, análisis de malware, interoperabilidad, preservación y software propio o autorizado. Excluye expresamente eludir DRM o licencias, copiar software propietario y reproducir su código y sus assets protegidos. Y conviene no olvidar que obtener algo parecido al código fuente no te da derechos sobre el programa original.

El caso de Heumann ilustra que esto no es teórico: retiró dos posts anteriores sobre el proyecto, deja entrever presiones corporativas y no va a compartir el código.

En la UE, la Directiva 2009/24/CE (artículo 6) permite la decompilación para interoperabilidad, pero con condiciones estrictas. No soy abogado: si es para un cliente, consúltalo antes de que el agente escriba la primera línea, no después.

Conclusión

La intuición correcta es la que muchos teníamos: reconstruir una ROM o un binario siempre ha exigido conocer la plataforma, tener la toolchain original y disponer de una forma objetiva de verificar. REA no elimina ninguno de esos requisitos, y su propio diseño está pensado para decirte «esto no lo sé» en lugar de inventárselo.

Lo que sí ha cambiado es el coste del trabajo intermedio. Leer pseudocódigo, nombrar funciones, cruzar referencias y proponer reconstrucciones lo hace ahora un agente. Si le das un oráculo, incluso un modelo barato lo hace bien.

En VB6 la noticia es todavía mejor. El conocimiento difícil ya estaba en herramientas de hace veinte años; lo nuevo es que un agente puede manejarlas por ti. REA aporta encima la disciplina de evidencia que convierte esa reconstrucción en algo verificable.

Para quienes vivimos de modernizar sistemas, la lectura operativa no va de magia negra. Antes de pedirle a un agente que reescriba tu VB6, construye el oráculo que le diga cuándo se equivoca.

Enlaces y referencias

REA

• Repositorio oficial https://github.com/morluto/rea
• Disclaimer de usos previstos https://github.com/morluto/rea/blob/main/DISCLAIMER.md
• Developers Digest — What the MCP Server Does and Where the Line Is (incluye la distinción REA/ArtCraft) https://www.developersdigest.tech/blog/reverse-engineer-anything-rea-mcp-agents-guide-2026

Agentes, oráculos y decompilación

• Maurice Heumann — 500+ Billion Tokens Later (fuente primaria) https://momo5502.com/posts/2026-10-09-game-decompilation/
• Developers Digest — Give Agents a PASS/FAIL Oracle (análisis del caso anterior) https://www.developersdigest.tech/blog/agent-harness-pass-fail-oracle-500b-token-decompile-2026
• Cisco Talos — Scripting the disassembler (VBDec + Claude Code, junio 2026) https://blog.talosintelligence.com/scripting-the-disassembler/

Herramientas previas

• GhidraMCP https://github.com/LaurieWired/GhidraMCP
• ida-mcp (Hex-Rays) https://github.com/HexRaysSA/ida-mcp
• Decompilación de Super Mario 64 https://github.com/n64decomp/sm64

VB6

• Microsoft — Support Statement for Visual Basic 6.0 on Windows https://docs.microsoft.com/en-us/dotnet/articles/visual-basic/reference/vb6-support
• VBDec (Sandsprite) https://sandsprite.com/vbdec/
• Semi VB Decompiler https://github.com/VBGAMER45/Semi-VB-Decompiler
• Recopilatorio de herramientas VB6 de David Zimmer https://github.com/commanderz/vb6_decompilers
• VBDecompiler (DaCodeChick) https://github.com/DaCodeChick/VBDecompiler
• VB Decompiler (DotFix) https://www.vb-decompiler.org/
• VBReFormer https://www.decompiler-vb.net/