Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Everyone has their own auditing methodology. Read the docs, don't read the docs, start with code, end with ... At the end of the day, the goal is to find all of the bugs. Most importantly for payouts in contests, are the unique findings. This author gives us some insight into some of their recent success.

According to the author, projects with good tests have made them afraid to go hunt for bugs. They thought that if the code was really well tested then no bugs would exist in it. So, they decided to not look at the existing tests written by devs anymore.

Now, they wrote all of their own tests from from scratch. They do this by getting a basic setup with a happy path. To them, the debugging is the most important part. They learn about the proper states of the project, right/wrong inputs and much more about the codebase.

With a simple happy path going, they start writing their own tests to check for edge cases in the system. The blind spots of one person are going to be different than you, now that you're writing the tests. In a week long audit, they will spend the first 2-3 days writing tests and the rest of the time on code review.

I find this methodology to be pretty interesting but frustrating. I personally read the docs to try to understand the purpose and flow of the project first. By doing this, you're essentially reverse engineering a protocol to write tests, which feels wasteful to me.

The nice thing is that the uniqueness is what makes this work. If everyone did this then it wouldn't be nearly as effective. In the bug bounty space, niche tactics and weird vulnerabilities are the most important thing. Recently, they had 6 highs, including 2 solos at a Good Entry Code4rena contest. Thanks for the knowledge!