Facing the Vulnpocalypse With lcamtuf

We talk to Michał Zalewski (lcamtuf) about the vulnpocalypse and if we even need fuzzers anymore. This episode may be export controlled at a future date.

This episode was recorded on May 28, 2026.

Links:

This rough transcript has not been edited and may have errors.

lcamtuf: Either the most interesting time in the history of InfoSec or the second most interesting after the arrival of the web.

Deirdre: Hello, welcome to Security Cryptography Whatever. I’m Deirdre.

David: I’m David.

Thomas: I’m Thomas.

Deirdre: And we have—

lcamtuf: And I’m Michael.

Deirdre: Yes.

lcamtuf: Oh, sorry.

Deirdre: I— That’s okay.

lcamtuf: I missed it all.

Deirdre: This is the first time I think that’s actually happened in almost 3 years. Nice. We have a very special guest today. You may know him from the internet as, oh my God, I say lcamtuf, but.

Thomas: Yes, lcamtuf.

Deirdre: But you have like a real world human name, Michael Zielowski.

Thomas: Oh my God.

Deirdre: I’m sorry, I know Irish and the name.

Thomas: We were all hung up on the first name.

lcamtuf: Yeah.

Thomas: I can’t believe you hung up on the second bit.

lcamtuf: That was absolutely terrible.

Deirdre: Yes. I’m sorry.

lcamtuf: Yes. No, that’s fine. Yeah, the Polish pronunciation is Michal Zalewski, but I usually just go by Michael and yeah.

Thomas: Oh my God. I pronounced the W wrong.

lcamtuf: See, we’re— Yeah.

Thomas: You’re justified. I’m just as wrong as you are.

lcamtuf: This is the most disappointing podcast I have, you know, ever done in my life.

Deirdre: It’s bad.

Thomas: It will get so much worse.

lcamtuf: No, it’s gonna get worse.

David: It’s gonna get worse.

Thomas: So worse. Right. So we thought right now was a good time to talk because of all of the AI vulnerability discovery stuff that’s going on. And I feel as if we would have a very easy time finding people to talk to that were all lit up about AI vulnerabili— like agent-based vulnerability discovery. I’m one of those people. But it’s trickier to find somebody who is both skeptical— might be the wrong word, but like not on the exact same page as everybody else and who also has your track record in the space, particularly. And I said this a little bit earlier, like 90% of what I talk about here is just me exorcising demons from Hacker News. And like one of my, like one of my continual irritants on Hacker News is that any time a story from one of the Frontier Labs comes up, like 3 people always say fuzzers did all this stuff already. And like, the problem is that Google isn’t running fuzzers or Apple isn’t running fuzzers or whatever. And yeah, so you’re the author of American Fuzzy Lab, AFL, which is like the de facto standard tool in that space. So I kind of wanted to get like your perspective, not right away on the AI stuff, but just basically on the trajectory of how we’ve been doing automated vulnerability assessment, let’s call it?

lcamtuf: So that is a very open-ended question, I think. Yeah. You know, like most of vulnerability research is being done automatically and it’s been like that for a long time, right? If you look at the browser space, I would wager that 80 or 90% of what’s actually found and fixed is a product of automated tools. At the same time, you know, even though it is automated, you can have dramatic sort of, you know, step improvements or sort of, you know, like revolutionary shifts in the tooling that we are using. And I think LLMs do represent such a shift. So I’m not gonna take the, you know, the contrarian position of, oh, all of this sucks and it’s the same as fuzzing and, time is a flat circle. But at the same time, I do have fairly complex thoughts about the impact of the AI angle specifically. And I can sort of get into that now or we can get there more gradually. But yeah, sort of to directly answer your question, I think this is a very interesting time to be in. I think we are seeing Very fundamental shift. The technology is real, real. It’s amazing. And you should be using it as a part of your workflow. I think that’s the bottom line.

Thomas: Yeah. So I think the first thing I want to like, I have like my own personal experience using like, you know, kind of fuzzer arrangements of various kinds to do projects, but I’ve never done the like the at-scale work that like, you know, Google did in like the 2010s, you know, so like large farms full of things doing, you know, profile-guided, you know, AFL coverage and all that, right? So I have a mental model of like fuzzers as tools of like, they’re like literally things that I would build as like shop tools to get like, you know, individual projects done. But like one of these, like one of the worries I always have when people say like fuzzers did all this stuff is like my, like my advanced fuzzer knowledge is not all that up to date. I understand exactly what the tools are doing, but like the difference between that and actually finding vulnerabilities with them, like actually having the field experience with them and seeing where like the, you know, the sharp edges are or where they were, they’re really, really effective or whatever. I feel like I have less real-world experience. So if I said that, like, I think the way I want to get into this is just to like make a, make a claim that it’s probably going to be wrong, but I’ll make it anyways just so that you can tell me I’m wrong. Right. My experience of this is that fuzzers are a really good way of getting a pile of, you know, variably quantified or variably qualified crashes in programs, right? And that, like, people that run large-scale fuzzing, you know, quickly get adept at, you know, building mountains and mountains of crashes. And in those crashes, I think there’s like a general understanding that there are vulnerabilities,, but the work is going from that pile of crashes to actual vulnerabilities. And if you’re not doing that work, you’re not actually solving the problem.

lcamtuf: Yeah, I think, you know, a large portion of running fuzzers at this scale and actually getting vulnerabilities fixed is the automation around the actual sort of, you know, permutation engine, right? Like it’s how you get projects on board in the first place. That’s, you know, a major bottleneck for open source. And I think, you know, quite often you have to do it yourself, and then it’s gated on the available capacity of software engineers to actually instrument code, plug it in the right place, make sure that the right functionality is being exercised. And then the really difficult part is, you know, crashes are often good enough. Like, I think open-source developers don’t necessarily need an exploit. They don’t need a very detailed write-up, but they want a repeatable crash and You need to bring it to them using the workflow that they prefer, you know, in a fashion that works for them. Some of them have their own, you know, pet peeves and sort of, you know, complex ideologies that you have to work with to actually make sure that things get fixed. So I think it was always a bottleneck for fuzzing. Not all of this goes away with agents. I think, interactions with open source developers continue to be a very challenging touchpoint that you can’t really automate with an LLM and expect good results, right? Right. But yeah, I think, like, again, I think the way I’ve been describing this, and that goes way beyond vulnerability research, is that, you know, most of security problems really boil down to text comprehension at a scale. With emphasis on scale, right? Like we never have enough resources to actually look at every event generated by an enterprise, you know, detection pipeline or to sort of, you know, look at every line of code that’s being written. And I think LLMs really profoundly changed the game on a number of fronts, right?

