You're missing out! If you're not writing detection modules.

We recently released a new tool called napalm, a detection module IDE. Napalm makes it easy to set-up a multi-tool custom detector project. Not stopping there, napalm provides an all-out quality of life upgrade for security researchers that like to write their own detection modules.

A tool that helps you develop detection modules is great, but it occurred to me that lots of people are not writing their own detection modules yet.

This is unfortunate, because building your own set of detection modules doesn’t just speed up your workflow, it might just save you from missing a vulnerability!

Its time to jump down the rabbit hole and get automation pilled!

Automation

Static analysis doesn’t necessarily have a good reputation.

The main issue? False positives! Unfortunately it’s usually very difficult (often impossible) to build good generic detectors that find all the issues without also finding many false positives.

💡 False Positive: An issue reported by a static analysis tool that isn’t actually a valid issue.

For example, a tool might report a re-entrancy vulnerability that’s impossible to actually be exploited.

Making matters worse for security researchers is the fact that public static analysers rarely find interesting issues. After all, developers and other researchers have access to the same tools. Everybody has already found and fixed the interesting issues, leaving only spurious warnings.

As a result I’ll often hear security researchers dismissing static analysis as a technique that “will never replace them”. This is unfortunate, as static analysis is an insanely useful tool to have.

Automatoors

Still, a not insignificant amount of security researchers eventually find themselves building static analysers.

The common factor amongst these researchers seems to be that they will find themselves discovering the same issues, over and over and over.

After a time they reach a breaking point and find themselves bored writing a report for the same issue time and again. At this point they’ll often write a script to discover the issue, and automatically generate an issue report.

This is the quintessential power of static analysis! Taking care of repetitive work, so you can focus on the interesting vulnerabilities!

Scaling Up

This initial set of scripts, often using regex, is a gateway drug to the more complex static analyses.

AST - An abstract syntax tree is a tree like representation of a source file. Using a programming language like javascript, you can write simple detectors that look for patterns in this tree. The structure of the AST makes for an easier time recognising patterns, than you would have writing regular expressions (regEx).

Intermediate Representation - Static analysers such as slither provide an extra upgrade. They’ve taken the raw solidity and translated into a custom new programming language. An intermediate representation. This IR is designed to be simple, easy to write detectors for, and stable.

Data & Control Flow - Static analysers like slither or securify often make it easy to do advanced analysis that take into account how data flows through the program, and possible execution paths. Advanced analyses such as this make it easier to write more precise detection modules that discover fewer false positives!

💡 Static Analysis devs using advanced techniques like IR & control-/ dataflow analysis will often underestimate the amount of things you’re able to detect with a simple technique like AST based pattern matching!

Sharing is Caring

Writing detection modules to optimise your own workflow is great, but the community will love you if you go a step further and share your detection modules!

🚀 Napalm makes sharing your detection modules a breeze!

All you need to do to share a poetry project is setup a pypi account and run poetry publish in your napalm project!

Check out this guide for more info!

Custom detection modules are extremely useful when you’re working in a team!

Usually, every team has a diverse set of team members, each having built their own unique skillset. This is one of the reasons why you usually want multiple eyes on the same audit. Different people are more likely to find different bugs.

Unfortunately it’s not financially efficient to have the entire team on an audit.

Detection modules allow us to solve part of this issue. Each team member can individually contribute some of their expertise to each audit by aggregating their own set of custom detection modules. Sharing those modules with the rest of the team allows them to (partially) contribute their unique experience to every audit/ security review.

You’ll find that a lot of high-performing auditing teams have a shared set of detection modules.

💡 Napalm is incredibly useful for setting up a shared repository with custom detection modules.

Get started now!

Let’s go!

Writing your own detection modules is 100% worth the effort!

You’ll find yourself:

• doing less repetitive work
• finding more issues
• with appreciative friends (if you decide to share your modules)

I recommend semgrep as a starting point for your first modules, it’s easy to set up and will have you productive in no time!

Once you’ve got a couple detection modules, set up a napalm project and start experimenting with slither and some more advanced detection techniques.

All posts