What I’m about to share with you took me from:

“I have no freaking idea what this code base does! It is so freaking big, I will lose my job!!”

To:

“I can predict what the next function call will be, and I can locate the exact line of code that will cause a vulnerability”

This methodology was developed throughout a year of auditing different types of protocols with different architectures and varying degrees of code quality.

So let’s dive into it.

This methodology consists of the following strategies:

1 - EntryPoint Selection

2 - Function Documentation

3 - Flow Identification

4 - Cross-Flow Logic Analysis

5 - Let’ wreck it!

4 out of the 5 stages are concerned with the recon of the code base, which is all about getting very familiar with what's happening under the hood.

( Recon is a term usually used in the military and it means to conduct an exploratory survey of the target )

I found that the more I spend in the recon phase, the more I “stumble” upon vulnerabilities. This phase can even take more than 50% of the whole auditing time.

It is okay to feel lost now. You have to remember that the goal here is not to find vulnerabilities but rather to build a working understanding of what the codebase does.

Truth be told, you usually don’t need 100% understanding in most cases to conduct an excellent security engagement. Sometimes, the timeline does not allow for a full understanding of the protocol.

What's cool with recon is that you can also catch low-hanging fruits, which gives you a major boost!

Entry Point Selection

We need to find a starting point for our journey. A core contract is usually the way to go here. For instance, if you are dealing with a pool contract, then a good entry point is the pool itself. These contracts will usually contain the majority of the flows happening in the protocol.

Assuming we start from a file called Pool, we can see that it inherits from another contract called PoolBase. And PoolBase also inherits from PoolLogic which interacts with a library under the hood for business logic.

So we have something that looks like this:

Now, we want to start working from the very base contract, because the logic flows down the inheritance chain. So we start by understanding what is happening in the bizLogic library.

Then we move down the chain until we reach the Pool contract. For each contract, we closely study and document its logic, more on that in the Function Documentation stage.

You want to do this step multiple times if needed until you have an intuitive understanding of what is happening in the core contract, because this is usually the contract utilizing the logic of the entire chain.

Keep in mind that you don’t have to start with a core contract at all. You can pick any contract and apply the same tactic to it. Isolating the code base into multiple small, multiple graphs will make it extremely easy to tackle each part on its own.

The graph for this example looks like this:

It will also be very useful in the Cross-Flow Logic Analysis stage and threat analysis (more on that later)

I cannot stress this enough, it is perfectly normal not to find anything during recon. Your #1 priority during this stage is to build an understanding of what the code is doing, not to find issues.

So, don’t panic if you can’t find anything, you WILL make it rain later on.

That’s it for now! In the meantime, try to apply this tactic to your current projects, and let me know what you think!

In the next article, we will go through Function Documentation !