Number Heist on @curta_ctf is entering Phase 2! (72 hours left)

The goal of the heist: 

Prove to the vault there is a number that is both prime *and* composite at the same time. 😦

But how could that be possible?.... 🧵

=== The Three Primality Tests ===

There are three primality tests we must fool to make the vault *think* that a number is prime when in fact it is composite.

1. Wilson's Theorem
2. Circle Cutting
3. Filson's Theorem

It's actually easiest to start by solving #3 👇

=== Test #3, Filson's Theorem ===

Points Mathematicians have labored endlessly to secure this vault system.

They are expert in Point mathematics, but a bit inexperienced when it comes to Number Theory.

Following from Wilson's famous result:

(n-1)! ≡ -1 (mod n) <=> n is prime

They have derived Filson's Theorem:

(n-1)! ≡ 0 (mod n) <=> n is composite

Their proof relies on the following observation:

Assume n composite

In the set {1,2,..n-1}, since n is composite there must exist x0, x1 in the set such that, x0 * x1 = a * n for some integer a.

∴ (n-1)! can be expressed as a product of some integer and n.

And by extension (n-1)! ≡ 0 (mod n)

This is immediately obvious for composite numbers that are multiples of two distinct primes.

However not as straightforward for composite numbers who's factorization includes powers of prime numbers.

Spoiler alert: 

The mathematicians have been so focused on points that they never ran this through a theorem prover. They also forgot to prove the inverse.

There is most certainly a counter-example to this, it is up to you to find it 👀

Once we have our counter-example to Filson's we know which `n` to use in the heist, time to tackle primality test #1!

=== Test #1 Wilson's Theorem ===

This primality test relies on Wilson's Theorem, which we're well familiar with at this point:

(n-1)! ≡ -1 (mod n) <=> n is prime

The only complexity here is computing (n-1)!

The vault's developers have chosen to accept the factorials as pre-computed factorials from the msg.sender.

Their reasoning for doing so?

"because why not?"

We will now show them why not...

The vault accepts precomputed factorials as 3 bytes objects.

These bytes objects represent the factorial results which can fit into:

• 4 bytes
• 8 bytes
• 16 bytes

A gas optimization which will surely cost them more in audits and exploits than it will ever save in gas. :)

The vault then validates that the precomputed factorials are indeed the valid factorial values by comparing them to the VALID_FACTORIALS_HASH.

However notice that they are using abi.encodePacked to make this comparison...

Therefore we can shift which bytes objects contain the factorials, so long as the valid factorials are the aggregate of all 3.

But the logic for retrieving the computed factorial for n relies on each of the three bytes objects containing their appropriate factorials!

Now that we know our `n`, we can shift these factorial bytes exactly to fool the Wilson's test into thinking `n` is prime.

It's up to you to shift the pre-computed factorial entries and manipulate the corresponding memory in order to show the vault that (n-1)! ≡ -1 (mod n)

=== Test #2 Circle Cutting ===

We've already solved Test #1 and Test #3, now we're just left with Test #2, this can't be so bad!

Well sadly it's time to turn it up a notch. 😈

Circle cutting is a reference to the cyclotomic polynomials:

cyclo-
ˈsīklō - Greek
     1. circular
     2. relating to a circle

tomic
ˈtɑmɪk - Greek
     1. of or relating to cutting, division, sections, etc.

In short, the cyclotomics are polynomials whose complex roots are primitive roots of unity, but that's not so important for this heist. 😁

These polynomials appear throughout algebra and have many applications, though we're interested in just one esoteric application, primality.

Let Φ𝑛 be the nth cyclotomic polynomial, then we propose ∃ 𝑎 s.t.

𝑝 is prime <=> Φ𝑝−1(𝑎) ≡ 0 (mod 𝑝)

Can this be true?

Unlike Filson's, the Point mathematicians got their number theory right this time!

So how can we fool this primality test? 🤔

If only there were a way to change the definitions of the cyclotomic polynomials...

First, we'll note that the magicTome storing the cyclotomics is written into memory without updating the free memory pointer, a classic no no...

Combined with the fact that we're accepting arbitrary data from the caller in _checkWilsons you can probably see where this is going..

If we provide even more data than the vault expects when providing the precomputed factorials, these extra bytes can overwrite anything already existing in memory...

A perfect opportunity to overwrite a particular cyclotomic polynomial. 😉

