-
Notifications
You must be signed in to change notification settings - Fork 471
Home
Welcome to the manticore wiki!
Explore the examples directory to find sample binaries and scripts that demonstrate the API.
We recommend starting with the following examples:
- multiple-styles writeup: demonstrates binary instrumentation and symbolic execution
- introduce_symbolic_bytes.py: demonstrates taint analysis
- Building an exploit: demonstrates crash analysis
More complex examples are also available in the manticore-examples repository
We're happy to offer bounties of $50, $100, or $200 for contributions to Manticore. Mugs and stickers are also available.
Contact us for a bounty payout if you:
- Publish a challenge writeup. We'll add you to the list of references on this wiki.
- Implement a new syscall or instruction. Help us get coverage of more complex binaries.
- Fix any bug! Try looking through the easy and help wanted labels.
Manticore and Angr are both Python-based symbolic execution engines that provide an API for binary analysis. Broadly speaking, Manticore is simpler. It has a smaller codebase, fewer dependencies and features, and (in our opinion) an easier learning curve. In exchange, Manticore lacks angr's advanced features like CFG recovery, ROP chain building, and binary patching. Manticore does not use any intermediate representation, and overall emphasizes staying close to machine abstractions. Angr, by contrast, raises native instructions to VEX IR, allowing it to support a wide variety of native architectures. Finally, Manticore supports exotic architectures such as the Ethereum Virtual Machine (EVM) and WebAssembly (WASM).
Not exactly. The Trail of Bits CRS used FrankenPSE to provide its binary symbolic execution capabilities. FrankenPSE and Manticore share the same heritage: PySymEmu (2013). The difference between the two stems from their respective use-cases.
Manticore is designed so an expert user can guide it, and therefore supports flexible APIs that help its users achieve specific goals. Manticore also supports more architectures and binary file formats.
FrankenPSE was designed to tightly integrate with the Trail of Bits CRS. This includes sharing the same program snapshot representation as the GRR fuzzer. FrankenPSE is also x86-only and uses microx, a lightweight, single-instruction x86 instruction JIT executor.
This happens because of a known bug in that specific manticore version. The gas limits are too small by default and then most complex transactions will just end with an OutOfGas exception. Even complex constructors could end like this failing to make the contract account. Fix, just change the gas defaults:
import manticore.ethereum
manticore.ethereum.ManticoreEVM.create_contract.__defaults__=(0, None, None, None, 0xffffffffffff)
manticore.ethereum.ManticoreEVM.transaction.__defaults__=(0xffffffffffff,)
You ran Manticore and it errored on something like this:
File "/root/.virtualenvs/manticore/local/lib/python2.7/site-packages/manticore/core/cpu/abstractcpu.py", line 1, in <module>
from capstone import *
File "/root/.virtualenvs/manticore/local/lib/python2.7/site-packages/capstone/__init__.py", line 230, in <module>
raise ImportError("ERROR: fail to load the dynamic library.")
ImportError: ERROR: fail to load the dynamic library.
This is a known issue in capstone. Try reinstalling capstone with the --no-binary flag.
I'm seeing "Invalid memory access" messages when I run Manticore on native binaries. I don't think these are correct. Is this a Manticore bug?
Maybe, but it might also be a bug in our disassembler dependency, Capstone. One way to check is to try using the --process-dependency-links
pip flag when installing Manticore. This will install the development branch of Capstone, which may contain useful bug fixes and potentially resolve the issue.
Manticore was installed successfully, the API is accessible via py scripts, but the commandline manticore
is not available
Your $PATH
can be set up incorrectly. Try running manticore via python -m manticore
.
It might be that you installed manticore with sudo
(e.g. instead of in a Python virtual environment) and so you don't have permission to run the manticore script.
If you are running our docker image, it might be that you overwrote the /home/manticore
path (e.g. by -v some_dir_on_host:/home/manticore
) which contains the manticore script in ~/.local
directory.
A deeper fix involves adding the correct directory to your PATH
environment variable. On Linux you can find manticore script by using locate
:
apt install locate
updatedb # may require sudo, updates locate cache
locate bin/manticore
The last command will find all paths that contains bin/manticore
and one of them should be your script. This way you can investigate whether:
- you lack permissions
- the script is there or is missing from the system
- you are not in a proper Python virtual environment
If you would like to cite Manticore, you can use this bibtex.
@misc{trailofbits-manticore,
title = "Manticore: Symbolic Execution for Humans",
author = "Trail of Bits",
howpublished = {\url{https://github.com/trailofbits/manticore}}
}