pierandrearizzo01/Claude

Ingeniería inversa de objetivos nativos, administrados, Electron/JavaScript, empaquetados, firmware y navegadores con REA. Usa evidencia de artefactos enviados o tiempo de ejecución solicitado para explicar funciones, comparar versiones, descompilar código o guiar una reconstrucción. Omite REA para el análisis de arquitectura de repositorios de código fuente ordinarios.

¿Qué es Claude?

Esta habilidad permite a un agente de IA (como Claude Code, Cursor o Codex) realizar tareas de ingeniería inversa sobre binarios, paquetes, firmware, aplicaciones Electron/JavaScript, capturas de red y otros artefactos de software, utilizando el sistema REA (Reverse Engineering Agent). En lugar de depender únicamente del código fuente, REA trabaja con evidencia del artefacto enviado o del tiempo de ejecución para descompilar, comparar versiones, guiar reconstrucciones o explicar características. La habilidad proporciona instrucciones detalladas sobre cómo seleccionar la herramienta REA adecuada según el tipo de objetivo (binario nativo, Android APK, firmware, base de datos SQLite, etc.), cómo conectar y diagnosticar el servidor MCP de REA, y cómo interpretar los resultados de la evidencia. Es útil para desarrolladores y analistas que necesitan extraer información de software empaquetado o del que no se tiene el código fuente original, o que necesitan verificar comportamientos en tiempo de ejecución.

Compatible con✓Claude Code✓Codex CLI✓Cursor✓Antigravity✓Gemini CLI✓OpenCode✓Windsurf
npx skills add https://github.com/pierandrearizzo01/Claude/tree/HEAD/.claude/skills/reverse-engineer-anything

Installed? Explore more Investigación y análisis de datos skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

REA

Usa REA cuando una afirmación depende de un binario o paquete enviado, descompilación, evidencia pasiva del tiempo de ejecución de la aplicación o comparación con comportamientos no establecidos por el código fuente disponible. Para el análisis ordinario de un repositorio de código fuente completo, usa las herramientas normales de repositorio y no ejecutes comandos de preparación o proveedores de REA.

Conecta solo cuando sea necesario

Instalar esta habilidad proporciona instrucciones; no registra el servidor MCP de REA, instala motores de análisis ni agrega herramientas a un agente que ya está en ejecución.

Si las herramientas de REA están disponibles y no se sabe que su registro esté obsoleto, procede directamente al objetivo. No ejecutes diagnósticos o configuración antes de cada investigación. Usa la lista real de herramientas del servidor conectado y sus esquemas de entrada; una habilidad instalada desde la rama principal del repositorio puede describir capacidades ausentes en una versión npm anterior. Mantén evidencia en línea completa cuando ese servidor no anuncie referencias retenidas.

Si las herramientas están ausentes, una llamada está bloqueada por el cliente o un proveedor requerido no está disponible, lee conexión y recuperación. Diagnostica el bloqueador observado, continúa con el trabajo útil compatible y reanuda la tarea original después de la reparación. La aprobación del cliente, la variable de entorno PATH del shell, el registro y la disponibilidad del motor tienen diferentes soluciones; evita repetir la configuración para todos ellos.

  1. Diagnostica sin cambiar la configuración de REA o del cliente. npx puede descargar el paquete y escribir en la caché de npm. Para Codex, ejecuta npx -y [email protected] doctor --client codex --json. Sustituye el cliente compatible actual: claude_code, claude_desktop, codex, cursor, gemini_cli, windsurf, devin, opencode, antigravity, copilot_cli, commandcode, vscode, grok_build, omp o grok_bot. grok_bot no tiene registro de archivo local: doctor informa el paso de chat de Grok Bot, y la configuración no escribe mcp.json. Si el cliente es desconocido, usa doctor --json e inspecciona sus resultados de registro antes de elegir un alcance de configuración.
  2. Distingue la razón. Un registro faltante, malformado u obsoleto necesita una reparación de configuración con alcance. Un registro alineado sin herramientas en la sesión activa necesita un reinicio/reconexión; doctor no puede probar que el agente actual se haya conectado. Un proveedor faltante afecta solo las tareas que requieren ese proveedor: la inspección estática de JavaScript no necesita ni Hopper ni Ghidra, y la inspección de Android tiene requisitos previos separados de JADX/Java traídos por el usuario.
  3. Para una reparación de configuración, prepara el plan de solo lectura: npx -y [email protected] setup --client codex --dry-run --json. Usa el ID del cliente actual, muestra sus rutas propuestas exactas, copias de seguridad y cambios, y obtén aprobación antes de que la configuración escriba o instale Hopper. La configuración normalmente instala también la habilidad empaquetada correspondiente; incluye ese reemplazo en el plan revisado. Después de la aprobación, aplica el mismo alcance con npx -y [email protected] setup --client codex --yes. Agrega --install-hopper solo si esa instalación separada fue necesaria y aprobada explícitamente.
  4. Reinicia/reconecta el agente afectado. Verifica que las herramientas de REA realmente aparezcan en la sesión y luego reanuda la investigación original. Si aún están ausentes, inspecciona el error de inicio MCP del cliente en lugar de repetir la configuración.