That's all you need to pull off the heist!

Now it's up to you to:

• Find the counter-example to Filson's
• Shift the precomputed factorial bytes to fool Wilson's
• Overwrite the correct cyclotomic polynomial

There are 72 hours left, then I'll release a full PoC.🫡

Number Heist: Cracking the Vault

If I started doing this sooner I honestly think I would be 5x better at auditing by now...

Here's the simple system I'm using to crystalize my experience.

• Helps me learn, remember, free my mind
• Others get everything I've learned + my audit systems

The "Auditing Brain"🧵

There's 3️⃣ distinct pillars to this "auditing brain".

But before we get into those, let's understand why we even need an auditing brain.

Ever feel overwhelmed with the amount of information in Web3?

🤚 I do!

It's impossible to keep track of it all, especially when you're heads down on an audit.

🧠 That's where this auditing brain comes in.

We move the 10,000 auditing-related bits of information we have from RAM (our brain) into Storage (the auditing brain).

This way we do a much better job of keeping track of all the information we collect and we free up our brains to do the actual auditing.

So we want to offload all of this information, but what's the best way to do it?

That's where our 3️⃣ pillars come in:

1️⃣ Findings Systems
2️⃣ Areas
3️⃣ Protocols

You can track these however works for you, personally I've been really enjoying using Notion, all pictures are from an example Auditing Brain in Notion.

1️⃣ Findings Systems

This is the gold mine, every time you see a new common bug or vulnerability, you document it here -- with a system that can be used to uncover it.

With these documented systems, your auditing quality/expertise quite literally grows and compounds with every audit you do.

The best part about this is that you're building an exact set of systems that others can incorporate to boost their auditing immediately!

Here's a system for early return statements that miss important logic.

This is a real finding from a real codebase -- with this system it should never be missed.

(automatoooors, many of these could be turned into static analysis or AI flags -- Slither has many like this but some require a little more context/analysis)

This is especially attractive to me as I want to be able to build out a specialized auditing task force at @GuardianAudits.

Distilling everything down and structuring it into repeatable systems like this is the key to ensuring audit consistency.

However, we must keep in mind that a good deal of high impact vulnerabilities will be entirely unique to specific protocols and there cannot be any foolproof system to uncover them.

For these types of findings, I documented my entire approach here:

https://twitter.com/0xOwenThurm/status/1618386420456099841?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1618386420456099841%7Ctwgr%5E39a4971b0ab88f66772a43e2408bcba0bc2440a3%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fcdn.iframe.ly%2FfJ1ZXnE%3Fapp%3D1

2️⃣ Areas

Did a deep dive on upgradeable contracts and learned a ton of new info?

Store it here.👇

Areas are your easily accessible & organized notebook on specific topics you learn about.

When you're researching for an audit, or just learning in general, you'll often spend hours digging up valuable information and forming it into digestible chunks of understanding.

Do NOT throw away all that time by just keeping it in your brain (and ultimately forgetting) -- document it in an ✨Area!

Every time you dive into something new and do a research session, create an area for it and add to those notes as you go.

💡Pro-tip: write it down as soon as you think of it/learn of it.

I can't tell you how many times I've had a thought and literally forgot it within minutes.

I like to use a "General" area for these random notes and learnings that might not fit into a specific Area, but I want to get down immediately.

These notes can be organized into their respective area/finding system later.

3️⃣ Protocols

As we know, during an audit context is everything.

These areas are for your audit-specific notes, this way you can keep track of all your context and continue to build on it throughout the audit.

This is especially useful when working with a team and getting others up to speed as fast as possible!

And after the audit, you'll always have these notes to refer back to.

• Doing another review and looking back at the codebase after a month? → Get back up to speed by looking over your notes.

• Auditing a similar protocol? → Get a head start by checking your notes.

There it is, the complete framework for crystalizing your audit knowledge in order to suck as much value out of everything you do.

Going to try this out? How would you improve the system?👇

The Auditing Brain: A Simple System for Crystalizing Your Experience

I've had nightmares about AI replacing Security Engineers.

My whole business is security.

Will AI replace Auditors in 8-12 months?

Or is AI just another tool?

Well, I just attended an AI talk from the Ethereum Engineering Group...

Suffice to say, a revolution is coming. 🧵

