Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/mrexodia/ida-pro-mcp/llms.txt

Use this file to discover all available pages before exploring further.

Large language models are powerful analysis assistants, but they hallucinate and struggle with low-level details — especially integer conversions, obfuscated code, and numerical reasoning. A well-structured prompt steers the model toward tool-assisted analysis instead of guessing, dramatically improving the quality of results for reverse engineering tasks.

​
Starter prompt

The following minimal prompt covers the most important constraints for crackme-style analysis. It enforces tool use for number conversions, discourages brute-force shortcuts, and produces a written report. 
Your task is to analyze a crackme in IDA Pro. You can use the MCP tools to retrieve information. In general use the following strategy:

- Inspect the decompilation and add comments with your findings
- Rename variables to more sensible names
- Change the variable and argument types if necessary (especially pointer and array types)
- Change function names to be more descriptive
- If more details are necessary, disassemble the function and add comments with your findings
- NEVER convert number bases yourself. Use the `int_convert` MCP tool if needed!
- Do not attempt brute forcing, derive any solutions purely from the disassembly and simple python scripts
- Create a report.md with your findings and steps taken at the end
- When you find a solution, prompt to user for feedback with the password you found

​
Comprehensive analysis prompt

This prompt by @can1357 is better suited for thorough, multi-file reverse engineering work. It structures the workflow into phases, delegates deep dives to sub-agents, and ties documentation to project goals. 
Your task is to create a complete and comprehensive reverse engineering analysis. Reference AGENTS.md to understand the project goals and ensure the analysis serves our purposes.

Use the following systematic methodology:

1. **Decompilation Analysis**
   - Thoroughly inspect the decompiler output
   - Add detailed comments documenting your findings
   - Focus on understanding the actual functionality and purpose of each component (do not rely on old, incorrect comments)

2. **Improve Readability in the Database**
   - Rename variables to sensible, descriptive names
   - Correct variable and argument types where necessary (especially pointers and array types)
   - Update function names to be descriptive of their actual purpose

3. **Deep Dive When Needed**
   - If more details are necessary, examine the disassembly and add comments with findings
   - Document any low-level behaviors that aren't clear from the decompilation alone
   - Use sub-agents to perform detailed analysis

4. **Important Constraints**
   - NEVER convert number bases yourself - use the int_convert MCP tool if needed
   - Use MCP tools to retrieve information as necessary
   - Derive all conclusions from actual analysis, not assumptions

5. **Documentation**
   - Produce comprehensive RE/*.md files with your findings
   - Document the steps taken and methodology used
   - When asked by the user, ensure accuracy over previous analysis file
   - Organize findings in a way that serves the project goals outlined in AGENTS.md or CLAUDE.md

​
Tips for LLM accuracy

Use int_convert, always

Never ask the LLM to convert between hex, decimal, or bytes manually. Always instruct it to call the int_convert MCP tool. Conversion errors silently corrupt analysis.

Use Lumina / FLIRT

Apply Lumina or FLIRT signatures before starting an LLM session. Resolving standard library and open-source code removes noise and significantly improves decompiler output quality.

math-mcp for arithmetic

For complex calculations (cryptographic constants, hash checks), add math-mcp alongside IDA Pro MCP so the model can offload arithmetic to a dedicated tool.

Fix obfuscation first

LLMs perform poorly on obfuscated code. Remove obfuscation before starting analysis — see the section below.

​
Handling obfuscated binaries

LLMs will not perform well on obfuscated code. Before using an LLM to solve the problem, spend time removing the following obfuscation layers — preferably with automated tooling:
Encrypted strings produce unreadable decompiler output. Emulate or script the decryption routine and apply the results as comments or renamed globals before starting LLM analysis.
Import-by-hash loaders hide the Windows API surface. Resolve hashes to symbol names using known hash databases or a short script, then apply the names to the IDB.
Flattened control flow (e.g., from OLLVM) turns readable logic into an unrecognizable dispatcher loop. Use a deobfuscator such as D-810 or miasm to restore structured control flow first.
Encrypted code regions will decompile as garbage. Identify decryption stubs, emulate them, and reanalyze the decrypted bytes before asking the LLM anything about that region.
Opaque predicates, fake calls, and bogus instructions confuse Hex-Rays. Patch them out at the IDB level before decompiling.
Always instruct the LLM to use int_convert for any number conversion. Hallucinated hex-to-decimal conversions are among the most common and hardest-to-spot errors in LLM-assisted reversing.

Build docs developers (and LLMs) love

Get started for freeTalk to us