Finding Bugs: 42 Tips from 4 Security Researchers

Transcript

GM wow all right our mics are on just waiting for the video uh the slides are not up yet okay all right so welcome back hopefully um we've all had enough caffeine woken up so thank you for joining us thanks to mully and the rest of the team the organizing team the volunteers for kicking off yet another fantastic DSS starting with the DSs 101 so hopefully we all here to learn and

get better and uh who's here not into finding bugs okay maybe a couple but all of us are into finding and fixing bugs so this is this is a topic that that uh you're going to be hearing from the four of us here today and um no guesses for why these this is 42 tips but we are four security researchers so why why do we want to do this right obviously because vitalik says so just kidding but this is a tweet I mean this is sort of Representative I we hear a lot about scaling in ethereum

right we hear the hundreds and thousands of l2s but for all of us the security researchers here we know that hacks scams Ru pulls happen on a daily basis um and that's why we are here to find the bugs fix the bugs make the space safer more reputable and um you know and generally good for the whole ecosystem so yeah as this tweet says I mean this I I I don't know if Alik was referring to the DAP layer the applications but presumably ethereum layer ones and Layer Two so the technical risk in the bugs and code is something really really high um we only

see this when things go wrong so unfortunately that is an occupational risk or Hazard that comes with uh information security so all the security researchers here you never really get to uh well it's it's sort of different in in this industry because you know whenever you participate in contest or other things and you find bugs you recognize but in general before web 3 people or um corporates are generally in the Limelight only when things go wrong so um you know that's that's something changing in web 3 so that's that's what we here to learn um and these are I mean these numbers are really the smart contract hacks and this is from defi

Lama these numbers have been growing up so as you can see the Trend the I think the tallest Bars were really the bridge hacks uh from hopefully a couple of years ago and uh things things sort of look better from this but I don't think this paints a very um you know accurate picture so I don't think it accounts for all the user risk the fishing and so on so this is I mean we want this to really sort of taper out right so that's that's why we are all here today all right so who are we I am I've been a security researcher for a long long time um had a brief stint with trail of bits um and then and that's when I got into ethereum security smart

contract security around 2016 uh participated in as an early participant in many of the audit contests uh but for a couple of years I've been doing collaborative reviews uh as a lead security researcher at spearit Cantina I'm also the founder of secum which is U uh really known for its ethereum security boot camp and trustex the event so that's me but I'm here joined by my smarter colleagues and uh we'll have them introduce themselves he everyone I'm Nat I'm also an independent security researcher I've been doing security since 2020 um where I also was at chobits um before that I was doing blockchain development in the most

recent years I've been doing a lot of um code review as well as invariant development horen hey uh my name is Jan and uh I've been in the space for six seven years now um been working on a lot of tools and tooling some of them you might know some of them you might not I started out kind of with um mithil symbolic execution um and I won't bother you with all the others um I am also a somewhat active Bounty Hunter I really enjoy it um and and yeah cool and I am hiup or Desman is my real name I'm also a independent

security researcher join the space in 2017 so it's uh really nice to be able to uh translate to web Tre security and uh help to cure the space cool and with that uh we can start with our first 10 tips so um the agenda is we have 42 tips we're going to sort of split it up amongst the four us and at the very end there is actually a workshop quiz which should be very interesting and it does have some rewards as well so please stick around and uh yeah have fun thanks cool awesome so let's get started with our first tip it's about challenging your intuition and assumptions and to

kick things off uh I'm going to make this a little interactive so I need you guys to take out your phones and do the slido uh so let's have a little quiz to test some of our inations okay um so do uh join or you can just go to slido.com and Keen uh the seven digits that you see there and I should start seeing your names uh popup and the quiz section and you can be anonymous and so on uh unfortunately it's a the free plan so I only can allow up to 100 people to participate so once I see uh that number then I'll proceed on to the next slide awesome awesome the numbers

going up nice I see some familiar names all right I'll give you guys maybe just another 20 seconds or so to join and then so is this uh it's just like a simple tree question kind of thing um to see how well you can challenge your intuition and understanding okay I give another 5 seconds so four three come on let's hit that [Music] number okay and we're good okay so first question uh it's a statement true or false right I recruit my losses right

the meme coin I bought pum 50% after it's down 50% is this a true or false uh you have about 20 seconds to answer okay yeah oh wow good job uh for those of you who answered false that is correct right so if you work out the math if let's say your coin that you bought is at a dollar it goes down by 50% it's at 50 cents and goes up again by 50% it's at 75 cents it doesn't break even so that's a simple warm up question and uh there's also like a timing right

so if you can answer as fast as possible then you'll be on top of the video and just for fun okay second question right so I am 31 years old I'm introverted relatively bright and I majored inl math I'm deeply concerned with issues like front running and meev right so which of the following is more probable I am a security researcher or I am a security researcher specializing in meev which one would that be huh wow okay it's not too too bad not too bad uh for those of you who chose the first option that is correct and why is that so because using basic probability Theory you'll know that the

first category the second category is a subset of the first so just by the fact alone the first is more probable right hey rajie is first and somebody is imitating me in second place cool all right last question so a frog is stuck at the bottom of a well that's 5 me deep each day you know it jumps up by 2 m but slides down by a meter so on what day is it able to jump out of the well mean it's like two and then you know minus one and then you know just got to work it out and might feel intuitive that know maybe you might gravitate to an answer

more than other but we'll see okay not okay not too bad not too bad and those of you who chose the fourth is correct so if you work it out logically it's an age case right where on the fourth day you're at 3 m the the frog is at 3 m so it jumps 2 m it exits the well it doesn't doesn't have to do that slide uh down biometer so it might seem that the the fifth day is a bit more intuitive but no that's actually wrong and so this kind of like gives you an idea of challenging what seems to be correct it feels correct but it may not necessarily be so right and

congratulations to Desman 2 awesome wow good job okay so we're going to look at couple of real life examples uh that I kind of have uh experienced uh through my uh Security reviews and the first case is fee equivalence right so for instance uh you can see these few lines of code um you have a swap fee and usually indexes you are able to specify either you're swapping uh the exact input or the exact output right so um this is how the S fee is calculated right you just uh take the fee in uh basis points multiply by specified amount and if it's in exact or uh input

or exact output then you just uh subtract or add the swap fee right and this might seem to be correct right so as an example here right if I swap 100 usdc for d at par one to1 assuming the fee is at 1% and I specify the exact I specify an exact input right so what does that mean it means at 1% It means I take one usdc as a fee I should receive 99 die back right so the fee equivalence in a sense would be that if I specify 99 die as the exact output I should be the Dex should be requesting a 100 usdc in return right and the problem is if you work through the math here

uh it doesn't really add up right um 1% of the 999 is only 0.99 so if you add that you're missing uh by 1 cent so you don't really have that exact uh equivalence so what's the fix yeah it's kind of you kind of have to change the denominator a little bit and uh that's the correct math so again it might seem those few lines of quote that you've seen previously might seem correct but you kind of have to work out the math and let's take a look at an another exam oh yeah so if you work this out then it would be correct um let's take a look at another example right which is taking fees in ch uh this is a Twitter tread by sing 9 so just a credit to him um but

you taking uh fees in shares is quite common right especially if you have uh autoc compounding vaults like ERC 4626 right so uh protocols tend to want to take fees in shares because it's autoc compounding so the amount of fees that they get will uh in increasingly acre in value over time right so uh this is the formula that they use right so it's the harest amount multipli by the fee and then uh multiply by the total Supply divided by uh the underlying value uh so let's take an example right so say you have a 20% fee and you harvest 100 e right so technically the protocol should receive 20 e in fees and