Last week @drinkcoffee2010 lead an excellent presentation exploring the effectiveness of AI tools for discovering bugs in Smart Contracts.

As a dedicated bug hunter, my expectations for AI were low.

But the results were surprising.

We've got two things to cover today:

1️⃣ Results of @drinkcoffee2010's research
2️⃣ What this means for auditors, project builders, and crypto enthusiasts moving forward

1️⃣ Results

5 Unique Smart Contracts were given to 4 LLM models prompted to uncover all bugs and vulnerabilities.

The LLMs studied were:

- ChatGPT-3.5
- ChatGPT-4
- Perplexity
- Google Bard

So what were the contracts?

First Contract, StuffC.

The first contract fed to the models was seemingly nonsense logic, with opaque method names and lacking documentation.

Can you find the bugs here?

Well, the AIs had a bit of trouble with it as well.

Only GPT-4 was able to uncover a lack of access control for the stuff7 and stuff9 funtions.

Meanwhile there is also a logic bug here as well as a few possible improvements.

Second Contract, Pausable.

This is actually the same as contract 1, but with much better naming!

We can see all of the issues with this contract here.👇

This time GPT-3.5, GPT-4, and Bard were much more effective!

In fact, GPT-4 uncovered all of the high-impact issues with the Pausable contract.

Meanwhile Perplexity continued to provide correct, but nearly useless information.

Yet another fantastic reason to write good, clean, well documented & easy to understand code.

It will literally be easier for AIs to find bugs in!

However of course several improvements were left uncovered by all models:

- Making the Pausable contract abstract
- Implementing a custom error with revert

Third Contract, FlashLoan.

Now we're getting a little more advanced, can you spot what the main issue is here?

It's a Reentrancy!

We're making an external call to the receiver before mutating the profit state variable.

But what did the AI models have to say about this?

Only GPT-4 was able to uncover this Reentrancy attack, meanwhile all others failed to point out any valid issues.

GPT-4 spotted every issue in the Pausable and Flashloan contracts... is this our new $20/month auditor? 👀

Fourth Contract, Proxy.

Now we're getting more specialized, how do these LLMs perform on a proxy contract?

Can you spot the risks here?

There's potential for storage slot collision & function selector over-shadowing because of the declared public implementation address state variable!

Let's see how the LLMs did...

None of them uncovered the potential risks!

Perhaps this indicates the models are less proficient at specific risks associated with more specialized patterns such as proxies.

At least for now...

Fifth Contract, Upgradeable Pause

Now let's examine a more subtle example, here we have a Pause contract that aims to support upgradeability.

What could go wrong?

Well, of course we'll want a storage gap after the notPaused state variable.

And we'll need to use the upgradeable version of the AccessControl contract.

But could the LLMs spot this?

No! It seems these LLMs have a blind spot when it comes to upgradeability. 👀

2️⃣ Takeaways For The Future

So we saw that LLMs could actually find some real bugs in Smart Contract code.

Notably, GPT-4 was the strongest at consistently uncovering the most high-impact bugs.

However, there were still several bugs that could not be uncovered with present LLMs.

And let's keep in mind that the performance on real live Smart Contract systems is still unknown.

But regardless, we can clearly see that AI is capable of uncovering at least SOME valid bugs and vulnerabilities.

And it will only get better...

So what does this mean for Auditors?

LLMs are trained on text, they're simply huge statistical formulas trying to figure out what the most convincing next word is.

They've imbibed on thousands of security reports and billions of lines of code and are simply regurgitating that.

There's no formal logic going on here, LLMs are just applying every single resource they've seen to the code at hand.

And it turns out this can be quite useful.

But by the nature of the technology, it can never fully replace a human expert when it comes to new bespoke systems.

For Protocols?

AI is a new widely available & easy to use security tool to help secure your protocol.

The caveat?

Unless you're building something really simple, you'll still need a security expert to have a look.

But AI will help you pick out any surface level issues!

For Crypto Enthusiasts?

Safer projects, less hacks, more innovation.

With more & more powerful AI tools we can have a higher baseline of security across the ecosystem.

Think "no more public burn function exploits".

This will enable more rapid iteration and innovation that inevitably brings about the mass adoption we want.

So, that's the lowdown on AI in Web3 Security.

What do you think? Are these tools powerful enough to become a staple in the security process?

Will AI ever be powerful enough to replace auditors? 👇

