Finding Bugs: 42 Tips from 4 Security Researchers | Devcon SEA

[Music] all right GM welcome back so uh hopefully all of us are here for the workshop this morning this is going to be about finding bugs which is really what security is all about finding and fixing bugs hopefully and uh this is an interesting format for a workshop we trying this out um recently so this is going to have 42 tips from the four security researchers that you see here 42 why 42 42 is supposedly the ultimate answer to all questions in the Galaxy so why not finding bugs as well and the for security researchers here I'll let my smarter colleagues introduce themselves first with uran thank you um I am a security researcher at consensus diligence where I work mostly on tooling and automation so you might have used a couple of my tools uh but I am also a buck Bounty Hunter so most of my tips today will uh go into that part of security research hi everyone I'm dcho um I work for the red y I'm a co-founder we do security for the public benefit of ethereum ecosystem um and in the past I used to be a l aitor open sing for many years and before that I was a web developer and pester hey everyone I'm Nat I'm an independent security researcher um I spent four years at Cher La bits uh where I did mainly Security reviews and before that was blockchain developer for three years so yeah today my tips are kind of going to be blockchain Dev related and security researcher related fantastic and I'm uh Rajiv so I've been a security researcher pretty much my whole life started with ethereum security roughly about U 6 to8 years ago um early participant in some of the leading on audit contest platforms um and then uh for the last couple of years I've been a lead security researcher with speit Cantina um and in this context um started secum about three years ago so secum was um was was funded by an ethereum Foundation Grant and collaborating with some of the leading projects in the space the goal was really to scale ethereum security right and by that we mean onboarding the next hundreds and thousands of security Auditors U to make ethereum safer so secum is um is really an online community known for its boot camp check it out online has monthly quizzes designed by uh many of the well all all the people standing here and many many others in the room as well uh check that out and U secum also hosts trustex which is uh one of the leading ethereum security focused events so with that we will kick it off right the first question we really need need to ask is why right why why are we doing this Workshop why are we trying to find bugs and as you can see the whole not not just smart contracts or opsc and other things right the whole domain of blockchains right is really about trust and in this case finding and fixing bugs is really one of the biggest um you know technical risks not just in the base layer in the layer ones and the layer twos in the bridges and anything else in between but also in all the daps right all the smart contracts that really uh and and all the glue that holds them together right we need to be finding and fixing bugs why so why is that important I mean it should be very obvious to many of the folks many of the security researchers here but just to sort of put it once more if we would like ethereum to be the world computer if we want to really onboard millions and billions of people onto the onchain economy and if you really want eth to be ultrasound money we need to make it Ultra safe right so that's really the goal here so with that um context will'll kick it off and and this this really sort of hopefully justifies it right I mean this is from defi Lama as you can see and I don't I mean this is probably representative it really does not capture all the other uh fishing and many of the other things that uh are draining millions and billions so this is getting better I mean this graph sort of gives us a warm fuzzy feeling that hey we may be getting better but I think we really have a you know long long path ahead so with that we'll start with the tips thank you clicker awesome so all of you are probably on Twitter uh if you're not you're quite unique and if you've been on Twitter and read any of the posts around bounty hunting security research uh you see a lot of grind set Focus post and um I'm not saying hard work and dedication isn't what's going like required to be a good security researcher but I honestly believe that going into security research with the mindset of ah I need to grind so hard work 16 hours a day is the worst possible approach um if you look at other Industries like doctors um that have a similar kind of mindset where it's like oh I'm going to work so many shifts uh I work so hard if you look at the amount of incidents that are caused by people working multiple shifts it's insane uh and the same thing happens for security research like I'll be stuck on a problem for four hours at the end of the day and the next morning I'll solve it in 5 minutes like staying stuck on a problem just because you feel like you need to work hard not a good approach okay tip two scoping out targets and not just picking anyone at random is a pretty good idea when you're doing bounty hunting there's so many programs and if you just pick one at random well it can be a fun approach but it's probably not that efficient so probably the primary thing you should FOC focus on is the amount of time that you have available closer okay uh probably what you need to focus on is the amount of time that you have available on these targets so uh maybe don't go for like a bridge implementation or uh like a an L2 if you just have a weekend um and of course like if you're looking to make a living out of this or a significant amount of money then don't go for projects that offer low bounties one thing I actually look at a lot is not necessarily the height of the main Bounty which is like 10 million or one million it's usually very high I look at the the the Bounty that's offered for the high vulnerability because that's usually a really good signal about how much a project actually cares about security if they won't offer anything for highs or if their high is like 10K and their crit is 10 million um this is just like random um that's not a good sign that they actually care about security uh they just wna yeah prevent the main things okay tip three try to sleep sort up okay so this one actually happened to me uh I was trying to sleep uh and then well as as it happens my brain is like oh you were working on this problem here's the solution and so there was like in the middle of the night typing up a bug report um the idea here is not to try to work well you're trying to sleep it's more so um exploiting the idea that you have like your brain is doing passive processing on in while you're doing random things like trying to sleep or doing the dishes um and to really leverage that it's important to not try to do too many things at the same time because so for example if you're bounty hunting on a project don't switch to a different project just keep doing this one go for a walk let it process and find some bugs um and don't go like watch Netflix and fill your head with different things because then you can't like Leverage this ability of your brain like um I have a cool example from when I was in university um was working really hard on a problem uh like the we had these days where you had to solve a a challenge in a day uh kind of hackathon um and it was like super stuck for like the first four hours of the day um took a walk to get lunch passive processing happened solved the issue like right after lunch so yeah till the year take some breaks uh and leverage this passive processing okay now some tips about how to approach bug Bounty discussions if you're doing Buck bounties eventually you'll have a discussion with someone because projects don't always agree with the impact or what you found um Everybody responds differently uh there can be some emotions involved when you tell someone their code is broken um so one of the things that's really useful is basically learning a little bit of rhetorics and preparing for fallacies um people will come up with arguments that don't work addressing them or strategies that basically derail a discussion being prepared for them will just make your life easier in the end another tip on Buck Bounty discussions is kind of taking the mindset of working with this project as a business partner that you might want to do an audit with uh later um this greatest s communication that's that's much more productive and much less likely to result in a situation where you're just name calling like no your code is and then they're saying no you can't find bugs and everything sucks um so this really uh helps things out there and as an at a benefit if you actually do end up buiness being business marter laser uh you have a much much better relationship okay then um it's going to be super useful if you diversify your skill your skills so with defi there's all these super useful uh resources like secur uh um that can help you become like a security researcher uh but it's often easy to overlook the fact that learning other things that aren't necessarily directly related to um defi or smart contract security is going to be incredibly useful like learning quantitative Finance is has been super helpful for me like there's a couple topics here uh like for example learning how compilers work I think is an insane thing like insanely useful thing to know because you'll be so much more familiar with how programming languages work how solidity Works under the hood you just get an intuitive sense of how these things work and that in the end will help you understand code better find and find more bugs um it's also just something that keeps things interesting you know like after a while maybe defi gets a little bit boring this kind of switches it up uh so it's it's also just something uh to have some fun okay now some strategies that you can actually apply uh in uh your buck hunting process I think I think one of the things that works really well is uh finding a paradigm and specializing in it so for example in defi uh you have systems that provide leverage so what you can do is become super familiar with all the things that you need to do to implement leverage systems and what can go wrong once you know all these things you can just quickly go into all the programs that have some type of Leverage see if they do everything everything right and if they do you just move on to the next project so this is kind of like a an approach where you go super broad um and it can be super efficient what's important here is to get pick a paradigm that is relatively unknown or that you think nobody else is specializing in because that way you have some competitive Advantage um I um so uh I guess leverage and concentrated liquidity are a little bit old now uh but I guess like various CK topics uh can be something right now that there's not that many security researchers that specialize in these where uh there might be uh some some good opportunities um and I just pick something that you find interesting to be honest uh because that's the best way uh to to learn and go about this all that was the go broad strategy now for the go deep strategy um instead of just going for a bunch of projects for one topic you can pick one project and then go deep on that one um this is an approach I usually take because I have like I'm very time constrained I do like weekends like short weeks um and the approach I basically take is I I pick a project and then I take some time to explore it and identify by all the like the interesting bits the risky bits uh the parts that I think are going to be super difficult to implement right if I were to implement them that myself and then I basically just go have a look at those um and see if they if they actually made the mistakes that I think uh they would have um and that's actually like a super time efficient uh approach when you when you think about it uh and this kind of exploits the fact that as a bounty hunter you're not an auditor as a bounty hunter you don't care about finding all the bugs it doesn't matter like it doesn't matter if something is left after you go by as an aitor that kind of sucks if that happens but as a bounty hunter we just want to find a bug as soon as possible and this approach will allow us to do that we we'll just have to look at like the critical code the code that does liquidations uh we don't have to look at all the like boring bits like usually you don't look at like the erc20 contracts where they do all the interfacing right I mean you could but that's not the the go deep approach tip nine read the documentation okay so design mistakes can be critical people come up with interesting ideas that fundamentally don't work or are super hard to do right and from reading the documentation uh this has happened to me this has happened to other people uh you can already notice some bugs and then you just have to go into code into the code to see whether like the bug you think is there is going to be actually there quick side note there documentation usually out of date uh fortunately unfortunately depends on how you look at it um and uh there just like there's going to be cases where you find a bug in the design a bug that's been there but they already like came up with something that prevented it and just didn't document it at all even if you don't find anything reading the documentation will set you up for a success because you'll have a good General understanding of what the code is doing um which is like the best foundation to actually get started so if you like when I do the go deep approach actually the explore phase for me is reading the documentation first um because with this documentation in mind like actually starting to read the code is going to be super it's more going to be more productive because you have some some contextual awareness of where everything fits in the in the big picture then for my final tip uh this is kind of a mental model I started applying myself is when you are reading through a code base you usually notice like a these tricks or gadgets where um it's not really a vulnerability per se like even if you would submit it it might be an information or LW but it's these tricks that allow you to do things in a system that are odd or usually not supposed to happen and even though these tricks are kind of useless on their own they are used usually involved in um what you would call a killchain so critical vulnerabilities generally aren't critical vulnerabilities not single bugs but they are kill chains and kill chains are basically a sequence of stabs or sequence of bugs that you string together to achieve a critical impact and by keeping track of these little tricks you find while reading the code base you set yourself up for success say when you find an actual bug that's maybe not exploitable or easily exploitable directly but when you apply your tricks it suddenly becomes like a super easy crit um and just making a list or keeping a list on a piece of paper or whatever note taking app you prefer Apple notes could be whatever uh just keeping like a bullet pointed list hey I can trick the system into doing this uh it's not a security risk but it might be helpful that's going to set you up for success in building these skill chains and basically escalating a vulnerability from maybe medium or high to a critical with a lot of impact all right with that I'll give it over to [Applause] mat all right just a raise of hands how many of you here are developers okay a good chunk um all right so my next few tips um as I mentioned before I'm going to kind of split between um developer based and security researcher based just because um I guess I've been a developer for almost as long as I was a as I am a security researcher um and it kind of ties into even my current roles all right so tip one is um architect first code later um there's nothing worse than a as a security researcher or a developer than trying to fix your bugs and then realizing that one bug fix results in something else happening which means you can't fix it anymore and you have to Band-Aid patch another thing and then that thing can't be fixed because you have to Band-Aid patch another thing um as a security res researcher that nothing is more dangerous than this but also as a developer it becomes really hard to manipulate your code to add new features um to add behavior um when you have new code that you want to add um and at the end of the day it makes your code much harder to read um that means when you bring new developers on board um that's more time it takes for a developer to understand your system um and more time for security researchers in a review or in a bug bount teach to understand what you're trying to do um I think this is probably um one of the most uh underrated techniques is just to really think about your code um figure out how do you what what do you want your system to do um how do you want to build it um identify you know the architecture of your contracts of of whatever your um system is supposed to do um and code it later and I know that's hard because even I tend to sit at a computer and just write code um but I will say for a project that go under goes continuous development and continuous features um following this kind of practice makes um just reading that code much easier this is kind of related to maybe one of the previous tips um document everything I think from a security researcher point of view there's so many issues that we try to uh find in code bases and they're because they're either wrong assumptions or invariants that maybe aren't correct um yeah sure the documentation might not accurately reflect what the contract or the co code is supposed to do um but as a developer putting the actual um effort into uh like documenting what you want your system to do um how certain functions work what the expectations are um that can do a lot to actually helping um other people understand your code I think there's also been a lot of times looking at certain functions um certain code bases and then realizing that everything all the documentation doesn't actually match the implementation and then for security research is we have to spend a lot of time trying to figure out all right if that documentation or if that line is n correct what is it actually doing um it can help save a lot of time um in order to bring people on board as well all right this one I'm I'm sorry for all your develop you developers but simultaneously test and code um yeah I know tests aren't that fun to write and I've been in that space I've been in that mindset um but I will say that it does help you think about your invariance it does think help you or forces you to think about how you want your system to work um and it forces you to like actually test the outputs of your function which you wouldn't be doing if you were just writing the function um you wouldn't necessarily be thinking about um how a function is supposed to behave um if you weren't actually writing the test with it this can help with at the very least extending your unit tests extending your test cases um such that sure maybe your test your test coverage may not be 100% but it will be higher than if you were coding and then testing afterwards it also helps to use this method to test for edge cases um because if you're forcing yourself to say like there's like a function with an if statement that covers like different Corner cases having a test for that means that you're also increasing your coverage there and I think there's kind of a a really useful use case for these unit tests is essentially finding bugs before your Security review or finding bugs before your bug Bounty all right um this one is uh kind of related to what I'm saying before is trying to automate as much as you can um there's going to be a lot of bugs when you write your code that that's already a known Factor um the more time that you put in your development process to um documenting to testing um the more bugs you'll find when like your code is going undergoing development and also the easier it is generally to actually fix those issues such that hopefully when you get to your Security review or your future security practices um hopefully there's less loow hanging fruit so that the security researchers can actually focus on the really fun technical um architectural maybe even like protocol level um design concerns rather than we found another re-entrancy here um explodable here with this token because that's something you could find with a tool and it would save you it would maximize how you use your Security reviews um in in a better way this last tip for develop is um kind of higher level not necessarily in the weeds um is proactively trying to figure out how can you increase security within your life cycle how do you what are processes that you can use um in order to find bugs during development um such that your bugs that found that are found future um in kind of the auditing side or um the kind of further security side um are are the the big ones um generally the smaller the code the I mean the the bugs have less impact within the system to fix um and so the more bugs that you find while you're writing your code the better for your code all right this is kind of um flip-flopping tracks because I am also um or mainly security researcher now um so I guess raise of hands how many of you are security researchers or interested in heading that direction okay um then let's get started um this next tip is preemptively ask questions and preemptively identify all of the assumptions that developers are making and this ties kind of into the previous recommendation for Developers about documenting your system nothing is harder than trying to identify what did you actually try to build in the first place um a lot of the time I'll look at a code base and then realize yeah that I think that's what was intended I'm not entirely sure um here's me looking at the code base here's what I think it's supposed to do but um it's really hard to have that clarification and if you make a wrong assumption during your code review I mean you're you're you could be missing a bunch of bugs um and and issues within the actual code because you misunderstood how it was supposed to be used so for that I would recommend collaborating with your security team collaborating with the developers um make sure that you take the time and the effort to identify all the assumptions that you're making in your Security review um and make sure that that's a lot with what how developers intended to users to use their system all right this one is a bit of an overlap as well um but essentially to as a security re researcher building a mental model of the code base um is incredibly important because um and and this um graphic is from uh the most I guess Sherlock Holmes where he kind of references um thinking about like different con Concepts in terms of a mine castle and where he can um kind of figure out how to um categorize information into this um kind of strategic uh model that he can kind of be able to parse through information um be able to understand things and then be able to bounce ideas as a security researcher this is super important just because um once you have this mental model of whatever code base you're looking at now you can start to understand okay this is how um you know this particular flow Works um this is how developers intended um this certain flow to progress um and then you can look for deviations and assumptions where they can might they might go wrong um a lot of the times this helps with um kind of taking a break and then you can be able to really understand like different impacts um of like different issues and and especially a kind of higher higher level view of the system um understanding just like how the codebase was built and how it works goes a long way all right this next tip is to learn your tools as a security researcher there's endless number of tools that you can use um to verify whether developers do are doing things correctly um endless number of um different like fuzzing Integrations verification Integrations that you can check things and I think there's far too much conversation about which is better I don't think that's a productive discussion um instead I think it's more important for um security researchers to really sit down play with each of these tools figure out when does when do they come in handy when are they most powerful um and really learn how to use them um I think there's also endless resources on how to use these um and at least for me as a developer I just have so much fun playing around with these I think um the more you play around with different tooling and the more you play around with um comparisons between like use for example like um fuzzing a code base um or like uh writing unit tests on a code base I think the easier it will be to test the code um and playing around with um the code base with these tools that helps you in a different way because with code then you can test with test the code base you can kind of see okay what are the different branches within your function how do you invoke certain um like if M um how do you you know Trigger or revert and it really gives you a good idea of how the system works so I guess the T tldr of this is really just play around with as many tools as you can um and see where they help you the most as a security researcher I've realized that um how developers intended users to use their system never really matches to how users intend to use it I think that's just because um developers have an assumption of you know this is the one flow that users are going to use and it's just this is this is it um and users are always creative in terms of arguments or just like the ways that they call Smart contracts um any kind of any potential deviation in these two things can be um a fairly big bug um and can result in like an impact in the system um so it is one area to look at my last tip is to lean on each other's strengths I think um from a security researcher side um I mean I I I was kind of sitting in in both sides before um but as a security researcher they bring kind of understanding of you know the security implication of in the system um security kind of um tooling and and knowledge there developers usually understand how they want their system to be used kind of the more um strategic side and I think for a security review you can really take advantage of those two things um and really collaborate with each other and lean on each other's strength to maximize or rather to shorten um the amount of time it takes both parties to to understand a code base and then to maximize the number of bugs you find during your review all right with that I'll pass it off to [Applause] Tino hello hello hello hi everyone let's put the stopwatch thank you hi everyone nice to see you all here and thank you for coming I know it's early some of you went partying last night probably um hopefully not too hard um yeah so the idea is continuing talking about these tips uh for security researchers for developers um nice to see many developers in the room next time perhaps you can put like security researchers on one side developers on the other and like with throw each other stuff or something like that just to get it started uh but anyway yeah let's let's be honest okay I don't think many of us here I include myself we not going to invent the next new big thing right uh it's probably the case that we are iterating on something that somebody else in the past built or that somebody else in the past found so it might make sense to learn from history and to learn from what somebody else found or what somebody else built uh to try to secure the thing that we are doing that we are reviewing so for example you will find uh particularly in crypto that we are very good at publishing things is not usual in the rest of the security industry uh to public audit reports you should take advantage of that this is just one example of Cypher Sol AIT where you will find a basically a database of issues that has been that have been reported in the past by many security researchers uh across multiple platforms auditing companies if you don't want to use this you can go know trailer bits I think publishes reports open sing publishes con intelligence publes Sigma Prime does the same and I could go on and on and on so I'm not saying that you should read other reports like you read a novel but probably you should at least scheme through them if you are building a new protocol H that I don't know it's a defi laring stuff or some deck or some whatever that you're building next uh go see if there's some similar project out there that has done similar things to you that probably the answer is yes and go read the issues and probably you will find good stuff um just to double check if you're not missing out on something it's sad when we see in the out there in the community the same and same and same issues being repeated again so please I don't know take a look at this or many other resources out there we already talked about this uh but I just want to reinforce the idea um particularly for for people doing security research out here it's very difficult to understand to what extent you should go deep to what first time you should go white uh there's no clear answer there's never a clear answer uh my only tip here is uh whenever you are very mat in depths of a code base be careful okay um it's very easy to get in tangle in I know line 250 of that a th000 line assembly code that you're reviewing and you end up finding something very cool that I know you can do something very unexpected in that function but there is it's very hard to sum out uh because you need to find the actual attack Vector you need to understand impact in the project and to understand impact you should have context how many times have you found something to then realize that well yeah but nobody can exploit this um if you are a little bit evil you might end up reporting that still to the developers just to fight with them and they will end up telling you that well uh it's not exploitable so zo out have context understand where you are standing understand the expected use cases uh an issue could be an issue for you but if the system is not actually expected to be used that way I don't know if it's not expected to integrate with that other protocol that you're thinking about or it's not respective to use that token that you're thinking about your is won't make sense so uh have in mind these kind of things di Mission returns uh are a I know something that I struggle with and actually I have questions I don't have tips uh I will borrow tips from you if you have some similar bullets to solve this um I usually don't know to what extent I should be chasing down bus I mean it will depend on the kind of Engagement that you're doing right so I will talk about this later but auditing is not back hunting and it's not doing contest for example so to what extent you should be chasing that bags um to what extent you should be going into that rabit hole when should should you stop probably experience will tell you something about it uh you will start growing some intuitions little by little on to what extent you should be yeah going down certain paths and not choosing others then when it comes to reporting doing Prof Concepts is also a place where we lose ourselves as security people um how much detail should you put in that how many I know how much infrastructure should you be setting up to test that bag you found in that bridge with that connect a thousand layer threes and fours and whatever uh sometimes it's very complicated and you might end up losing too much time on that I've been sometimes like a week trying to set up a whole test n environment to try out an exploit uh just to realize that then when I reported perhaps it wasn't the case or the proof of concept it's too complicated to run or I end up debugging the my own proof concept instead of debugging the actual code that I need to review so again just uh questions to think about things to consider either and then the last one I'm not a very big fan of uh this new security contest but some people in the room might be um you will find this escalation Wars if you're not familiar with it essentially uh in contest you will find people like competing to submit bags at some point in time there I think this is true in all in many platforms but they all do the similar things but not exactly the same uh people will start fighting each other just to um escalate their issues and try to make them more or to fight back the judges or whatever and you will see like endless threats of people throwing at each other um and spending precious time on that while they could be doing something more valuable for the ecosystem um but again I've been in some cases there and I know the feeling and it's very hard to to understand to what extent we should be doing it uh but anyway dimin returns uh okay diagrams yes I love this part as a security researcher I'm a visual thinker so that means that I often times find myself like drawing stuff just to think about the things that I want to do I also write a lot and I will tell you all writing then uh but let's talk diagrams now I use diagrams to understand systems and this I and I do different kind of uh level of details in diagrams this was me for example trying to understand account obstruction uh in the past uh and I ended up drawing this as I was going through the code through documentation and everything I was just drawing stuff and trying to understand what I was seeing in this case it's more kind of an architectural diagram I don't know I don't even think about it I just write components and I write names and and try to see which are which are the actors how are the relationships and this at least for me is very useful uh perhaps for you too so take a look at it and perhaps you you will find something valuable then I do some other things uh in terms of tyam I could go into more detail with them in this case this is was me just thinking about the them buner defi this is kind of a set of security challenges that I created this is one of the solutions for one of them so I was explaining this at DSS and I Ed a diagram to explain the actual solution so you will see me like doing function calls and usually drawing where are the funds and where we should be putting the funds and everything this just one example in real AIT probably I will be doing uh bigger things such as this h i I do go in depth sometimes so this was me back hunting in ler um so in this case I was reviewing main at contract so and I need kind of to create a mental map of how the contracts work and how they interact with each other and where are the addresses and then I would use like uh yeah which are the EAS in this case there's a multi there and then I would try to understand how fees are distributed and I also use diagrams and I they would try to understand uh story St layout and I would also use diagrams and so on and so forth right so uh you might say that I'm spending too much time drawing stuff and not looking at code but this is just the way I think uh often times and I find this valuable uh in many cases IED up finding bags just by looking at diagrams and trying to understand how actors and contract relate to each other and sometimes I end up finding finding kind of holes in my diagrams so I realize that people can call things that shouldn't be able to be called so yeah and well you can use whatever tool right so you can use online tools your whiteboards in your rooms in your offices whatever that you that you feel like um moving out with the comfort zone is another good thing uh that we should be all trying to do in many aspects of life but let's just keep with security research uh I just put that picture of that book because I like it if you want to read it and give it a try uh it has a chapter about the comfort zone so um if you're a security researcher uh probably sometimes you will yeah you will find yourself uh Growing Experience in certain fields in certain categories let's call them of vulnerabilities or or even protocols uh but sometimes it's good to do something else earlier this year I was um I mean I've been for most of my career I've been auditing solid smart contracts uh so I don't have that much experienceing notes and infrastructure for example but earlier this year uh there was a contest I think it was on Cantina for blast and I had the chance to either go for the smart contracts I mean I didn't have much time so I had to choose smart contracts or go for the node H which was written in goang it was a fork of gu and I decided to go for GU H for the fork uh and I didn't look at the Smart contracts I missed H the all the fun that people had with the smart contracts um but I did have lots of fun reviewing it um and I learned a lot and I ended up finding issues and we did quite well but I wouldn't have I wouldn't have said that I was a an auditor of Goan code uh but I ended up finding things and that only happened just because I I moved out of the comfort zone and I started learning go I had never read anything about golang um so I learned about it I did a few courses I prepared myself I went in there and ended up finding things and even if you don't find things it might be the case that you end up learning which is always cool and the things that you learn you can actually use in the next contest that you do and little by little you can specialize in that new technology that you're exploring um so I'm not saying you should always be doing this otherwise it's like you're not specializing in anything but every now and then see where you can do something else uh if you're are a smart contract auditor see where you can audit a node or the the other way around right um just give it a try and see and then you can tell me about it so writing I told you that I'm a visual thinker but I also like writing a lot uh two articles that I recommend essays about the from from Paul Graham that I recommend reading about writing and importance of writing particularly for thinking um I do very much agree with idea that you only know something if you can write about it and you can explain that to something to someone else by writing it and that's the only way I'm sure that I understand something probably if you follow me online H you know that I write a lot and I publish articles on on on the blog of the red Guild and that's the way I think and I spend a lot of time writing uh so when I do AIT I explain my functions in writing I take down notes and little line by line and explain myself what the function is doing and in that way I can find bags uh because what I write sometimes doesn't make sense also when we are exploring a new codebase it's the case that uh we explore many different uh lines of thoughts but you cannot be jamping around uh many lines of thought right I usually I'm single threaded so I can only do one thing right uh so I write down the other ideas I have and I don't want to forget them so I write I write them down and I come back to them later in the next day or whatever and to communicate I always say that secur doing security for me is uh particularly for Auditors 50% finding BS and 50% communicating backs you might be the best finding a bag but if you cannot actually write a good report and communicate that to someone else and convince that someone else that you're right about it it doesn't make any sense so uh du L to write it's very very very important and it's also somewhat fun uh so I do recommend that a particular strategy to find bugs uh It's just sometimes going for what's not tested um what I sometimes do is essentially jump into a test Suite see which are the P functions in the contracts that are never called and start exploring there it's usually the case that whenever there's a public function that is never called from the test it could be yeah it's sometimes the case that there might be something at least at least to explore in that sense then what I would do is that I take advantage of the ex existent tests I modify them I hook into them I rework them I bring them around I I do whatever I want with the tests uh but just because I don't want to be building test from scratch right so I want to reuse the existing test Suite that's what what that's why it's very important to always H take a look at them try to use them run them and see if if it helps you we could talk a little bit more about this uh I don't want to extend myself uh I do have some minutes left according to Rajiv he told me I had some extra time um so for me oing is not back hunting but hunting is not contest and contest are not aiting the skills the mindset the experience the intuitions the way that you play these games is totally different and you might be the best auditor out there I I consider myself a good Auditor in the past and then I moved to contest and I realized that people play a different kind of gaming there uh and perhaps I wasn't the best doing that and about country is the same right uh in aiting you will find yourself doing client facing work you will find yourself going deep and going wide and going very detailed and writing very detailed reports and talking a lot with developers uh not necessarily discussing but just thinking along along with them just to to find more vulnerabilities and backs and you have access to to these developers often times you also feel the responsibility when you're an auditor particularly if you're leading audit you feel responsible for what you're doing which might not be H sometimes the case if you're just back hunting right back hunting you're just perhaps a Sol back Hunter you're uh um shitless in your home just doing whatever you want and looking at some code sometimes you look it more you look less you you might not feel as responsible as other people uh um you can go as deep as you as you want you can just get one win and you're done Auditors might need to find everything it it's a very different mindset and in contest well contest for me are just like Madness um some people find it fun uh sometimes I do but uh again it's a different kind of game you should be finding sometimes specific bags that are more unique uh you should be thinking differently about how to report some people leave them influence judges some people throw at each other just to escalate their bags I mean they are a different mindset too so uh if you're an auditor perhaps you're not a back Hunter and perhaps you're not good at contest or the other way around but choose your ground and know what you're doing uh I about to wrap up so whatever ground you choose H try to be professional we see lots of people on Twitter um not representing very well the security community in many ways so I always try to share with people these ideas of being assertive without being aggressive stand your ground but not necessarily being aggressive with developers be empathetic to them and new developers with have security research too we try we try to always be as thoughtful as possible we take our time uh to think about the things we want to report the things I want to explore the things that we share with you um always putting as much attention to detail as possible this is a big uh thing to me uh paying attention to details in reports to the code when I'm when trying to find uh BS so very being very thorough being sometimes slow and being thoughtful about what I do and always trying to be kind to each other I I this is the kind of the hippie part but trying to be kind to each other and respectful uh we all have uh we are humans we have friends family problems we can get very adversarial sometimes uh but as long as we are respectful to each other uh and we don't each other publicly on Twitter uh sometimes it could be necessary a little bit um but please avoid those reports on Twitter or you just public shaming somebody somebody that is not answering your report that you just submitted 15 minutes ago and it's ends up being an informational or whatever uh so try to be professional uh we're try to be like big security Community here wrapping up have patience everything takes time particularly when you're doing security becoming a security researcher takes time finding backs takes time reporting triaging judging escalations let's not even talk about how payment sometime takes endless time so yeah it's a game of patience lots of people coming to me what should I do how should I get started how should I find this this and that and what I always do is be patient uh because uh we are here for the long run Rajiv you're up thank you great good to see uh people sticking around till the 30th tip so uh people may be getting hungry but I would request you to stick stick around for 12 more uh there is a fun quiz at at the end with rewards which may be interesting all right so uh the next 10 tips more uh memes I would say um I would like like us to zoom zoom out right so you've had fantastic tips sort of covering both the security researcher mindset good to see developers as well so covering that as well and by the way on that we need we need more people in security so if you're devs then do consider not just securing your own code base um and having that attacker mindset security mindset but do consider looking into security getting into more of security as well so in this case the first thing is really both as a Dev as well as a security researcher is to zoom out and sort of assess the protocol that you're building or reviewing right first thing is I mean look at this so Billy somebody hands them or her um money right but would like to sort of take time to explain the importance of smart contract security but of course you know YOLO go and dgen mode look at what the assets are put it into the vending machine do some actions and then you know make money or regret right so this is I mean this may seem like fun but it's all about the assets right I mean that's that's why we're here all these assets are being put on the blockchain in U various forms what are those assets as a protocol you obviously will have a very clear view as a developer but as a security researcher this is the first thing you need to see what tokens right where are they being held where is it entering the system and more importantly where is it exiting the system because attackers are really looking to exit out of the system with the these assets right so having this mental model documentation of assets is really critical and of course actors right I mean these actors could be users of your system could be abusers could be attackers could be um developers themselves in in the sense of you know all the code that's gone in and potential um impacts negative impacts as well I'll get into more more of that later it could be even the governance right I mean here we are talking about smart contracts in general right so it could be even the governance and how does that how does governance as an actor factor in to your threat model or trust model so that has to be considered and of course all the actions right so what are what are the various actions uh that can be taken by these actors when are these actors uh when are these actions happening when does it make sense when doesn't it make sense right I mean these these will be very clear to the developers or the security researchers once in the context of the protocol but you really have to zoom out and think about these very consciously and how are these actions impacting the assets how are they impacting the actors and why does this all make sense so that is at a 100,000 foot level I think that is really what this is really what security is about so if you go back I mean uh for for uh those who are familiar with security Theory this is really what an access control Matrix is you have the subjects operating on the objects you have the Matrix of permissions right so this is fundamentally what we are looking at all right the second meme so you may see sort of repeating repetitive um things in the tips that we have we've been talking about but that this is what we are doing consciously to drive these points home right as a developer you may have an expectation of your ideal users right or the users of your protocol but the reality is going to be very different and as a security researcher this is something you have to pay you know great attention to right again users and abusers how does this particular protocol get normally um I mean how does it function normally what's the normal behavior but then that is that is fine we need to build that model but what we are looking at is the anomaly right how can this go wrong now not all anomaly is bad right I mean obviously there are so many things U that we don't intend to capture in the protocol which is fine and not every anomaly is a security issue right it's really a small subset of that is what what we call as bugs right but really vulnerabilities that really impact the system that affect the assets that affect the actors drain it out and and everything in between so this is something that is super critical that all the developers should really be thinking about right how is this going to be used how is this going to be abused the reality is going to be right more than one user I mean the the monkeys on the keyboard sort of an analogy right so really pay attention to this and this is not just the users I mean this could be again extending to all the actors right it could be the governance as well you've seen whole bunch of governance attacks where um it wasn't within the attack the threat model to really consider something like that happening but that is really what happens and for the users right I mean this applies really to every scenario so as as a user or a security researcher one I mean we could expect uh on the flip side a particular sort of a behavior from the developers right but of course we have scams we have Rock pulls so even there the reality might really not match what our expectation is so for all the users developers and the security researchers there's really a message here great so third one third meme challenge assumptions I mean we are saying this repeatedly in different you know using different memes different ways of saying it but this is really the root of all bugs right the assumptions made by the developer about the user the assumptions made by the security researcher about the code base about the developer the assumptions made by the developer and the security researcher about the users I mean all combinations right so this is this is really the root of anything that's wrong with security right so question everything as a developer question question all possible scenarios all the different ways that you know maybe you have a design maybe you have a spec from uh from your team but how can this be used right how can this be abused question everything every scenario all that has to be captured within your model and as a security researcher again question everything right I mean ask Nat mentioned uh tincho as well about questioning everything to yourself and as much as you can to the protocol to the developer team as well right because if we do not understand as a security researcher if you do not understand what this is supposed to do how is this going to be used we certainly cannot understand how this is going to be abused right so as much as possible obviously practically there's obviously a limit it's all time boxed so figure out you know and this uh depends on the model as well so if you're doing a collaborative review you know you have quite a bit of leeway in terms of asking questions if you're doing a contest maybe not as much if you're doing a bug mounty again very limited ways of uh sort of questioning the protocol about every U knit and you know Nitty Gritty detail that you may want to know about right but try to get an idea of who again actors actions assets who is it what is it being done when when and where right so that is really critical question everything and security is nothing without discovering the misuse scenarios right again repeating myself use and misuse critical and abuse is really a subset of misuse so figuring out just the various misuse things is not going to um you know do much as a security researcher you have to figure out the abuse cases and the abuse cases are really the vulnerability ities we'll talk about the impact in a bit and really to map out what the attack surface is right so for a developer in this case it is really to reduce the attack surface of your protocol of your code base reduce it so that I mean one way to reduce it is to reduce the complexity right reduce the number of U actions that can be done figure out what is really critical there is a concept called guarded launch you know maybe you can do it in steps various ways to reduce attack surface because if you reduce it then the potential for abuse is much lower right so the probability goes down and your actors and attackers I mean we we are in the blockchain environment right so in this case we really looking at sort of um the worst case scenarios from an adversarial um mindset anything and everything can be attacked and will be attacked and by anyone who is a part of the system so we really looking at a very uh High bar right when it comes to who that attacker is unlike the web 2 or the web 1 World we do not have an good idea of who the Insiders are and who The Outsiders are who what is a characterization of uh the the normal users of my system so it's a really adversarial mindset um that should be kept in mind when you're designing coding and reviewing great so um severity tincho talked about this in the context of bounties and and uh contest this is probably more relevant for the security researchers right if we do not I mean we we great we found a misuse abuse scenario but if we cannot determine and communicate like Ino said what the impact is then it's of no use right I mean it's probably going to be like an informational finding or maybe a low severity one but not much but quantifying that is super critical and the way the sort of the rule of thumb is to see evaluate the assets are they being lost are they being locked is it temporary is it oops is it uh permanent is it does it apply to all the assets or is it only a few of the assets is it only the fees or is it the user assets is it you know can they impact assets of I mean assets that they own or can they impact assets of all users there are so many ways to sort of slice and dice this right so that is critical I mean this and and the good thing is I think the impact is U objective I mean can be fairly objective in terms of how we determine it but likelihood which is really the probability that this can happen that is trickier right is does this happen all the time does it happen sometimes what are really the conditions under which this particular um vulnerability can be exploited that's really what we're looking about right uh looking at so that is um hard uh and typically what ends up I mean that's where all the escalations happen that Ino was talking about and these conditionals there are a whole bunch of Nesta ifs right that if this condition is met and this and this so you go on and I think realistically the more the number of predicates or ifs the lower the likelihood right so figure out what uh the likelihood is what the impact is and uh use that to sort of quantify the severity of the vulnerability that you're reporting and on the flip side for the developers who may be sort of looking at these audit contests or bounties right this is again I mean if you're evaluating uh if you're one of the judges or if you're on the team looking at U any of these contest results or Bounty submissions this is something that you need to pay attention to right and and it It's Tricky but it is really important great so for the star Star Wars fans it's really all about being consistent for the developers it's about being consistent with your checks in different parts of your code base on the various assets on the various actors and actions if these checks are inconsistent then it leads to inconsistent transitions right in your protocol and those result in inconsistent State and that is again the root of all bugs right I mean these may seem very obvious very simplistic but at a 100,000 foot level that's what it really is right so if you go back to the code that you're looking at uh that you're developing or the or you're reviewing look for these patterns of checks anything that's done in one place that is missing in other places that is uh you know it's a big red flag it's a good starting point right so web 3 well this is uh this is a meme adopted from web 2 right and it's I think I've seen it used in the context of dependencies where the the small uh block that you see marked out as bug is really a dependency for almost everything that you run but it is small nobody really knows about it nobody really knows when it was developed and whether it's being maintained and breaking that right could really bring down the entire space so in the case of web 3 I think um it is very similar and I think it is even worse because web web 3 is not of sort of isolated from web 2 right it's really building upon web 2 and and there have been many talks here that talk about the web 2 aspect of security so we won't get into that but the bugs in web 3 can be any anywhere and really they're everywhere at this point so this may paint a very sort of red nasty sort of uh uh picture uh very pessimistic Outlook but I think we are getting better right I mean it's it's worse it was worse it also sort of signals the maturity of uh the entire stack the entire space but these are getting better right and as we do this we also add adding a lot more um lot more codebase lot of you know a lot of new infra a lot of new tooling so it's sort of um uh cat and mouse game right you you fix these bugs but there are new ones there's new code bases and there are new bugs in them so for for the developers I guess the message here is that every line of your code M codebase matters right so just be very conscious about everything that is getting into your code basee try to see if it is really required or not and for the reviewers for the security researchers read every line that's not enough read between the lines as well and what this means is what it's it's relatively easier to sort of find bugs in the code that you see but it's much harder to imagine things to imagine bugs in the part That You Don't See right so do that and uh and that even then it's on enough right so it's uh it's almost um an unreachable challenge for the security researchers because you have to read every line between the lines and Beyond the Lines Beyond the Lines is really about the dependencies that you see here right it's not enough if you look at what your code base is but all the other code bases I mean we really building the Legos of the future or the the the financial uh defi blocks the future internet 3.0 piure term right if you want to build that then they have to work together and if they have to work together we cannot afford to have security issues in the glue that is connecting them right so that is that is the real part here so in the case of web3 smart contract specifically you may be looking at dependencies on oracles right I mean dependencies on other protocols dependencies on your web tooling all those can have bugs and has to be within uh your U uh threat model right so next meme for all the Matrix fans here bugs are really everywhere right they're really there in every code base it's it's pretty much a matter of um what incentives are right for the developers or the researchers to find them so the message here is look at what's there and what's missing for all the developers think like an attacker right the security mindset how can it be broken so that is really the sort of the repetitive message here and for the researchers obviously think like that but also act like a white hat right uh we can get into more of those stories later on I think uh yuran had um had a talk earlier on with u talking about bouny stories at the security conference okay so this again is invariance Right a lot of security well lot of it in the smart contract space in in your code base boils down to invariance invariance is another term for properties what properties should hold in your code base what properties should not hold good in this code base right and these have to be consciously thought about right I mean this comes up in the context of uh formal verification typically where you'll have to specify the invariance and then use a checker but then even without that as a developer before you write a line of code right think about what should what invariant should this satisfy what are the properties that I'm actually coding for and document it great if it can be a formal specification fantastic right because then we can use formal verification tools but let's even lower the bar right write it in plain English what is my code supposed to do that is super critical for all the researchers and reviewers who look at your code basee Nat talked about this as well document everything right put it in quote comments inline comments Communications is going to be super critical in the space and all of us are sort of repeating all this over and over again because it's really all these fundamental principles that apply so readed as a security researcher read all this hopefully the devs have written up all this ask ask questions be direct in asking your uh protocol teams or your on your favorite contest or Bounty platforms ask you may not get the answer but it doesn't hurt and ultimately try to infer some of these if you don't get the answers right so that's that's possible as well there's a uh fantastic area of research where you can actually infer inv variant and a simple way of thinking about it is inconsistent checks if there are some checks if there are checks in some places and not then it's either an invariant or those missing checks are sort of exceptional paths so try to infer looking at clues in the code and docs and so on all right the the final tip is just find it right I mean we tend to um talk a lot think a lot but ultimately it is really about reading the code right and and the good good part of the space is most of these Protocols are open source they have verified sources so you can actually look at the code base right and know that okay it's hopefully the same one that was reviewed was deployed look at the code there is no buck free code it may not be the you know critical criticals or the highs but it may be the lows and the infos but there are bugs right read the code find the bugs and like all of us have said both for devs and for researchers I think success you know we may think of overnight successes but we don't see the sort of the we see the tip of the iceberg but there is a lot of preparation that people have done right people have spent uh years decades in different different ways practice and then ultimately patience so I have I have the pleasure of U also sort of summarizing a lot of all these steps we'll do that in the next two um next two slides and then we will have time for questions we have 10 minutes and then there's also a fun contest so quickly right for devs before you code specify and design and after and during you Code test right so this is not I mean it it's it's written as sort of a linear thing but it's really sort of a cyclical thing it it happens it's a helical model so do that repeatedly think about assets actors and actions actions think about where assets leave your system security mindset is critical in this space both for devs and and the security researchers shift left which is a really well-known thing in the space and all it means is that let's not wait for you know uh test in prod kind of a meme right think about Security even before you start coding for the devs think about I mean that's that's really what that's really the uh environment we are in in in this case right test properties trest invariance use your favorite tool it could be you know the the the provs we have some fantastic ones from um uh the serator approver use use fuzzing we have the Medusa from um from Trailer bits use simpler static analysis tools we have so many of them as an example Slither and if if you're U more into bug bounties you have various tools there as well use Foundry use solo D to as an example to look at some of the P to learn from the past use glider to look at things on the main net there are so many of these tools play around with them right I mean some of them may really work for you some of them not and for the devs obviously the buck bounties and you know things may not may not really matter uh for the devs but all the various other tools right there are so many plugins for your Dev environments use those to test it out there are testing Frameworks there are ious extensions the key is to find your tools and your techniques right and there are we we I mean we lucky to have a good choice think about the use and abuse scenarios think about the adversarial environment think about defense and depth right because if there is any place where we require defensive programming this is it right do not assume that I have um you know I have an um I have an array and it won't overflow right or I have this code path nobody will uh it won't be executed or nobody will um create a pool with this uh weird erc20 token right do not make assumptions right and for devs in this case um yeah so won't repeat we're out of time we want to save time for questions as well but all these things right and all these slides will be available uh soon the video I believe is being live streamed but the bottom one I think is critical right we tend to get overwhelmed but take care of your code as devs from a security perspective and more importantly take care of yourself well with that thank you cool so U I think we have questions we can take I don't know if people in the room have questions or or if they have used the tool to put it up here but maybe we'll start with this hello hello hello we yeah all right the first one um what do you think regarding an issue in erc20 standard discovered in 2017 which caused $15 million loss by ethereum users which one is this I what I don't recall that one I don't know okay excuse I don't have a formed opinion about it thank you okay while while that link is getting posted I think we have one that went up how do you say your process is unique what do each of you do differently from everyone else oh that's a good one um I would lie if I'm I would say my process is unique [Music] um I don't think it's honestly I don't think it's Unique I think uh well I don't I haven't worked with these guys side to side but um I do to some extent our process might look similar sometimes I think we might defeat initiating to what extent we use tooling for example that's one case in my case I don't use tooling very much I'm very much a manual reviewer uh but perhaps not Rajiv or or Jonah might use some more tooling sometimes okay go first okay so um I was very interested in the to in this topic last year or sometime last year like different methods of approaching bounties Audits and there there's a lot of different ways of going about Audits and security research but in the end they're all not that dissimilar I think for J's last slide is just read the Cod um in the end that's kind of what everybody ends up doing um Everybody builds this like General mental framework that they add information into as they read codes um writing specifications running tools they are all just methods thinking writing another matter of thinking about the code but in the end you're all just like mentally processing uh and yeah so I don't think it's going to be super dissimilar yeah I would Echo that I don't think it's that different um I used to do a lot of my reviews with invariant testing and fuzzing um but I don't think that's atypical um I think if you put the time into really learning how to use the tools um I think anyone can really spin up like a fuzz test um it's really just a matter of kind of how complex um you want to get with that there's too many tools should we pick that one um I think uh n had a slide on this um doesn't matter which tool you use just use the ones that work for you um I feel like that's very true there's a couple V code extensions that are super nice I personally don't end up relying a lot on this kind of tool I use V code bookmarks super useful uh but that's not really security researchable obviously you're going to use some syntax highlighting go to definition type tooling um but beyond that is really like what works well for you um um and I recommend you try out like all the different things um in terms of researchers to recommend these guys there are a whole bunch I mean um just just go on Twitter um look up and let let me look at the publication right um which publication so I would definitely uh do a shout out to uh block Threat by Peter from from coinbase so as a publication so it's a I think a weekly thing where all the threats in this ecosystem are very neatly compiled so do take a look at that if you're interested and um if you're specifically interested in smart contract bugs then the various um reports from from contest from U different project I mean different firms like diligence they all have you whatever publicly available reports on their soloed that com that compiles it so those would be uh definitely some there is a whole I mean all these security videos right um recorded talks so there was a uh defi security Summit DSS conference last week and I think we had pretty much every uh well most of the leading researchers in the space web 3 web 2 anything in between every aspect right were there all their thoughts have been captured so just go to those YouTube channels or wherever they're hosted take a look at it uh so that is something I would definitely recommend I found the link by the way you can find it in this thread if you scroll down the comments okay I don't know how to scroll down um not in this yeah maybe yeah we'll we'll hang around so you can show it to us offline as well can yeah sorry I wanted to add something about tooling um I personally use Foundry a lot does it count as a tool I don't know but uh I write tests and I do fasing with Foundry uh that's mostly what I do and yeah visual code visual studio ctions and that kind of things cool can can we go back to the slide I I think there was just one slide we needed to show for the quiz so while it comes up so this is a a short quiz it's really 15 minutes and you don't have to finish it now just look at the QR code uh it's eight multiple choice questions there's a small contract which was designed by uh and this was designed by tincho it has uh you know for for the devs and for the security researchers there are some bugs in these uh contract Snippets so if you go to that link and if you use this password you'll be able to answer the quiz and uh the top two top two participants will get tickets to DSS next year DSS is the defi security Summit the security conference that happened last week here in Bangkok so hopefully it'll happen next year as well so yeah if you get a chance do take a look it's going to be open for about a day and any further questions so yes thank you for sticking along any further questions uh we're going to be hanging around in oh there's one question in the room thank you can I explain the history of the issues that was asked regarding the erc20 standard can I explain it and ask you for your opinion regarding the issue I I'm sorry I don't understand your question history of the erc20 attack the erc20 uh problem that was asked in this uh commments channel the erc20 standard contain security flaw that the Fabian vage the creator of rc20 standard confirmed in 2023 uh it is classified as the lack of transaction handling so the erc20 standard is designed in such a way that uh when you are trying to send tokens to a Smart contract which is not designed to receive Tokens The Tokens are lost permanently for example if you would send ethereum to some smart contract which is not imp which does not implement the receive function or if you will send the nft token to such contract that doesn't that does not implement the on ERC 721 uh reception function uh it will not be lost but the ec20 token cannot be uh uh handled on uh the contract's uh side as a result uh if you send such tokens to a Smart contract that cannot reject them they will be permanently lost so in uh 2017 this issue was described uh there was 16,000 of dollars lost because of this issue at that time in the next year there were $2 millions of dollars lost uh in 2023 there were $60 millions of dollar loss because of this issue because it is still not patched and uh on 1st November 2024 there were $90 millions of dollars lost and two days ago a user lost $25 millions of dollars because of this exact issue got it yeah I think uh we understand it now so token sent to a contract being lost right as a as opposed to being sent uh accidentally to a contract right so I believe I mean it is it is how it has been designed so users actually excuse me uh why is ethereum and NF designed in another way and does not cause the loss of money for users do we want to say that the loss of money was designed I don't believe so this is very specific to Smart contracts right and it's not nothing to do with the ethereum base layer and it also is about how your smart contract works right so we can go deeper into this I think there's a misunderstanding here so we can uh talk about this but time's up but we also want to take the last question in this room uh thank you uh just very curious uh uh perhaps maybe the three of you can uh like describe how you approach a fresh Cod code base where you studied and like how do you map out and what your workflow like thank you how do you look appro a fresh code pleas so I already answered the question I think before so me personally I start with the documentation because there's going to be problem sometimes you already find bugs just reading documentation I think I saw a Twitter message like or the other day where someone actually did the same thing found a bug reading just documentation and then usually like Global scanning of the code base and then for me I usually take the go deep approach so I just like spearhead for for the parts that I think are uh vulnerable but I think that is mostly a bounty hunting approach doesn't work for auditing or yeah a let others speak to that hey thanks for the question uh so in my case um I will say yeah documentation first uh with a healthy dose of disrespect for the documentation don't trust everything that you read because it might be a case that in the code doesn't match the documentation so you have fun with issues there um and what I would also do is just this is perhaps something personal but I will just start with the little Parts uh I wouldn't go first for the big contracts where you have like all the main interaction everything sometimes I just start by the small libraries but isolated things that I can then just treat as black boxes in in the future in the so I would start at the beginning with those and then move up into complexity yeah I would Echo documentation I would also add um starting to like find and identify invariance from the beginning um so I kind of start with that withd documentation and then reading the code finding some more invariance and kind of iterating throughout that process um I think over time the more you understand about the code base the more invariance you can find and very likely um the more break thank you [Applause]