[Music] hello everyone welcome to another episode of the day Zero podcast a little bit of a shift this week for our regular listeners instead of our regular topical coverage this week's binary episode we're going to do a follow-up video to our previous discussion from a few years back on the future of exploit development and it's one we've been wanting to make for a while because where it's been a few years things have changed our views have changed changed a bit because a lot of what we talked about in that video such as mte was at the time mostly speculation but has now been brought to fruition before we get into it though I think Z wants to clarify a little bit on the scope of what we mean when we say exploit development and some of the terminology there yeah and I also want to say with our last video I did feel like we came across somewhat pessimistic and I know some people have actually used as Reas to not get into exploit development and I am definitely a lot more off Mystic than I was at the time of recording this but yeah jumping into some of the uh terminology that I wanted to hit on one of the changes I've seen over the past couple years actually is a change in what certain things mean just as more people are coming into security certain terms are kind of becoming almost genericized in a bit like exploit development when we talk about exploit development and the future of exploit development what do we mean like you know it's kind of been genericized where some people are using it to refer to like their development of like a web exploit where they're do like exploiting a you know time based SQL injection that does take a little bit of complexity there terms of ordering or not ordering the request of making them there's some complexity there so they're developing an exploit for a bug completely fair to apply the term there but what we mean and how we're talking most specifically in the context of memory corruption bugs and lowlevel exploitation in a similar way binary exploitation is kind of similarly generic or genericized I guess um where you could mean it as you know exploiting of any sort of binary software so you know any application that gets compiled down to binary code any vulnerability any exploit of that could be binary exploitation but again more what we're getting at are specifically when it comes to memory corruption bugs so that's like your uh buffer overflows out of- bounds access your memory over like use after free or double free or type confusions it's those sorts of bugs and not like your command injection to you know inject shell commands into a string or something uh those are kind of higher level what I'd call just general appc and the thing that makes binary exploitation unique is this focus on memory corruption and traditionally exploit development has referred to the development of exploits for memory corruption bugs I do think that's actually going to kind of change in the nearish future and we will see a Ed a lot more in the generic sense but for now for this video that is kind of what we're focusing on is memory corruption bugs and vulnerability research as in finding these low level bugs yeah so that's what we're talking about here so I do want to go into a bit of a quick summary of what we said in our previous video for anyone who might not have seen it or hasn't seen it in a while because as I said it is a few years old in that video both Z and I agreed on thinking that the memory corruption exploit meta would shift towards more of a higher level application security focus and that memory corruption would go on a decline due to both more secure development practices as well as things like memory tagging on the mitigation front now In fairness we didn't say memory corruption would die or anything we were very clear on that but we did say that some of the mitigations that were coming and stuff might accelerate the decline and as the mentioned we were fairly p istic about the future of memory corruption and while I don't think our views have 180 like having completely flipped around I do think we want to dial back some of our opinions a bit so on memory tagging specifically because it was a fairly big focus of that video yeah I actually have a little quote of you from that one where you actually said like memory taging is the next big scary thing my coming after that but like and it was at the time like we had like Intel C was coming with control flow guard Well Control flow guard exists but like a hardware enforce control flow integrity and Shadow stack like it was coming mte was coming another Hardware thing like at the time it's just like there's this Hardware security that really can be very impactful depending on how it lands uh like it really was just kind of this looming thing that we hadn't gotten to play with yet or explore with or hack but now there has been more opportunity and there is more in it into it more research so it's not the scary being anymore go ahead and not only that it hasn't really been adopted nearly as much as we thought it might be and uh part of that is due to some of the restrictions that it has so um talking a little bit about memory taging I don't want to go too deep into it but the granularity was fairly uh highly granular I think it's granular down to 16 bytes and it also had a fairly small tag space of only 16 potential tags um because it uses the upper bite uh or top bite ignore feature of arm so because of that you know it's fairly Limited in how effective it can be it also can't really prevent intra object overflows which is something we have seen a few times the other thing that is relevant with it is that mte actually has two modes that it has the synchronous and the asynchronous mode and in the asynchronous mode which where it has been adopted seems to be the mode that's in use because the sync mode is somewhat expensive but in async mode it can also be raced and memory tagging in general seems to be fairly expensive in terms of things like battery power which when you're talking about low power devices like phones and things like that is a pretty big consideration because vendors don't really want to impact battery power for regular users for a mitigation that they don't even understand what it does so because of that mte had kind of limited adoption and on top of that it is also weaker than what we thought it might be where we have more of the implementation specifics of how it works so uh yeah because of that how Works in uh some situations um obviously everybody can kind of do their own thing here allocators can do different things but there has been more of the opportunity to kind of explore its limits and what it is actually doing and as you can probably guess you know hackers are going to hack on it and thus you know Finding you know ways around it ways that you can still wiggle in your exploit things you can do to avoid and all of that uh as with so much it's just the more exposure you get to it the easier it is to start finding flaws to start finding ways around it and you know ways to keep your exploits alive yeah and some of those ways were being explored and talked about pretty early on when mte started to land so yeah mte to rephrase my previous quote that he brought up it's not as big and scary is you know it seemed like it might be at the time and it's it's limited adoption it's been a little bit surprising to me honestly I thought it would be adopted a little bit more than it is but you know I guess it's just more expensive than people were hoping it might be at the before it was introduced as well and it's kind of fallen into the same category as pointer authentication has because Apple's been leveraging pointer authentication which also leverages a top bite ignore functionality of arm they've had pointer authentication for a long time now and it hasn't really come to other devices uh I know there was some like discussion of maybe it coming to Android at one point there was some developer discussion on that but it seems like that's just not happening it doesn't seem like anyone else is really interested in it so it seems like these Hardware tagging mitigations are just not really being picked up you know maybe that will change down the line like maybe it's just a longer time scale that's required for that change to really take effect but in the near future doesn't really seem like these Hardware mitigations are going to be adopted across a wide area of the space it's really only on The Cutting Edge that it's even looking like it's possible to be adopted in the near future so that's something that we wanted to touch on because as as I said like it's something we know more about now than we did then and there's also been some progress on things like C though and we've gotten a little bit more information on that which you'd kind of alluded to see yeah and I mean it's it's kind of the same case on both like adoption hasn't really come at the I mean I'm not that surprised actually when it comes to C and adoption like computer hardware kind of has that standard life cycle something gets introduced but you know people aren't necessarily going to update as soon as possible and then so a lot of software does support C just like we'll get that compiled in there with like specifically actually I should say the side of C that's doing control flow enforcement on like indirect branches not so much on the side of Shadow stack Shadow stack has felt like it it support just in software being compiled with those instructions not really as well supported it is out there but the indirect stuff is you know software supports it but Hardware still isn't necessarily supporting it too well it is worth mentioning in C is an Intel thing specifically there is kind of a zen3 or AMD response to it uh where they have also implemented C in Shadow staff but I don't believe their instructions are compatible with the Intel instructions so it's seen even kind of less adoption out there but still like the adoption you know it technology takes time to change and now that we've had more time to actually explore these there are still kind of problems with them exploitation is you know still going to be around I do think Shadow stack gets adopted that's going to do a lot especially Hardware enforcement there to cut down on Rob specifically and that's really what it's set up to stop is like anything that's going to so Shadow stack actually originates I think before Rock was a thing more as a like way of detecting just the kind of a stack canaries became more popular but I think Shadow stack comes from about the same time period where you would just overflow the stack override the saved return address and they would be able to detect that corruption um so kind of goes back and it's never really been adopted in all that time I do want to go into a bit of the nuances because part of why I thought memory tagging would be adopted more than it has been is because mte is kind of built into the execution cycle right so when a pointer is being followed like anytime there's a memory D reference the CPU internally is going to be doing that tag checking and that tag there is some special instructions that are needed for setting up the tags in the first place and that's why like you need kernel support uh for mte so it's not purely the hardware that's being relied on but for the most part A lot of that checking is being done implicitly by the CPU whereas with s uh things like C it does introduce a lot of those custom instructions so for something like that I assume a longer timeline on adoption because you kind of need that support by the compiler and you need developers to be using the latest compiler and using the right Flags and all that kind of thing uh whereas with memory tagging it was more centralized in the hardware so that's why I was thinking mte might get a bit more adoption than something like C would but it just hasn't really worked out that way well C being Intel actually felt to me like it would get a pretty good adoption just because it's Intel like it's there everybody like people run Intel it's not seems like Intel's not even interested in pushing it in their own CPUs yeah um I will say with with Intel with C it has landed there are devices with it so can kind of explore the limits of these things and while Shadow stack will do a good deal of damage when it comes to trying to specifically go for like Rob and that really late exploit stage so uh when we talk about stages during like exploitation kind of have the early stage where you get some basic primitive you turn that into like a more powerful perimeter like arbitrary read right and probably a control flow hijacker use the read rights make some hijack whatever and then an often thing would be would be to create a Rob chain and then just Rob to actually get your arbitrary code execution and enable that uh and so having the shadow stack the hardware level is going to make it hard to actually go for rough so that is going to do a lot of damage to a classic exploitation technique however the meta when it comes to exploits in the last couple years has shifted away and that's just because like control flow Integrity also has kind of done a little bit of damage and that is kind of seen in software a bit more but also just in terms of writing like a stable exploit off that's something that's more portable people are kind of moving more towards the data oriented exploitations where rather than targeting like hijacking control flow you just find like some actual code that's going to maybe it's going to execute like a shell command and you kind of introduce that sort of bug there like introduce your own commands into that or you know you can chain it whatever way that the thing about data oriented is it's not a generic technique you can't just apply some generic data oriented technique and get Shell Code running or get your own code running like you could with raw it does require more of a kind of specific knowledge of the application but that has kind of been where the meta for exploits has gone is this other thing and that's not impacted by the shadow stack that's actually also not impacted much by control flow and Integrity because the point is you're only messing with the data of the application rather than the control flow um and so yeah and I think part of why that's happened is people have realized that code execution is overrated um it it's kind of been what has always been chased for quite a while but then when targets started to become more hardened and we started getting more hardening on the control flow people realize like wait I don't even need to deal with all of these things like I can just go for the data it's aot lot easier and it's a lot harder to protect so yeah I agree that that shift has been uh noticeable and a lot of the mitigations that we've been talking about outside of like mte and even that it's protecting the pointers more than the data itself yeah like a lot of the mitigations like C and stuff are not really able to do anything about data oriented attacks yeah and And to clarify you can still end up from a data oriented attack you can still end up with running arbitrary code it's just you end up actually getting it run you don't end up hijacking the process you're in in order to run it um you're not running it as a weird machine yeah that is that's the perfect way to put it it's not weird machine programming in order to get to that point I I mean I guess you could actually still argue about with the data being weird machine either way you know I'll just leave as like you do still get code ex like you can still run arbitrary code it's not like you're limited to only dumping the database like a SQL injection or something like you're not only getting data out of effect you're still able to go for if you want to there are actually reasons like kernel exploitation where just modifying the data is actually sufficient to be very useful but yeah like data data oriented has kind of been the shift and meta already so now these mitigations it's like you know we're already kind of able to bypass many things that are coming out now and thus they seem a lot less scary now that we're kind of moving towards a different metaph for exploitation anyhow but at the same time that's leading into a different meta when it comes to the mitigations that we're seeing too so so far we've been walking back a lot of the stuff we've talked about with mitigations that we saw coming we just didn't know a lot about them yet but there has been some work that's been done that we didn't really see coming that's been pretty effective too and as usual on the mitigation front apple is leading the charge on this so on the iOS side of things and whatnot there's been Chic type so for those who aren't really familiar or haven't really seen that Chic type is something that Apple has introduced and it's basically introducing type isolation into the Heap so taking advantage of things like type confusions or overflowing to hit some specific object is a lot more difficult because you're going to have the same objects grouped together so overflowing into a different object you might not be able to give yourself the same kind of Primitives that you were before and for doing uh memory overlapping and things like it's going to be a lot harder to overlap arbitrary controlled data with useful pointers so that's something that's been uh pretty effective on the Apple side of things and it's a mitigation that's not necessarily Hardware uh enforce but it's more at the design level another thing that Apple has done is something like blast door so again for those not familiar with the Apple mitigations blast door is more on the attack surface reduction side of things so it's basically making it so that jit and things that are really useful for exploitation like being able to set up arbitrary code is just not turned on if you're in like a locked down mode so yeah there has been some stuff that has been pretty effective and has been forcing meta changes from how memory corruption has been exploited in the past but again it's mostly been on Apple and it's not really been adopted across the industry so I do want to point them out and Yeah K it is something that could potentially influence into other products in the future but yeah sorry go ahead I was just going to mention like CH type is pretty new it is newer than like our last video for example wasn't even out yet yeah that does a lot and it starts acting at a slightly different level as we were saying than just the hardware mitigation and a lot of those mitigations like CT it's you've already got the ability to hijack control flow or you know do something like that and then this mitigation is kicking in where some like k type is really kind of starting to actually try and cut off the bug class itself and mte does a little bit of this with the probabilistic Overflow aspect um and like there are aspects of it but that's almost like the focus of KOC type is cutting off certain bug classes as being making it very difficult to exploit them at like the compile time in a sense or just that structure so like there is that shift now kind on the defense side to try to cut off the bugs and not just the exploit mtig like not mitigating the exploit but mitigating the bug itself which has also of course LED towards safer languages you know of course Russ being the big one but there has been this kind of change also in the Met of how things are being defended and you talked about or you just mentioned like blast Thorn attack service mitigation that's also been a big thing on like the Android side of trying to limit what what areas are actually privileged or not or what's being done in privilege areas and limiting the surface that can you can attack privileged code from that is timate a big thing on Google side I'm not sure if I'd say the same about Windows though and a focus on that aspect but I am not a Windows researcher so while I'm not sure if I can say that it's because I'm genuinely not sure and not because I think like oh they're not doing anything about security cuz Windows you know absolutely like I know they invest a lot onto finding the bugs early I wouldn't be surprised if they were well I mean we know they do a lot of fuzzing so I'm not surprised to know that if they also kind of took more of the like s sanitizer R rather than tossing these mitigations onto users to detect it kind of in real time as they're running just implementing get even stronger things earlier on in their own like buzzing setup and all of that just happening earlier on in the whole development process or happening as part of development not making its way there and that would be why it's just not as seen not that WS is just stupidly insecure or something because they take security seriously also yeah I quickly want to mention it it's not just that we're like hating on Windows and that's why we're not bringing it up but Windows is in kind of a weird position like a unique position because of how they support Legacy code and have that design goal making radical changes like introducing like big mitigations or even like using secure languages is just very difficult in that area and it's not something I'm expecting to see anytime soon whereas on the mobile side and like with and stuff like that like it's easier to enforce change there so that that's why we're talking about the more in this discussion I think there might actually be since you're talking with the skure languages there might actually be some Rust in the windows kernel now I know there's support for Rush drivers now where I'm quite certain there is and I think I recall reading about getting rust in or yeah about Microsoft at least starting to do some rewrites of components into rust for the windows kernel I'm just pulling up an article about that uh this is just an article I just Googled for so I'm not going to stand behind like the quality of the content here uh but it does seem like somebody during uh blue hat I of last year which shout out to blue hat I is an awesome conference but they talked about doing some engineering at Microsoft for this is a quote here I guess uh you will actually see Windows boo with rust and the colel in the next several weeks or months so you know they're they are kind of more silent about it but adopting Russ or more secure languages you know even into Windows yeah but with Windows you have a lot more vendors in the ecosystem so it's going to be a lot harder to get that secure language adoption across like the stack you know yeah it might be there in the kernel but not every Drive and that has been a constant problem even with like Windows implementing smap or smap has been like drivers still exists and you know and it's that Legacy inheritance again that that's causing a lot of those issues whereas Linux is just like okay well you know you're going to deal with this driver authors are going to have to rewrite these things whereas Windows doesn't want to do that because then people complain when their things don't work and yeah so yeah I did want to quickly bring that up but this does segue nicely into another important aspect on memory corruption and that is the movement to secure languages so obviously like the rewrite it in Rust is a bit of a meme and rewriting something as big as a kernel like let's say the Linux kernel in Rust is realistically not going to happen but what quick is well I mean I just don't think it's going to happen in general but what is what does seem to be the focus is okay we can't rewrite everything in memory safe languages but what about things that are in the lower privilege levels so things that are exposed to like sandboxes and things well when we narrow down the scope to that okay we can rewrite drivers that are exposed to those areas in more secure languages and that's something that uh seems to be somewhat taking off so we've we've talked a little bit on the podcast before about how rust is being adopted into the kernel specifically for Android it's the binder driver which is the IPC driver and has been a source of memory corruption issues for years that's been receiving a rewrite and rust now as far as I know there's still no rust C that's been shipped to a production kernel like it hasn't been upstreamed but there is a more of a shift to using the memory safe languages in the sandboxed areas which you know again kind of kills the or tries to kill the memory corruption issues earlier on without having to rely on the mitigation again though like I said like these rewrites have been in progress for a long time now and they still haven't shipped it's something where it's because rust is such a radical change from C where it's a lot harder to write you have to you have a lot more of these compile time guarantees you have to meet it's It's tricky to rewrite things in Rust and make sure that they work so it's not something that's going to be immediate it is going to be something that's a bit time lagged but it is something to consider that you know Defenders are trying to mitigate memory safety issues at least on the lower priv PR sorry privilege levels which means that while memory corruption again like I'm not saying it's going to die or even that it's going to be impacted super severely but it might require chaining with other higher level issues in order to reach the memory safety issues um you might have to do more of the you know lateral movement in order to reach those areas compared to before where it's just like immediately jump into hitting me corruption issues in the browser or something yeah so one thing say is any sort of rewrite it as you're saying it takes time so a really common question is you know what about these memory safe languages if we keep adopting them if everyone adopts them are we you know our memory corruption vulnerability is going to be extinct and the simple answer to that is yes for like generally speaking like technically speaking no there will always still kind of be the potential for bugs or for those typ of bugs somewhere like there's going to be some Legacy system or whatever but if everybody were to actually adopt a a type safe l or memory safe language then yeah we're not really going to see a lot of memory corruption bugs because everybody's using it but that is a huge ass to be like everybody adop memory safe languages over time we are going to see more and more of it and new projects do tend to use better languages like C isn't popular language for new projects but there is still a lot of legacy and there are new projects being written in C I do still see that from time to time um but even try to rewrite like something like Linux even if they were going to go all in on Rust that's going to take a very long time because it's not going to be let's rewrite everything in Rust in one shot it's going to be let's rewrite this component like we're talking about binder Bluetooth driver I think is something Google's been working on also it's like let's do this component that's going to takes like you know a few years and maybe another component gets worked on maybe another and another and it does add up over time but actually getting to that point of using it is like a absolutely massive massive ass there's still going to be software out there that's just like no we know see let's use see because that's what we know or we already have things fundamentally like done in see whatever like there's this huge Legacy push that's going to continue to exist and there's going to be Legacy software there's embedded software there's a lot of places where it's just not easy to move and one other point is we actually were just talking about CV RS happened to be within the last few weeks where you could use entirely safe rust code and still have memory corruption issu now they are fixing that so like shouldn't be around but that was entirely safe rust code you could introduce these bugs not likely to end up in a real product but it was still safe code that you know unlikely but could have existed or you know could have been planted into software and the other thing is especially on rust is it's not that everything is safe in Rust it's just that you have unsafe blocks of code that say this is where you want to audit if it's not but auditing it is actually kind of hard if you've done or tried to do a rust audit if you want to Go just with the unsafe code like you can audit that and just look at all your unsafe blobs and see if they do anything but there's so much context about everything else going on that you need to keep in mind that while yes it's nice that it is able to specify look at these areas and that does help with auditing it's not easy and there still can be these bugs that slip through because you just don't notice them we had a one of our spot the V challenges used to be a or was a rust vulnerability like that where just like here's some Rust code and you take a look the or you take a look at there is some unsafe code but it's not just clear that this is the problem of course it is the problem like we only had like 10 lines of code there's not much place for there to be a problem but you know Russ can still have issues and we also talk about like memory another important aspect is you know we'll talk about occasionally it's been a while but like PHP memory Corruptions where even in PHP which is considered a typee safe or me I keep saying type safe A Memory safe language will have a memory coruption bug in it that allows for remote code execution granted you're already running PHP code so like that RC isn't as useful it's mostly used when you have like safe mode on and like to bypass the safe mode but the point is like the language run times unless they're also written in a safe language are then also susceptible to having these memory corruption vulnerabilities so like they're going to continue to exist for a long time like I don't think there is any talk whatsoever about rewriting PHP in Rust for example or python python has the same they've had a number of bugs that you know have been in the python runtime although you have less access to actually abuse those from the outside so they are a lower risk area but more the point that like they do still exist even when using typesafe languages unless the types safe language is secure actually just came to mind but JavaScript JavaScript bugs are found all the time and exploited in the browser JavaScript is a memory safe language and for some reason I keep wanting to say type safe so if I say that just understand I mean memory safe but yeah JavaScript bugs are another good example where like you're in the browser you're finding this memory safe language and you're exploiting a memory corruption bug in it it they are going to continue to exist for a very long time they will continue to get harder and I think more rare as we go they're still kind of out there the mitigations aren't really stopping the attacks now that we have more of a take on like I mentioned before the data oriented attacks as we look at other ways of attacking software and have a better understanding of exploitation these mitigations aren't really stopping us but they are changing things and I think that's the same thing with rust like R well we focus on Rust but safer languages is just they will change things but it's Russ is just a useful vehicle for talking about memory safe but yeah we mean memory safe not just rust yeah yeah rust is like a really good vehicle for because they do my opinion a lot of things right and they're actually useful as like the lowlevel replacement for where C is used but yeah no it's there are other options there too and I mean you know even something like go link actually has unsafe like you can use unsafe it works a little bit differently than Russ or Works differently than Russ period but like you know you can do unsafe pointers in like goang too which is you generally considered memory safe he still introduced these bugs so main point there is like there's a lot of places for stuff to hide they're maybe not the most you know sexy areas to find your bug in but they're still going to exist there's still going to be you know areas is for you know this sort of memory corruption vulnerability to matter yeah I'll leave it I'll leave it at that yeah and I mean we didn't really talk about it on the podcast but the White House had also released a white paper recently talking about memory safety and trying to push for more of the adoption of memory safe languages uh rust they do give as an example but uh you know like what we're trying to do like they're mostly just talk about the memory safety as a whole but the adoption of that is slower than a lot of people would like and you know part of the reason for that is people like developers want to be tasked on shipping features that are going to sell things right the reality is rewriting things that already work to be more security safe is not a selling point and so and introduce new bugs you right you're going to introduce new bugs most of the time that too but yeah like the the reality is that rewriting any significant amount of code is just it if it gets done at all it's going to be done on the long time scale because it's not a high priority uh for a lot of companies Google is has kind of been unique in trying to push forward the security on like open-source products like Linux kernel for example I mean obviously there there's a feedback loop there that benefits them but you know Google and apple have kind of been leading the charge on trying to do this adoption of more memory safe languages and trying to push the mitigations forward but they're trying to drag everybody else with them and that's a heavy weight so outside of like The Cutting Edge targets like mobile for example like mobile bugs are going to be cutting edge targets and it's going to be harder and harder I feel like iOS and Apple has already kind of reached the point where uh and query actually talked about this in a presentation he gave somewhat recently in the last year or two uh at hexacon actually iOS has kind of reached the point where unless you have help it's not really feasible to break into it and start trying to find and exploit memory corruption issues um it's just too it moves too fast there's too much hardening too much sandboxing that's been in play so like on those kinds of targets it is maybe a little bit towards the glum side of like what we were in our first video but the reality is most products don't fall into that category and probably won't for a long time so that's kind of where we wanted to dial back our previous opinions I guess and and kind of update on uh what our thoughts are involving those mitigations and memory s languages yeah and actually on that point like yes those topend products you know those hard targets are going to you know be impacted by that but at the same time as that happens the value of being somebody who can do that sort of exploitation increases I think on our last video kind of speculate with regards to like how much money is like a government entity really willing to spend on those sorts of exploits and you know will human intelligence be more valuable and I still have no idea on that case on how much value those are actually going to have to them or any of that but but it does seem like there's still room kind of there like things are still kind of being spent because of the challenge of finding issues like they actually kind of are more valuable now so I don't think things are even going to be dead there it will take more research and like you're not finding a bug all the time or you need to work with other people and do all of that but it's not like that has no valuable or has no value because it's rare like yeah you might not have as many jobs being published for it because there aren't as many people able to do it but that doesn't mean the people able to do it have like no value or it's not a lucrative position or job to have and that's I think that would be a good way to state my final position on it is just that it's becoming harder and harder and in some cases impossible to be a one-man Army like it was 20 years ago or something it just means you need more resources uh it's not going to be killed off though yeah um and even at the lower end of that I think there's still going to be the demand like if you're a pentester on a random corporate Network there's going to be a lot of this random Legacy software that just isn't as secure and is not the high-end product you're maybe not going to write like a browse you probably wouldn't today either a browser exploited on the middle of a red teaming engagement or network pentest but you might write an exploit against that random driver or something the random webcam software iot software so it's still going to be a valuable skill set in there and in the professional sense there's you know you're not going you're Maybe not going to be able to do that high-end exploitation but there's still a ton of targets that are going to take a very long time to I guess potentially phase out and like become secure use secure use secure languages like such a slow process that it's still going to be a useful skill to have uh that said I do feel like you know if I were getting started today I would want to understand higher level application security also uh and that's not just because of the fact that you know finding those bugs is kind of important too but with data oriented exploits and kind of going that route it requires you understand the application better so you kind of understand the sort of bug you can use a memory corruption to introduce bya corrupting the data and to get to that point you need to understand all these other types of bugs that you might be able to do something with so you kind of need more knowledge today and you need that more round Ed knowledge Beyond just memory corruption and I was kind of thinking about this when I actually spoke on our last video about how you know I wouldn't I think I said something along the lines if I wouldn't bet on a long career and purely binary because that's kind of what I was thinking about is the fact that you don't want to only know binary if you want to be good at binary you need to understand the rest of application security too and the other types of bugs because they do matter both binary and just the finding bugs in general you need to have that wider more rounded knowledge regardless and that's more what I was saying like you might not only do binary but it's not like that non-binary knowledge is just entirely useless to the binary World these things work together and you're better at the binary I think when you understand the rest of it so i' still kind of Stand by that idea of you're not going to only know binary you can't just do that anymore yeah on the Harden targets like saying oh I'm just going to go looking for a stack Overflow where they read in an integer and there's an INT overflow and something and that lets me corrup memory like those days are kind of over on hardened targets but where you have the more comprehensive coverage with vulnerabilities interacting from that higher level and having the memory safety like those kinds of issues yeah um it it's just it requires more of a comprehensive knowledge of the target yeah I agree yeah that's kind of the big push I'd make like yeah things are getting harder because you do need more knowledge I think but I don't think exploit development is just going to be an entirely Dead art too soon here you know things slow with other stuff yes more integration needing more knowledge and that's just kind of the natural progression you need more knowledge it just happens that that other knowledge that you need also helps you out if you don't do binary and you just focus on the higher level but it also makes it easier to transition to Binary because binary has a lot to learn but you do benefit by understanding The Wider security realm for sure it's not something you can just ignore like you might have been able to in years past sorry go ahead yeah like in years past you could really just focus on learning well I mean we didn't even know how to exploit some of the issues we exploit these days like you know use after free was kind of an understood denial of service for a while like you could do some issues but nobody really had a solid handle on exploiting them whereas today like it's just like you oh you have a use after free that is probably exploitable because we understand it better but that takes understanding the application in order to do that so in years past like the simple stack Overflow example like that's all you need to learn there's just so much more to applications today and we've kind of formalized that knowledge yeah I mean you can kind of see the same thing like even if we just take memory safety issues in a bubble and specifically Heap corruption a lot of the early days like when you talked about exploiting the Heap you were talking about attacking the allocators right you were talking about getting your house of style Primitives where it's like okay this application is using this allocator I know how I can turn Heap corruption into an arbitrary right or something and then as time go went on Heap corruption shifted more towards like okay what kind of objects does this application have that I can take advantage of you're you're shifting more from the generic techniques to the application specific techniques which requires that deeper understanding and that's just kind of progressing more and more in that direction and the mitigations are are kind of forcing you down those paths too yeah but on a whole it it's still going to live on for a good while and I think even on the side of like you're not doing the high-end products it's still going to be useful knowledge to have and it just makes you a more valuable you know pentester red teamer whatever when you have that ability and that becomes a skill you can draw upon even if it's not your primary skill or you're not only doing that yeah and you know part of why we wanted to make this video and update our views here is because the way we did our first video did seem a little bit discouraging and some people did take it that way they took it as like okay well then it's you know it's a waste of time to to learn memory safety issues and that isn't necessarily what we were trying to convey in that first video but the clarification on things like mte and how things have changed since then have further pulled us back towards saying like you know the memory corruption knowledge is still useful to have it's just it might be harder to put into practice but it's not like useless or something yeah like I don't reject things that I said last time but not like oh yeah this is a 180 change but yeah like our views aren't completely flipping it's just they've been kind of tempered by some of the things that we speculated about at the time coming to fruition and being able to take a look at how things have manifested yeah yeah tempered and clarified because I mean s fed I think is easily taken like I don't fault anybody for taking us as pessimistic with the last one but I'm hoping we've been able to get across some of the Nuance a little bit better here and just you know know give you some hope towards continuing with exploit development because I do think it's still a worthwhile area to learn and I will say personally like Beyond just how we can bait it like I'm more hopeful now than I was back then too um because like you said where you had these things coming that were looming over you it's easy to just kind of assume it's going to be the ideal case where you know with mte for example there was a lot of nuances and restrictions to it and hasn't been adopted as much as we might have thought it would be back then so it was worth making a video on and like we said we kind of wanted to do it a little bit earlier but we just Titan got around to it and we finally have now so uh yeah I think that's pretty much everything though unless you have any things you want to add z uh no I think we all I had to say I think we've hit everything I will mention as we're ending the episode here I think this is kind of a format that we want to adopt a little bit more not specifically just taking over binary episodes but doing more more discussions having more guests on so I'd appreciate hearing any feedback on this sort of thing or if you actually have a question or something you want us to address feel free to hit us up on Discord or wherever else you can reach us yeah for sure and it's something nice that we can do especially on weeks like this where the binary episodes in particular have been harder to do lately there's just been kind of a drought of topics but these kinds of discussions are a bit more Timeless so we're not as time constrained on trying to look at things within the last couple weeks or something so uh yeah it is a format that we're hoping to go with going forward so any feedback would be appreciated so yeah with that said thanks everyone who tuned in and we'll see you in the next episode