Thomas: So. Let me like, let me try really quickly just like I mean, two things, right? First of all, cards on the table, my interest in all of this stuff is like almost purely on the capability side, right? Like what vulnerabilities are we finding is a much more interesting question to me than how, how this works as an engineering process, right? Like how we solve the open source metabolizing these things, all that stuff. Those are really important and valid problems that I have passing interest in, right? But like, I’m, I’m really focused on like the raw capability side of it. Right. And then like with respect to how fuzzers kind of have traditionally worked, I had like a radicalizing moment a couple of years ago, like maybe a year and a half ago where like, um, an engineer on our team, Salim, um, who, uh, is amazing. Um, like once a week he was finding game over vulnerabilities in our platform and like, you know, resolving them. And one of them was, This wasn’t a game over vulnerability, but it was a really good concern that we hadn’t thought about. We run farms of virtual machines for our customers, multi-tenant on the same hardware. And in some corner of our system, we were doing file system maintenance for VMs on the host side. So like we’d do like file system repair before backup or something like that. It was like whatever the current equivalent of fdisk is or whatever, but we’d run that on the host side, he’s like, well, you know, the filesystem obviously is controlled on the guest side. So now you’re exposed to the entire kernel surface for whatever this filesystem is. That’s a really good find. We solved that pretty quickly. But like, we’re trying to figure out how big of a deal it was. And it’s like, I’m just gonna go to syscaller and find crashers and run them through it. And like, there were crashers for it. Like he was immediately able to repro, you know, I don’t, you know, you can’t call it a memory corruption vulnerability just because it panics or whatever, but like, things where if we had found them ourselves, we would’ve gone and investigated them. And I have now this perception that there is just a mountain of Syscaller things that are just sitting there and like somebody should triage them, I guess. But like, are they vulnerabilities or are they not vulnerabilities? I don’t know. We’re in a state of uncertainty about that, right?

lcamtuf: No, so I think that’s like a fundamental change, right? And again, it doesn’t matter as much as, people sometimes claim, but I think it does matter, especially if you have like, you know, Heisenbugs that you don’t really, you know, you can’t immediately decide what’s causing this. It doesn’t reproduce consistently. It happens in a weird place that may be, you know, miles away from the original fault. So look, like again, in terms of technical capability and how it changes the game for InfoSec, I’m not actually a contrarian at all, right? My contrarian position lies somewhere else and it has more to do with how we as an industry think about the vulnerability research in the first place, right?

Thomas: Yeah. I should say, like, I’m saying that my interest is in XYZ, but like, I don’t speak for David, you, or Deirdre. I think I’m a, I’m a weirdo in this, in this one thing, right? Like, I find vulnerability research really very motivating, um, as a reason to learn pretty much everything I’ve learned about technology and math. Um, but that’s just me, right? Like, I think you’re right to like call out the, the— you, you just said something interesting that I’ve heard you say before, which is just like, um, how the industry kind of looks at vulnerability research. And you’ve said in other places Like, I get the impression that you generally feel like we way overvalue vulnerability research as an intrinsic good.

lcamtuf: Yeah, so, you know, maybe let me answer that in the form of a rant. And I’m gonna get to, like, a very precise AI-related point down the line. But yeah, I generally have come to, you know, detest infosec punditry on some level because I think we consistently get fixated on things that are, not really representative of what actually matters day to day. And you mentioned Hacker News and I actually checked Hacker News today and there was someone talking about how InfoSec, information security has already ceased to exist as a field, as a consequence of AI vulnerability discovery. And I think we have—

Thomas: That was not me for the record.

David: Let me call my boss real quick and let her know the field doesn’t exist anymore.

lcamtuf: So, you know, and it’s not just that, I think, you know, like, when you think about what arguably changed enterprise security the most in the past 15 years, it’s not the stuff that people present at Black Hat or that we, you know, sell at RSA. It was the one thing that we all love here, I think, Bitcoin, right? It used to be that ransomware was this niche thing that basically was constrained by how much money you could move through Western Union. Which was not a lot, right? And now it’s this like global economic powerhouse that funds hostile regimes and really is the one thing that keeps most CISOs up at night. And, you know, post-quantum cryptography doesn’t. I’m sorry to say that, right?

Deirdre: I know.

lcamtuf: Yeah. And so in my mind, you know, the discourse around AI vulnerability discovery kind of fits that mold, although not, again, not in the way that many people claim. You know, many folks think that the technology itself is hype or, And it isn’t, right? Like, again, it’s real, it’s impressive, and you should be using it. But, and again, as I mentioned, right, I think most of security is text comprehension at a scale. And now we have a, and we were really severely constrained by scale, and now we have a tool that largely removes that constraint. And that’s amazing, that’s transformative, and it’s absolutely gonna change the practice of InfoSec. But to get to my actual point, I think, you know, our industry has long overstated the practical importance of vulnerability research. And I think it’s partially because it’s sort of, you know, our origin story. And then it’s a part of our collective identity. It’s how we can, you know, it’s what we can bring up to show how clever we are and why we need to be paid more than everyone else. And it has cool ties to spycraft and all the other things. But But fundamentally, you know, like, zero days were generally not how enterprises get popped, and having 5 times as many zero days or 50% less doesn’t really change the nature of the game. And part of it is, you know, sort of physical constraints too, right? Like, the technology is not magic. It doesn’t give you an endless supply of, you know, zero days in OpenSSL, for example. It gives you some respectable numbers of new findings in software that was OpenSSH is already kind of busted and had exploitable bugs every year. And, you know, and that you probably have somewhere in your enterprise in a version that’s 5 years behind, right? So we were always kind of operating in that reality and we have far more basic problems that we can’t quite solve or couldn’t, you know, inventory patching, human behavior that are adding up to a much larger and less tractable attack surface that actually keeps biting us in the back over and over again. And this is actually where LLMs are absolutely amazing and are going to change the, because like all of a sudden you can actually reason about every single thing that’s happening within your enterprise quite possibly, right? And you can take action on that. And on the offense side, it’s kind of, you know, the same thing that like the attackers can now afford to pull on every single door handle within your enterprise and they can do that more quickly and they don’t have to care. Like, you know, if you’re using an agent, you have to worry about it deleting your production database. Ways. They don’t, right? Like, if it messes up, well, that’s a shame, but that was your data, not theirs, right? So, like, again, I think there’s a lot of interesting wake-up calls for security, and things we need to reckon with, and things we need to start building. But, like, you know, the vulnerability research side is amazing, and it’s, you know, on some level, it is, depressing to me that, you know, this is the one thing that I always enjoyed. And, you know, same as Thomas, right? Like, it really motivated me to learn. And now, you know, there’s a computer that can do it better, the same or better, and, you know, for a lot less. But yeah, so that’s sort of, you know, the genesis of my skepticism here, right? I think the AI apocalypse In the industry or the day of reckoning is coming, but it’s probably not the, you know, vuln-pocalypse, right? Angle specifically.

David: Yeah.

lcamtuf: Yeah.

Thomas: I want to— David, you go. Sorry.

David: I mostly agree with you. The way that I would put it is that it seems like zero-day exploitation is currently, or let’s say, pre-AI was not supply constrained at all. It was demand constrained because like for the most part, society works in the sense that it is like not a good career option for anyone on this call to decide to like go into exploitation. And if they do, but like actual like computer exploitation, not like vulnerability research. And if they do, like you said, they’re probably just gonna go after unpatched things anyway. It’s not clear that increasing the number of available zero days results in more, like, actual operationalized exploits. Yeah, well, to me— And it seems like it won’t.

lcamtuf: I think, you know, there are quantitative differences, right? Like, I think it lowers the bar, right? And sort of, you know, there’s gonna be like, I think, you know, it’s gonna alter the market dynamics, right? Like if you wanna buy a zero-day, maybe you’re gonna be able to buy it for less. But that’s kind of, you know—