AI and Security: Is A Revolution Coming?

Want to become a more advanced Web3 Developer/Auditor?

Then it's crucial to understand how memory works at a low level.

I compiled exactly what you need to know in just a few tweets 👇🧵

(💫 Takes 117 seconds)

1️⃣ What is memory?

Memory is just one of several areas where data can be stored by the EVM during tx execution.

In total there are 6 areas where information can be potentially written to and/or read from:

• The Stack
• Memory ←
• Storage
• Calldata
• Code
• Logs

On every message call to a contract, there is a fresh instance of memory available to write to and read from throughout the execution.

Commonly, memory will be used to store things such as strings and structs.

Essentially anytime you see the `memory` modifier.

Now! We need to cover how data is stored in memory.

Memory is laid out in 32-Byte words, a word looks like this 👇

The word above has 32 bytes, all of which are `00`. Pre-pended with 0x to signal that this number is in hex.

Count it out! (Or trust me)

This is an empty word, the value stored here is 0.

However of course a word can be nonzero and store an actual value.

See this word here👇 what value is stored?

The value stored here is 0x80.

This is in hex, let's convert it to decimal!

Remember each character in a byte corresponds to a single bit (either 1 or 0) and each bit counts for an increasing power of 2. 👇

Here we only have a single 1 in the 128 spot, therefore 0x80 in hex = 128 in decimal!

You can confirm this in a python shell with the following. 👇


2️⃣ How is memory laid out?

Okay we understand what words are, now we have to understand the default structure of memory when we're using Solidity.

Given that each word is 32 bytes, each word is laid end to end in memory and can be referenced by these N-byte values.

Take a look at the layout below 👇

Here we see 5 different words in memory, each has a reference to it's location on the left.

0x00 is the beginning of the very first word, it sits at 0x00 = 0 bytes.

0x20 is the beginning of the second word, it sits at 0x20 = 32 bytes.

E.g. the second word comes directly after the first word.

After the 32 bytes of the first word, that's exactly where the second word is located.

But why does the word at 0x40 store a nonzero 0x80 value while every other word stores zero?

Let's get into that...

3️⃣ Reserved Memory Spots

The first four words in memory:

• 0x00-0x1F
• 0x20-0x3F
• 0x40-0x5F
• 0x60-0x7F

Are reserved for individual special purposes by Solidity.

Let's talk about each 🔮

> 0x00-0x3F - The First Two Words

These two words are reserved as "scratch" space for particular computations like hashing functions by Solidity.

These two words should be avoided when manually interacting with memory.

Let Solidity have some room to do it's thing.

> 0x40-0x5F - The Free Memory Pointer

This word is dedicated to "pointing" to where it's safe to write new data to memory at!

We need this to see where we've already written so that we don't overwrite anything important!

Solidity always initializes the free memory pointer as 0x80 (128 bytes or the beginning of the 5th word).

But 0x60 is not storing anything as well, why not point to 0x60?

> 0x60-0x7F - The "Zero" Word

The word stored at 0x60 is intentionally left completely empty so that it can be used as the default initial value for dynamically sized arrays.

Do not write to 0x60! Or else you will get some very cool, yet annoying, bugs.

> 0x80 and beyond!

Just like the free memory pointer says, the word beginning at 0x80 and all subsequent words are completely empty and ready to be used!

Write whatever you want to them. 🙁

4️⃣ How do we interact with memory?

Okay so we understand how memory is stored and the exact layout out now.

But how do we interact with it? How do we actually write and read from memory?

Let's talk briefly about... OPCODES.

Opcodes are simple instructions to tell the EVM to do stuff.

E.g. "put this over there in memory"

or "Store this in that slot in storage"

We won't go too deep into opcodes today, but just know that there's a whole bunch of them and you can see them all in the Ethereum Yellow Paper.

The opcodes we're interested in today are MSTORE & MLOAD

> MSTORE

MSTORE will take two items off of the stack, a value and a location to store it at in memory.

And then can you guess what it does?

It stores that value at that location (or byte offset) in memory!

We won't dive into the stack today, that's a story for next time. 😉

> MLOAD

MLOAD is how we read from memory. We "load" in the value from a specific byte offset in memory.

You guessed it, this value also comes from... the stack!

That's cool and all but how do we actually use these opcodes?

Well... you use them every day!

