The angr team is happy to announce the release of a new major version of angr, angr 8! angr 8 brings a variety of large and potentially breaking improvements, as well as a bunch of smaller bugfixes. The highlights are listed below, but we also recommend checking the angr 8 section of the Changelog for a list of the major changes and the Migration Guide for help in migrating your project to angr 8.

As always, to contact the angr team please reach out on our slack. You can request an invitation here. For more information on how to get involved with the angr project, see here.

Highlights:

Python 3 Migration

The largest change in angr 8 is the migration to Python 3. As of angr 8, angr will be dropping all Python 2 support and moving to Python 3. For now, we will be targeting Python 3.5, with plans to eventually move to 3.6. The last Python 2-compatible angr release is version 7.8.9.26. This release pins the version numbers of all its dependencies so it should hopefully work far into the future. If you need any help migrating your code to Python 3, please see the Migration Guide.

Clemory API Refactor

With the upgrade to Python 3 come a number of changes to the Clemory API (project.loader.memory) around replacing the Python 2 string type with Python 3’s bytes. This should make working with Clemory easier, as well as yield significant performance benefits. We also recommend no longer using the cbackers and read_bytes_c functions, since the improved performance makes them unnecessary. Except for this, migrating code to use the new API should be relatively easy. For a detailed explanation of the changes, see the Migration Guide. Thanks to @rhelmot for the refactor!

For those interested, the commit with most of the changes can be found here.

Up to 5x Speedup in CFGFast

Driven by the need to recover the CFG of a large blob, the angr team has significantly improved the performance of CFGFast. Amongst other things, angr is now able to lift blocks without converting their statements into Python objects, perform more of the analysis in C, and avoid lifting any basic block more than once. All combined, we’ve seen this give a more than 5x speedup on large binaries! For changes and benchmarking details, see PR #1092. Thanks to @KevOrr for the binary that motivated the changes and @ltfish for the optimizations!