Why use NotHoly for reverse engineering

Reverse engineering is reading. You already have Ghidra, radare2 or IDA open, and the slow part is making sense of a decompiler dump, naming the locals, and writing the script that renames the next two hundred. A model helps there, but only if it takes the question without a lecture and reads what you paste. NotHoly does both. You keep your tools, and the model explains the output and writes the scripts. The reverse engineering use case has the longer workflow; this is about why it fits.

#Paste the output, get an explanation and a script

Decompiler and disassembler output is the input. Paste a function from Ghidra, a block from radare2 or a listing from IDA, and the model explains what it does, names the structure it sees, and marks the parts that look like a bounds check, a decode routine or a parser. Ask for a script and it writes one for your tool: a Ghidra Python pass that renames by pattern, a radare2 command sequence, an IDAPython snippet, a Frida hook to log a call. The script runs on your machine, against your sample, never ours. Because the model does not refuse the task, an unpacking routine, an obfuscated loop, an anti-debug trick or a licence check is read like any other code, as long as the work is in your scope.

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

#A first look before the heavy tool

Attach a binary in the chat, or run notholy analyze, and the static tools give a first pass without opening the decompiler. For an ELF or PE you get the SHA-256, the size, the entropy, the format, the entry point, the sections and the imports. For a sample you also get the strings and a disassembly preview of the start of the file. An APK gives the manifest and the text of each entry, and an archive gives its tree. Each file is parsed in a disposable sandbox with no network and a read-only root, nothing in it is executed, and a Python pickle is disassembled with pickletools, never loaded. High entropy and a short import table are enough to decide whether a sample is worth the hour in Ghidra. The files reference lists the types and limits.

#What else is within reach

The knowledge base is part of the model, so a question about a packer, a file format or a calling convention pulls in curated technique with a source and licence on each passage. A version string you recover goes straight to a CVE lookup that returns the CVSS, EPSS and KEV status with dates. Both the knowledge base and the CVE data read through the CLI and the API as well, so a batch of samples can be triaged from a script, and the same model that explained the function can draft the report that goes with it. The same model that drafted the report can turn a recovered format into a parser, so you move from bytes to a working script without changing tools.

#Where it does not fit

The platform does not decompile. There is no decompiler and no control-flow graph on our side, and the built-in disassembly preview stops at the first part of the file and a short instruction count, so the real listing comes from your own Ghidra or IDA. Nothing is executed and there is no dynamic analysis, no debugger and no emulation, so a packed sample's behavior at run time is yours to observe in your own lab. Images give dimensions only, with no OCR yet. And the model can misread an offset, invent an API or explain a function wrong, so treat the explanation as a lead and check it against the bytes.

Keep your decompiler and let the model read its output. Put a small balance on pricing, paste a function, and ask for the script.