David: You may have the Jevons paradox.

lcamtuf: Yeah, it’s kind of like, you know, qualitative versus quantitative, I think is the distinction I see, right?

David: Yeah. So I think there will be, there is like a risk that like the people in like, let’s say Southeast Asia, not to rag on them, that are currently running like tech support scams,, may find that it is now economical to run subset of like AI-driven exploitation things on some subset of users. Um, but I suspect that that would look different kind of in the same way that like pirating music got replaced with like listening to Spotify versus like everyone just started paying $0.99 a song.

Thomas: I like, so I think I’m like the resident vulnerability research and AI maximalist in this conversation, right? And I do think that the, like, the emphasis on, you know, the, the first tier targets like Chrome and iOS and all that, right? I do feel like that’s mostly a competitive thing, if that’s the right way to put it. It’s mostly kind of like a, it’s, it’s tournament logic, right? It doesn’t have that much to do with making things more secure. I feel like when we talked to, uh, Mark Dowd about like the markets and vulnerability research, I didn’t come away from that with the sense that like they were lacking for possible vulnerability avenues to chase down. Um, and like, there’s a, like, there’s a persistent logic that, you know, state-level actors or whatever are stockpiling vulnerabilities, which turns out not to be true. Like, it’s a software product like every other software product, and they’re literally more concerned about paying maintenance costs for vulnerabilities and exploit kits than they are with like, you know, having 15 different backup vulnerabilities. So I think you could look at the situation and say, okay, the fact that it’s going to get cheaper to find Chrome vulnerabilities, like a Chrome drive-by or whatever, um, that won’t change that much because everybody that you cared about having Chrome drive-bys already had them.

Deirdre: Exactly. Or at least had—

Thomas: there’s already a market that makes that work.

Deirdre: Already had the ones they really needed and no more.

lcamtuf: Yeah.

David: And I think there’s— an early Uber investor a few weeks ago was saying, oh, I don’t know why we didn’t give Mythos, like, to the US government and then use it to hack China, like, before announcing it. And it’s like, well, that’s because that’s not how any of this fucking works. Like, we’re not short— the reason that, like, the US military can or cannot get into something in China has nothing to do with, like, a shortage of exploits.

lcamtuf: The other reason why I’m kind of skeptical about the vulnerability situation specifically is that I think there’s, like, inherent symmetry to it, right? Like, any tool that the bad bad guy can use, the good guys can use exactly the same way, right? So if Chrome or, you know, Microsoft or whoever, Apple want to sort of, you know, match the increase in the availability of zero days, you know, they have a simple lever to pull and they can sort of, you know, get where they want to be to restore the previous equilibrium., right? Or even go beyond. I think there are many other areas in security where that symmetry doesn’t hold, right? Like the example I mentioned, like, you know, the defense versus offense on the enterprise side has this asymmetry baked in. It’s a lot easier to crank out hyper-targeted spear phishing emails to execs than to detect and stop them reliably, right? Even with AI. And so I think that’s where the AI gives the bad guys a lot more advantage that is more difficult to counter, right? Versus just, you know, we were fuzzing Chrome before, now we’re also gonna, you know, throw some LLMs at it, right? And that’s kind of, you know, the eternal struggle. Between good and evil, right? Right.

David: It changes things operationally a lot for all the reasons that like Thomas doesn’t care about, um, which are, I think, the ones that are interesting to me. And so like, you, you have a question even like right now, I’ve had people come to me at Chrome who like work on other parts of Chrome and are basically like, aren’t we just drastically overinvesting in basically like anti-exploitation things. And if you look at it like by the numbers, right, there’s like not that many people whose crumbs get popped every year. So in some sense, we are. On the other hand, like what we’re really doing is like we’re winning, sort of, for some definition of winning. And like if we stopped doing all of this, it will go back and it would look like the early 2000s or the late ’90s again.. And so we just kind of have to do all this work to run in place, sort of. And then like what, um, like AI bug finding has done has, I think in many ways, like just validated things that a bunch of security people already knew, like for, for platforms basically. Like let’s ignore the open source projects, which is like not interesting. I agree. I agree with everyone else that—

Deirdre: Not including Chromium.

David: How about, uh, about like small open source projects? And instead, like, let’s just talk about like things that previously were targets for exploitation, which is like client-side platforms, like browsers.

lcamtuf: Yeah, let’s not talk about stuff like XZ, right? Like, who cares about that?

David: Um, I mean, in practice, um, in practice, like, uh, I, I would just, I would quote Hermione, um, and, and say, you know, when it turns out when that happens, we’re pretty good at catching it. Um, uh, but like, the deluge of AI bugs has created, like, has magnified all of the things that were already stupid about bug bounties, which was that, like, a bug bounty is, like, the worst possible way to prioritize security work because it’s entirely interrupt-driven. And so instead what you have is you have just deluge of bugs that were basically validating everything that security people said, which was like, your code’s full of memory safety vulnerabilities and these are the areas that are the worst. And then people are like, oh, you know, I don’t know. Like, and security people are bad at their jobs at getting people to change anyway. And so all these bugs show up and then you have this operational question of like, how do we deal with that? And you have to deal with it, even though the like impact of increased exploitation might not be that bad, because eventually, like, if we just chose to not deal with it, we’d be back in the 2000s again and we don’t want that. So you have to figure out how to deal with it. And like, yeah, you get the AI tools to help you deal with the problems that the AI solved. But again, I think it is a little bit harder for defenders because like, if you’re an engineering team, you need to like make sure this stuff is repeatable and can either run on every commit or you have like a consistent way of using a harness to find bugs and patch them and prevent them from coming back. Whereas if you’re like selling exploits, even if you’re operationalizing it, What you need is a fuzzer you can run for a few months that pops out a big enough backlog. And then a couple months later, you need to be able to do that again. I’m kind of, I haven’t actually worked for an offensive firm, so I don’t know that for sure. But there’s a difference between finding a lot of bugs once and then like actually solving a problem. And again, the people working on the platforms actually have to solve the problems again. And that just always sucks because you’re, you know, doing—

lcamtuf: Yeah, but I think, you know, like With browsers in particular, I think the implicit assumption is that given the developer velocity, the choice of languages and the features that are sort of being shipped every year, we are accepting, implicitly accepting a certain baseline of security failures, right? So like we are not aiming for a state of having zero vulnerabilities because that would be insane. And also, yeah. And so, yeah, you wanna lower the base rate, you know, you wanna run the same tools that the bad guys are running at the same or larger scale to make their lives harder. But ultimately, more hinges not on the inability to find another bug in, you know, WebGL or whatever, but on actually on mitigations, right? Like holding up and making it really difficult to reliably exploit And sort of, you know, bringing the cost up, right? Like most of the mitigations you can eventually bypass if you get lucky, if you chain together, you know, 5 or 10 bugs, but a large portion of why zero days have gotten so expensive is because you need to do all that legwork that wasn’t necessarily essential before, right?

David: And I think that— I disagree with that a little bit in the sense that like, As enough mitigations, like, do actually have an impact on attackers, but unless you can like affirmatively say like a given bug that comes into your queue, like, doesn’t matter. Like at this line of code, ideally by like inspecting the line of code, being like, oh, this uses a span. So I know it’s not an out-of-bounds read unless the span is constructed wrong or it uses raw_ptr, miracle pointer in Chrome. So we know the use-after-free doesn’t matter.