Every time you use the keyword `memory` for a variable and change/read it's value, you're using these opcodes under the hood!

We can get a little closer to these opcodes by examining some in-line assembly (Yul) 👇

Here we're loading in the word value stored at 0x40 (the free memory pointer) and storing it in our `free_memory_ptr` variable.

Then we store the value `100000` at the `free_memory_ptr` location.

We can see what this produces by reading the actual memory slots with Chisel! (!md)

Let's see, what do we have here?

We can see we stored a hex value in the word located at 0x80: `0x186a0`.

Python tells us that's exactly what we stored there!

But notice, the free memory pointer above is still pointing to 0x80!

This is potentially dangerous, if we read the free memory pointer again at 0x40 we would incorrectly assume that there is nothing written at 0x80.

⚠️ It's important to note that mstore in Yul does not update the free memory pointer.

> MSTORE8

It's worth noting you can also store a single byte (8 bits) into memory with MSTORE8.

✅ And that's it... everything you need to know to have a working understanding of low-level memory in Solidity & the EVM!

Is there anything you would add to this? 👇

Understanding Memory in Web3 Development

🚀 Excited to share a comprehensive guide to your first audit.

We have four key elements to go through:

🧠 Auditing mindset
📚 System breakdown
🏷️ Audit tags
🔧 Utilizing attack knobs

Let's start with the most crucial part: the mindset.👇 🧵

🧠 A successful audit begins with the right mindset.

You have the capability to find valid, high-impact vulnerabilities in any codebase, you just have to believe it.

Believe it or not, confidence actually contributes a great deal to your bug-finding abilities.

Your first audit will be difficult, but it’s crucial in building confidence and understanding your ability.

🤔 Struggling with imposter syndrome? Push forward!

After you get your first finding, it literally becomes easier to uncover more because you simply see that it's possible.

Believe in your track record and let it fuel your confidence.

Once you believe that you can uncover vulnerabilities, you have to believe that they exist.

Virtually no codebase passes a thorough audit with zero findings.

💡 Prove this to yourself:

Check out past C4/Sherlock contest reports.

Findings are everywhere – if you believe they're there and that you can find them, you will.

📚 Once our mindset is sorted, we need to take an organized methodical approach when we open the codebase.

The first goal is to understand the system.

What it does and how it does it.

Once you understand the system, potential vulnerabilities and bugs will be obvious.

We need to gain context on the system as quickly as possible so we can get to this point of all-seeing and all-knowing in a codebase.

So how do we break down the system?

List out the tasks that need to be accomplished by the system.

Now walk through each relevant codepath in the contracts until you understand how each task is accomplished.

🧩 This way we can break up even mammoth codebases into digestible atomic units of logic.

🏷️ We're walking through a codebase getting context and we notice something.

We need to understand the entire codebase to be able to asses impact, but we really want to dig into this issue right away.

Now audit tags come in.

✍️ Leave audit tags as notes in the code when you notice potential issues.

If you notice a potential reentrancy or have a question about a particular edge case, leave an audit tag.

We have limited time during an audit, so efficiency is crucial.

Don't get stuck focusing on those issues, remember, we need to focus on gaining context as fast as possible.

You can always grep for "@audit" and find the tags again.

We've walked the whole codebase and now have context!

What next? 🔧 Introducing: knobs.

Knobs are just anything of note in the codebase that could potentially cause bugs or vulnerabilities.

External call to an arbitrary address? → Knob
Potential divide by 0 revert? → Knob
Critical piece of state can be overwritten? → Knob
Attacker can front-run to gain an advantage? → Knob

🔍 Keep a running list of these knobs.

Once you have full context on the system, review the knobs you've collected to see if they can be twisted to uncover potential vulnerabilities.

Often times multiple knobs can be mixed and matched in bespoke ways to yield interesting unique findings.

As you do a second pass on the system, refer back to your list of knobs and take an offensive mindset -- see what you can break based on all the knobs you've collected.

🔄 Keep these four key points in mind for your first and all subsequent audits:

1️⃣ Build confidence in your auditing ability
2️⃣ Understand the system first
3️⃣ Use audit tags to note potential issues
4️⃣ Track knobs and leverage them for unique attacks

The Comprehensive Guide to Your First Audit

The solo auditor movement is pivotal to the advancement of DeFi.

Entrepreneurial teams need access to affordable quality security.