uh let's work that out right so the Harvest is 100 if assuming we have a total asset initially of a th000 if uh so, 100 if multiplied by the fee which is 20% uh the fees specified in basis points so then uh multiply by 100 shares and uh you divide by a thousand so yeah just uh replacing the numbers with the variables uh you'll see that uh the number of shares that are minted is 1.81 right so the question is is this 1.81 shares equivalent to 20 e right and you'll realize that it isn't right and so what's the reason behind it why is it that it's less than the 20 e that's

expected well if you think about it you are actually diluting the Share value because you're meting extra shares so you have to account for that share dilution right and so this is kind of the correct formula that you are supposed to use instead and uh if you work out the math then you like you end up meeting slightly a bit more shares which will uh give the protocol a little the uh desired 20% right so again something that looks really intuitive it looks really correct but then if you want to work out the math it doesn't work out right so that uh is my first tip on challenging assumptions and uh challenging your intuition okay so tip number two scoo ni is a start and end of

life cycles right um usually the start and end of life cycles are a bit more uh age cases right so for instance let's look at initialization right is the condition for in initialization explicitly defined and if it's implicit can it be exploited uh and we've seen those happen in Real Life Cases right uh the first is in balancer V2 where uh I highlighted in red you can see that they there was an initial condition where uh you could uh exploit the case where the circul the circulating Supply is zero right and you cause the pool to be rein initialized by resetting the rate to one and the other is the meme attack that happened earlier this year right where

uh the uh the tldr is that you're exploiting the initial condition of the one to1 uh shares to Value u mean the borrow share to asset ratio right so if you can get the system to a state where uh you have more shares equivalent to one way of value uh then you can exploit that initial condition so uh you do have to kind of take a look at the start of the uh life cycle and also consider the end of the life cycle right so is there any state that is supposed to be totally reset but isn't and uh conversely is there any that are not reset but they should be right so for instance um lingering approvals on token or ownership

transfers okay um so this is a finding by watch Park uh for a contest Sherlock contest where they found that expired locks uh you know like once you have a you if you know the V uh token model of locking out your tokens to uh receive more rewards then uh once the lock expires you know what is the state of that uh uh condition right um and in this case you know expired locks are considered the same as deposit with no locks right so there should be a way to kick out uh expired locks okay so tip number four right be familiar with multiple Frameworks right um Foundry is mostly widely used but

there are projects that still use H head right so there might you might be spending time porting uh the setup the logic over to Foundry uh and that is kind of like a trade-off and so it will be good to still be familiar with multiple Frameworks like hardhead but it could be worth it if you are using uh exclusive features that are features that only exclusive to that framework so for instance like invariant testing or fast testing might be more popular on Foundry so then it might make sense to kind of pot over uh the test site from hardhead to Foundry okay tip number five run coverage if possible um unfortunately more often than not I run

into the shoe of St to it when I run uh with Foundry with uh even with the IR flag on um but if you can run it h it's a really good thing especially if you pair it with coverage gutters which is a uh useful extension right so if you run Forge coverage uh with uh you run this line right uh and then you turn on the extension you can display the coverage so you can see uh you will have three different colors right so green means the the coverage uh that line is covered if you see yellow it means either it's you're not fulfilling the entire coverage you are missing out on the branch coverage so it's either the if or the else branch that uh is not covered and if you see totally red then it's not

covered at all right and if it's red then those are prime Prime areas uh to uh you want to scrutinize those uh areas further because that's where bucks might tend to lie more uh some other useful extensions like spell checker uh the solidity uh extension bomic Foundation uh so here one one example is that if you kind of like highlight over uh the function name it kind of gives you the uh parameters and uh the variable types and the other useful extension is the solidity inspector where it shows you for instance the contract size and it shows you redundant import right so you can see here it's an unnus import the

console uh import there okay tip number seven you want to mock minimally right so as much as possible you want to use actual implementations and network conditions right and the reason for this is that different networks have different Behavior so for instance uh Trent op codes might still not be supported on some networks uh or for instance like solidity globals might return different values um for different networks right so I would highly recommend doing uh for tests uh especially especially if the project that you are auditing is integrating with other projects so instance like using uh avat using the DSR uh MERS DSR yeah okay tip number eight mess with the

code um so you want to try reimplement try reimplementing uh certain function to differentiate against right and you might be able to spot some subtle differences and you might then you will start question like why is it that I write things differently and it might help you to uncover subtle bu and ideally you when you do the change right uh it should cause at least a test to fill and that's kind of uh the idea of mutation testing where you are kind of testing the strength of the test Suite uh yeah so if you notice I went from tip number two to tip number four and that is where number three is and it's the idea of thinking what is absent right so it's very easy to spot what's

actually present what's you're actually seeing on screen uh it's yeah it's very easy to identify issues that are written rather than Unwritten right especially when you are reviewing uh fixes and I feel that's where things tend to be a bit more uh tricky right so for instance this was a uh PR that I reviewed for unisoft V4 where they changed uh the V4 call and you know it looks good lgtm right uh turns out it's not really lgtm because there was something to be fixed in periphery uh that is dependent on this behavior and that was a bu that I think some of you guys sh in the room f as well uh so you know you live and learn right um yeah tip number nine uh you want to periodically step away from

the code base right and the thing is that you might suffer from review for where you're staring at a Cod like over and over again then you start to have tunnel vision you stuffer from cognitive biases and that's when you might also start to realize that you see uh patterns that you're familiar with and then that's when you start assuming things are correct but you know it might not necessarily be so so consider like switching tasks might want to take a break or you start uh writing some tests or write up the issues that you found already so just switching things up a little mixing and matching a little bit I think helps to keep your mind a little off and then when you come back you it's in a fresher State of Mind in a sense so

that would help you uh to be a little bit more focused and it might help to open that uh part of your brain that spot something that you didn't see before and for my last tip it's about taking care of yourself right so you want to have for instance regular exercise uh for me I have a garment watch that I bought a few months ago to check my health uh to check my sleep as well so it's uh really important to take care of yourself physically mentally right um touch grass take a vacation right and I I feel like this is like really important because uh if you want to be like athletes you want to be uh at pck performance it means you need to be at Pi condition so uh those are my 10

tips and I'll hand it over to horen thank you there go okay so um my background is as I said before uh in automated tooling automated security analysis but also in bu bounty hunting and today I'm going to kind of focus my tips on that second part the bounty hunting and not so much on tooling and using tooling um I think a few tips later on we uh cover those and my first tip is kind of has a little bit of overlap with the with the previous

one take care of yourself um basing um on Twitter sometimes uh you kind of get a sense that um audit contest Buck bounty hunting they're all about the grind set and grinders um and I honestly believe that is like the worst possible approach uh to doing any kind of really good deep security research and I think like a couple of examples really outside of security research will show you that this kind of makes sense so there's a um if you look at doctors they also or tend

to have a culture around grinding like taking multiple shifts working really long hours and um not sleeping that kind of stuff and the data shows that uh more people die because of this like there's more more uh risks that are introduced by like this type of grinding behavior and I feel like or I think the the same is true for auditing or security research this is like a very tough mental task that your brain is not able to do for like long stretches of time like you need to give your your brain time to recover and digest um and to to

give an example like I used to be uh have a course in University it was a while ago um and we had these um challenges in this course where we got a day to solve some networking challenge uh like you build some kind of protocol like it was very interesting but for me what those days looked like is me just going like tunnel vision for 4 hours until lunch and then um I take a walk to to like to get my lunch and during that walk I solve the whole issue like I would be stuck for four hours basically then 15 minutes walking I solved it so

it's really important to give yourself or your brain like this this this time to rest and digest to process uh so you actually yeah yeah work more optimally so I think taking it easy is actually a more productive approach in the end this is not to say that discipline isn't important and also not to say that it's not a lot of work to like build the skill build the knowledge necessary to do bounty hunting or security research but just that when you're doing it eight hours straight or doing more than eight hours of reviewing code I'm not sure that it will work well okay tip two I think the 's a lot