lcamtuf: Oh no, no.

David: I, I— Like if you have something where like, oh, maybe it’s just a write and not a read. You still have to treat it like it’s bad. No, no, no.

lcamtuf: Yeah, I was, I was talking about—

David: And then it comes through your whole process as an engineer.

lcamtuf: Yeah, I was talking about the offense side, right? Like I think on the defense side—

David: Yeah, but you can’t discern. The problem is the defender can’t discern which ones were useful and which ones were not. And so you have to treat them all the same. And so if you just apply mitigations, even if you are actively hurting the ability to actually exploit Chrome, like you’re not solving your problem of you have this massive interrupt queue of security issues, which eventually you’re just going to stop looking at.

Deirdre: Yeah.

lcamtuf: Yeah. We’re basically doing two things that are not solving the problem, but which is trying to enumerate all the bugs, but yeah.

Thomas: So there’s like an implicit assumption here in this conversation that the vulnerabilities that agents might find, and we can get into more of why we think agents might or might not find different kinds of vulnerabilities, but the vulnerabilities they’re going to find are going to be of the same kind of, they’re going to rhyme with all the vulnerabilities that we’ve seen so far. And like we’re accepting a certain amount annually or every month or whatever of memory corruption vulnerabilities in client-side software or whatever it is, right? And so like, I think we feel like we have a decent bead on where things are going. And like, I do feel like we’ve kind of like organizationally and as kind of an industry, we’ve metabolized a certain level of, you know, dealing with vulnerabilities, right? Like the sky doesn’t fall every time a new vulnerability comes out. You’re much more likely to get popped with phishing or by a dumb misconfiguration in an S3 bucket something like that. Like fully agree on that, right? And like LLMs apply to that stuff the same way they apply to everything else, which is super interesting. But I wanna push back on the idea that like what agents are gonna do is, you know, get us to peak oil on memory corruption vulnerabilities or something like that, right? Like there were moments in the past when we as practitioners, like we were practicing when SQL injection, you know, broke out, right? And there’s, there’s like a before or after moment that was probably the span of like just a couple months where like before there were a bunch of things that were hard to break into and after, like for a while, everything was trivial. The first commercial pen test I ever did was like, it was an application where I logged in with quote, unquote, quote equals quote, which is literally the first SQL injection I ever attempted and it worked, which totally ruined me for vulnerability research ever after that. ‘Cause I’d always think that would work and it almost like, you never get blatant SQL injection vulnerabilities like that. But I did in that one instance and thought they were that common. But like, so like, When we discovered SQL, when we first published StackOverflows, right? There’s a clear before and after to enablement for StackOverflow vulnerabilities. Before, lots of software was, you know, resilient enough. And then after, the entire internet was vulnerable. And in those moments, it’s really material, the vulnerabilities that you’re finding, right? In those moments, it actually really matters a lot that there are all these new vuln— it becomes the dominant vector that things get popped with until you kind of figure that out. And I’m not as certain as I think the implicit assumptions in this conversation are that we’re not we’re not going to see more things like that. So, you know, side-channel attacks are a good example of where there’s like lots of kind of intellectually understood vulnerabilities that we don’t viscerally feel and we don’t deal with because there isn’t enough elite attention to develop them into real vulnerabilities. How certain are the three of you that like all Go memory race vulnerabilities are not going to really be practically exploitable?

lcamtuf: So I think you’re sort of, you know, Entering toward this sort of, you know, AGI question here maybe, right?

Thomas: Is that AGI? It’s like—

Deirdre: It’s not even AGI.

Thomas: Is a memory race exploitable an indication of AGI?

David: Exploiting a Go race condition, AGI confirmed.

lcamtuf: Right, yeah, no, I think, you know, to some extent, you know, all that I have seen so far is that LLMs are very good at scaling the methods that we’ve been using in the past and finding the problems that we’ve been finding in the past. Now I think there’s also less numerous data points from other fields that they are actually so good at combining and synthesizing information from the sort of training corpus that they arrive at completely new conclusions, completely new findings, like fundamentally new math, right? And so on. I think you’re asking about unknown unknowns, right? There is a future where we, it actually turns out that there’s a nearly inexhaustible supply of zero days in OpenSSL in places we were not even thinking about. But I have no way to prove or disprove that.

Thomas: And I don’t think— Hold on. Hold on. In fairness, I want to say, I actually don’t think we’re going to get like a bottomless supply of OpenSSH vulnerabilities. I have like a, despite it being an old school C code base, I have a very high opinion of the OpenSSH code base, right? I’m actually thinking of things where it’s like, I have a nagging suspicion that there are already things there. And to me it’s not as much about advancing LLM, like frontier model capabilities, although that’s a factor. It’s not as much that as it is the new abundance we have of elite attention. OpenSSH, right? Where like, it doesn’t take that much time for me to set up the conditions to like, do, you know, a side-channel testing harness across the internet or something like that. Where like, I, I’d have to do a whole lot of studying and research and like trial and error to get that, like those harnesses set up for myself to do that kind of testing. And now I can just dispatch it and have it done. Um, like it’s, so I feel like the really high-end vulnerability research has been for the past 20 years done by like a reasonably large number of people, but it’s still an elite in the industry. And I don’t like that. Right? Like I think that’s always been kind of bullshit. And like one of my big things is just, I don’t think that the people doing this work on the high end are really in any fundamental sense more gifted or capable than any other engineer. They just, they, they’ve been inducted into the field and they get to do that work. Yeah. Right. And like, I think the bottom has fallen out of that. Right. And so now if you imagine 10, 100 times more people being able to do that work because it’s no longer as time-consuming, I think a lot more things get kind of proved out.

Deirdre: Not even time-consuming, but like, no, like, where do you even get the knowledge to start the thing that requires— like, that also requires time, but it requires some sort of like entry point of like, how do I even get started on this path? And now you don’t even have to know anything. You just like go look for vulns in place. Like, here’s your guide, start here, enter here, and it will find something more, more likely than not. If it’s a, if there is a vuln there, it won’t, you know, maybe it’ll hallucinate something that’s not really there, but then you can write a test that’ll actually, it’ll ask it to write a test to be like, confirm that this is broken. So there’s, it’s, it’s not even just the time amplifier, but like, there’s a lot of stuff that you used to be, have to be able to know what to ask or know where to start or know how to approach a thing. That you basically have a very powerful shortcut on.

lcamtuf: I would say this. I think that a lot of money and compute has been thrown at this problem by the frontier labs over the past couple of weeks or months. And we’re going to start seeing a trickle or a flood. I mean, we have already started seeing some of the sort of public results from that. My understanding of, you know, what I’ve seen so far and what I can talk about is that they are not fundamentally different from, again, you know, the kind of vulnerabilities, the kinds of targets, the kinds of attack surfaces that we’ve been seeing before. So I think, you know, that doesn’t disprove your theory, but I think the, it would hinge, I think, We would depend on some additional breakthroughs before we get to this point where you can point GPT-5.5 or Mythos or whatever at Chrome and come up with completely new classes of vulnerabilities or, you know, the, like, again, race conditions of the kind that we thought are not exploitable in past. Like, I think it’s possible, like it happened before.

