Solidity Lab
  • 🧪Guardian - Solidity Lab
  • 📚Encyclopedia of Solidity Attack Vectors
    • 🔁Reentrancy
    • ✋Contract Cannot Accept Ether DoS
    • ⛽Gas Griefing
    • 👿isContract Manipulation
    • 🏃‍♂️🏃♂ 🏃♂ Front/Back-Running
    • ⏪External Call Reverts DoS
    • 🕐block.timestamp Manipulation
    • 🎣tx.origin Phishing Attack
    • 📩Directly Sending Funds
    • ✍️Signature Malleability
  • 📚Encyclopedia of Common Solidity Bugs
    • ➗Division Precision Loss
    • ‼️Unexpected Panic Revert
    • 👬Matching to/from Addresses
    • ⏸️Forget to Update Parallel Data Structures
    • 🚫Lack of Success Checks
    • 🤷‍♂️🤷♂ 🤷♂ Lack of Access Control
    • 📝Inaccurate Allowance
    • 🔼Overflow/Underflow
    • 💲Unsafe ERC20 Operations
    • 🦺Lack of Exception Handling
    • ✖️Duplicate Values
    • ⚖️Asymmetrical Code
    • 🛑Constant Protocol Parameters
    • ⬆️Storage Not Updated
    • 🕵️Delete Item, Unupdated Index
    • 🎁Native vs Wrapped Handling
    • 1️⃣1⃣ 1⃣ 1⃣ Off By 1
  • 📙The Auditors Handbook
    • 📝The Auditing Process
      • 0️⃣0⃣ Audit Setup/Preparation
      • 1️⃣1⃣ Beginning The Audit
      • 2️⃣2⃣ The Meat of The Audit
      • 3️⃣3⃣ Writing Tests & PoCs
      • 4️⃣4⃣ Wrapping Up The Audit
      • 5️⃣5⃣ After The Audit
      • 6️⃣6⃣ Addendum
Powered by GitBook
On this page
  • Tests
  • PoCs
Edit on GitHub
  1. The Auditors Handbook
  2. The Auditing Process

3⃣ Writing Tests & PoCs

Time to test!

Tests

If the test coverage is poor, fill in the gaps. By writing tests, you get a more intimate understanding of the contracts + there’s a good chance you find a bug (untested code is hearsay). There are some bugs that are much more obvious to a runtime execution than to human manual analysis.

Test suites should aspire to reach 100% code coverage, the behavior of untested code paths is dubious.

While you're writing tests, you may encounter some odd behaviors that you didn’t realize before — @audit tag them and explore these further after you finish your current thought/test.

PoCs

Now take the time to PoC any findings/attack vectors that you haven't already. It’s important to comment throughout each PoC sufficiently, both for your own understanding and others.

While writing a PoC, you might discover that the system does not function as you thought it did, and your attack is not viable. In this case, go back to the drawing board and examine how your attack could be tweaked (the list of knobs is helpful here) so that the attack is valid.

Now is a good time to use security tools to verify invariants you identified during the previous stage, etc... ("Security Tools" under construction)

Previous2⃣ The Meat of The AuditNext4⃣ Wrapping Up The Audit

Last updated 2 years ago

📙
📝
3️⃣