of value in uh scoping out targets for bounty hunting um if you're like me uh you have limited amounts of time available to do bounty hunting on a single Target at a at a certain point in time so for for example I'll have a week or a couple days um then it doesn't make sense really to go for like a an L2 implementation like it is just too large so I think it makes sense to to then uh pick targets that have about the size that you can handle or that you think you can find something interesting with

the amount of time you have other things you can look for in uh finding b or Bounty programs to hunt on or I guess other contests is the the type of program uh if you're very familiar with l2s uh with Bridges then finding bugs and bridges and l2s is going to be easier uh if you're not familiar with those then it's going to take a lot more time uh and you're going to be more efficient working on things that you're familiar with that said it's often like a good idea to switch things up to make sure you like stay sharp uh and uh and everything then there's one more thing

that's not really about you but about the program itself and this is something I kind of look for in Bounty programs it's the the medium and high payouts because often a program will be like ah here's a couple million for a critical bug and then they won't pay out for highs uh and this kind of tells me uh something about the mindset that people have running their Bounty program um being not so much interested in improving their security reducing risk of hacks but more so kind of like catching just the worst case scenario um and uh I have a feeling that like even if you find something you'll have a hard time getting a like a good payout

out of those those protocols so I I tend to look for that as well okay tip three uh this kind of overlaps with my first tip a little bit um and uh this actually kind of happened to me so I was trying to sleep uh lying in my bed and then uh I'd spent the day like looking at some codee and my brain is like yo what happens if you liquidate your own position and I was like oh um so in the middle of the night I was tying up a bug report cuz well I couldn't sleep and the tip here isn't really to try to sleep and then do bug bounty hunting at the same time that's probably not a

really good tip um but it's really about uh a mental model of the top idea on your mind um this a blog post I I forgot uh where it was posted but the idea is that you basically have like a a place in your brain for a thing to work on when you're doing different things so let's say I'm doing like doing bounty hunting on a specific project and then I'm going to take a walk or I'm GNA do the dishes clean like the house that kind of stuff during that time your brains kind like passively processing things and so for me like a not

insignificant amount of bugs came from this in like passive processing time so to really optimize on this make sure that you're not trying to do too many things like if you bounty hunt and then do two hours of I don't know trying to learn something else then your brain is wholly occupied with this other thing and not working on the bug Bounty thing anymore so if you just like make sure sure that you work on bounty hunting and then give your like brain the passive processing time that might work out really well for you okay then a tip on Buck Bounty discussions um Buck bounties are great uh but unfortunately if you submit a few you'll probably get in a

situation where the protocol team does not agree with you it happens uh every discussion is different every team responds differently it's usually a high state situation and you're telling someone hey your code doesn't work um often unintentionally there's going to be fallacies uh it makes sense to prepare for those fallacies in a way that you can handle them in a like a in a good way uh not just saying hey that's a fallacy you don't know but just handling it in such a way that you can move the conversation onwards so there's couple lists on the internet you can

look at them be like read through them see how you should respond it's a really good way to to improve your speed I guess or improve your productiveness in these discussions another one uh thing you can do to improve these discussions is kind of change your mindset I saw like over time I've seen tweets that kind of indicate like this adversarial mindset of like um this project sucks and there not giving me anything um that usually doesn't work out really well and I personally like to take a uh perspective of like I want to work with this project in the future I want to

submit more books I I might want to work with them in a different capacity so I adapt my self communication to this and that ends up being a lot more productive or I I think it ends up being a lot more productive then the more adversarial hey you need to pay me because XYZ okay tip 16 diversify your skills this is a somewhat cheesy one but really anything you can learn outside of just web 3 security um it's going to be useful so there's a couple lists here like learning how compilers work can be super insanely useful because then you know how solidity works you can know

about the quirks like the issues that people might encounter everything becomes a lot more logical and also like compilers in general make like your understanding of programming languag is like insane um another thing I really like is like don't stick to web 3 related topics necessarily um there's a book called How to solve it um I'm not sure how to pronounce the author's name it's a book about how to approach mathematics problems um in a like there's like a strategy about like solving the the issues and creating proofs um and I really like that because it's kind of

teaches you a different way to think about things and the more ways you learn to think about things like by learning about different topics the more ways you can use to find actual bugs uh so yeah I think this is very useful thing to do okay some specific bug hunting strategies I think think um something that works really well uh is to find a specific Paradigm and specialize in it um so for example uh in defi you have a lot of systems that allow you to have leverage uh these Pro systems have problems uh liquidation is

usually very difficult to do right um and there's been tons of bugs there um so what can do is kind of learn a lot about how these different systems work what their pitfalls are and then once you're really comfortable with them you can probably just go on immuni list all the different like types of systems that might have leverage go through all of them and see if the pitfalls that you've identified or learned about um are apparent in these these uh implementations and then well you report them obviously if they are there so in defy like Leverage is one example I think uh it makes sense to have a look

at like what's like current uh like a a paradigm that is currently being developed like um like concentrated liquidity an example where there's like Unis swap released um their version and then like a couple other projects will also have like all implemented their concentrated liquidity and um if you were an expert like you might have known that tick Transitions and uh ending up like right on top of a tick in can be a really difficult thing to implement uh which has led to some hacks unfortunately um and like in that way you might have gone through all the implementations and found issues related

to that type of like difficulty in implementing this kind of Paradigm uh I think like ZK is an example where there's not that many people that I know of at least that are specialized in uh these kinds of systems U so there might be a lot of opportunity there I don't not sure but I think the general approach of finding paradigms specializing and then going broad can be very effective because you can go really quickly through a lot of pro uh bvy programs okay that is kind of the go approach um there is also a go deep

approach and this is kind of the one I tend to follow it works really well if you have like a very limited amount of time um um which might be like a week or a weekend um and it's kind of like this explore explore exploit type problem so what I do is I kind of like explore a code base or usually I just start reading documentation actually um and then I identify like points of interest or things that I think are going to be difficult so it's really like it it's has some overlap with the the Paradigm specialized strategy um in the sense that you like identify the potential

pain points and then like go for those once I have like the list of things that I think can go wrong very easily then I just go deep into the code see if they do these things well and well sometimes they do sometimes they don't uh and when they don't like you can write up your buck report uh what's really nice about this approach is that um it kind of leverages the fact that as a buck Bounty Hunter you do not need to write a an audit report that has to be complete like as an auditor you want to make sure like you find all the bugs not necessarily all the bugs but you need to find uh give a comprehensive report that

will allow the project team to build like a really good and secure code base as a bounty hunter you just want to find one bug uh that's your goal or like one critical bug I guess and because we have this we don't have the limitation of having to find comprehensive bugs we can um focus on just those parts of the code base where we think there will be bug and over time you'll get a kind of spidey sense of what these parts of the code base are going to be like yeah um and you're going to be like browsing through a code base and be like H this

looks fishy let let's have a look at this um I think this works really well uh so I already mentioned reading documentation is kind of the first part of this go deep approach I think reading documentation is sort of an underrated not that much talked about approach um there is a lot of bugs design bugs that happen that you can find by just reading the documentation some ideas just fundamentally don't work or fundamentally have some flaws that people need to uh worry about um so you can find these mistakes or critical

points but just reading the documentation uh and then seeing if they actually implemented the necessary safeguards so this is actually a like a relatively fast way of of uh approaching a a project um yeah and then finally um there's a toolbox mental model uh and I really like this one so a lot of critical bugs aren't critical bugs necessarily so if you have a report on immuni for example a boundary report what's very important is the impact of your report and to get a critical impact to

drain all the funds it's very often the case that it's not a single bug that leads you there it's often like a series of bugs that will allow you to get around various safeguards and measures um to actually end up in a situation where you can take out all the funds so we commonly call this a killchain and what I tend to do when I review a code base is I mentally or actually write them down sometimes keep track of these tricks and gadgets that I found um in a code Bas and the name gadgets is kind of St them from binary exploitation but the idea is that if you find um