Thomas: But that’s not what I, that’s not what I think, right? Like, so there’s the big thing with Mythos has always been Nicholas Carlini being able to aim those frontier models at a piece of software and just say, give me a zero-day exploit, right? And those words put together and getting real output from that was like a, a huge thing. I, I, I, that’s, it’s, that’s a real thing, right? But like, I’m not coming from a place of, you know, pointing, you know, a frontier model at a code base and saying, come up with an entirely new bug class. Like, it’s just gonna figure that out. I’m more coming from like, like, do you really not have nagging suspicions about— so first of all, this might just be me, right? It might just be because I learned all the computer science I learned by reading exploits. But like, it’s like, it’s like all I think about is like what, like what the new bug classes are gonna be like Spectre. Like, that was amazing for me, right? Like, things like that. Like, that’s the punctuation for this whole kind of career that I have, right?

lcamtuf: But it’s kind of like—

Thomas: I’m always thinking about like what the other, like, what weird thing this could turn out to be. Entire bug classes. Do you not have anything like that? Do you not think that way? Are you not a vulnerability researcher?

lcamtuf: I have a lot of things, like, you know, there’s a lot of places, there’s a lot of rocks that I think we have not peeked under. And I think LLMs are gonna, like, you know, in the embedded world, which is, you know, something I’m spending a lot of time with as a hobby. There’s a lot of absolutely terrible things that are absolutely everywhere right now. And I’m not talking, you know, like a crappy HTTP stack on a more fundamental level, right? Like, you know, the radios and everything.

Thomas: Yeah, RF.

lcamtuf: Yeah. And I think this is, but at the same time, you know, so yeah, I think, you know, we’re going to unlock a lot of interesting things. Does that Is that like a fundamentally qualitative change versus, you know, some researchers deciding, oh, actually I’m going to throw a fuzzer at this hardware as it happened many times in the past. And, you know, what is the actual, like, you know, Spectre, again, like a fascinating class of bugs.

Thomas: I know, I know what you’re going to say.

lcamtuf: Does it like, you know, so what? Like, I absolutely loved it, every bit of it. And, you know, the insane amount of resources. We spent—

Deirdre: but we agree, we probably agree. The foundation of the trusted compute base. It’s a lot of, it’s a, it’s a lot of things that are kind of, we worry about in cryptography is like, this is highly difficult to exploit in a lot of cases, but it’s the foundation of trust in almost everything that we build on top of it.

Thomas: I know, I know. Fundamentally, fundamentally, the impact of Spectre was simply to make all of our computers slower. I understand this, right?

Deirdre: But that’s interesting. It could have been a lot worse. It could have been a lot worse.

Thomas: But you, you can’t say that about SQL injection. Fundamentally, the popularization of SQL injection materially changed the susceptibility of networks to attack, right? Spectre didn’t do that. SQL injection did do that. SSH, more recent example, right?

lcamtuf: Yeah, but again, like, you know, you also have tools to eradicate it more quickly now. So I think there is symmetry, right? We get, like, you know, we’ve been through those cycles before, many times before, and both on the sort of, you know, like the, uptake or the sort of, you know, uphill portion of it when, you know, someone discovers XSS and it turns out that you can do absolutely terrible things with it, including, you know, running code on your device because we moved everything to the web, right? Including control over endpoints. And then sort of, you know, we’ve seen people actually make progress, making those classes of issues go away, right? Like, you know, like, If you want to find an XSS on google.com, you’re going to have a hard time, right? Because of the investments that the company has made into getting rid of entire class of engineering.

David: Into safe coding specifically. Like again, not mitigations, like safe coding, stop the bug at the source.

lcamtuf: So I think, you know, like if you’re asking me if security is going to be interesting for the next couple of years, absolutely. And vulnerability research is gonna be interesting and a lot of other, you know, attack and defense related aspects of it are gonna be fun as well. But again, like, you know, and I guess, you know, it’s a question of where we draw the line between apocalypse and business as usual, right? And maybe we are just defining it a bit differently.

Thomas: I didn’t come up with bugpocalypse or whatever it is. I don’t think there’s any pocalypses coming, right? We’ll figure it out. I think the RF thing is like such a good example just because of so many times I had the experience of being on projects where there was an RF target and like we’d go in and like everyone wanted to like get good at GNU Radio or whatever people were using, like SDRs and all that. Right. And like by your second project, you just knew going into that, like, no, you’re not gonna do anything with an SDR for this RF target. You have no idea how complicated it is to actually get a protocol up and running like that. Right. Inevitably you’re just going to do the hardware hacking to find like the serial bus that you can like turn this thing into a modem for its own protocol. That might not be true anymore though, right? Like now, like that’s, that seems like a reasonable task to stick an LLM on. ‘Cause it’s got like in the training set, there is all the RF knowledge. It’s just like none of us are electrical engineers. So we were never trained to do that stuff. But like the model’s an electrical engineer, it’s every kind of engineer. I, I just think that’s, I know, I get what you’re saying. Like even like widespread RF attacks probably wouldn’t, I don’t know, maybe it’d be more destabilizing than Spectre, but like, No, like, you know, you could probably build some cool worm, right?

lcamtuf: And like, I’m, but again, you know, we’ve done that. We’ve been there.

Thomas: It’s a worm. We’ve seen worms.

David: The apocalypse isn’t going to be on users. It’s the, like, let’s classify projects into like 3 shapes. There’s like some stuff like OpenSSH and BoringSSL that pretty much doesn’t have bugs. Um, what did you say? OpenBSD?

Deirdre: Insha’Allah. BoringSSL.

David: BoringSSL, which has had the AIs pointed at it and they have not found any high severity memory issues, whereas they have found many in other SSLs. Um, and like OpenSSL, like there’s like 3 people in the world that can write like safe C code, like, uh, the WireGuard, uh, Jason is one of them, but, um, So there’s some projects that like we’ve actually managed to make safe. There’s another set of projects that just like don’t actually matter that much. And then there’s the like set of projects that are like actually juicy exploit targets. And I think we’re all loosely in agreement that those will not, that like we’re not really expecting a ton more exploitation. Like maybe it’s a risk, like we’ll see what happens with the market dynamics. Um, but the, the, the apocalypse there is on the engineering teams of those products. Because you have more and more bugs than ever and there’s, there’s not a good way to prioritize, like, how you handle this.

lcamtuf: Yes.

David: You need to be taking the set of bugs and turning it into like a queue of actually preventative actions and not just mitigations because you need preventative actions to like save the time of an— I’m— of the actual engineering teams. And if you just choose to say, you know, well, exploitation was already like demand-bound, not supply-bound. So it doesn’t matter. Like, doing nothing will result in the Jevons paradox and like bad things happening. So you have to do something. And so the apocalypse is just like, you have this massive queue of interrupt work that is saying like, you got 20 million lines of C++ in Chrome. Well, not all of them are going to be winners, right? Yeah. And if it’s one bug per like 1,000 lines, that’s, you know, like 20,000 high severity bugs, and if an AI finds 10 a day, well, I’ll see you in like 3 to 10 years.

