Get Into The Attacker's Mindset
Summary
TLDRIn this video, the speaker delves into the essence of the 'attacker's mindset,' a crucial perspective for uncovering vulnerabilities and bugs in smart contracts. By adopting an offensive approach and actively seeking to disprove security protocols, auditors can significantly boost their success rate in identifying critical flaws. The speaker outlines four key steps to cultivate this mindset, including incentivizing oneself appropriately, believing vulnerabilities exist, collecting 'knobs' or potential vulnerabilities, and combining them to construct exploits. Emphasizing the importance of avoiding pitfalls that undermine this mindset, the speaker provides a real-world example demonstrating how this approach uncovered a critical risk-free trade vulnerability in a perpetuals exchange protocol.
Takeaways
- π Adopting an attacker's mindset is crucial for uncovering vulnerabilities and bugs in smart contracts. Think offensively to find what developers, thinking defensively, may have missed.
- π° Incentivize yourself properly to find bugs by structuring your compensation based on the number and criticality of vulnerabilities discovered.
- π§ Mentally prepare yourself to believe that bugs and vulnerabilities exist in the codebase you're auditing.
- π While auditing, collect and note down interesting behaviors, missing lines, or any peculiarities in the code ('knobs').
- 𧩠Combine these 'knobs' to construct unique and critical attack vectors, like puzzle pieces.
- β οΈ Avoid charging upfront fees that remove the incentive to find vulnerabilities, as it may subconsciously convince you of the protocol's security.
- π« Never assume the codebase is secure or agree with the developers' assumptions. Question everything from the ground up.
- π The example exploit involved delaying order execution by reverting with an 'empty position' error, then toggling the revert condition to execute the order at a favorable price.
- π€ Leverage the two-step order execution system by executing orders with outdated prices from when the order was created.
- ποΈ Join communities like lab.guardianaudits.com to learn from other auditors, collaborate on audits, and access comprehensive smart contract security training.
Q & A
What is the attacker's mindset, and why is it important for smart contract auditing?
-The attacker's mindset is a way of looking at code with the intent of breaking as many things as possible, rather than verifying or proving its security. It's important because adopting this mindset makes an auditor more likely to uncover vulnerabilities by actively trying to disprove the protocol's security.
What are the four key steps to get into the attacker's mindset?
-1) Incentivize yourself correctly by structuring compensation based on the number and criticality of vulnerabilities found. 2) Personally believe that there are bugs and vulnerabilities in the codebase. 3) Collect 'knobs' or interesting pieces of behavior as you go through the code. 4) Combine the knobs to construct potential exploits.
What are the two critical mistakes that can prevent an auditor from getting into the attacker's mindset?
-1) Not getting the incentives right, such as charging all the money upfront regardless of findings, which incentivizes spending as little time as possible on the audit. 2) Not believing that vulnerabilities exist in the codebase, leading to a mindset of verifying rather than attacking.
In the GMX V2 example, what was the first 'knob' or interesting behavior noticed?
-The first knob was the two-step execution process, where a keeper executes orders using prices from the block when the order was created. This opened up the potential for a risk-free trade if the execution could be delayed until a more favorable price movement.
What was the second knob discovered, and how did it contribute to the potential exploit?
-The second knob was that limit orders that reverted with an 'empty position' error would be retried instead of canceled. This allowed for delaying the execution of the order.
What was the third knob, and how did it enable the risk-free trade?
-The third knob was the ability to set the remaining collateral amount to zero while still having non-zero size in USD and tokens. This allowed the order to revert with the 'empty position' error, delaying execution until a favorable price movement occurred.
What was the final knob that allowed toggling the exploit on and off?
-The final knob was an if statement that set the initial collateral delta amount to zero if the order size matched the position size. By decreasing the position size to match the order size, this condition could be met, allowing the order to execute without reverting.
How does the provided example demonstrate the importance of combining multiple 'knobs' to construct a successful exploit?
-The example shows how several individual behaviors or 'knobs' had to be pieced together strategically to enable the risk-free trade exploit. Each knob on its own was not sufficient, but by combining them in a specific way, a critical vulnerability was revealed.
What advice does the speaker give for finding interesting vulnerabilities and adopting the attacker's mindset?
-The speaker advises auditors to be malicious in their approach, actively trying to break things and keeping track of interesting behaviors (knobs) as they go through the code. These knobs can then be combined to construct unique and critical attack vectors.
What resources does the speaker recommend for aspiring smart contract auditors?
-The speaker recommends joining the Guardian Audits community (lab.guardianaudits.com) to connect with other auditors and participate in team audits. He also mentions a paid training resource he collaborated on, which aims to provide thorough training in smart contract security auditing.
Outlines
π§ Embracing the Attacker's Mindset for Effective Vulnerability Discovery
Owen, founder of Guardian Audits, emphasizes the importance of adopting an attacker's mindset for uncovering vulnerabilities and bugs in smart contracts. This mindset involves thinking offensively to find issues that defensive-minded developers may overlook. Owen outlines four key steps to adopt this mindset: incentivizing oneself appropriately, believing in the presence of bugs, noting down peculiar behaviors or 'knobs' in the code, and combining these knobs to identify unique vulnerabilities. He contrasts this approach with the typical defensive stance of developers, who aim to secure protocols rather than break them. The goal is to shift focus from proving security to disproving it, thus uncovering potential vulnerabilities more effectively.
π« Avoiding Common Mistakes that Hinder Adopting an Attacker's Mindset
Owen highlights two critical mistakes that can prevent one from effectively adopting the attacker's mindset. The first mistake involves incorrect incentives; auditors should be rewarded based on the vulnerabilities they discover, rather than being paid a flat fee. This aligns their incentives with finding more bugs. The second mistake is failing to believe that vulnerabilities exist in the code being audited. Auditors should always be skeptical and question the security of the code, avoiding the trap of automatically agreeing with developers. This skepticism is vital for maintaining an offensive perspective and effectively identifying vulnerabilities.
π Practical Application of Attacker's Mindset in Smart Contract Auditing
Owen applies the attacker's mindset to uncover a vulnerability in the GMX V2 smart contract. He identifies a unique attack vector arising from a two-step execution process, which allows for a potential risk-free trade by exploiting the delay in order execution. By observing how limit orders can be manipulated to delay executions, Owen pieces together various components ('knobs') of the contract to construct a potential exploit. This includes exploiting the price range validation in orders and manipulating the collateral amount in positions. The exercise demonstrates the practicality of the attacker's mindset in identifying complex vulnerabilities that might be overlooked in a traditional audit approach.
Mindmap
Keywords
π‘Attacker's mindset
π‘Incentives
π‘Knobs
π‘Risk-free trade
π‘Empty position error
π‘Keeper
π‘Limit order
π‘Oracle
π‘Proof of Concept (PoC)
π‘Lego bricks
Highlights
Getting into the attacker's mindset is probably the number one thing that you can do to immediately boost the amount of findings vulnerabilities and bugs that you uncover.
You need to start thinking offensively to uncover the bugs and vulnerabilities that the developers, who are thinking defensively did not uncover.
The attacker's mindset is very simply boiled down just a way of looking at a code base where you're trying to break as many things as possible and there's an optimal way to do this.
The attacker's mindset is going to benefit us because if we set out looking to disprove the security of a protocol by finding a valid vulnerability in it then we're going to be a lot more likely to uncover that vulnerability than if we were to set out to verify or essentially convince ourselves of the security of the protocol.
Incentivize yourself accordingly by structuring the way you get paid or rewarded by the amount of vulnerabilities and criticality of vulnerabilities you uncover.
You have to personally believe that there are bugs and vulnerabilities in the code base itself.
Collect knobs as you're going through the code base - note down everything interesting, every interesting piece of behavior, anything that's off, any line that's missing.
Combine your knobs - take the list you've compiled and piece them together, find each individual knob that can fit with another to create exploits.
Not getting your incentives right by charging all the money for an audit upfront no matter how many findings and vulnerabilities are uncovered can prevent you from getting into the attacker's mindset.
Not believing that vulnerabilities exist in the code you're auditing and subconsciously agreeing with the developers can prevent you from getting into the attacker's mindset.
GMX has a two-step execution system where you create an order and then a keeper comes in and executes your order in two independent transactions to avoid front-running attack vectors.
If you can delay the execution of the keeper's transaction, you can get a risk-free trade by executing your order at a later block with the prices from the block you created the order.
Discovered that if a limit order reverts with an empty position error, it will be retried, allowing potential to delay execution.
Combined the price execution logic with the empty position error delay to construct an exploit for a risk-free trade.
Pieced together multiple code intricacies to toggle off the empty position error at a favorable time and execute the risk-free trade.
Transcripts
getting into the attacker's mindset is
probably the number one thing that you
can do to immediately boost the amount
of findings vulnerabilities and bugs
that you uncover you need to start
thinking offensively to uncover the bugs
and vulnerabilities that the developers
who are thinking defensively did not
uncover in this video we're going to
cover exactly the four things that you
need to do to get into the attacker's
mindset and then we're going to cover
two things that will prevent you from
getting into the attacker's mindset and
then we're going to cover a particular
finding that required me to really get
into the attacker's mindset and pull a
few knobs in order to pull it off and
actually have a valid finding and so
this way you're going to see exactly how
the attacker's mindset comes into play
and how it is actually applied in
practice all right but first of all who
am I and why should you listen to me
talk about out the attacker's mindset
well my name is Owen and over a year and
a half ago I founded Guardian Audits and
ever since then we've uncovered dozens
and dozens of critical and high
vulnerabilities in over a hundred
different smart contracts and over a
thousand different hours spent auditing
smart contracts and so my goal is to
take down everything that I've learned
along the way and give it to you so that
you can ultimately become a much better
smart contract auditor than I ever could
be in a fraction of the time alright so
without further Ado let's get right into
the attacker's mindset
[Music]
okay so we are talking about the
attacker's mindset but first of all what
really is it and why will it benefit us
the attacker's mindset is very simply
boiled down just a way of looking at a
code base where you're trying to break
as many things as possible and there's
an optimal way to do this this is of
course in direct opposition to the sort
of mindset of a defender or a developer
where they're looking to secure a
protocol and essentially verify that it
is indeed secure at its core what this
boils down to is looking to disprove
rather than prove and of course the
attacker's mindset is going to benefit
us because if we set out looking to
disprove the security of a protocol by
finding a valid vulnerability in it then
we're going to be a lot more likely to
uncover that vulnerability than if we
were to set out to verify or essentially
convince ourselves of the security of
the protocol okay so now let's discuss
the four key steps to get into the
attacker's mindset and then we'll
discuss two critical mistakes that are
pulling you right out of the attacker's
mindset okay so first of all of course
is to incentivize yourself accordingly
you want to ensure that before you even
go into the audit you have the correct
incentives that are setting you up for
Success where you really want to find
vulnerabilities what does this mean this
means that you structure the way that
you get paid or rewarded or however
you're being compensated for this audit
by the amount of vulnerabilities and the
criticality of vulnerabilities that you
uncover and so obviously if you're
competing in a contest or maybe if
you're charging per vulnerability found
of course this is a fantastic way to
correctly incentivize yourself
and sort of change the structure of your
mind and make you think by default like
an attacker because you are literally
getting compensated like an attacker
would be okay then second of all after
we've gotten the incentives right we've
set the Baseline for how a good
incentivized audit can occur now we just
have to personally believe that there
are bugs and vulnerabilities in the code
base itself of course if an attacker did
not believe that there were
vulnerabilities in a code base they
would move on to a new one in order to
find as many bugs and vulnerabilities as
possible you simply have to be convinced
that many bugs and vulnerabilities exist
in the first place okay and then the
third step is to collect knobs as we're
going through the code base so as you're
going through the code base and you're
getting that initial context you want to
note down everything interesting every
interesting piece of behavior anything
that's off any line that's missing you
want to note that down and save it for
later because as you're going to see
things like this can be combined with
other knobs in order to yield really
unique and critical attack vectors which
leads us into the fourth step which is
of course to combine your knobs now what
you have to do is take this list that
you've compiled and piece them together
find each individual knob that can fit
with another to create one of these
really cool puzzle piece sort of
exploits each of these knobs is going to
be a Lego brick that you can use to
construct a more complicated exploit all
right now that we've discussed that
let's talk about two key mistakes that
you might be making right now that are
preventing you from getting into the
attacker's mindset and these are really
the flipped version of the earlier steps
and so first of all of course if you're
not getting your incentives right you're
going to be starting off on a bad foot
and setting yourself up for failure so
what does this mean this looks like
charging all of the money for an audit
up front no matter how many findings and
vulnerabilities are uncovered so if you
think about the Baseline incentive here
you are purely incentivized to spend as
little time on the audit as possible and
your mentality is going to be to
convince yourself of the security of the
protocol you're going to subconsciously
want to believe after a certain amount
of time that you've spent on the
protocol that the protocol is indeed
secure you might not notice this
consciously affecting your actions but
this is exactly what makes the
difference between spending an extra day
on a piece of functionality that's
really involved just to get that last
little tiny knob that ends up being a
full-blown critical exploit and versus
if you weren't incentivized to find that
little tiny knob and get that critical
exploit you might end up subconsciously
convincing yourself that that area of
functionality is actually secure and
there's no need to spend many many hours
digging into it okay and then second of
all is of course to not believe that
vulnerabilities exist of course we've
talked a lot about this but I cannot
iterate this enough you have to believe
that there are vulnerabilities in the
code you're auditing you have to
distrust the developers always otherwise
you start to get into the headspace of
verifying rather than attacking and you
start to agree with the developers if
you find yourself subconsciously
agreeing with the developers immediately
turn that on his head and start to
question everything from the ground up
okay now that we've explored what
exactly the attacker's mindset is let's
have a look at it in practice and see
how it can yield some really interesting
unique exploits that are even missed in
audit contests okay so before we hop
into this particular finding and walk
through it walk through the steps that
it took me to actually come across this
finding we need to get some context on
the code base for so this is of course
from the GMX V2 code base from an
earlier audit as GMX was early on in the
development stage of the protocol before
it's released now if you want a full
Deep dive and breakdown of the GMX V2
code base and to really get enough
context and introduction to fully
understand this finding go ahead and
watch my intro to GMX V2 video on this
channel but to give some really really
quick high-level context just enough so
you can get the gist of this finding as
we go through it GMX is a perpetuals
exchange Traders can open positions and
they use orders to do that you can use
orders to increase positions and
decrease positions and you have all
sorts of market and limit orders as well
as stop losses and importantly GMX has a
two-step execution system where you
create an order it's it's sort of like a
request to have an order executed and
then a keeper comes in and executes your
order and these are in two independent
transactions and this is essentially
done to avoid a lot of front-running
attack vectors on the exchange so the
first knob here actually arises from
that two-step execution process the
keeper will essentially provide prices
from the Block in which you created your
order in order to execute your order so
what does this mean this means that
essentially there's a unique attack
Vector here where if I can delay the
execution of the keepers transaction I
can get a risk free trade let's have a
look at exactly what this looks like
right so if we have a timeline here and
let's say I simply created a straight up
Market order at this time here let's say
this is block 100 over here and then I'm
able to delay the Keeper's execution of
my order until this block over here
let's say it's block 110 essentially I
can execute have this order executed at
this time block 110 with the prices from
block 100. so in Block 100 the price of
ethereum might be a thousand dollars in
Block 110 the price of ethereum might be
eleven hundred dollars and so I could
see that the price of ethereum currently
in Block 110 is eleven hundred dollars
and then make a risk-free trade where I
say oh yes I would like my order that
was submitted here to be executed only
now at block 110 and end up getting an
Arbitrage of a hundred dollars per ether
risk free right I have the knowledge
that ether has appreciated 100 since
these prices here in Block 100 so that
is the most simple version of and a
risk-free trade that could occur and
that's essentially the first knob that
we're going to use in our list of knobs
right so as I'm going through the code
base this is something that I I just
know as a class of vulnerabilities that
exists on the exchange and so it's in my
list of knobs that I have to twist as
I'm going through the code base so let's
go into the first knob that I discovered
that essentially begetted what
ultimately became this vulnerability so
first of all I'm going to notice that
the empty position error is something
that gets reverted on so what does this
mean this means that when we revert here
this order is going to be retried
instead of ultimately Frozen or canceled
if it were a market order or something
like this so if we have a limit order
for example and it reverts with an empty
position error it's going to be retried
what does this mean this means that we
can delay the execution here so I'm
going to note that if I can get get a
limit order to revert with the empty
position error then I can delay the
execution of the Keeper's transaction so
I know it can delay it but I need
something to keep the prices that the
order is going to execute with outdated
so if the keeper has to keep making new
basically executions so the way the
keeper will work is they'll see that
this would revert with this error by
basically simulating this and they will
not execute this transaction until they
see that it doesn't revert and it
successfully goes through so how do I
get it such that the keeper will use
outdated prices when all of a sudden
they see that this no longer reverts
with an empty position error well
particularly for a limit order we can
see that in the set exact order price
function which is used to essentially
set the prices that are going to be used
to execute this order for a limit
decreased order we can see that we're
going to end up validating that the
price is ascending right so it is not a
limit increase it is not a stop loss
this is a limit decrease and let's say
it is for a long to make things simple
so we're going to validate that price is
ascending and so essentially this is
going to take the earlier price in the
range of prices that are provided by the
Oracle and the later price and the range
of prices provided by the Oracle and
assert essentially that price is
validating over this range and this
range must encapsulate my trigger price
so if we draw this out and we have a
look at what this looks like on a a
price graph so we'll say this is my
trigger price now what has to happen for
my limit decrease essentially like a
take profit to execute is price has to
be ascending right so now any arbitrary
range here is hypothetically a valid
range to execute this limit decrease
over as long as it's including my
trigger price so now I can see that if I
combine this price execution logic with
the fact that you could potentially
delay this execution with an empty
position error then I could potentially
get some sort of benefit from a
risk-free trade if price did something
like this so let's talk about this if I
have my limit decrease order waiting to
get executed and then price enters this
range here but I do not allow it to be
executed by reverting with the empty
position error then essentially price is
going to continue time is going to
continue on we're still reverting with
the empty position error the keeper is
not trying to execute this yet as they
see that it's reverting until we see
price goes down down and now let's say
we're at this point here every time
before this we were reverting with the
empty position error now you'll notice
something if we look at the price option
here there has never been a valid price
range to execute this over after you
know
so you know something like this point
here now there's no valid range after
this point where you could execute this
there's no range that is increasing that
includes our trigger price and so now if
all of a sudden we're to stop reverting
with an empty position error and allow
the order to be executed at this point
in time now we're going to be forcing
the keeper to use prices from in this
range and so of course this is a classic
risk-free trade I can execute an order
at this time with knowledge of what the
current price is only I'm executing it
with old prices so I'll get a price
somewhere in this range here and of
course I can modify my acceptable price
to get any particular price that I might
want okay so we have the means to make a
risk-free trade happen but the question
is where can we get that empty position
error to end up delaying this and how
can we talk toggle it such that if I
decide at this point in time that I want
this order to go through and the
risk-free trade to be realized then How
Can I toggle that empty position error
off and allow the order to go through so
these are things that I'm immediately
looking for now in the attacker's
mindset right I am looking to
maliciously really maliciously find how
I can make this sort of risk-free trade
happen so I'll notice one key thing when
I'm looking at the decrease position
this if statement here if our position
was closed of course we remove the
position from the order store and we
don't do any extra validation and that's
if the size in USD or the size and
tokens are zero however if there's a
position left over then we're going to
go ahead and do this critical check here
which is to validate position and if we
click into this we'll see that we
validate non-empty position and which
revert do you think that gives it gives
the empty position revert and so we have
three different knobs here that we can
twist in order to get the empty position
revert and cause this initial sort of
delay so now here's my goal after
realizing that I can get the empty
position revert when a position is left
with size so we must have size in USD
and we must have size and tokens enabled
to to go into this else branch and
ultimately do this validation now I know
that this cannot be zero and I know that
this cannot be zero in this case so
we're left with one option here the
collateral amount we need to be able to
manipulate the collateral amount to be
zero here while the size and tokens and
the size in USD are non-zero and then
once we're able to get into that state
we need to be able to retroactively
toggle that state off without touching
the order in order to ensure that this
can be executed retroactively so what I
first notice is if I go into the process
collateral function if we scroll down
here there's actually no check that I
can't just set the remaining collateral
amount to zero I'm not going to go
through this whole 300 line function but
you can essentially take my word for it
that we wrote a POC and it's actually
true you can essentially have an initial
collateral Delta amount that will allow
you to set the remaining collateral
amount to zero and so that's exactly the
knob that we needed to make this attack
work to give us some Ray of Hope so now
after processing collateral and getting
these values we set the remaining
collateral to zero right so this
remaining collateral amount is now zero
from our initial collateral Delta which
is essentially the amount of collateral
we want to remove using our order so
this gets set to zero on the position
and then when we do this check here
we're going to have some size left over
so we go here and we validate and we get
the empty position error so we're
starting to piece together the Lego
building blocks and we've almost
finished our Masterpiece of an attack
here but we still need some more Lego
bricks to come in and help us out we
have successfully found a way to
essentially make an order revert And
Delay that success here's what we've
done if we can use this as a timeline of
price action here's what we'll use as a
timeline of order execution
let's say before this we have a position
that has let's say we have two thousand
two thousand USD of size so this is the
size of our position and let's say we
have just 10 collateral tokens 10
collateral tokens of collateral maybe
this is ether let's say it's ether it
doesn't matter right so we have that and
then we have an order in the store and
let's say the order is for 10 collateral
tokens and only 1500 size
so now what we've got so far is we see
that if this order is to be executed at
this point in time right so let's say
you know the order would be executed
tried it would be normally attempted to
be executed at this point in time what
would happen is this order this 10
initial collateral Delta amount would
negate the collateral on the position we
would end up with zero collateral tokens
we would end up reverting on this
validate position function when we check
validate non-empty position the
remaining collateral Mount is zero and
we revert with the empty position the
empty position up in the older order
Handler is ultimately causing a top
level revert which means that the keeper
will not execute the order so as long as
this order lives in this collateral
amount here is 10 and the collateral the
initial collateral Delta amount on the
order is 10 then this will continue to
revert revert revert until let's say at
this point right here now we see that
prices moved in a favorable Direction
meaning that if we were to be executed
with prices from over here on the left
at this point in time on the right
we would make risk-free money we would
be able to buy ether at cheaper than the
the market rate or you'd sell ether at a
higher price than the market rate you
know something like this so now exactly
what we need is the knob to twist to be
able to toggle this off and be able to
make the empty position error not get
raised and so after scanning and looking
and looking for exactly that thing to
twist we can find that exactly here on
this if statement right here this is the
last Lego Brick of our attack Vector
what is this doing right here we're
seeing if the size Delta USD on the
order is the same as the size and USD of
the position
then what we're doing is we're setting
the initial collateral Delta amount to
zero ladies and gentlemen this is
everything we need this is exactly the
toggle that we need so how are we going
to achieve it so let's remember this one
case this is literally the case we need
if the order size is the same as the
position size then we can toggle our
risk-free trade so what can we do we can
decrease the position size to match the
order size so we'll see the position
size is 2000 USD the order size is 1500
USD at this point in time when we want
to toggle it normal
Market decrease to decrease our position
by 500
USD so our position now becomes at this
point in time it is now 1500 USD size
and 10 tokens in collateral so what does
this match up with it matches up with
perfectly the 1500 from our order over
here so we're going to hit this exact if
statement right here we're going to set
the initial collateral Delta amount to
zero and in fact it doesn't even matter
because we're going to go into this if
statement here and so we're not even
going to have any position left over
because ultimately the size in USD is
now going to be equal to zero and we're
not even going to enter the branch where
it's possible to throw the empty
position error okay so now ladies and
gentlemen this is literally the entire
exploit this is everything we need to
pull off a critical risk-free trade on
the exchange so I hope that wasn't too
too in depth to understand how exactly
we go through and piece each of these
individual Lego bricks together I
recommend you go through and watch this
a few more times in order to fully
understand the attack vector and really
try to notice how we're going through
and as we uncover bits we just keep them
in our backlog until we match them up
with something else that's potentially
related and notice overall how we're
really being malicious about this and
we're really going for and trying to
break things intently this is the core
of the attacker's mindset okay so that
covers everything to do with the
attacker's mindset everything I know
about getting into the attacker's
mindset and finding those really
interesting vulnerabilities I hope that
this helps you find something really
interesting and if you learned anything
new go ahead and just pop it in the
comment section below alright and of
course if you're looking to grow as an
auditor and connect with a community of
growing aspiring Auditors to get to the
next level of auditing skills or
whatever and go check out lab.guardian
audits.com where you can join over 500
smart contract security Auditors and
learn from everybody in the community
share your thoughts get experiences from
others and even team up with others to
participate in team Audits and get
rewarded for findings that you uncover
and of course if you're not 100
confident in your web 3 auditing
abilities I collaborated with a number
of top tier Security Professionals in
the field to bring you exactly the most
thorough training on Smart contract
security this training will literally
take you from just understanding
solidity to a full-blown solidity
auditing Chad as efficiently as possible
if you are looking to go the paid route
then this is absolutely in my opinion
the best paid resource hands down out
there on smart contract auditing so if
you are indeed looking to go the paid
route then of course you can take fifty
dollars off in the link in the
description below alright guys that is
all for this time I can't wait to see
you in the next one
foreign
Browse More Related Video
$25k GitHub account takeover & justCTF 2023 CSRF+XSS writeup
CompTIA Security+ SY0-701 Course - 4.3 Activities Associated With Vulnerability Management. - PART B
Payatu Case Study | Automotive Security Assessment | EV Security Testing
Fuzzing XSS Sanitizers for Fun and Profit | Tom Anthony
Arithmetic Overflow and Underflow | Hack Solidity (0.6)
Information Assurance and Security 2 - Lesson 2
5.0 / 5 (0 votes)