like a I would almost say it's a a low severity vulnerability if you find a way to make the system do something on or weird like maybe you're able to get a system to uh go like write up to a certain margin requirement uh that is not expected but also not a CR like a vulnerability um that might be a useful thing to set up a killchain so when you're reading through a codebase and you find ways to do like weird stuff that's not necessarily A vulnerability just write them down or keep track of them so that when you find an actual bug you can have a look at all these gadgets

tricks that you found and see if you can change them together to end up in a situation where you can actually exploit the vulnerability uh and get um some some decent impact all right um those were my tips that's yeah there you go all right hey everyone I'm Nat so just to give a little bit more or context as to my background I mainly did a lot of code review and invariant

development and so a lot of these guides are going to be kind of somewhat code review related somewhat invariant related and some tooling related so to start off with I think the first thing that at least I encounter when I look at code bases is to F is like kind of reading through code and then realizing that certain pieces of code are much more complicated than others and those I think better better than ever usually there's a bug or some unexpected behavior in those C in those parts of the code so these I kind of separated the tips into a few different sections um I'll start with kind of tips on uh reviewing kind of complicated code how

to break it down into something that you can better understand and then to kind of form that into um something you can better kind of English English siize with um expected behavior and then a brief talk about tooling without getting into specifics so I think one underrated tip that I have is to take complicated code and then write psea code based on what you're seeing so as an example okay sorry um as an example um if you have for example a calculate and distribute rewards function um you can e fairly easily break it down into for example

part one um it calculates um some amount of like how much should be distributed to certain users um and then you can then split it up into the actual distribution so the actual transfer functionality um and then obviously after that it has to change certain values the benefit of this kind of practice is it takes you out of the code base and takes you into more more of a high level review of what a certain function is doing um because a lot of the time the function name is not actually going to match what the function does um or it's going to match maybe a little subset or a very specific behavior of how developers expect users to interact with their system but not um the entire scope of how a user would

actually interact with that function so at least for me when I pseudo code things out I'm not focusing on whether like for example the user rewards is the correct amount or like whether there's a rounding issue um it's more of a high level understanding of like what does this function do and once you understand that then you can go deeper down into actually like analyzing arithmetic or um in this particular case would be arithmetic but could be really whatever um that function focuses on my next tip is to play around with the unit tests unless you have none um a lot of times um the first thing I will do at least when I um clone a repo is to

run the unit test and see what the output looks like ideally as hiccup said run the coverage but sometimes that's not actually possible but it does tell you a story about what the developer was thinking when they were building this function if you go back to like even just the calcula and distribute rewards if there's a unit test based on that function then you know at the very least hopefully um how the how the developer intended to use the system and how the how essentially the developer um you know forms arguments forms like the function calls and like what the expected behavior is it can give you an idea um it might not tell you exactly what it does but it will help guide your

understanding of what is expected you can play around with these unit tests in ways that um I think are that allow you to manipulate the code and play around with like say changing an argument or invoking a um functional revert for example if you're looking at the client code you're looking at the unit test and there's no test for like the rting case I think it's actually at at least insightful to kind of manipulate that unit test to invoke certain functions or certain paths so that you understand like if you have for example nested if statements that you understand how what is required to actually hit those statements um the

benefit of that is a lot of the time developers are also going to go in with the assumption that you know users are only going to use this function in this specific way therefore this if statement is only executed under these conditions um and with a unit test you can very easily um be able to test that in livetime and when you actually get to code review or like um in the future if you do get to invariant development stuff it also means you have a better understanding of how that function works and how to get a proof of concept up if you need to I'll emphasize while you're doing this and maybe this ties into one of my later tips as well um is to document

everything you notice about the system so I think um whenever you look at a code base it's going to be really clear that the developer made some kind of assumption while writing this function um on how it's called or how it's executed um and making sure that you write down everything you notice about the function is useful later down the line for um in variance as well as as reviewing the system my next tip is realizing that how developers want users to use their system is not equivalent to how users are actually going to use it there's been a lot of

times where developers have assumed the users always going to use their front end or a certain back end to interact with a smart contract um or that users are always going to use this very specific periphery um to interact with one that's a dangerous assumption just because the nature of smart contracts unless you have that access control check on your smart contract to make sure that you know only certain users or certain the users have to interact with your contracts in a certain way um if there's any kind of differential between those two expectations that's a bug in the system um and usually a fairly High severity one all right so these tips I think um

help under help you understand what code is expected to do but that doesn't necessarily go into actually finding invariance so um my next few tips will be based on finding invariants to take a step back an invariant is basically something that you expect your s in your system to hold true so that can be something that's based on like a function if you call a function you expect something um some Behavior to happen afterwards or it can be based on the entire system as a whole usually the system invariance are going to rely on system behavior um System state generally with um data structures but this particular tip is based on

functions themselves so if you're looking at a function um you can essentially using kind of the practice with like playing around with unit tests you can eventually determine what are the conditions required in order for a function to succeed what are the conditions required for a function to fail and if you just start even just creating a list of all of those cases you have at least um created started to create a list of invariants that you can later check on the code base this is important because again it's really easy to look at code and get stuck in the details get stuck in like certain flows um but this

practice will help you kind of step away from the the depths of the code and be able to compare like behaviors of different functions this next tip is around expected behavior of the system in terms of um more of a high higher level this is related to like State changes um what is expected to change within like different functions so for example I think the most colloquial example is the deposit withdraw should be um kind of opposite functions whatever the deposit does and what whatever the state variables a deposit function changes the withdrawal should essentially reverse

those you're looking for any kind of behavior that you can kind of be able to link in terms of patterns um if one does one thing the other one should be doing something else these invariants also um or this practice at least also helps you get out of um kind of very specific like nitty-gritty in the code all right so so yeah you have a list of invariants I think the invariants help but you you they're not actually useful unless you do something with them now the first thing I hear is but I don't actually know how to use a certain tool I don't know how to use Foundry I don't know how to use um meduso or whatever the tool is and I'll

preface this with you don't need to for this talk because I'm trying to keep it as high level as possible um so that you can use these invariants during your code review during your um whatever what ever practice you're doing um and be able to use these invariants in a way that will help and guide the process of your card review so generally when I go through the practice of actually finding the invariants what'll happen is I just have a list of say like 50 55 invariants that I'm not 100% sure on all and any of them um but very likely every time I look at the code base and every time I look at

the code I understand a little bit more and therefore can refine the invariance to be even more specific or to highlight assumptions that maybe weren't um visible before I'll emphasize document everything you're not sure about because in the future um depending on how long your code review is of course but in the future if you're kind of at a loss and you've looked at the code base for a lot of for a long time you're not not entirely sure what to do anymore these invariants can help as guidelines for future things to explore just because it's something that you've maybe identified as unexpected behavior and then therefore you can um continue to

trace down those paths um at the end and I'll preface this with you don't necessarily need to you need don't necessarily need a fuzzer or like a unit test to verify these invariants I think it's more important that you review the code base with these invariant in mind because then you can um for example if you're looking at relationships or assumptions between functions um you're you have a better idea of what to look for what does unexpected Behavior look like um and where the potential bugs are so with that um essentially never trust users users input always have the smart

contract verify them um that's where a lot of the invariants are based in um and are related this is kind of echoing some of the previous um tips on tooling and I will emphasize that yeah tooling is really hard to use sometimes I think it takes a lot of time to understand what would you use your tool for what um but I think the more time you spend using the tools the the more you understand um the quicker it is every time you use these tools to spin up like a test um for example if your background is in if you if you know how to use like unit