Deirdre: Yeah. Yeah. And that’s not even including like, you know, up the past couple of months, couple of years, like there’s been sloppy reports to bug bounty programs and, and bug trackers and stuff like that. And like, you can get rid of a lot of the, the crap reports. It’s laborious, but you can do it. Now the reports are just very, very good and a lot of them are not slop and that is like when they’re all very good and they’re all high, like you have to deal with that too.

Thomas: Yeah. Can I take a minute? Can I just take a minute here? Another Hacker News thing just blew up in my brain. I’m sorry, I’m having a message board stroke.

lcamtuf: Okay. Oh my God.

Thomas: But can we talk, can we talk for a second?

Deirdre: You mean like Hacker News statins or something?

David: What’s going on? What are we doing?

Thomas: Can we talk for a second here about the idea that curl is the benchmark for how effective a vulnerability tool is.

Deirdre: Fuck, why?

Thomas: This is—

Deirdre: No.

Thomas: This is entirely— Am I— I’m waiting for any of the three of you to tell me that I’m wrong and that curl is deceptively difficult software to build. And that you wouldn’t expect it to work properly. ‘Cause all I hear is like Mythos didn’t find awesome things. Like they did a Mythos scan on curl and it didn’t find any new curl zero days. It’s like you could do a Mythos scan on cat and I wouldn’t think that cat would have zero day vulnerabilities either.

Deirdre: It’s a little bit more complicated than cat, You know, it’s not OpenBSD, so I wouldn’t expect it to be that juicy.

Thomas: Well, you shut your mouth.

lcamtuf: I also, you know, like we, like, I think there’s also the risk of like, you know, I had the opposite of this conversation with many folks many years ago before AI that, you know, like in the context of some of the mitigations we’ve and sort of, you know, defenses and so, and practices we’ve been developing at Google. That all of this is cool, but it works for like, you know, this one company in the world that is sort of, you know, has a codebase of a sufficient complexity and a sufficient amount of funding and so on. And everyone is sort of, you know, struggling with more basic problems, right? So I think curl is actually representative of a lot of what’s out there, right? Like it’s actually a pretty good baseline for a codebase that isn’t terrible. It’s not like, you know, some of the— It’s not FFmpeg, right? Like you can’t throw a parser at it and have like, you know, 50 bugs in an hour. But it’s also not like, you know, some like very simple trivial library that is not gonna have bugs.

Thomas: So I think it’s a good— I think curl matters a lot. I think curl matters. I just don’t think it’s a complexity benchmark.

lcamtuf: Yeah, I think, you know, there are people making arguments both ways that this is like, basically if someone tells you that whatever outcome with curl, good or bad, is proof of anything, then they are probably full of it.

Thomas: But I feel bad. I feel bad putting this to you because I feel like fundamentally the subtext of what you’re saying is like, we’re way over-indexed on vulnerability discovery and response in general, right? And like, we can go different angles on that. We can talk about backup software, we can talk about the oddball stuff that I’m worried about getting, you know, popped right now that like isn’t Chrome or whatever, right? But like, more generally, I wonder Like one big problem that we have is, um, it’s, it’s really easy to imagine, you know, next week, like Mythos 2 is gonna find a reliable KVM exploit, right? Um, like something that broadly impacts everybody and like, I’m gonna have to reboot every single, you know, server in our fleet. And that’s a lot of hardware to reboot. It would take us all, it would take us some, we’ve, we’ve tabletopped this. It’s, it’s doable, but like, it’s, it’s rough.

Deirdre: Like the vuln wouldn’t be anything. I think we’re speculating the vuln wouldn’t be anything like completely alien that no one’s ever seen before. It’s just threading pieces together in a way that because it holds all this context in its quote head, it’s able to thread them together and find an exploit.

Thomas: Well, hold on, forget LLMs finding this. Imagine, you know, just Travis Ormandy publishes this next week. Of course. Which he has done to us before.

Deirdre: He took a shower and then, you know.

Thomas: Yeah, I’ve like gotten lunch and come back and like Zenbleed is happening, right? Oh boy. Whatever. Put aside how the— I admire him. He’s amazing. I’m not dunking on him. That did happen. That did happen to me. My thing here now is on the, on the defender side, right? Like another thing that agents potentially do for me is put me in a situation where I don’t necessarily have to reboot to do that. Right? Like it’s much more plausible now that I could do a dynamic kernel patch than before.

lcamtuf: Yeah, but that’s kind of one of the places where you do have that asymmetry, right? Like, to find vulnerabilities, you’re perfectly happy with a, you know, 50% accuracy rate. Like if 50% of the findings or 90% of the findings, that would be just like absolutely wonderful. You will not accept 90% accuracy for binary patching in production, right? So I think the solution is a lot more challenging than the—

Thomas: I’m like, You’re like, you’re two steps past where I’m at, right? Just assume we’re at the, assume we’re in a, in a situation where like we’ve identified the vulnerability, there is an official source level fix for it. That’s the right fix and all that. And I, I have the simple logistical problem of how the hell do I actually apply this patch given I’m gonna have to reboot, you know, tens of thousands of, you know, physical machines or whatever.

Deirdre: How do you deploy the fix?

Thomas: Not, right. Okay. Like I’m thinking more just in line of like, we have a known good fix for it. And like, I can, I can imagine that in most cases, even I’d, in many cases, I’d be able to dynamically, given a known good patch, dynamically apply that in the business operation sense, not in the like software library.

Deirdre: Like I just have to release a security fix version and blast it out to all official channels, et cetera.

David: No, no. By apply, you mean hot patch your live running.

Thomas: Yeah, exactly.

David: Right. Without rebooting.

lcamtuf: Yeah. But you have confidence that the solution is right and you just need like a monkey with a wrench to log in.

Thomas: Well, yeah, but I mean, I think a lot of things don’t get fixed just because it’s very difficult to schedule resets and take the outage.

Deirdre: Yes. Or in this case, take the risk of an outage. You might have a lot of confidence that you can live patch this, but that’s still risky.

lcamtuf: If you can get to that point, yeah. And then, you know, like you still have the problem that, you know, if the agent goes to Reddit and decides to ransomware you instead, you, But like, you know, that can be mitigated, right? Like with sandboxing and it’s all probabilistic, but I think we have to get used to the notion that, I mean, you know, it was always probabilistic, but like humans are probabilistic too, although in a different way and maybe a bit more predictable. And we need to build better models of how to deal with the unpredictability of agents every now and then. But yeah, no, like, yes, I— I don’t think you’re crazy.

Deirdre: So a nice thing though with software is that you can do all this other stuff outside that the model isn’t touching, and you can try to get something that’s a lot more deterministic to try to like confirm so that it’ll spit something out and you can have pretty good confidence in what it will do behaviorally because you did all this other work to like test it up the wazoo yourself and try to basically mitigate the probabilistic trust that you have.