Highly skilled solo auditors can provide just that.

When I was building in 2021 there were no reputable options for less than $20,000.

Counter view is that with only one set of eyes there is still a decent likelihood that things are missed.

I can't tell you how many times @dannygfromnyc has found something that I would never have seen.

Is the solution to simply hire multiple solo auditors? 🤷

The Importance of Solo Auditors in DeFi Security

1️⃣3️⃣ Cheat-codes to get your Smart Contracts ready to audit for maximum security! 🧵 👇

You'll be kicking yourself if you don't do #7 😉

1️⃣ Documentation! 📖

Time is of the essence during an audit!

Here are a few things to document to speed things up:

• High-level goals of the system
• Goals of each contract
• The codepath for each goal
• Anything users should not be able to do
• Formulas used

2️⃣ Static Analysis

🐍 Slither is a fantastic tool that will flag any code that leads to common vulnerabilities.

Run it as a first pass before the audit!

https://github.com/crytic/slither

3️⃣ Examine All External Calls

⚠️ External calls are the riskiest part of any system, pay special attention to them and flag untrusted calls for auditors.

Keep in mind that an arbitrary address can:

• Revert to DoS
• Return nonsensical results
• Gas grief
• Reenter

4️⃣ Use CEI Uncompromisingly

Check-Effects-Interactions describes how you should structure each function.

👇 Follow this order as closely as possible:

• Require statements
• State updates
• External calls

This way you avoid all sorts of nasty Reentrancy attacks.

To get up to speed on the many permutations of Reentrancy and see how it might affect you, check out my complete guide on Reentrancy here. 👇

https://www.youtube.com/watch?v=3T1t2ginfTg

5️⃣ Call out your assumptions!

Share all of the invariants the system purports, this gives auditors exact rules they should try to break.

If one of your invariants doesn't hold, you'll certainly want to know about it!

6️⃣ Do a kickoff call to share context

The #1 time suck in an audit is gaining context on how the system functions.

Invincible Mario Super-Star mode through that phase by downloading all of your knowledge on the system into the auditor's minds with a recorded kickoff call.

🛑 If one of these so far gave you something actionable to try out before an audit:

Go to the first tweet in this thread, press the Like + Retweet button, before you come back and move on. 🫡

7️⃣ Get A 3rd-Party Initial Review

A quick review from an independent auditor can go a long way toward pointing out surface-level issues that ought to be addressed before the audit.

This way the real audit can focus on the nitty-gritty → You get a higher tier of security.

If you have a project and would like to get it reviewed before you move on to a full-fledged audit, shoot me a DM.

I will personally review your project to point out any glaring issues/risks for 🆓 if you send me a message in the next 24hrs.

8️⃣ Call Out Areas Where You're Unsure

Any questions you have related to specific functions, attack vectors, integrations -- leave them as comments!

These are perfect roadmaps for auditors to dig into and uncover critical edge cases.

9️⃣ Have An Open Line Of Communication

Encourage your auditors to come to you with attack ideas, questions, and suggestions during the audit.

Again, time is precious during an audit. Combining your context with the auditor's knowledge/creativity is a huge win for efficiency.

🔟 Code Freeze

Typically the most vulnerable code happens to be the most recently written code.

You want to go into an audit with the most secure code to begin with.

🧊 Freeze the codebase and internally review it for at least a few days before the audit.

1️⃣1️⃣ Engage Auditors Early

Especially for large projects, the earlier you engage auditors the better.

• The auditors get a head start on context
• Development is security oriented from the start
• Booking is easy
• Launch can be faster

1️⃣2️⃣ 100% Code Coverage

Again, we want to enter an audit with the most secure code possible!

Thoroughly testing the system is low-hanging fruit.

Now the audit can focus on juicy exploits rather than baseline functionality issues.

Strive for 100% or get as close as possible.

1️⃣3️⃣ Provide Your Test Suite

Your test suite is a hidden piece of documentation, it shows:

• How the protocol expects to be used
• What areas have been under-verified
• Quick copy+paste to make a new test/PoC

Give it to auditors for more context & utility!

Those are the 13 cheat codes to have the most productive audit possible!

For 7️⃣, I will personally review your project and point out any glaring issues/risks to be fixed before an audit for 🆓 if you send me a DM in the next 24hrs.

13 Cheat-codes for Smart Contract Auditing

