Por qué usar NotHoly para ingeniería inversa

La ingeniería inversa es leer. Ya tienes Ghidra, radare2 o IDA abierto, y la parte lenta es entender un volcado de decompilador, nombrar los locales y escribir el script que renombra los próximos doscientos. Un modelo ayuda ahí, pero solo si acepta la pregunta sin sermón y lee lo que pegas. NotHoly hace ambas. Mantienes tus herramientas, y el modelo explica la salida y escribe los scripts. El caso de uso de ingeniería inversa tiene el flujo más largo; esto es sobre por qué encaja.

#Pega la salida, recibe una explicación y un script

La salida del decompilador y del disassembler es la entrada. Pega una función de Ghidra, un bloque de radare2 o un listado de IDA, y el modelo explica lo que hace, nombra la estructura que ve y marca las partes que parecen una comprobación de límite, una rutina de decode o un parser. Pide un script y escribe uno para tu herramienta: un pase en Ghidra Python que renombra por patrón, una secuencia de comandos radare2, un fragmento de IDAPython, un hook de Frida para loguear una llamada. El script corre en tu máquina, contra tu muestra, nunca la nuestra. Como el modelo no rechaza la tarea, una rutina de unpacking, un bucle ofuscado, un truco anti-debug o una comprobación de licencia se lee como cualquier otro código, mientras el trabajo esté en tu alcance.

r2 -q -c "pdf @ sym.main" ./bin | notholy "explain this function and write a radare2 script to rename the locals"

#Un primer vistazo antes de la herramienta pesada

Adjunta un binario en el chat, o corre notholy analyze, y las herramientas estáticas dan una primera pasada sin abrir el decompilador. Para un ELF o PE recibes el SHA-256, el tamaño, la entropía, el formato, el entry point, las secciones y los imports. Para una muestra también recibes las strings y una vista previa de disassembly del inicio del archivo. Un APK da el manifest y el texto de cada entrada, y un archivo comprimido da su árbol. Cada archivo se parsea en un sandbox desechable sin red y con raíz de solo lectura, nada en él se ejecuta, y un pickle de Python se desensambla con pickletools, nunca se carga. Entropía alta y una tabla de imports corta bastan para decidir si una muestra vale la hora en Ghidra. La referencia de archivos lista los tipos y límites.

#Qué más está al alcance

La base de conocimiento es parte del modelo, así que una pregunta sobre un packer, un formato de archivo o una convención de llamada trae técnica curada con una fuente y licencia en cada pasaje. Una string de versión que recuperas va directo a un lookup de CVE que devuelve CVSS, EPSS y estado KEV con fechas. Tanto la base de conocimiento como los datos de CVE se leen por la CLI y por la API también, así que un lote de muestras puede triarse desde un script, y el mismo modelo que explicó la función bosqueja el informe que va con ella. El mismo modelo que bosquejó el informe convierte un formato recuperado en un parser, así que pasas de los bytes a un script que funciona sin cambiar de herramienta.

#Dónde no encaja

La plataforma no decompila. No hay decompilador ni grafo de flujo de control de nuestro lado, y la vista previa de disassembly incorporada para en el inicio del archivo y en un conteo corto de instrucciones, así que el listado de verdad viene de tu propio Ghidra o IDA. Nada se ejecuta y no hay análisis dinámico, ni debugger ni emulación, así que el comportamiento de una muestra empaquetada en tiempo de ejecución es tuyo para observar en tu laboratorio. Las imágenes dan solo dimensiones, sin OCR aún. Y el modelo puede leer mal un offset, inventar una API o explicar mal una función, así que trata la explicación como pista y compárala con los bytes.

Mantén tu decompilador y deja que el modelo lea su salida. Pon un saldo pequeño en precios, pega una función y pide el script.