tests um in a way that's very quick for you I think there's there's bit always been kind of a discussion between um fuzzer versus fuzzer like tester or framework versus framework and I don't think that's a productive discussion I think it's more about playing around with the different tools play around with what works for you and identifying how you want to use the tools so related to tooling each tool I think was created with a slightly different purpose some tool might have been created to get um invariant testing up fairly easily some tools maybe require maybe were created

um in order to test very and find very complex issues use and at the end of the day every tool has its limits but every tool has its pros and cons and taking the time to actually understand what do you know about each tool um and how you can use these tools during your code review is important for example if you take one of those previous invariants that you found and then you write like a unit test on it yeah sure that might not be fully um that might not prove like a lack of a bug as much as a fuzzer or like a verifier approver might um but at least you you're you're using the tools to to your advantage more than you would as a

manual reviewer you're at at the very least increasing the scope of what you're learning um and what you're providing to users and and Developers for your code base and once you actually get to finding bugs um find finding unit test failures finding fuzzing failures I will emphasize that um any failure that you get from any tool that you're using is a potential bug and treat it as one because the bug technically speaking could be in the client code could be in your unit test could be in your fuzzing code could be in your mock code could be at any

stack and if you're just changing your code just to make a test pass you don't actually know where the bug was um and therefore you your test might actually be masking a bug in that I think um there's there's kind of an endless discussion to be had on kind of the rabbit hole of of reversing like why a certain test failed um and I think taking the time to really understand um every layer of the code so the unit test the whatever test that you're you're writing um and the client code is important because um from there you you could there have been a lot of cases in which um fuzzer found a bug unit test said it wasn't a bug it didn't

actually it didn't actually fail but the fuzzer did and um it was because the unit test and the client code was incorrect and so realized that there could be also multiple bugs in all of the different text Stacks um and realize that your unit your your fuzzing test or unit test could could also be buggy um I think that's probably the the biggest lesson I've learned um while writing these invariants is realizing that um or in other potential cases you wrote the invariant you wrote it like week one and then week three you're coming back to edit one of your invariants and you're realizing that's completely incorrect

that's I think a very common issue with any kind of testing um but especially for code bases that change so quickly I think the more time that and the more stringent we are with testing and testing practices um I think the the more that these these code these um tools can help us find these bugs and essentially make us more more well-rounded security researchers so that's all the tips from me I'll pass it off to reiv [Applause] [Music] [Applause] thank you

Nat so hopefully um we have not reached a Tipping Point with with all these tips and finding bugs those were hopefully some really good tips From The Trenches right so as you've heard their introductions they've been doing this for a long long time so all these have been sort of distilled these may seem very simple and obvious but we believe that's that's what it really is right so with my tips I would like to take us sort of zoom out so going From The Trenches really going to uh let's say

the troposphere if you will right and sort of reexamine some of the concepts that have being discussed right as steps so the first thing that I always like to talk about is everything in security boils down to this right so for those who have done security Theory it's uh you can think of it as an access control Matrix so it's really all about the assets without assets you know there's really nothing to do or steal or hack and obviously if you have assets we need actors to act upon the assets to deposit them to withdraw them to do anything else with them and all these are actions right so the first thing in

security is really about assessing assets what are the assets who are the actors and what are the actions manipulating those so in this meme you see that um Billy right uh Billy's parent I don't know who that person is but they want Billy to learn about money and the importance of smart contract security but of course Billy is too anxious runs off to what looks like a vending machine that really has all the assets right so the actors here are Billy presumably the the person handing the bill itself and um there are various

actions here you just see them sort of depositing money and maybe getting the assets but this is this sort of sums up in my head what we are trying to do with smart contract security right so you have assets all the things we talked about so the first thing that we should really aim to do I mean here we talking about smart contract security but in general insecurity is what are the assets where are the Assets in our case it could be a simple e it could be various tokens any representations of those and then the next question is okay who are the actors and actors in in the case of the blockchain systems right I mean remember

we are dealing with a Byzantine failure model right so it's not just the users who are the actors it's the developers themselves right we've all heard of Ruck pulls scams so those they are actors as well you have uh governance for example all the token holders who may decide to upgrade contracts and change a whole bunch of things within your system they are actors as well well right so there are various categories of these assets that we need to sort of understand when we look at a system and of course finally the actions what is happening when is it happening right the

sequence matters how is it happening what are the various conditions under which it's happening and ultimately why is it happening right so just because an action is allowed doesn't mean it should be allowed so all these are sort of sort of fundamental questions they seem very simple but ultimately this is what it boils down to so we first assess all these things and then of course look at what the behavior is so some of some of my colleagues talked about sort of expecting the unexpected and this is the reality yeah I don't think you can see this laser but

our expectation may be totally different from what the reality is and this is I think way you know way more real in the web3 world than it is than it's been in uh earlier with web2 and others right so if you sort of dial back and look back at the history of information security there's really two two categories there's something known as historically as misused detection and there's something known as anomaly detection so misused detection for all the anti virus you know 20 30 years of research you know what what the signatures are of all the bad

things which is good but then you can never really keep up because attackers keep innovating and anomaly detection is where you really build a model of what is allowed by your system and then you detect what the anomalies are right and anomali is anything that Falls outside this model of what we think should happen so categorizing this sort of the normally and the anomaly is important at a high level when you look at a system specifically a smart contract system a protocol now notice that all anomalies need not be bugs right it may just be

our failure of capturing what a normal model is and this this capture capturing may be in the spec in the invariance in the documentation in just our understanding of what the system is but it's really a small subset of these anomalies that end up as bugs and we call this bugs because it's sort of convenient I mean it's security purists really find it U annoying because you know the bugs are really meant to be annoying they're never really meant to sort of cause uh real harm so even these bugs which are a subset of anomalies may not really be vulnerabilities right and this like

youran mentioned in bug bounties some of these may be you know denial of service and uh temporarily so it may not even be a permanent thing it may be a loss of funds but those May really be fees under five different conditions so those may be minor annoyances right but here we really talking about I mean we we want to cover the whole Spectrum but if you want to prioritize you want to sort of prioritize the criticals right we want to prioritize the real vulnerabilities and vulnerabilities are what really result in loss lock of funds and so on we'll talk a bit more so expecting the unexpected so as you see

here the users and and Nat mentioned as well in this scenario the users are really coming in we don't know you know uh who the attackers are really I mean this is an open permissionless system so anyone from the outside we really don't have a periphery right it could be uh somebody in the governance we have seen governance attacks it could be you know even the developers we have seen Ruck pulls and it could be you know coming outside the system as well it could be any of the dependencies the tool chain that may be corrupted and there are numerous examples of these on a daily basis right so that is really what we are up against and finding bugs finding

vulnerabilities in each and every one of this is really what what we're up against so it's really tricky very hard problem so the first thing like Nat and others mentioned as well is assumptions assumptions are the mother the root of all bucks right period so the assumptions could be from the developers it could be I mean it really starts all the way in the life cycle right it could really come in from the design of the protocol there could be

some fundamental things that cannot be inherently uh solved on a blockchain so it could stem from there it could be in the specification it could be in the implementation it could be in the testing it could be even amongst us when we look for bugs right we're making certain assumptions and those assumptions may be incorrect and actually may lead us to miss out on certain bugs so question everything right this is easier said than done and it obviously depends on the context so if you're doing um let's

say in this case bug bounties right you can question everything but you may not actually get the answers from the protocol or from the platform itself in the case of audit qutis it used to be the case that you know uh the developers are on the same Discord or whatever Channel or whatever platform you're on so you could ping them but then we hit a scaling problem when you know some of us started out they were like 10 of us uh looking you know actually competing in a contest so it was U not a problem back then but today it's a good problem to have we have thousands of security researchers