La configuración de REA nunca instala ni actualiza Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk o Unblob. Usa los requisitos previos existentes; no instales software no relacionado para reparar el registro MCP. Para un cliente no compatible, usa el registro stdio manual con un paquete rea-agents con versión fija o continúa a través de la CLI.

Un respaldo CLI concreto para un árbol JavaScript o ASAR proporcionado por el operador es:

npx -y [email protected] analyze-javascript-application /ruta/absoluta/hacia/app --json

No se requiere registro MCP ni motor nativo. Lee la Evidencia, el gráfico, las limitaciones y las incógnitas devueltas con el mismo cuidado que un resultado MCP; la CLI devuelve el registro de Evidencia directamente. Este respaldo no establece que MCP esté configurado. Las tareas nativas de la CLI aún requieren su motor seleccionado. Prefiere una CLI rea existente. Cuando no haya ninguna instalada y la adquisición del paquete REA esté dentro del alcance autorizado, usa npx -y [email protected] en su lugar. La reparación de configuración comienza con un plan de configuración de solo lectura; muestra rutas, copias de seguridad y reemplazo de habilidades antes de aplicar los cambios autorizados. Preserva los límites de aprobación y ejecución de objetivos existentes. La configuración de REA nunca instala ni actualiza software no relacionado, incluyendo Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk o Unblob.

Enruta el objetivo primero