lcamtuf: Yeah, sorry, I didn’t mean to interrupt. No, sorry. Yeah. I know, I have this theory that if we’re thinking about using agents in like mission-critical settings, like enterprises and so on, the principle, the way to build those architectures is not to put agents with human-like autonomy and human-like access and hope for them to always make the right decisions. It’s to give them tools that are secure by default, provide them with more constrained permissions and more constrained access that is tailored to the differences between those. They are fundamentally different. You can’t put them in prison, right? If they delete your data, they can write you an apology letter, but that’s kind of as far as it goes. So there’s like, you know, the usual social contract you have with your employees is gone and all the negative consequences that come with that. So I think, you know, there are architectures that are conductive to building secure agentic platforms today, and we should be leaning into that more in the future. But I don’t think this is the direction that the frontier labs are moving in, which is basically human-like agents that are, you know, your coworkers, your assistants, and basically have access, unconstrained access to everything that you have and that act with full human-like autonomy, right? And I think that is, I may be wrong about this, but I just don’t, Until we solve prompt injection and all the other problems that we don’t seem to be making as much progress on as on capabilities themselves. I, yeah, I don’t know.

Thomas: I do get, yeah, I do get squicked out. Like I see a lot of places where LLMs are super applicable to defense, but I do get squicked out every time I see somebody using an LLM as a reference monitor, right? Like this is the actual defense we have is that an LLM will make smart decisions about things. Like I’m sure there are a lot of places where like, good smart decision-making as like a good triage step or whatever, but like literally as an access control mechanism, kind of like doesn’t seem right to me.

lcamtuf: Well, the problem they are trying to solve, I think in many cases is that you now have agents on the attack side, right? So, and they can move very, very quickly, like, you know, compromise to persistence to lateral movement in, you know, what, 30 seconds, right? And they can do it at any time. And so you kind of need human-like reasoning about what’s happening in the enterprise and autonomous decision-making on timescales that are just fundamentally incompatible with human workflows, unless you fundamentally rethink how companies are structured and built and you, you know, compartmentalize everything a lot better than we are compartmentalizing today. So I think on some level, LLM-type reasoning is unavoidable on the defense side if you want that real-time clever sort of countermeasures, but it’s incredibly difficult to get this right and not shoot yourself in the foot.

Thomas: So yeah. It wouldn’t be my first move as a defender. That wouldn’t be like the first place I would go.

lcamtuf: Oh yeah, yeah, yeah. I think, you know, like, like you need a lot of piping before you even get there, right? Like, you know, it needs to have the right sources of information to begin with. And, you know, most enterprises don’t even have that, right?

Thomas: Let me ask you a weird question. So you’ve got the book and I’m going to ask you about the book and the new book in a second, right? But like, like how, how, like, how like security are you going to be going forward? Are you going to veer off into circuit land?

lcamtuf: No. So, you know, so yeah, electronics has been my passion ever since. And I think, you know, it’s kind of like I ended up doing computer security kind of by accident. You know, computers, like I was either going to become an electrical engineer or a chemical engineer. And that was sort of, you know, my childhood thing. And then computers showed up and ruined my life, right? And it was sort of the right time, the right place, right, to be getting into InfoSec.

Deirdre: I feel like that could be said of all of us, and then computers showed up and ruined my life.

lcamtuf: Right, yeah, yeah. So I think, you know, so obviously, you know, no real regrets about that. But yeah, I keep going back to that. And here’s the thing, like, I’m still very passionate about security. And I think, again, like, this is, incredibly interesting, right? Like this is either the most interesting time in the history of InfoSec or the second most interesting after the arrival of the web, right?

David: Yeah, absolutely.

lcamtuf: I was not nearly as excited about the field for a good while, right? So I wanna be a part of it. At the same time, I think, you know, the things that make you visible in the field, like basically punditry, you know, I guess having a TikTok now, right? Or a podcast. Or like, you know, doing vulnerability research work. I think, you know, I’ve done this long enough that it feels kind of, when you look back at it, it feels kind of futile, right? Like I did two security books. They are basically completely obsolete at this point. All the, you know, hundreds of advisories and whatever that I published, you know, a decade, two decades ago, No one really remembers or cares about any of that. And it’s not that, you know, I’m sort of, you know, I, like, I’m not seeking eternal fame, but I think it’s kind of weird about InfoSec compared to almost anything. Like, you know, if you publish a book about electronics, yeah, it’s going to be slightly outdated in 10 years and maybe badly outdated in 20, but it’s sort of, you know, it’s, it’s not as rapid, it’s not as dramatic, right? If you build a, if you’re a woodworker and you build a stool for yourself, you know, it’s still gonna be fine. Like you’re gonna still gonna be able to look at it and maybe pass it onto your children.

Thomas: No, like if you wrote like a comprehensive catalog of shop jigs in a woodworking book in like 1965, I would probably still be interested in reading that.

lcamtuf: Right, so I think, you know, I’m trying to balance, like basically I looked at my, you know, infosec legacy and thought to myself, oh my God, this is all like, you know, this is worthless. Right? Like there’s, you know, AFL is going to get forgotten before long as well. And I’m trying to, you know, like find ways to make a more durable difference before, you know, before my time is up.

Thomas: Right. So the book, I’m looking at a cover with a woman holding a solder, a hot solder iron way too close to her face. Yes. Tell us more about the book.

lcamtuf: Right.

Deirdre: What is the name of the book?

lcamtuf: The Secret Life of Circuits.

Deirdre: Awesome.

lcamtuf: Yeah.

Thomas: Let me ask my first question is, will this book teach me how to solder? Because I am terrible at soldering.

lcamtuf: It actually contains some, you know, like pretty useful tips, which is basically spend more money on a good soldering iron, like a pencil shape. Like, you know, versus the one that you hold like a toothbrush and is about as fine of a tool. And that really, really makes a difference. But yeah, so like, there’s plenty of books about electronics, but I think we have this weird two-track approach to teaching that discipline, right? Like there’s the hobby track, which is where you basically tell people that circuits are like water pipes, And I guess a diode is like a check valve and the transistor is God knows what, right? Like some sort of a plumbing abomination that you probably don’t want in your home. And all of this is very seductive, but it’s also kind of terribly wrong because there are interactions between electrons and charges that are happening at microscopic distances. Like, you have two wires and there’s current flowing in one and a voltage appears in another one. And like, you know, you can’t really explain that with like, you know, plumbing analogies, right? So you, so all that stuff that they teach you basically has zero predictive power and you struggle to build your own circuits down the line. It’s kind of like watching, you know, 3 Blue One Brown videos on YouTube and you are really impressed by how clearly it’s all explained. And then you realize that you don’t actually know how to apply any of that knowledge to any practical problems. And then there’s the second track, which is sort of the college degree approach, right? Where you have a textbook that is more anatomically correct, but the way we teach electronics to students is we really front-load the calculus. You’re basically only learning truly punishing math for the first year and a change before you get to an LED or like whatever, right? And you use that as a foundation to streamline all the electronic theory down the line. But this means that, you know, like college textbooks are basically completely inaccessible to hobbyists because no one is going to take a semester or two of calculus.

Thomas: What’s the level of, like, what’s the level of math I need for the— I know that you’re doing a different track here, which is super, super interesting, right? You’re trying to be like at least practically theoretically rigorous about things without forcing me to solve partial differential equations. But what’s the level of math rigor you think you’d need to bring into the college track normally? How far do you have to get in that sequence?

lcamtuf: So are you asking about the way people normally teach it?

Thomas: The way people normally teach it.