including many of you in this room who are on these contest platform so if you question everything and we want sort of authoritative answers from from the developers it is not scaling right so do question everything try to resolve them to the best of your ability and see where it goes qu I mean where do you start off again basic questions right who the actors what are they trying to do why are they trying to do this can can a certain sequence be allowed can a certain set of conditions uh happen when are these conditions valid when are they invalid right and where it

could be a certain set of tokens it could be a certain set of conditions it could be a certain set of actors or functions all these things are fair game to question so that is really the mentality to go with when you start looking at a system to find bugs and the goal obviously is to discover misuse scenarios right so use is sort of well understood relatively speaking you look at a protocol you look at a code base you know you see certain flows you see the deposits and the withdrawals and everything in between so you understand

the uses as security researchers our goal is one to understand how things can be used and really the end goal is to understand how these can be misused used right and again here misuse maybe okay it may be outside the realm of what is considered acceptable usage but not everything that can be misused is really abused and by abuse here we mean things that lead to a tangible loss lock anything like that so these these become critical again

depending on where you are so if you're looking at bug bounties a misuse situation may not be really um you know very interesting for the protocol but if it can be abused in certain ways in certain conditions maybe you know ideally you don't require any other condition for this to be abused then that is something that's really really bad right so really what we trying to do here is we are trying to map out the attack surface right that's really what it is I mean all these bugs that we trying to find are really entry points into the system for the attackers to abuse so that's really what we're trying

to do great so now let's say we have done all this we have questioned everything we have uh made you know no assumptions we found bugs we found that they can be abused the next big question which is becoming a hotter topic these days is how do you objectively and I don't think we are at a point where we can quantitatively do this yet but it's all very qualitative but how do you evaluate the severity of a bug so this is something that's been evolving in the last uh few years as

well for those of you you have done this you're you should be very familiar with the uh severity Matrix right so you have impact you have high medium low then you have the likelihood high medium low high high becomes a critical you know you know what the other boxes are so severity is really impact times likelihood right now what's impact I think of the two impact is well impact is really how it hurts or where it hurts the protocol impact I think is more objective right because you can really

specify what is happening to the funds what is happening to the protocol is it are the funds being lost are they being locked is it a temporary thing is it a permanent thing is it happening to all the assets or is it happening to uh few of the the assets so all these can be relatively specified in a in a sort of objective manner right it's it's hard to sort of um um disagree on this so that's critical to to sort of focus on the impact where it gets tricky is the

likelihood right so for all the bug bounty hunters here for all the people participating in contest I mean this is a very touchy point right obviously as researchers you want to be uh fair and you want to sort of be as objective as possible but this is a two-sided marketplace right so from the protocol perspective or from the platform perspective they also want to sort of pay out only for bugs that matter right so that's where I think likelihood comes in is this so some of the some of the metrics for likelihood is this always the case I mean is this

impact is this impact going to happen all the time or does it happen only some of the times that's critical is it conditional or is it unconditional so this is this is I think fairly obvious but I think where it gets trickier is when you start looking at the conditions right it's really how many ifs or buts there are for this impact to happen and the more the number of ifs and low the lower the probability of each of those predicates the lower the likelihood so this is uh something that we see on a daily basis um this is not

as much typically not as much of an issue when you do collaborative reviews because there the well the the project has really you know already paid there is no sort of conditional pots or um bounties at stake the the payment the whole pot has been paid to the platform or to the researchers and the project typically um you know is is more forthcoming or I should say does not matter as much to them if it is a medium or a low but even there the better the accuracy the higher the accuracy on our part the better right because think about it the project goes out let's say

they want to make this and it matters more for collaborative reviews and protocols where they want to make the report public right a protocol would you have more confidence in a protocol that has 10 criticals or that has zero criticals 20 highs or five highs get trickier five highs or 50 mediums right so it's all today we there's a mental math that that happens in our heads I mean this is this is just the security researchers thinking right we don't we we believe well we think that a majority of the users don't even uh you know um look at these audit reports or really understand uh what to make of it right but we may get there

soon so this I think is something that we need to think about and as a collective as a community we need to do a better job of sort of making this more objective over time all right so maybe there are some Star Wars fans here but consistencies right or the lack of I think that is where a lot of the security issues lie inconsistent checks I mean this is something that all of us who have been doing this for a while you look at a piece of code you see that okay you may not know that documentation or or what

it's supposed to do but just by looking at inconsistencies you realize that either there's something wrong right I mean this is the differential stuff that Nat was mentioning as well you see that there's something wrong or that the inconsistent the path where the check was missing was maybe an exceptional path where you don't really need that check right and this inconsistency is really the root of many or most of the security issues if you think if you map the whole protocol as a a finite State automaton a state transition diagram

right you have States and then you have transitions inconsistent transitions right on certain um certain conditions there is a transition that happens from State a to State B you would expect that it happens for very similar actions in any possible flow but then in some particular flow that transition is not happening and that may be um you know very simply it could be withdrawal it could be um um fees it could be anything right there's something that's missing so those inconsistent transitions leads to inconsistent

state which effectively is an issue right depending on what that state is if it is really the balance then we are really in a bad position so again like I said I mean these are very high level ones I mean this is where we should sort of be zooming out and thinking in terms of the protocol right inconsistencies it it could not be maybe they're not very apparent on uh day Zero when you look at it but as you start looking at it over and over again that's where you see those pattern patterns emerging okay so this is um a popular meme in the web two space right this uh

the image that you see and that's typically in the context of Open Source and dependencies where there is uh I think this works but you see the bug over there so that's in in the case of web 2 the dependency thing it's not that's not really a bug but that is like a small tiny piece of dependency that nobody even knows about right where we are operating on the top and if that thing breaks the whole you know thing falls apart right so that's that's the meme so I just sort of uh adopted that from the

web2 space but I think in web 3 this becomes even more critical because web 3 is not something sort of different from web 2 it's sitting on top of web 2 and I think there are multiple things tincho talked about there is a workshop happening I think uh that's going to talk about this there is a panel on this uh day after that I'll be moderating so do do a time um but if this is what web 2 is Right web 3 we have a much much challenging task today right I think the maturity of

the ecosystem has obviously is much better today than it was let's say 8 years ago and here I'm talking purely of smart contract right web 3 not layer one not Layer Two is just your daps all the protocols that we build and review there are bugs in every part of the system there are bugs in the protocol there are bugs in the dependencies there are bugs in the governance processes right and we've been slowly sort of making our way and fixing as many as we can the point here is as reviewers to find

bugs every line matters right every single line it could couldn't the the amount of dollars that are at stake per line couldn't be higher anywhere else right so if for those of you who are coming from a web 2 background sure sensitive data loss breaches and so on right RC all that but in web 3 the loss is tangible it's immediate and usually it is IR

irrecoverable right there's no going back in most cases so every line matters so when we review to find bugs this is something we need to keep in mind and as reviewers when you uh when we look at stuff right it may not be obvious in the first pass we may not sort of figure out okay what what is this line doing or maybe what is even this function doing it's okay to sort of uh proceed with gaps in our in in the understanding but like my colleague said make a note come back because every line is supposed to mean something and if it does not it better not be there because it's a source of bugs if it's not a

feature it's a bug right read between the lines as well like hiup mentioned what is there I mean this is this is I think probably the biggest blind spot that researchers sort of fall into because we are good at analyzing what is there but what is between the lines is not there so we don't think about it right so that is where we need to step we need to shift left think about not just the code that we see but about what is this function supposed to do what is this protocol supposed to do what is this flow supposed to do and what is supposed to be between these two lines

that is missing from a security perspective that I think is critical it's I mean our our tasks as security researchers is not easy read every line read between the lines and Hell read Beyond the Lines as well right what does that mean that's again going back as an example looking at the dependencies things may look okay right but there is a dependency on an oracle right or a certain API that may be buggy that may be faulty that may not be within the scope of uh of this particular review right because