⚠️ The Ultimate Guide To Reentrancy just dropped! ⚠️

We covered:

• Classic Reentrancy
• Cross-function Reentrancy
• Cross-contract Reentrancy
• ERC-721 Reentrancy
• ERC-777/677 Reentrancy
• Readonly Reentrancy
• Reentrancy detection system

👇
https://www.youtube.com/watch?v=3T1t2ginfTg

I made Read-only Reentrancy as simple as possible!

No longer does this exploit need to be mysterious nor complex.

Read on(ly) to understand exactly what Read-only Reentrancy is and how you can spot it in your next audit.👇🧵

Read-only reentrancy is infamous for several exploits disclosed by @chain_security relating to Curve pools from roughly one year ago.

The disclosures netted over $100M in funds at risk! 🤯

However, when it comes to understanding this vulnerability, things start to get murky when you have to first explore the intricacies of Curve.

So we're boiling it down to the most simple form. 💫

Here's what we're going to cover:

1️⃣ What is Read-only Reentrancy?
2️⃣ The absolute simplest example
3️⃣ How you can spot this in your next audit

Let's get to it! 🤝

1️⃣ What is Read-only Reentrancy?

Read-only Reentrancy is really just a special case of classic reentrancy that emerges from the same root cause:

→ A piece state that is updated only after an external call. ←

The only difference here is that the attacker "re-enters" into a third-party system, rather than entering into the same system to exploit an outdated piece of state.

That third-party system will *read* this outdated state variable from the underlying system and ultimately get exploited because of it!

That's it, that's all there is to it.👌

Remember, Read-only Reentrancy arises when a piece of state is updated *after* an external call to an arbitrary address.

It is exploited in third-party systems relying on this piece of state.

2️⃣ The absolute simplest example

Okay so let's have a look at this in action!

Let's consider a very simple vault system, where all you do is deposit and withdraw, with one extra view function.

`isAllowedToWithdraw` - which simply tells if a user has deposited enough to withdraw a certain amount.

Here's the code👇

Can you spot the Read-only Reentrancy here?

Take a minute, try to find it before scrolling forwards!

⌛ ...

⚠️ The balances mapping isn't updated before calling the `msg.sender`!

This way a malicious actor can withdraw and get their withdrawal amount & control over the tx execution before their withdrawal is reflected in the balances mapping.

The upshot?

The `isAllowedToWithdraw` view function will return true for the malicious actor's original balance -- however they have already withdrawn some of this amount! 😱

Any system that relies on the `isAllowedToWithdraw` view function to credit users with tokens, NFTs, collateral, etc... is vulnerable.

The malicious actor may re-enter into such a system before the balances mapping is updated and exploit the third-party system based on the outdated balances mapping.

3️⃣ How you can spot this in your next audit

All you have to do is note any state variables that are updated after external calls to an arbitrary address.

If any of these state variables could potentially be utilized by a third-party system building on top, you have yourself a potential Read-only Reentrancy. 🤝

Here are some potentially juicy outdated states:

• AMM Pool Price
• Vault Deposits
• Collateral Amounts
• Auction Price

Look for anything like these and more! 🫡

BONUS Trivia 😉

Can you tell me why the withdraw function in our contract above is immune to classic reentrancy itself?

All right that covers everything you need to know about Read-only Reentrancy and how exactly you can spot it in the future.

I hope this made this mysterious exploit quite clear! 🙏

Simplifying Read-Only Reentrancy Exploits

👉 Just getting into Web3 Security? This one's for you 👈

If you're reading this, you're early. The tales of tech newbies making 500k/y within months are true.

Here's a series of videos explaining EXACTLY how you can get in and make this your reality. 🧵 👇

⚠️Disclaimer: It is simple, but not easy.

In the following videos, I tell you absolutely everything I know about becoming a proficient and lucrative Smart Contract auditor.

It is up to you to put in the work and write your success story.

If you ever need help, my DMs are open!

1/ The 4-Step Roadmap To Becoming An Auditor

https://youtu.be/vlRauaoboFI

2/ How Exactly I Got Into Auditing

https://youtu.be/a1AOAN0SBwo

3/ A Complete Smart Contract Auditing System

https://youtu.be/5g-Hzw5ind8

4/ Put It All Together & Get To Multiple Six Figures Solo

https://youtu.be/3J9zTHGgq1k