lcamtuf: I think it goes pretty far. It’s like Laplace transforms and complex number calculus and stuff like that, right? So it’s not just like the basics of of here’s the rate of change or here’s the sum over time, right? It’s like far more punishing. And the thing that I, like, you know, I don’t have an EE degree, but I actually tried to follow that path. And the thing that is really frustrating by the end of the day is that none of the calculus is really explained from first principles, right? Like you’re given formulas for, this is how you calculate the rate of change of this particular function. But it’s like, it’s just a rapid fire of formulas that you’re gonna forget if you’re not applying it day to day, within like 6 months of— And so, yeah, the approach I’ve been trying to take in the book is, and so, The problem, like the further problem with that is that all the electrical engineers are taught the theory in a specific way and they kind of assume that the complexity is essential to the explanation, right? So if you go to Wikipedia or you go to Stock Exchange and you just want to understand why the formula for the reactance of a capacitor or the frequency response of a filter looks this way, the answer is you know, kid, like, learn some calculus and come back, right? And I don’t think you actually have to do that, right? Like, for sine waves, you can do all of, like, you can derive all of this from basic trigonometry, and it’s going to take you a bit longer. And, you know, there’s going to be more triangles and circles that you have to draw. But you kind of just need, like, you know, middle school, early high school foundations. To explain electronics. So I think, you know, there’s a distinction between essential complexity and the complexity that makes sense and is expedient in a college setting, but doesn’t really make sense for hobbyists. And so I’m trying to aim for that middle ground. And it’s been a wild ride and a lot of triangles and like almost 300 hand-drawn illustrations and diagrams and yeah.

Thomas: I haven’t asked you specifically before, but I get the sense that you have most of the math already. So I was like, is the work here going from like, I can metabolize this stuff because I have, you know, like complex calculus and all that, right? To like translating it down or like, is this literally you trying to figure this out as you go?

lcamtuf: No, no, no. So I think, you know, you know the answer, right? And you sort of, you know, start from that point, but it’s actually— Sometimes when you force yourself to explain something simply, you realize, actually, you know, do I really understand this? Like, you know, why is it the way it is? And how do you convey that in a way that makes sense to a person who, you know, hasn’t read the same books, right? And hasn’t gone down the same rabbit holes. So it is a bit of both, I think, you know, like, trying to explain is when you realize that you don’t know certain things.

Thomas: And Yeah. Yeah. For sure. How far are you into the book now? I saw like 420 pages. Have you written 420 pages?

lcamtuf: Yeah. Yeah. It’s all done. It’s like, you know, with the printer right now. So yeah, you can preorder and get a free PDF today and it’s going to be like the entire book. And then it’s going to ship in September, like physical copies. It’s going to be full color and hardcover. So like really, really fancy.

Deirdre: Will there be copies at the NoStarch booth at DEF CON or Black Hat or whatever?

lcamtuf: I would expect so. Cool. But, you know, like, I’m not in charge of their marketing, but they usually bring all the new stuff.

Thomas: It would be a funny role for you to take.

lcamtuf: Yeah. They actually always try to rope me in. They ask, you know, are you going to DEF CON or Black Hat or whatever? And my answer is always no, thank you. I went there like, you know, 20 years ago on the Good enough.

David: Will it teach you how to calculate the equivalent resistance between two resistor nodes that are a knight’s move away in an infinite grid of ideal 1-ohm resistors?

lcamtuf: So that’s the thing, you know, there’s a lot of things that we teach to people just to torture them, I think, right?

David: Or in some cases to be hit by a bus in an XKCD comic.

lcamtuf: Yeah, and I think, you know, there’s also a lot of things that we teach in a particular way for historical reasons, right? Like if you buy an electronics book, there’s probably going to be a chapter about things like tunnel diodes that, you know, no one has made commercially since the ’70s. And you can, you know, buy some Russian surplus on eBay, right? Like if you really want to, or how to wind your own transformer or stuff like that. And no, and And the book is not going to be spent, or like, you know, like, you usually start with NPN or BJT, like, you know, bipolar junction transistors, which are kind of not exactly obsolete, but they are more complex than the more common and more modern field effect transistors, which is what you actually use everywhere, right? In digital circuits and power switching and so on. So I’ve been trying to step away from that as well and like really focus on modern problem solving. And that means that, you know, if you want to build an oscillator, you’re probably not going to be putting together individual transistors. You’re going to get a microcontroller that costs like, you know, 50 cents and program it to output whatever waveform you want, right? And if you want to change the frequency or whatever, you can just upload new code. So I think there’s a lot of stuff like that. In the book, just trying to keep it practical and not torture people with math or theory just for the sake of it. It’s just the things you really need, or, you know, the things you need to know to make sense of Wikipedia articles or college textbooks down the line if you really need to investigate a specific thing.

David: Well, that’s very cool. Thank you. Thank you for coming on. Thank you for telling us about the book. Thank you for letting us interrupt you while you talked about AI bug finding for like an hour before talking about your book.

Thomas: Okay, cool.

David: We appreciate it.

Thomas: Okay, cool. Thank you. I mean, so much for this is, this is, this has been, um, a very fun conversation. Yes. Even though I think that vulnerability research is gonna matter more than you think it will. Uh, I am super psyched for the book, although I’m a late in life math student, so I’m actually psyched about the math parts of it. But still I’m unbelievably terrible with electronics and I did not realize I could, I did not realize I could download the whole book right now, which is awesome. So that is The Secret Life of Circuits. That is Mikhail Zelensky’s, Zelensky’s, get it at some point, new book. Everything else he’s written, we used to give copies of The Tangled Web, which was your second book.

lcamtuf: Yes.

Deirdre: Which I have right here on screen. To every candidate that applied at Montserrat.

Thomas: Exceptionally good writer, very fun to read. So yeah, look, thank you so much for doing this. We really enjoyed talking to you.

lcamtuf: Thank you. And you know, after the Volnpocalypse, I’m happy to come back onto the show and you can tell me how wrong I was.

Thomas: You’re a prepper. That was your third book is about like preparing for the— it was about preparing for the Volnpocalypse. So I’m sure you’ll be ready. We’ll come to your place because you’ll have water stockpiled for us.

lcamtuf: Yeah, I have an excavator. So, you know, You don’t actually have an excavator, do you? I have an excavator. I have a tractor. I, you know, I’m all set.

Thomas: You’re buying all the equipment that 2-year-olds were really fascinated by. You have the means now to buy the real-size Tonka trucks.

lcamtuf: Yeah. The trick is you publish a book to make it look legit and then you can buy whatever.

Deirdre: Okay. Well, when the Volmpocalypse comes, we’re running to your compound. You already invited us. You can’t take it back. Security Cryptography Whatever is a side project from Deirdre Connolly, Thomas Daczek, and David Adrian. Our editor is Nettie Smith. You can find the podcast online at SCWPod and the hosts online at @durumcrustulum, @tqbf, and @dadrian. You can buy merchandise at merch.securitycryptographywhatever.com. If you like what you’re hearing or seeing, give us a 5-star review wherever you rate your favorite podcasts or videos. Thank you for listening.

Thomas: I can’t believe he has an excavator. I can’t believe he has an excavator.

Facing the Vulnpocalypse With lcamtuf

Latest Posts

Facing the Vulnpocalypse With lcamtuf

AI Finds Vulns You Can’t With Nicholas Carlini