we are sort of looking at only one part and I think hikab gave an example from unisoft V4 but it's it's very common right read Beyond the Lines and that's true for us that's true for the protocols that's true for everyone oops for any of the Matrix fans here just like the Matrix bugs are everywhere all around us even in this room just to sum up look at what's there look is look at what's missing think as an attacker and this is something that uh is tricky for us to do

right especially maybe for people people uh who come in with a developer mindset because there it's all about how is this going to be used as opposed to how will this be abused so that attacker mindset is critical and it goes without saying but act like a white hat right and this is this is something that um seal uh 911 there's a white U white hat Harbor and M multiple things so look at that I think there are going to be talks tomorrow do attend so things are getting better for white hats to actually uh act like a white hat right

if they one so in terms of reporting the bugs in terms of claiming the bounty in terms of not being um uh not being sort of scared of potential lawsuits and there they on okay and this I think uh L talked a lot about invariance so this is again what a lot of security boils down to what are these properties right what what properties is this protocol is this code is this function supposed to hold the good thing is read the comments right read the code first obviously read the comments if there are any read the

docs read the documentation while things have gotten better in the last um eight years I would say Doc there's a still so much more that can be done in terms for again for the protocols if there are any developers here so much more that can go into the documentation right that will make the protocol safer the lives of the reviewer safer make this ecosystem much much safer right docks can get better specifications even better right we have several formal verification projects serur multiple other ones coming

up that allow the developers and maybe even the researchers to specify what the invariants are of course you can have bugs in the specifications itself but at least it is a great place to start right so those can be the places where invariants can already be specific ifed so that's where we can read as researchers but depending on the context right ask I think one thing that is missing that that is not as good as it uh it can be in the space is the communications between the researchers and the developers so time boxed audits time Box reviews um again depends on if it's a bug Bounty how much

Communications can happen depend on the context is it a bug Bounty is it a contest it is is it a collaborative review bug bounties maybe not as much as yuran said right I mean it can be oh yeah no this is a feature no we won't pay oh yes the the good news can be that hey yes confirmed right or uh looking at it looking at it more I don't know what the labels are so that's bug bounties contest uh developers of the protocols are typically available and even the platform uh where the contest is hosted can have people answering questions about some of these properties this is where collaborative

reviews stand out right because there you're really collaborating not just with some of your other researchers but you're collaborating with the protocol itself the developers themselves are on the same shared Channel Discord telegram whatever where you can ask them hey is this a property is this missing is that missing right instead of not communicating and going away into the weeds writing an entire POC for 2 days coming back you know submitting with evidence only to say that oh sorry that's that's actually a feature right so that's wasted effort and we can't afford to waste a single second in the space right so

ask ask others ask the protocol ask other SAS ask yourself uh but do ask the final one is what is actually U actually become a a a separate field a subject within the software engineering community for the last 10 20 years actually it's about inferring invariant right so actually some very cool techniques where you can look at the code apply uh various techniques right it could be machine learning data mining it could be uh different ways of inferring what the invariants are and as a very simple example if there is is um going back to web 2 so um if there are Malo and frees Right Where You assign

memory and where you delete memory if there are 10 paths where maloc is being done where you allocate memory and if there is one path if there are nine nine of those paths have a free but there is one path where that free is missing that is a memory leak unless that happens to be an exceptional path you know triggering an exception right so this this is sort of an an easy invariant to know because this happens at an OS level or at a library level um in in um you know in your system programs but uplevel it right if you have apis where you have similar things Fu followed by uh followed by uh Fubar on many paths on all the paths except a few that is a

Miss potentially a mess right if there are a few parts where you only have Fu but you don't have Foo bar call to Fubar after that so that that's a very simplistic example from a call graph perspective but that is really what inference is about and this could apply to State apply to data as well not just uh uh function calls so look at clues in the code right especially when uh we do not have an opportunity or we've exhausted all the asking opportunities so this is where we can look at it and sort of infer and these are also clues that you can look at in the unit test like Nat mentioned that is really where all the security Clues are right all the

paths that we're tested all the um um gooda happy cases the not happy cases all those are really laid out look at them don't get biased by them right okay last the 40th tip is there is no bug bug free code right bug bugs will exist as long as code exists just read the code and find the bugs right oversimplifying it but that's ultimately what it boils down to there can be 42 tips there can be 420 tips there can be hundreds of tools and

techniques But ultimately it's really about finding what works for you in terms of reading the code as an example you see a lot of this in this uh in the space right where um people who are just joining the space want the the next greatest road map the shortest path to success to their million dooll Bounty or whatever it is but ultimately it's a lot of preparation right I can speak for myself and maybe the four of us here we've been doing this a very long time and

I'm not the smartest guy so many of you are much smarter so you can do this faster but preparation is Key Practice is key but the biggest one is patience right P have patience with the code have patience with yourself see what works best for you that's it so I do have the sort of the privilege of quickly summarizing all the tips the 40 tips so 41 and 42 are really um sound bites if you will right of all the 40 tips the first thing is read the

code think of assets actors actions think of use and abuse challenge every assumption made in the program test when it comes to testing properties and invariance are key depth and breadth you're AR talked about it you can go deep you can go broad figure out what really works best and there is no magic bullet here right you have to do both again depending on the context specialization and generalization see again what works best for you audits contest and Bug bounties have

different sort of require different skill sets if you will ultimately they all require you know the basic security thing but when it comes to sort of maximizing the outcome right it really requires a different mindset and especially these days with contest and audits things are also U getting interesting um they're getting very specialized in terms of with all the conditional parts and the different sort of combinations of all three right you have ponas that look like bug bounties that are some sometimes s um thought of as audits or reviews scoping is critical scope out ultimately it's attack surface but the scope that is there for you for the review that's

critical and then once you know that how do you sort of pace it right do you go fast is it a Sprint is it a marathon um do you want to run slow run fast it's that's a tricky thing to look at zooming in and out I mean this is this is sort of one of my favorites we sort of get into this tunnel vision like U hicup mentioned where you zoom in and you're focusing on this but then it's only when you zoom out that you see that wow this wasn't a bug but in the context of these two calls there is a problem right so zooming in and out and this is not sort of there's no zoom in and then zoom out it's not sort of a uh streamlined structured process typically

what works best for me personally is sort of doing this on a um I guess it just happens automatically you zoen and then look look at the broader context and see what works we talked a lot about documentation but with the lack of that or if it is not enough there is also something about gut feeling right you over time you really get a sense for uh your intuition tells you that something is missing here or something something is wrong hicup talked about the start and the end of life cycles critical follow the whole path usually it happens multiple times some flow something is missing something uh didn't start

well with code mock less Fork More Mess Around more depends on your personality some people like to do a lot of that some people you know prefer doing just looking at the code and you know just keep everything in the working memory of the mental state Frameworks and extensions explore see what works best for you a lot of the assumptions are really around preconditions and postconditions for functions or for statements keep thinking about that we talked a lot about coverage in terms of let's say your bug Bounty or in terms of the scope but there's also leverage right and this maybe matters

more in contest in bug mounties leverage your strengths your AR talked about sort of leveraging let's say if you're really good at L2 or you're really good at um certain aspects of defi liquidations there are there are bugs that have been found where people have found you know uh something reported in one protocol and they've gone and really leveraged that across multiple protocols there could be Forks or similar ones zoom in and zoom out the other way of saying that is really Dive In right and sort of step out take a break take walks take you know um any other breaks whatever suits you right Pomodoro of your choice do

that and I I really loved this about uh I think U Nat I forget who mentioned but the your should be underlined it does not matter what the four of us say or the 400 of us say but it's really about finding your tools finding your techniques what works best for you just because it works for one does not mean it has to work for anyone else prepare practice and patience that's that's the key and finally it's really about taking is TLC is just a uh acronym in some parts of the world for Tender