Elige la primera herramienta a partir del objetivo que el usuario proporcionó. Usa open_binary para flujos de trabajo nativos o de archivo de objetivo activo; las herramientas sin objetivo toman su propia ruta o endpoint explícitos y no lo necesitan.

  • Árbol ASAR o JavaScript/Electron extraído: analyze_javascript_application.

  • Inventario de miembros de archivo/paquete (ZIP/APK/IPA/MSIX/AppX o DMG): open_binary con la ruta local proporcionada; usa inspect_artifact cuando su gráfico y hallazgos ayuden a responder la pregunta.

  • Código, clases, métodos o referencias entrantes de Android APK: inspect_android_package, luego herramientas de Android enfocadas cuando se anuncien. El inventario de miembros del archivo aún usa la ruta de archivo anterior.

  • Ensamblado PE/CLI administrado: inspect_managed_artifact.

  • Imagen de firmware: inspect_firmware_regions cuando se anuncie. Usa extract_firmware cuando se solicite la extracción, con un nuevo directorio de salida absoluto seleccionado por el llamante. Estas herramientas usan Binwalk/Unblob proporcionados por el llamante en Linux; consulta la guía de firmware.

  • PE/ELF .NET NativeAOT: análisis nativo de Ghidra. El código nativo puede producir pseudocódigo; consulta el flujo de trabajo NativeAOT en references/native-and-artifacts.md para la recuperación opcional de metadatos y su límite de host/diseño compatible.

  • Página del navegador propiedad del usuario ya abierta: list_browser_targets.

  • Acción del navegador que el agente debe realizar (clic, escribir, navegar): capture_browser_scenario con acciones declaradas. Consulta observación en tiempo de ejecución para conectar/iniciar y las herramientas de navegador de seguimiento enfocadas.

  • Tráfico de Fiddler Everywhere o una captura nativa .saz: lee el flujo de trabajo de Fiddler. Inspecciona SAZ guardados con inspect_web_network_capture y format: "saz"; conecta el servidor MCP separado de Everywhere para tráfico en vivo.

  • Captura retenida de HAR/SAZ/mitmproxy nativa/aioquic qlog: inspect_web_network_capture. Selecciona ordinales de registro originales cuando sea útil; inspecciona campos de productor y datos adjuntos de bytes/números sin recuperar URL registradas ni reclamar atribución en vivo. Consulta capturas históricas para el perfil upstream exacto y exclusiones de credenciales. El soporte de Qlog comienza con aioquic 1.5.0 JSON 0.3; la cobertura de flujo y las declaraciones de pérdida de punto final no recuperan cuerpos ni establecen pérdida de red. Prefiere resumen detallado, luego páginas de traza/flujo qlog de tipo; selecciona una traza, ID de flujo y dirección para páginas de contribución/rango. Los hechos retienen el alcance de todos los eventos registrados antes de la selección. Otros diseños de qlog y correlación de PCAP no son compatibles.

  • Tiempo de ejecución de Electron propiedad del usuario ya abierto: list_electron_targets. Antes de un intento de Inspector de electron-main, verifica los fusibles empaquetados con inspect_electron_fuses; EnableNodeCliInspectArguments deshabilitado significa que la aplicación ignora --inspect.

  • Descubrimiento de campos de paquetes: inspect_packet_fields busca protocolos instalados y nombres/tipos de campo antes de elegir campos para inspect_packet_capture. Consulta/pagina los registros relevantes; los registros no establecen tráfico observado.

  • Capturas de paquetes grabadas: inspect_packet_capture con campos TShark seleccionados, filtros de visualización y reglas de decodificación. Requiere Linux, util-linux prlimit y REA_TSHARK_COMMAND; consulta la guía de captura. Los límites de paquetes cuentan los paquetes de entrada antes del filtrado. La salida predeterminada es de 50 tramas coincidentes; usa match_offset / match_limit para páginas posteriores, o un límite nulo explícito para la salida completa coincidente. Preserva el resumen de origen entre páginas. Esto no realiza captura en vivo. Para resúmenes de direcciones/DNS/SNI/protocolos usa inspect_pcap_capture con resumen detallado de MCP, luego páginas pcap de tipo retenido. Requiere tshark y capinfos de Wireshark 4.x, con prlimit de Linux o Job Objects de Windows; consulta resúmenes de paquetes. Selecciona una pregunta DNS exacta para páginas de direcciones; el agotamiento de la página no prueba la integridad de la red. Esto lee grabaciones y no adquiere tráfico.

  • Descubrimiento de decodificadores: inspect_signal_decoders busca IDs de decodificador instalados o ayuda de decodificador seleccionado, incluyendo canales y opciones. Consulta y pagina los detalles relevantes antes de elegir configuraciones; esto no escanea hardware.

  • Trazas de lógica/señal grabadas: decode_signal_recording con decodificador explícito, configuración de canal y protocolo. En Linux con util-linux prlimit, proporciona sigrok-cli 0.7.2 a través de REA_SIGROK_COMMAND; consulta la guía de grabación. La salida predeterminada es de 50 líneas literales; selecciona clases de anotación y pagina con line_offset / line_limit, o nulo explícito para toda la salida restante. Los recuentos de ventana son líneas de visualización, no anotaciones o muestras. Preserva los resúmenes de origen entre páginas. Esto lee archivos existentes; no adquiere señales de hardware.

  • Artefacto WebAssembly local explícito: inspect_wasm_artifact. Proporciona WABT 1.0.42 a través de REA_WABT_BIN_DIRECTORY; retiene la identidad exacta de byte/herramienta y WAT decodificado. Selecciona glue de JavaScript y rutas candidatas explícitamente y preserva la ambigüedad de URL/ruta. Sin fetch implícito ni ejecución de objetivo; WAT no es la fuente original. Consulta la guía WASM.

  • Portador de bytecode EVM local explícito: inspect_evm_interface con codificación raw o hex seleccionada por el llamante. Preserva los resúmenes de portador/decodificado y trata los selectores, cadenas de argumentos y mutabilidad como candidatos inferidos; esto no realiza búsqueda en cadena ni ejecución de objetivo. Para la interfaz inferida completa sin hex o stdout duplicado, descubre el soporte y selecciona detail: "summary"; la Evidencia completa permanece retenida bajo su identidad original. Usa el parent_evidence_id devuelto para páginas de función exacta o bytecode_hex/stdout/stderr. La cobertura de candidatos no establece la integridad de la interfaz. Consulta la guía de bytecode EVM.

  • Metadatos de compilador, módulo o configuración de compilación Go incrustados: inspect_go_binary con el archivo local explícito. Esta inspección incorporada sin objetivo no requiere instalación de Go ni desensamblador. Preserva los bytes de módulo sin procesar y los rangos de origen; los metadatos ausentes no prueban que un binario no sea Go, y los registros de texto no analizados permanecen explícitos. Consulta la guía de binarios Go.

  • Metadatos de dependencias Rust cargo-auditable incrustados: inspect_rust_binary con el archivo ELF, PE o Mach-O delgado local explícito. Esta inspección incorporada sin objetivo no requiere instalación de Rust ni desensamblador. Preserva el orden de los paquetes, los índices de dependencia y el rango de archivo de la sección. Una sección .dep-v0 faltante son metadatos nulos, no prueba de que el binario no tenga dependencias. Un hash de commit de rustc es una inferencia de una ruta de solo lectura /rustc/<40-hex>/. Consulta la guía de binarios Rust.

  • Instantánea de base de datos SQLite local explícita: inspect_sqlite_database. Inspecciona con Node.js 24.x >=24.15 o 26+ que proporcione límites SQLite nativos. Lee el esquema primero (inventario compacto por defecto) o selecciona una tabla ordinaria exacta y columns cuando se necesiten filas. Los valores predeterminados son el esquema de la tabla seleccionada y 20 filas; solicita schema_scope: "database" para el esquema almacenado completo. Preserva la identidad de la base de datos y del WAL hermano existente; las muestras de filas informan truncamiento y tienen un orden no especificado. Usa una instantánea inactiva en lugar de asumir que un par base de datos/WAL en vivo se copió atómicamente. Consulta la guía de SQLite.

  • Archivo ELF Linux explícito para diseño fuera de línea, símbolos, reubicaciones o evidencia de mitigación estática: inspect_binary_layout. Esta operación sin objetivo usa pwntools proporcionado por el llamante sin abrir una base de datos de desensamblador. Preserva sus ubicaciones sin procesar y los límites de inferencia/cobertura; consulta la guía de binarios fuera de línea.

  • Core ELF x86-64 Linux proporcionado: inspect_recorded_crash. Lee cada hilo grabado, nota sin procesar y registro vinculado a origen sin abrir un objetivo en vivo. Los PID históricos no seleccionan procesos en vivo. Solicita include_debugger_context solo cuando los candidatos de mapeo solo de núcleo ayuden; consulta la guía de fallos grabados.

  • Árboles de tipo/nombre/idioma de recursos PE y referencias de grupo de iconos estáticos: inspect_pe_resources con una ruta explícita. Esta operación portátil no requiere objetivo activo ni motor; las cargas útiles opacas retienen rangos de archivo y SHA-256.

  • Ejecutable, biblioteca o base de datos de análisis nativos: open_binary, luego usa herramientas de análisis enfocadas directamente; llama a binary_overview cuando los metadatos o el contexto del inventario sean útiles y estén disponibles del proveedor seleccionado.

Para una configuración MCP de IDA existente, usa open_binary con el binario de entrada original y provider_id: "ida"; no pases una base de datos .idb o .i64. El perfil adjunto heredado vincula la entrada GUI ya abierta por SHA-256 y deja su base de datos abierta. La versión moderna sin cabeza

Skills relacionados