Have an smooth and easy angr Experience
A few days ago, I found myself staring at a reverse engineering challenge that had me stumped. The usual tools in my toolkit weren’t cutting it, and I needed a different approach. That’s when I decided to give angr a try. I’d heard about this symbolic execution framework before, but it always seemed a bit intimidating, especially since I was working on an M1 Mac and wasn’t sure about ARM compatibility.
To my relief, I discovered that with the right setup, angr works beautifully on Apple Silicon. After setting up a proper development environment (more on that later), I was able to dive in. The initial learning curve was there, but it wasn’t as steep as I’d feared. What really surprised me was how quickly I could start getting useful results, even as a beginner.
What Makes angr Special?
Angr is more than just another reverse engineering framework – it’s a powerful platform that combines static and dynamic analysis with symbolic execution. Here’s what makes it so special:
- Symbolic Execution Made Accessible: angr abstracts away the complex mathematics behind symbolic execution, allowing you to focus on solving the problem at hand.
- Cross-Platform Support: Whether you’re on x86, ARM, or even dealing with MIPS binaries, angr has got you covered.
- Python-Powered: The entire framework is Python-based, making it incredibly accessible and easy to integrate with other tools.
My First angr CTF Challenge
I recently tackled the first challenge in the angr CTF series, and it was an eye-opening experience. The challenge seemed simple at first glance – find the input that makes the program print “Good Job.” But the real magic was in how angr could automatically find the solution.
The Aha! Moment
When I first ran my angr script and saw it automatically find the correct input, it felt like having a superpower. The fact that I could write a few lines of Python and have the computer essentially “solve” the challenge for me was mind-blowing.
# The magic happens here
project = angr.Project("./00_angr_find")
initial_state = project.factory.entry_state()
simulation = project.factory.simgr(initial_state)
simulation.explore(find=0x4012d2)The Technical Challenges
Of course, it wasn’t all smooth sailing. I faced several challenges that made the journey even more rewarding:
1. Building a Cross-Platform Environment
The Challenge
Working on an M1-M4 Mac (ARM processor) presents some unique challenges. The default Mach-O binaries on macOS aren’t directly compatible with angr’s analysis, and many CTF challenges are distributed as ELF binaries. I needed a solution that would:
- Run ELF binaries seamlessly on ARM64
- Provide consistent behavior across different development machines
- Make it easy to share and reproduce the environment
The Docker Solution
I created a comprehensive Docker-based development environment with these key components:
Key Features
- Multi-architecture Support: Handles both 32-bit and 64-bit ELF binaries through QEMU user-mode emulation
- Development Tools: Includes gcc, g++, make, and essential build tools
- Debugging Environment: Comes with gdb and radare2 pre-installed
- Python Environment: Set up with Python 3 and angr
Base Image
FROM ubuntu:22.04 # Essential build tools and Python environment RUN apt-get update && apt-get install -y \ build-essential \ gcc-multilib \ g++-multilib \ python3-pip \ python3-dev \ git \ gdb \ radare2 \ findutils \ && rm -rf /var/lib/apt/lists/* # Install angr and dependencies RUN pip3 install --no-cache-dir angr # Create a non-root user RUN useradd -m ctf USER ctf WORKDIR /home/ctf
Build System
I created a rebuild_all.sh script to automate the compilation of all challenge binaries:
#!/bin/bash
set -e
# Compile all C source files in the current directory
for src in *.c; do
if [ -f "$src" ]; then
echo "Compiling $src..."
gcc -m32 -no-pie -fno-pic -o "${src%.c}" "$src"
fi
doneWorkflow Optimization
Volume Mounts: The container is run with-v $(pwd):/ctf for seamless file access</li>
Development Loop:
- Edit code on host machine
- Run and test in container
- Debug with gdb/radare2 as needed
Reproducible: The entire environment is defined in Dockerfile and scripts
This setup not only solved my immediate compatibility issues but also created a portable, reproducible environment that works the same whether you’re on an M1-M4 Mac, Intel Mac, or Linux machine.
2. Understanding the Binary
The Learning Curve: Understanding how to properly analyze the binary and identify the correct addresses to target took some time, due to my first time user learning curve. I can see how once I understand exactly what I’m looking for, how angr accelerates finding the variables in static and dynamic analysis.
The Bigger Picture
What started as a simple CTF challenge turned into a deep dive into setting up 32-bit ELF docker Containers, binary analysis, symbolic execution. The skills I’ve learned while working with angr have made me a better reverse engineer and platform engineer.
Working with angr has been an interesting addition to my reverse engineering toolkit. It offers a different approach to binary analysis through symbolic execution, which can be particularly useful for certain types of challenges. Like finding groups of things in running binaries.
While there’s definitely a learning curve, I found that I spent most of the first session in infrastructure enginering. Use my Dockerfile I listed above to skip past the container work and get right into using angr.
If you’re interested in binary analysis or automated exploit development, angr is worth exploring. The documentation and community resources make it accessible, and the ability to automate certain analysis tasks can be a real time-saver.
Happy hacking! 🚀
This post was inspired by my work on the angr CTF challenges. You can find my solutions and documentation in the repository.