Love care take care of the code which is why we are all here more importantly take care of yourself so those were all the tips and with that we I think have maybe uh few more minutes for AAS so this has been sort of a one-way um monologue right or quadr uh but yeah any any questions I think there should be a microphone feel free to ask us we should have few more minutes and after that we will announce the quiz so do take a note of the quiz as well there are some interesting rewards

for that so yeah no questions it's one there couple of there so thing hi my name is John uh quick question is that I'm new to security I wish to pick it up so is there any resource that can get people started okay just to repeat uh so you're new and you're looking for resources I think the fact that you have come to BSS 101 is a fantastic resource um there is as of today I don't think there's any

dirth of resources online so right so look look it up um I will maybe sh secum as one starting point um so do look it up it sort of evolved but there is I would say cine I think is a fantastic C audits cyph audits Pat Patrick Collins has a good YouTube course yeah um he covers the basics and he goes into the evm as well and I think other languages like Cairo so really good like 12-hour courses or and longer uh rescues is another one uh by the way rescues is having a rescues Day on Sunday so if you available I think it's going to be a fun

time thank you yeah so cyphon rare skills and there are numerous road maps and blog posts and articles online hey it's Sam here oh that's loud hey it's Sam here sorry to wake everybody up um but I was curious as folks have been in the space for a while now how do you decide between going really deep into a specific vertical versus exploring some of the more kind of adventurous sides of of development right now I know fully fully homomorphic encryption kind of based chain Stark net so um each of you like how do you do the trade-off between chasing something new and becoming an expert there versus just

kind of going deeper and deeper into something you already know personally I just play around with everything and see what's the most fun and see what I think um just in terms of like the knowledge that I already have lines up the most I think there's definitely something to be said about no shortage of different topics different things that you can learn um so my tactic is just kind of learn a little bit about everything and see see what sticks yeah I think there's a difference between like a professionally and just exploring so in terms of exploring uh B just go for whatever is interesting it

doesn't even need to be web 3 related um but for like more the professional side like you're kind of bound by who's running contests bounties or trying to get audits so there are I guess like your more common D5 web three kind of things are going to be the the things you're going to look at most for me um it's primarily been ethereum smart contract security uh focusing lately focusing more on the infrastructural projects as opposed to the latest uh D protocol or uh the next you know new shiny object so that's

that's been my focus so it goes back to my coverage versus leverage right I mean there is so much happening in the space that one can endlessly hop from one to the other without really uh you know maybe getting your feet wet but really not understanding it well enough I mean especially a security re maybe for developers or for others that is an option but for security researchers you really need to go deep and understand uh anything really better than the developers and the project itself right so it doesn't give us the uh the freedom to sort of just hop from one place to another really have to go deep so that's that's sort of a limiting factor but

that's that's sort of what what I enjoy yeah uh for me I would say say I am a heavy D5 user so I think it's good to have the perspective of a user uh trying out latest D5 protocols and you never know when that knowledge comes into play so to give you an example uh back in def5 summer when me not even mean coins um all the food tokens were launching and then there's this like Master Chef and there's a sushi swap there's kimchi Swap and then you just start like depositing money because I'm in here for the tech and the money yeah uh so it it the the Master Chef contract like you start reading the code and then you start realizing how it works and then

you realize protocol start forking it and you're using it in various ways right so then that knowledge somehow comes into play because you start auditing or you start reviewing these contracts uh a few years down the road so I think it's like exploring and also understanding from a US users perspective how you can uh how you are using the system right and that gives you in a sense an advantage when you're in them yeah hi there uh this one's specifically for Nat but happy for others to chime in uh when you're writing notes and more around how you structure your notes uh so you go through with pseudo code and say writing things per function would

you tend to have a specific section just for invariant or assumptions or do you mix them amongst uh everything because it can be pretty easy to uh lose some of those important things amongst the mass of documentation yeah personally I create just a separate document just for the list of variants because I mean it helps to have it in code because the next time you go around through it you might realize something different about it but um for like talking to developers and kind of syncing with developers in terms of like correctness of invariance I definitely put that in like a Google doc and share it with them um I think otherwise it would be a lot harder to share in variance with

developers um and kind of to Pro to get feedback um on whether they're correct or not sorry you have a question over hi I'm jonath uh in addition to that question um how do you make sure that you have like all the invariance um completed in your list or not not only completed so but that the uh list of invariance is complete you're never going to be complete um I think the there's kind of a like you can be you can be as complete as possible within an x amount of time but I think um given time Box reviews

given just the time differential um it's it's going to be really hard for a security researcher to make like to make sure those invariant the list is complete I think as a sec researcher my goal is to essentially bootstrap developers with like these are the envirment that I think are true of your code base um it's obviously the developers responsibility to go in make sure they're correct make sure that they are accurate um and then hopefully for a developer to continue extending that list and continuing to change that as their code grows um but I can say for certain I've never been in a position where I felt like the invariance that we've considered and and kind of thought

thought up during a Security review was 100% complete cool hi hello time for one we have we have time for only one more question so yeah hey this is no and uh you know everyone knows uh AI is is becoming uh very powerful uh tools especially one we build protocol One Way coding uh so my question is uh relative to the the combination of AI and uh you know blockchain maybe uh we can use AI for our uh daily development and uh the

security research so I have two questions first is uh uh how AI can Empower you know uh security audit what kind of tools what kind of things you do with AI uh during the the uh security uh product and my second question is uh what's your uh recommendation for uh those uh defi Builders and protocols to uh use AI to empower uh their Securities and uh uh you know daily works thanks I can yeah so um AI I think we've seen uh a good use case is for churning

out report issues so I think evom for example he uses an AI tool to help uh write out his report but of course then after that he does a manual review and uh makes adjustments as needed uh the other is for uh kind of like throwing documentation into an AI board and then you ask it questions and you get it to ask questions back to you so it kinds of uh enhances or refines to understanding of the protocol and if you're unsure about something you know just ask personally I use cck gbt when I'm unsure of something thing I'll just like ask it um as when I I'm unclear of something or like help help me write out this issue and then I'll make some modifications yeah I mean just to add to

that um I think there are multiple projects in the space trying to leverage AI uh tooling right in all in the entire life cycle it could be for uh program understanding so in terms of you know feeded the code and ask questions about it um and of course like with anything else um hallucinations are a problem right so you can't just rely on it and I mean this I believe is a big I don't know how how bad the problem is but I believe um with all the bug Bounty platforms you know all the AI generated issues is uh causing a lot of spam right so it's sort of the downside uh but I I mean I think we're just scratching the surface in

terms of how this is going to help um and and yeah looking forward to see where where this evolves yeah I mean it's very promising but uh unfortunately a lot of the AI approaches have been like hey I go like I put this smart contract in C gbt and gave me all the issues and then the contract is like the Dow hack um this is like the weakest form of evidence that it can work um so yeah it's really cool could be really cool right now I think the main valuable approach is to use it for code understanding and not necessarily for like or llms in specific not necessarily

for actually discovering the vulnerabilities on its own so more like the hybrid like working together form yeah and I guess so one I bit might be in invariant development like you can kind of work together to like you can come up with your list of invariant and then more quickly develop them in like in the various Frameworks so maybe set Foundry and variant test like you might improve your workflow uh there one thing though you also said like how could projects use AI um I forgot the name of the paper but there was some research into the code written

by Ai and vulnerabilities introduced by the AI itself um and it turns out that there's some risk there as well where the AI even though you tell it to build secure code um it's not always very good at doing so um so yeah I would be really careful with uh yeah asking your uh CH GPT to build a whole dii protocol uh and then just deploying it and putting your money in yeah yeah that may lead to a whole class of sort of AI copy and paste bugs for programs that you know where where the training data involved buggy programs and sort of you know your co-pilot and

other things sort of filled it up that yeah