James Kettle on inventing new attack techniques with LLMs

0:04James Wilson: Hey everyone, I'm James Wilson and welcome to this episode of Risky Business Features with Port Swigger's Director of Research, James Kettle. Now, we all know that AI and large language models can shake out bugs, vulnerabilities and even exploits now from seemingly any piece of software, open source or closed source. But the divisive question remains, can a large language model actually conduct and produce novel security research? That is, can it move beyond everything that it's been trained on and produce research that the model's never seen before, but most importantly, a human expert researcher in that field has also never thought of before?

0:44James Wilson: That is the question that James Kettle sought to answer, and it is the subject of his most recent research, as well as DEF CON and Black Hat talks titled, Can AI Do Novel Security Research? Meet the HTTP Terminator. The HTTP Terminator is essentially a custom agent harness that James created by his own omission, completely vibe-coded. But the important thing here is it encodes his methodology for working with and uncovering these HTTP desync attacks, as it's known. This is a topic that James has been exploring for many years and in fact has done over, well, I think it was actually five now, Black Hat and DEF CON talks about HTTP desync attacks.

1:25James Wilson: So it's something he knows really well. So he took his research methodology, what he knows about these HTTP desync attacks, and essentially encoded that into a harness. He taught the large language model how to do research the way he does research. not because he wanted it to continue to exploit these HTTP desync attacks for bug bounties and whatever other projects but rather because he wanted to essentially ask the model if I teach you to do research the way I do research can you do research and come up with techniques that I haven't even thought of yet and the answer is yes it can but this conversation is not about the vulnerabilities that it found.

2:08James Wilson: This topic, this interview really focuses on what does it take to make AI do novel security research? How do you generate useful hypotheses? How do you evaluate tens of thousands of ideas that an LLM will generate without drowning in false positives? How do you turn these anomalies into working attacks? How do you use these as discoveries for, you know, how do you use these discoveries as seeds for the next phase of research? All these sorts of things go into building a flywheel that is then able to do. truly novel security research. But most importantly, what we also delved into in this conversation is where does the automation and the agents stop?

2:46James Wilson: And where does an expert security researcher become not just an important part of this process, but actually the essential force multiplier that is actually the enabler of the large language model doing truly novel security research? I'm going to drop you here into the conversation where James first talks about what these HTTP desync attacks are and how they work. It's important to delve into this because this attacks type is not just a, he didn't just choose this to be the, I guess, the verification of the research that the LLM was doing, but rather it's a very deliberate choice for two reasons.

3:26James Wilson: One is James has just an inbuilt instinct that there's still a lot of undiscovered vulnerabilities that stem from this just systemically insecure and perhaps, you know, not quite fit for purpose protocol, let's say. But also it was an important decision because it's something that James is a deep subject matter expert with. And it turns out those are the two important ingredients here. If you want a larger language model to be able to do novel security research, you can't just one-shot prompt that. You've got to be able to combine existing research methodologies that you know and you deeply understand in a field that you're a deep subject matter expert with so that you can sort out the wheat from the chaff, the hallucinations from the real, and most importantly, you can determine what is actually novel research versus is just something that a model is getting very excited about.

4:21James Wilson: Enjoy. HP desync attacks were first documented in 2004 or so, but then everyone forgot that they existed. And then when I stumbled on the concept in 2019, it was glorious. It worked on everything. I could hack about a third of the internet and the reaction that I got from people when I reported a vulnerability using it was literally, that's impossible. Well, let's delve into that because this is a great starting point, right? Because the research, as I understand it, was 2005 from WatchFire. They'd called it HTTP request smuggling, and it had a fundamental problem of both. It was very difficult to get a reliable result, and also there was a lot of noise and collateral damage around it.

5:09James Wilson: But I just, I love your excitement there. You looked at it and said, that's glorious, but that means you also intuitively found a way to get around the fact that it was hard to do and or create a lot of collateral damage. So how did that come about? So yeah, I looked at it and my first reaction was fear, like, oh no, I'm going to take things down by accident. I don't understand this stuff. But once I got to understand it, I was like, well, I don't think there has to be collateral damage just from probing for it. And then once you've identified that something's vulnerable, you've just got to ask, well, what's worse, like disrupting a couple of visitors on this website, bearing in mind that, you know, what, 50 % of website traffic is bot traffic anyway, or actually unveiling a horrific flaw that someone could use to just compromise the entire system.

6:03So I think basically since 2005, website security has got more important. The baseline of security has reached a point where the tradeoff to find an issue like that is absolutely worth it.

6:17James Wilson: Yeah, that makes sense. Okay, so get us back on track now. What is the actual nature of the issue here? Why did it allow you to hack a third or more of the internet immediately? and why is it such a prevalent pattern in the way that web apps are built that allows this to happen? So the issue is that many, many websites still use HTTP 1.1 and it's a super, super old protocol and it's text-based and it fundamentally was not designed for the kind of complexity of systems that you've got these days. So if you use HTTP 1 and it's just a browser talking to a server, there is zero risk. But most modern websites now, they've got a front end of some kind, maybe a load balancer, maybe a caching proxy, maybe a CDN, maybe like eight layers like that all talking to each other.

7:11And the problem is with a text-based protocol like HTTP 1, it's very easy to send a message that gets interpreted by the systems differently. And due to the way HTTP 1.0 reuses connections, that inconsistent interpretation between systems has a catastrophic effect on security because it means attackers can alter other people's HTTP requests. And they can make the system lose track of which response is meant to go to which user. Because unbelievably, HTTP 1.1, messages don't have an ID. deep. People just assume it does. People think that each message is fully isolated, but actually underneath, it's just a stream of text and the responses and requests are just matched together in the order that they came in.

8:06So if one request triggers two responses, then everything gets out of sync and you've got random responses going to random users and the outcome is pretty bad because that generally ends up logging random users into other people's accounts, thanks to the set cookie header, which is pretty bad.

8:26James Wilson: Small, small problem. Yes. Okay. So not a small problem at all. Let's test my understanding of this to make sure I've got all the bits and pieces right. So a modern web app, there's my endpoint, my laptop, my desktop. It's not talking directly to the source of truth, right? There's going to be a, let's say, an HTTPS connection to a endpoint in the cloud. That might be, you know, there's terms like backend for front end, it might be some CDN or some proxy layer that's sitting in the middle, but there's at least one, if not many hops between my laptop and the actual server that might be serving the authoritative content for the request that I've got.

9:08James Wilson: And even then, you've probably got multiple endpoints within the given web app that might be used to serve the multitude of requests that are required to render a modern web app. Now, if I understand the, I guess, the fundamentals of vulnerability here is that HTTP 1.1, as you say, allows multiple requests to be queued up. So, you know, when I go and launch, you know, apple.com, there is not a single request, get me apple.com. There is a request for apple.com. There's a request for JavaScript. There's a request for images there's a request for all sorts of things so if i'm using http1 those requests are going to be on a single connection but that connection is to some point in the middle of this whole thing but the key point here is that it allows me to batch up my requests and basically say in a long breathless stream give me apple.com give me the javascript that it requires give me the images that are all here give me this give me this give me this give me this give me this And because it is a text-based protocol where these things all just get queued up like this, and to your point, there's no identifier, which is madness.

10:13James Wilson: We even managed to get that right in UDP and TCP, but amazingly, we missed the memory. Absolutely. HP1 is way less secure than TCP and UDP. Yeah, well, congratulations. But the problem here is twofold. I think it's that these requests, this long breathless batch of requests, they have to be answered back in that same order because there is no key to sort of correlate them but the really neat thing here is that i think if i understand correctly the the thing that makes this vulnerable is that different web servers or different points in that chain right whether it's the proxy whether it's the cdn whether it's the back end for front end or whatever it might be each of those could be a different could be a different web server it could be a different implementation it probably is a very different implementation and each implementation parses these headers and this text-based protocol in subtly different ways beyond just what the spec says but even the spec doesn't do us any favors here because it says and i understand this is the key but you tell me if i'm wrong if there's a header present that says here's my content length right which would say how long that request is in amongst that batch if there's a content length and there's also a header that says actually this is using a method called chunked transfer then the spec says ignore content length just rely on the chunked transfer which has its basically its own inbuilt length and data length and data length and data step within that stream and so if first of all tell me if i'm right there because i'm hoping i'm a good student but second of all can you extrapolate from that to help us understand why those vulnerabilities then become such an internet melting vulnerability as it was.

11:56That's absolutely right. So you can send a message with a content length and something else saying this message is chunked. And then depending on whether the server gives precedent to the content length or the transfer and coding header, they think that your request body stops at a different point and therefore they think that the next request starts at a different point, which means you can affect other people's requests, you can send multiple requests in one and so on. And that example of content length versus transfer encoding, it's just one example of many, many, many different pitfalls which lie there in the RFC.

12:42For example, the HP Terminator, which we're going to get to, found a nice vector based on a line that pointed out actually HP 1.0 ignores the transfer encoding header. So for backwards compatibility, it's actually transfer encoding gets priority over the content length with HP 1.1. But if it's HP 1.0, you ignore the transfer encoding header and use the content length. and there's many other even worse things hiding there in the RFCs because they just weren't designed to be robust against this kind of issue.

13:18James Wilson: Right, and that's useful for you because if you can find a situation where there's an HTTP, let's say the first endpoint that you connect to is HTTP 1.1, if it's then proxying through to something that's expecting HTTP 1.0, then the headers again will be differently interpreted. But let me try to paint a real-world example here to bring this to life. Let's say you and I are both interacting with the same website and we're both logged into it. You send five requests, I send five requests, and we do this at the same time. Now, my five requests hit the front end. Your five requests hit the front end at the same time.

13:55James Wilson: That front end is talking to the same back end, and it basically streams my five requests and your five requests through in one connection. And this is a super simplified example, but just for the sake of example, let's say in this magic timing, your five requests are the odd numbered requests and my five requests are the even numbered requests. So we each hit the website, five requests, but that front end or that proxy that's answering up front, the front door, so to speak, when it talks to the back end, it takes our collective 10 requests and might say, here's James Kettle's request, here's James Wilson's request, here's James Kettle's request, here's James Wilson's request, right?

14:31James Wilson: they're interleaved but the magic here is you've got seemingly myriad ways to make your five requests not just five they're actually five on the surface or more to the point they're five plus some extra ones they're hidden in there which is important because when they then get interleaved such that you're the odd numbers and i'm the even numbers let's say your request number one is good my request 2 is good your request 3 contains not just request 3 but also another request afterwards all of a sudden your request 3 is request 3 but your tacked on request at the end of that is now request 4 that should have been mine and all of a sudden we're out of sync right my request is actually yours and it's almost like we've traded places in the queue of of of data streaming through here we're out of sync and you'll get back what should have gone to me yeah exactly which often includes things like a set cookie header with your session key in it which then logs me into your account for example okay so i think we've given folks hopefully a good understanding of an httpd sync attack and i think the key elements here is one it's based on just a spec that was never designed to operate securely.

15:51James Wilson: Unfortunately, that has now been deployed well and truly beyond this most simplistic way that it should have been deployed, which maybe would have still been safe, right? If there was none of this interleaving in the middle, it would have been okay. Yeah. Ultimately, it's a parser discrepancy vulnerability. And when you've only got one parser, you are not exposed to parser discrepancy vulnerabilities. The problem comes when you've got multiple ones. And modern websites have about five.

16:19James Wilson: All right. So why in the year 2026, did you think, maybe I'll dust that off and see what AI can do here with this seemingly well explored and well known attack? I would say so. I wanted to answer the question of whether AI can do novel research. And And HP request smuggling is a field where I've just spent a lot of time researching that area. Prior to starting this research, I delivered four Black Hat USA and DEF CON presentations on that topic. And the most recent one was HP 1.1 Must Die, which was only last year. Oh, wow. I didn't realize it was that recent. Cool. Yeah. So what that means is I've got a polished methodology for how I personally do research in this area.

17:14And also I've got a very good awareness of the fact that this is an under-researched area and there's a lot of potential for more serious vulnerabilities out there. That was the entire thesis of HTTP 1.1 must die was there are tons of zero days that no one's found yet because the underlying protocol is so broken and that this will always be the case. So if you want to be secure, you have to ditch HTTP 1.1.

17:45James Wilson: And just a quick detail, we will come back to the notion of LLMs and AI being able to do novel research because that is a big meaty question. So last year you did the talk HTTP 1.1 must die, which would tell me that a year ago it had not died. What is the scale of the volume of deployments that are still using HTTP 1.1? Are we talking about some esoteric weird little outlier or no? No, no. It's very, very common. Some major CDNs such as CloudFront don't support upstream HTTP 2. So if you're using CloudFront, for example, or many other popular CDNs, then you have to have at least one hop over HTTP 1.1.

18:28James Wilson: Wow. And do you only need that one hop or do you need two to induce that parser discrepancy? Just one hop because we're talking about the upstream. So one hop from a front end to some kind of server behind it. Yeah, because the discrepancy will still be in the thing that is expecting something other than HTTP 101. Yeah, okay, I get it. Yep, makes sense. Yeah, it's like one server to server hop. Yeah, okay. So massive problem that still remains. But let's, okay, so now let's delve into this notion of can AI and LLMs do novel security research? Now, this is a very divisive topic around risky business.

19:06James Wilson: you know and and i'll sort of i guess i'll straw man and steel man my point and and the arguments that pat and i have about this because a large language model is trained on such a large corpus of knowledge and because once a model get out gets out there of course everyone tries to one shot against their favorite target and so you could kind of take the argument that once a model is in there out there in the public domain there is a a class a candidate set of zero day that is just immediately public knowledge, right, or is so easily discoverable that there is no real novelty or, I guess, lasting use for exploit development or sort of a use case that requires something to remain undiscovered for the point in time with which it is still a useful asset.

19:57James Wilson: So that's one argument there. The other argument is that, well, a large language model has been trained on a very large data set, but largely it's a pattern recognizer. So it's only going to be able to recognize the patterns that it's already seen before with maybe some variance, but it's a big stretch to think that it will actually be able to invent or extrapolate very far from those patterns. Those are the arguments I've heard. I have a sense that the answer is far more subtle and it revolves around where a human is involved and what that expertise is that the human can bring to bear into the equation.

20:29James Wilson: But talk us through, I guess, your starting point. Like why even challenge that notion of can AI do novel security research? Sure. I would say as someone that does novel security research for their job and has done for a long time, I just needed to know the answer to the question. I saw a load of people saying AI can't do novel security research and and yet at the same time I I didn't I guess maybe because I've done it so long I've got the methodology I don't feel like novel security research is that difficult like when you know how to approach it I think it's got this kind of all around it like people think that these ideas like magically just drop into your head and it's like that's novel research something just pops into your mind magically out of nowhere and you just hack a load of sites with it and it's like that's not really how it works novel novel techniques come from a source of inspiration and often as a researcher you can recognize you can go this is the inspiration for this and i tested out can ai cut like consume inspiration and create something from it and found that it can.

21:57So that gave me reason to think, actually, this may be possible.

22:01James Wilson: Was your initial instinct, did you expect to be proven wrong or did you expect to be proven right? No, I definitely expect to be proven right. Because while I was doing my HV1.1 must die research over a year ago, as I was discovering novel things manually that the AI didn't know, I was retesting, can the AI discover this itself? Could it have made this discovery? And obviously, testing it that way around doesn't prove the answer to the question, right? Because I'm giving it like a leading question to see if it can discover a specific thing that I found. But it kind of gave me the indication, no, this is probably possible.

22:47James Wilson: Yeah, but even then, you were giving it a leading question, which I guess is a form of giving it that inspiration. But you then, my understanding here is that your research is very much hypothesis and prior research based, right? And in essence, those initial small examples you were doing there were a small localized version of that. Like even just saying, well I found this new technique, could an LLM find the same sort of thing? You're giving it that hint of here's the prior knowledge that I'm aware of so see if it can work out from there. But I imagine there must have been still a bit of a gap between, you know, let's say even if you took a leading LLM and threw it at the problem of going to find my novel ways to to create more of these HTTP desync attacks, you're not going to just one-shot a prompt out of that.

23:41James Wilson: And so what was the... Well, maybe you did. I don't know. No, no, absolutely not. And I think that's why people thought that it was impossible, right? In the same way that I can't one-shot desync research, I've got a methodology. If I want to find something new and have a remotely, any reasonable chance of success, I apply my methodology to it. it's the same with an AI. If you say, give me a novel desync technique, it will give you something that is obscure, if you're lucky, but definitely not novel. And it's kind of a trap, actually. I've seen people use AI to invent something that they look at it and they think that it's novel, but it's not actually novel.

24:27It's come from the draining data somewhere. And that's another part of the reason that I chose to focus on HB desync. attacks to answer this question because it's the area where I've got the most confidence that having spent years and years researching it, I can tell whether something's novel or not, and I'm not going to get hoodwinked and end up saying something is novel when it's not.

24:50James Wilson: Yes, yeah, you are well and truly qualified to call BS on a model, hallucinating something that then it'll do a damn good job of convincing you it's novel, but you've got the ground truth from from all of that research. Just before we get into what the actual research was here and how you structured it, one of the elements that you've talked about in terms of HTTP desync is the combination of you felt like there was still a lot of zero-day and untested and unfound vulnerabilities here, which I guess is a property of the HTTP desync space. Now, let's play a thought experiment here let's put us in the world of looking for vulnerabilities in a very well hardened kernel like mac os for example i would say that that's a space where it's not that there is no zero day but the the number of established techniques and vectors that i can go after to turn something like a simple primitive of a little out of bounds right or a little out of bounds read into something that i couldn't really crack open a mac os operating system it's very very limited It feels like this is a field where the possibility space, the vectors, is very tightly constrained.

26:05James Wilson: But as I was putting together the notes to have this conversation with you, I started to challenge myself on that. Is that almost like my own learned helplessness setting in? Where maybe should I be looking at the discipline of finding bugs in things like operating systems and kernels? Should I be approaching it with that mindset that this is actually a fairly well-trodden thing? there's four or five different established techniques for how you turn a primitive into an exploit? Or does it universally apply that we should take a step back and just go, no, take an LLM, teach it those techniques, give it the history, and let's see what it finds?

26:39I think to give, if I was talking to someone building a system like this, to do this kind of novel research, what I would say is take your research methodology, take a methodology that that works, build something around that methodology, but make sure that you leave the door open to flagging anomalies, weird things and such like, because that is how it will find new things. That's how it will go beyond finding the kinds of bugs that your methodology normally finds to having these crazy breakthroughs. Right.

27:18James Wilson: So you're saying even if I feel like the science of turning a small kernel primitive or a kernel panic into an exploit feels like there's not a lot of opportunity. I shouldn't let that limit me and I should give it my methodology, give it my research, heck, give it other people's research and other exploit kits and say, hey, see what you find, right? So you need to sort of give the model, I guess, the encouragement to think outside of the box. Is that what you're saying? Yeah, I think whenever you do, I mean, there's that distinction between looking for a vulnerability, which is like a known pattern, and looking for an original piece of research, which is like a discovery.

28:04It's outside. It's outside like what you would expect to find. You've got to leave the door open to that kind of thing. And the systems are definitely capable of doing that, of advancing the state of the art. in an area, as I'm sure we'll get to.

28:22James Wilson: Okay, and we will get to that. And I'm sorry, I just want to test one thing here because I think you just made an excellent point, which is what I was talking about there in terms of like finding, turning a kernel panic into a vulnerability. That's not novel research. That's me finding bugs, reporting bugs, et cetera. If we wanted to put the novel researching frame on this, I would need to actually be thinking about something like, and I'm thinking on my feet here, an entirely new way to use the inter-process communication system in the operating system to deliver payloads in a way that exposes a totally unthought of queuing scheduling mechanism problem that, wow, opened up an entirely new attack surface, right?

29:01James Wilson: That's the difference between vulnerability research, finding a bug, reporting a bug, and actually novel research in terms of unlocking a, I guess, not so much class of attacks, but an attack space, a set of vectors that was otherwise unknown. Is that a good way to frame novel research here? Yeah, absolutely. There's like a scale of novelty, and that's a good example of something near the top of the scale, where it's like it's a new, never-been-seen-before pattern of vulnerability, or it's a completely new weaponization pathway. And you also get this kind of middle ground where maybe you might discover a technique that makes a known pathway twice as effective or makes it applicable in more constrained circumstances where previously that technique was not thought to be viable.

29:56James Wilson: Yeah, interesting, which only makes it more astounding that a larger language model is able to do that definition of novel research that we just landed on. So I think this is the jumping off point to actually go into how did you go and answer this question of can AI do novel security research that ended up with the HTTP Terminator? I mean, where should we begin? So the question, can I do novel research? It came from two places. One was like the obvious question. And the other thing was people weren't pushing AI to the limits and talking about where it broke down. There were kind of two camps of people, basically.

30:36One camp of people that were pushing AI to the limits and then selling a product and not telling you where the product was bad. And there was a camp of people that kind of AI avoiders, haters, whatever, that will just say it's bad, but probably aren't the people that are actually using it to its maximum potential. And no one was saying use it to the max potential and talk about where it blows up. And so for me, there was this massive appeal of taking something really, really difficult and seeing can AI genuinely achieve this in life? What's the limit? What's the real ceiling on this thing?

31:15James Wilson: Yeah. And I think a crux of your research is sort of the foundation of your methodology, which if I understand it sort of follows a pattern of ideation, evolution, weaponization, cascade. So maybe we start there. Like, you know, we've talked about how the key here is to encode your methodology in a way that the larger language model could then leverage and access. But how did you go about doing that? What are those stages? Yes. So I made it use the methodology that I use. At the time, I didn't actually understand my own methodology anywhere near as well as I do now. I didn't realize the cascade process even existed in any kind of significant way.

31:54James Wilson: Well, that's really interesting. Can you give me a sense of what did you know about your methodology? What was version one of trying to encode this? So I've always done automation-driven research. So I knew that in my head, my methodology was basically you have an idea, you write some code to test that idea out. And then if you find something, then you weaponize it. That was the basic version. And what I didn't realize was that a substantial number of my best discoveries came from iterating on earlier discoveries from the same research process came from exploring those leads because it was all being done manually.

32:45The only you know I was relying on things like manual notes and you know you know in research you've got one goal to hack this thing or make this technique work you're probably focused on that and anything that will help you with that and you aren't tracing backwards what's the kind of crazy path that actually led you to this discovery to this lead in the first place whereas being forced to actually code the whole thing out I built I put logging in everywhere because I wanted to trace everything and understand the discovery process for everything from start to finish so I could say exactly how did this discovery happen?

33:26And that revealed that this cascade process of analysing something and finding nearby things is what fuelled a load of the best findings from this research.

33:36James Wilson: That is amazing. So now what I really want to understand is the, I guess, the form of this thing, right? We've talked sort of in the abstract of you gave it access to, I think, prior research and you encode sort of, I guess, your step-by-step technique, that state machine of ideation, evaluation, weaponization, and then along came Cascade. You've talked about how you logged everything so you could understand this, but I'm stuck at like, what were the inputs? What did you actually feed into the system and how? So the primary input was HTTP RFCs, which are just documents like old school protocol defining documents and the key thing about rfcs is the rfc is what every hp server implementation is based on so so they're a wonderful source of oh i think something's going to go wrong here someone might misinterpret this it says you must not do this, but what if someone does do it?

34:41Or it says something here that's a bit ambiguous. So what if they take this interpretation and what if they take this interpretation? So I gave it 138 RFCs and split them into tiny fragments of like one to three sentences each and used those individually to generate vectors.

35:02James Wilson: You broke it down into those individual chunks or you automated the process of taking it? No, no, yeah. So the whole thing's automated. So I ran chat GPT deep research to get a list of 138 RFCs and then just pasted that list of URLs in it. And then the system breaks it all down, analyzes it. You know, it breaks things down in slightly different ways based on what style of input it is. So you can feed in things like security research. You can feed in things like server code. but to be honest pretty much all the best vectors came from HTTP RFCs. Interesting. Okay, so this was sort of like the preparation phase.

35:44James Wilson: You took those RFCs, you had it break it down into these little chunks of smaller units that it could reason with. Then is the next step a sort of a prompt of, you know, dear agent, please go and come up with some hypotheses here, come up with some ideas. Like what's the transition from a great big chunk of RFCs and broken down components to actually starting to get, I guess, some leads or some things that you might want to go and experiment with? So it's like I give it this list of RFC URLs and I pull the lever, right? Hands off from that point onwards, right? And so it splits them down into tiny sentences and then every single pair of sentences gets given on its own to an LLM with the prompt, create a novel.

36:36I did some careful phrasing. I said, create a HTTP request in this format to trigger state machine or buffer bugs. And then I say, you must use this as inspiration and then give it the two lines from the RFC.

36:56James Wilson: Oh, interesting. So it's a very structured hypothesis generation. I grounded back to that source of truth, right? That particular part of the spec that you're testing. Exactly. And that got done about 15 ,000 times with 15 ,000 different RFC sentences. And it was told to generate multiple, multiple vectors from each sentence. So the end result, it was maybe like 50 ,000 novel vectors. And after doing some deterministic, after the system deduplicated ones that were clearly identical, it left about 30 ,000. Yeah, interesting. Okay, and just to orient ourselves here, are we now talking about the HTTP Terminator itself?

37:41James Wilson: Like I've sort of imagined that we were just talking about almost like a precursor research you were doing, because you mentioned that. No, no, no. Yeah, that's the HTTP Terminator. The precursor research is get a list of URLs and pull the lever. Yeah, okay. Because as soon as you said get the URLs and pull the lever, I thought, oh, that's the Terminator. We're pulling the lever on. Okay, cool. so it generates these uh 50 000 uh you know hypotheses you do sort of a pass through of of sifting you know the wheat from the chaff and you're left with a pretty good bevy of things to go and test does that take us into the evaluation stage of the terminator exactly yeah yeah yeah yeah how does this just to clarify it isn't me doing the past to detube it it does it of course yeah the whole thing is autonomous like that was a key point but yeah yeah yeah yeah yes Yes, as brilliant as you are, I didn't imagine you sat down to go through 50 ,000 suggestions.

38:39No, no. So anyone now, I've open sourced it. You can just give it a URL and hit the button and it will do the best. Wow.

38:48James Wilson: Okay. So they give it the URLs, they pull the lever. That goes through the ideation phase of this. Next, we move on to evaluation. I'm just sort of glancing over here to look at the original paper about HTTP terminology, but it's got this heading here about the core evaluation primitive. How does this evaluation process work? What was that primitive? So each of these HP requests that it's created is basically, it's a potential desync trigger or a potential desync vector. And the idea is that it may get interpreted differently by different web servers. So the evaluation phase is basically take every desync trigger, take all 30 ,000 and try them out on live websites to observe whether they do get interpreted differently or not.

39:43And the way it does that is deceptively simple because I engineered it over years and years of research and slowly honed it. But basically, you send a simulated victim request, which is like a completely normal request, like just asking to fetch the homepage. And you send the trigger, the desync trigger on a separate connection at the same time. And you see whether one affects the other. So if the victim request by itself just gets a consistent, normal response, but then when you start sending the trigger, suddenly starts getting a different response. that's a good sign that there's something weird happening.

40:25And it's deliberately really kind of, it doesn't have expectations about what the victim response should look like when it gets poisoned like that, because as soon as you've got expectations, you're missing out on things that don't fit your expectations and you're missing out on the best, craziest findings.

40:42James Wilson: Yeah, any deviation is valuable here, right? If you've got the control set of the victim requests working perfectly and there's any alteration or deviation whatsoever, that's pretty good pretty good signal i'm curious as to like how because this is all a bit indeterministic in terms of the the protocol interactions here like how many times you have to run this to be sure that any given one of these sort of desync triggers is truly introducing some sort of perturbation into the system or has just hasn't changed the victim request i don't know 10 times, 20 times, 100 times, how many times do you have to rerun it?

41:19James Wilson: And then what's like the variation in how many different combinations of web servers and topologies and all the rest do you put this through? Because I imagine this is pretty hard to get, it's pretty hard to get to a clear, a trustworthy, no, there's no problem here, unless you are really testing this over and over again, in many different configurations? Yeah, indeed. Great question. So with this kind of research, false positives, thinking there's an issue when there is not an issue, is a lot more harmful than a false negative at this scale. Because false positives, you get a bunch of them, they hide all the valid things, and your brain discounts the most promising things or you don't have the tokens to spend on them maybe.

42:04So the evaluation system is heavily tuned towards not getting false positives. So it's pretty cheap to run if it doesn't see anything interesting happening. But if it thinks it sees something interesting, it repeats it over and over and over and over and sends, I don't know, maybe like 500 requests to see. is there a definite valuable correlation happening here.

42:37James Wilson: And what's like the variance in the sort of test bed, I guess, that you're sending this through? Yeah, yeah. So it will do things like send the victim request by itself like 50 times back to back and ensure it always gets a consistent status code. So what that means is it will get false negatives, but the system is designed to run forever. It just keeps going and keeps going. It scans 24-7. It runs for months back to back. So eventually things surface. So that's an interesting point to this, right, in terms of like the variables involved here. You've got a system that you can run forever, continuously over and over again.

43:15You've got a very, I would imagine,

43:17James Wilson: an endless test bed out there to test on through bug bounties or authorized targets or even your own lab, et cetera. Yeah, about 30 ,000 websites is what I did most of the testing on. There's many more bug bounty sites out there, but I can't be bothered spending ages doing recon to find them. It's a pretty big scale. And as you were talking through this, I could see you and I were both struggling with the same thing, which is false negatives, false positives, and avoiding false positives and trying to get to false negatives. You get, hang on, how many double negatives have I stacked together? Have I made sense?

43:50James Wilson: So let me make sure I understand here. If the system comes up with a proposal of an interesting desync trigger, If you get a false negative, as in all the victim requests come back with no change, but there is actually something valuable in there, that's one potential bad outcome. Yeah. Is that worse than, and why would it be worse than or not, than the case, the opposite case, which is you run that desync trigger and maybe one time out of a thousand, it does actually show something different, which makes you think that, oh, I've got something here. Because I was a little lost on which one of those is actually the more materially bad outcome for you in this process.

44:35It's definitely more materially bad to think you've got something when you don't have anything.

44:41James Wilson: That's interesting. I would have thought it's the opposite way, which is that lost signal. So why? I think it comes from the scale, right? at a small scale, like when you're doing stuff manually, maybe you've got 10 ideas and you're testing those 10 ideas out. You can kind of rule some, you can kind of, if you get a false positive, you'll investigate it and you'll go, oh no, it's a false positive and you'll rule it out, right? Yeah. But when you've got 30 ,000 ones, of which maybe 100 are actually valuable, you can see how those hundred will get absolutely drowned in the noise of all the false positives.

45:28And the other thing is it kind of, a lot of the best discoveries are the things that don't make sense. They're the things you don't expect to find, right? But if you don't have confidence that your system never, ever, ever says there's something here when there's nothing there, that your system never cries wolf, then you're going to discount those because you're going to look at them and go, that's weird. I don't understand it. It's junk. It's noise. So like a tiny false positive rate is still enough to make you miss out on the best things. And those are exactly the things where probably the AI is going to struggle to kind of confirm them itself, no matter how many tokens you throw at the problem.

46:14James Wilson: Yeah, okay. That does make more sense. But the next question I was going to ask kind of dovetails into this, which is the things we've talked about so far in terms of that consuming the RFCs, doing that ideation process, and then that evaluation that we just talked about. This is all specific to HTTP desync triggers. Is there a modular element to HTTP Terminator where I could say, you know, I want to plug in a different evaluation engine? You know, maybe I want to say here's the source code for the XNU kernel. Go make a whole bunch of hypotheses about that. The evaluation module that I'm going to create for you is here's how to compile an exploit.

46:56James Wilson: Here's how to run the kernel developer kit, et cetera, on macOS. Like, is it designed with that level of modularity or am I dreaming and hoping that you're going to say yes? what i would say is so the concept the research methodology can be applied to basically anything but i think you're talking about the code and what i would say is this whole thing it's 80 000 lines it's fully vibe coded i haven't read a line of code in this system i would not take this system and try to use it for something as different as kernel research. You could probably take it and adapt it to do like webcache poisoning, something that's kind of fairly similar where you're basically sending HTTP requests and seeing what happens, right?

47:49Like that evaluation component, that's a Burp Suite extension that just runs with 2 ,000 threads, right? You don't want to be trying to use that to hack the kernel.

48:02James Wilson: Well, I mean, I'm a little bit disappointed with that answer because I had something that I really wanted to do with this. But at the same time, I'm going to take stock of the fact that you fully vibe-coded it and haven't been looking at the code. So I don't think you actually can really answer that question. It might be entirely possible that I could use this, but that's my naive hope that I'm holding out for. I think what I would say is like your system, if you understand the methodology, you can basically one-shot your system these days. So you don't need my code to quickly explore that research concept.

48:32Code is so cheap. It's just disposable these days.

48:36James Wilson: That's such a brilliant point. I'm asking you the entirely wrong question. It's not whether HTTP Terminator is modular. Even if it was, it would be almost like a fool's errand to either make it modular or to plug the modules in that I want to use. I will end up expending far more time than just saying, well, here's the methodology I want to, I want this system to leverage and operate at scale, go create it for me because I can. Absolutely. You can do that much faster. Yeah. Okay. Fascinating. All right. So we've covered ideation, we've covered evaluation, then comes the fun of weaponization. What happens after you've got this cache of triggers that have shown that perturbation in the system that, you know, you've got high confidence in them because you've really trained out or you don't get the false positives, what now?

49:25So at this point, we're looking at a specific website with a specific technique. And we've identified when we use this technique on this website, something weird happens. Basically, there's some kind of cross request contamination. And so that's not something that you can report to a bug bounty program, it's not something that you're going to get paid for. What you need is proven security impact. And there's a kind of a number of steps to take on the journey to that. The first one is mapping it to a known desync pattern like CL0 or such like, which is basically just, it's really just understanding where you need to put the payload.

50:05That's pretty much all it comes down to. And then once you know where to put the payload, which is really understanding how the two servers are interpreting the request differently. You can start to get towards impact. And in the case of the HP Terminator, I focused fully on response cube poisoning, which is the approach we were talking about earlier, where you sneak in two requests and it makes everything go out of sync, which is really nice because it's very easy to... Well, the attack type is very difficult, but it's very easy to know if you're successful because you've got other people's responses.

50:43That means you're successful.

50:45James Wilson: Yes. Yeah, the bar of success, or I guess the theory of victory here is pretty clear in that way. But also it makes me wonder, where's the line here between knowledge that you've provided at specs or other research that you've provided this versus any sort of novelty in the system's ability to weaponize this, right? There was novelty, and I guess it's extrapolation from the RFC to create those ideas and go and explore them. But now in the weaponization phase, are you looking for weaponization within a, I guess, predefined set of classes that you know about? Or do you give it free reign here to make stuff up?

51:28So the initial system was not designed to really try to do novel things in that phase. I was trying to answer the overall question of can it do this whole thing end to end autonomously uh but that said the whole thing was working in like january uh so at that point i was like well i think i've got an opportunity here to to get it doing some novel research in this area as well as coming up with novel decent triggers uh because response cue poisoning is really difficult thanks to something called the stacked response problem. So I built like a subsystem that used that it took advantage of the fact that it had these vulnerable systems to research new ways to make response cue poisoning work on targets where it did not work, basically.

52:25James Wilson: Interesting. Okay, so we've almost got like that sort of, you know, like the concept of like the, the diamond of like, so it's almost, What I'm understanding from you is there was novelty in generating the hypotheses that were then tested. And then it sort of comes down to this narrow point of, okay, all these hypotheses, I want you to test it with this reverse Q poisoning, I guess, attack class. But then expand back out from that and say, it's not just about reverse Q poisoning as you know it, but find other ways to either do the poisoning or overcome the limitations of that poisoning. Maybe just worth a little bit of an explanation of the stacked response problem there.

53:02James Wilson: Why does that prove such a challenge? Sure. Basically, response queue poisoning is about triggering two responses to what the front end thinks is a single request. And it can be really difficult to get this into an exploitable situation on some websites because the front end HTTP stack, it overreads. So it reads the first, it's expecting one response. It reads in one response and then it sneakily goes, I wonder if there's anything else to read. And it reads a little bit more and goes, oh, that's not good. Something's gone wrong with this connection. I'm going to reset the connection. And when that happens, if they were 100 % successful at doing that, then the response cue poisoning attack would be impossible.

54:03James Wilson: So you'd know that you'd triggered something but you wouldn't be able to exfiltrate the result, right? Yeah, so generally what a hacker would do is use one of the many, many other exploit routes that you can use that don't hit that issue. But I wanted this system to do response cue poisoning because it's like the most shiny thing. And I also felt like it was under-researched. Right. As well. Like, yeah. So I saw there was a research opportunity with this attack class. Yeah, interesting. And I guess these are important things for people to keep in mind. Again, this is not a system that you can just take, run, and expect to have a shower of zero days and bugs, even if you try to point it at something that is the tangent you mentioned there of like, you know, You're not going to take HTTP Terminator and turn it into a kernel panic exploit creator.

54:57James Wilson: But maybe there's something web adjacent that you could nudge that towards. But I guess where I was going with this is that there's still, and this will sort of get into an exploit around the cascade, there's still a need to be very deliberate about your, I guess, all of the parameters that you've put into this. There's a need to be deliberate about what research you're feeding into it and an assumption and belief that that research or the specs that you're passing into it give rise to vulnerabilities, some of which may not yet have been defined. There is a certain attack methodology that is known, but the choice there is, again, deliberate because you're deliberately finding something that I guess is fertile ground for there to be more, right?

55:40James Wilson: Maybe we'll just do a quick thought experiment. If you took HTTP Terminator and pointed it out, not reverse-q poisoning, but something that you had far less belief that there was more bugs to be found, what do you think would happen? if i so i considered this so i could have made it i i if if i'd said the goal of this system is to successfully hack as many websites as possible i wouldn't have get it i wouldn't have focused it on response queue poisoning i would have got it using well-known techniques like using prefixes to hijack JavaScript loads with redirects to my server, for example. And really, it only does research where your harness and methodology push it to do so.

56:35So I don't think I wouldn't have high confidence. Also, it's just really bad at request smuggling, exploitation. Like prior to me, the harness is way more. The weaponization harness is a lot more complex than I wanted it to be. I thought, you know, oh, these models are pretty smart. I've seen them write powerful code. I'll just tell the model, here's your vector. Get me response to poisoning on this target. Right. If I did that to like a competent human, they could do it. It's not that hard, except on the sites where it's impossible. But it's not that hard on a whole bunch of sites. Right. but the model really struggled so for me the model is a very very long way from like actually doing something novel without the harness to guide it and then if it did how would you know if it was novel or not are you relying on it telling you that it thinks it's done something novel like that you're going to have a bad time if you do that

57:37James Wilson: yeah well again this comes back to just being very clear about what we mean about novel right I think that was a great example of like you could have given HTTP Terminator the goal of go and hack the whole planet and compromise as many websites as possible. That would have used well-established techniques like the JavaScript method you just mentioned. But that's not novel research. That's just a demonstration of scale. And, you know, we know what these things can do in terms of scale and machine and, you know, operating machine speed. So the novelty comes from the combination of your knowledge that there is both unexplored potential for unexplored territory.

58:14James Wilson: There is potential for more bugs to come out of this. But, you know, to your point, what's that old quote? Anything sufficiently advanced, any technology that is sufficiently advanced is indistinguishable from magic. And I think you could also say on the flip side of that, anyone that is not sufficiently advanced in their own understanding of the subject matter is going to find virtually any finding novel, right? Anything mildly interesting is going to look novel. You've got to understand the subject matter really well to be able to understand what is truly novel. Would you agree? Absolutely. And no matter how good you are, reviewing something to identify if it's novel has a cost, has a human cost to it.

58:57So the last thing you want is a system that claims something is novel when it's not. Yeah. That's why if you look at the HB Terminator, the only systems that kind of declare any kind of novelty are doing so with a whole load of evidence coming from deterministic processes. There's AI inputs to them, but there's deterministic processes that validate it.

59:22James Wilson: interesting interesting okay yes i can definitely relate to that experience the as you know when i started off my little side project journey of security vulnerability research i um it was a couple of like really bad weeks actually of of not sleeping well and i realized it was because i was getting so excited every time one of these models would say we found something we found and then you only only to sort of really prompt it and then be like okay but what about this okay but what about that and then you know kind of goes oh you're absolutely right you know there is no way that this can actually be reached by you know whatever right so so i get it there is there's almost like there's been inbuilt characteristic of the model to want to celebrate and tell you that that something is novel when when it's not which requires your expertise now that leads me into um you mentioned this at the start of the interview which is you you thought the process here was ideate evaluate and weaponize because that's what your I guess, original understanding of what your methodology was.

1:00:21James Wilson: Yes. You then had to add in Cascade. So talk me through this. What is Cascade and why did it become such a pivotal, valuable thing in this HTTP Terminator workflow? So the Cascade is basically just analyzing each discovery to try and see, to try and discover two things. One thing you want to find out is if this finding, this discovery happened kind of by accident, which is often the case for the best stuff, the coolest stuff, then how can you improve the system to detect that sort of thing more reliably? Right. Make more happy accidents. Exactly. And the other one is quite different. it's analyzing the finding and going what's the root cause like how far how far back can you trace this this vulnerability all the way back to maybe uh a flaw in the mental model of the developer that wrote the code and then go okay well this is the flaw in their mental model may maybe possibly if i had that flawed mental model when i was writing this code what are the mistakes would I make?

1:01:42And what other vulnerabilities would I create? And those will often be different attack classes. And if one developer's got a flawed mental model, other developers are going to have the same issue. So they may well be different attack classes affecting completely different targets. And those two things, they're like chasing the breadcrumbs, right uh yeah to to the to the craziest findings but what what does the okay so i mean i i love

1:02:11James Wilson: this um what what does this actually look like in terms of implementation have you created a bunch of different prompts that say hey what other things might be like this or what was what is the mental model here that would have given rise to this what does this tell us about the quality of implementation like what you said there is so amazing but i want to bring it back to how? What does this actually look like in the implementation? So initially, because I completely underestimated how important this process is, it was only happening manually. So I was reviewing the novel stuff that it found.

1:02:46And every now and again, it would do something crazy. Like it found like a kind of server memory leak buffering issue that just happened to change the status code. And I went, oh, we're triggering loads of memory leaks. Well, I guess that makes sense because we're sending 30 ,000 really weird HTTP requests. So I'm going to add in a little bit of code into the evaluation harness that looks at every response and says, is this a potential memory leak? So in that case, it's basically a regex and it looks for a weird blend of text and binary data in the response. If it's predominantly text, but there's some like randomly changing binary, that's pretty suspicious.

1:03:31And adding that in found some more memory leaks, but then it also found some even crazier behavior on a different site. And so that was another finding. And then analyzing that led to another change in another finding and so on, which led to a lovely desync zero day in Apache traffic server, which exposed a load of websites that used to pay really good bug bounties but don't anymore uh and so this was happening manually and because i was still tracing everything like uh i could see oh right like this best one of the most valuable decent findings only came out from me analyzing a weird memory leak and that's what made me realize oh okay i i need to automate this if i automate this it's going to make the whole system a lot more powerful.

1:04:21So then I built another research subsystem that looks at every single confirmed finding and it asks those two questions.

1:04:28James Wilson: How do you store the results of this such that it continues to, I guess, build a set of knowledge or artifacts that it continues to learn from? Like I'm almost imagining you'd need or could this benefit from it? It's almost like a graph database of, you know, we learned this, that led to this, that led to this. Now either trace the vertices and the edges back or push them forward? What else can you find along this path? So the whole trace and float, everything is stored in the database somewhere. I also saved every full LLM trace of every stage. So I've got over 50 gigabytes of LLM traces just floating around on the disk.

1:05:11James Wilson: I've got a few open weight frontier labs that might be interested. oh dear yeah i can't share those but uh but so the this system had two kinds of output one output was novel desync triggers which just get fed straight back into the evaluation system and tried on live websites and the other key output is uh markdown files from my consumption which describe things it thinks are novel ideas that don't fit into the desync space they're not novel desync vectors so it's unable to evaluate them itself so then i have to manually review them right and even though it's not like the model even the best models available i would say i think i them a score of like four out of ten on how good they are at this asking this question yeah uh reviewing those still led to probably the most significant finding of the entire research it's a really interesting point i've noticed the same that models still you know i've talked before about how they just have this inbuilt bias to want to be done but there's there's another property emerging from them that i'm noticing which is they so quickly get um blindfold not blindfolded but they get these blinkers on and they just doggedly follow one sort of, I guess, linear path to the goal that they think they were.

1:06:39James Wilson: I mean, a classic today was I've been looking at this bug that, you know, I've been looking at it for about a week or two now, just with models, right? Because I'm at the lazy stage. I don't have a huge amount of hours in the day to be doing this. So it's more like just early in the morning, late at night, come on model, where are we at? What are we doing? But to my surprise, I said to it today, you know, it had gotten to the point of telling me about five times over, James, there is not a bug here. There is not a vulnerability. And I say, there must be, there must be. But I said to it, what happens if you do the steps you've been doing to elicit the crash, but do it in a way where it doesn't crash?

1:07:12James Wilson: Isn't it useful that we've manipulated the memory and not crashed? And it was like the model just went, oh my God, I hadn't considered that possibility. And it opened its eyes and it was like, yes, let me rerun all of these assessments without crashing. This is amazing. The operator has an incredible idea. But it's just, it's a proof point of like how models are great but they're not particularly good at taking a step back and just thinking through what led them to where they got to and and pivoting and forking and branching their thinking that still feels like that's the value of the human and i wanted to quote one section from your exact summary here because i think it just it is a beautiful encapsulation of so much what you learned which is um the system's true power is unlocked by putting a researcher back in exactly one point, the discovery cascade, where each finding becomes the seed for the next.

1:08:00James Wilson: This yielded multiple significant discoveries, including a genuinely new class of vulnerability I call the shared parser confusion. So on one hand, this should be very heartwarming for all security researchers because it shows that you've absolutely still got a role in here. My question to you, though, as we sort of get out of the experiment and start to think about what comes next is but is that a gap that the models will close or is this a fundamental thing that they can't close does this role of the human in this point or in some point of the process only increase over time because it needs to the importance will grow with model capabilities that perhaps don't and can't provide this level of augmentation like what's your sense of you know Take that statement I just read to you, your own words there.

1:08:48James Wilson: How long does that stack up? I don't like to make long-term predictions these days. Although, to be honest, I never have. No, looking at where it is, there's multiple different reasons why having a human in the cascade adds a lot of value. So I would think there's a, if you're talking about an expert, especially uh i think you've got at least a couple of years there probably yeah uh where where the system is more powerful with the human there because one aspect is like the model was just i mean i evaluate yeah i evaluate its performance there as four out of ten it's with the best model i've got access to right like it just it just kind of doesn't get it and that's something that i expect to change relatively quickly you know models are getting better pretty fast uh so maybe in a year maybe in six months they'll be able to perform as long as you've got something without any safeguards stopping it right but on the but the other thing is well these are these are ideas the ones that are not in the desync space or the ones that are around detection, there's no architecture to evaluate them automatically.

1:10:13So you've gone from this territory of like the desync trigger generation is like under 1 % of the desync triggers generated are valuable, right? Wow. Yeah. And even as a human, if I were to manually read the 30 ,000, I couldn't tell you, you know i could probably delete 80 but of the other 20 i couldn't tell you which ones are going to work or not so yeah so you see there's this whole big architectural reason where you need a human to be able to actually accurately evaluate these things as as well or if it's a change to the anomaly detection system to kind of detect more of something weird again like you you need the architectural change to be able to support trying out arbitrary anomaly patterns without the entire system blowing up yeah and so on uh and also this entire system the whole of the hp terminator not only is it personal code because it's horrific but it's also like it's my exact methodology right so if you got a different decent researcher to build a system it would find different issues because it would be an encoding of their personal methodology.

1:11:38So there's a load and load of work to be done building these kinds of systems. And also I picked request smuggling partly because it was the area where I saw the clearest path to success. I was like, this is a high-risk topic. I'm going to pick something where I have the most confidence that if it's possible, I can pull it off. Right. Other areas, it's harder to build this kind of system. It's harder to get that automated evaluation loop that's absolutely critical for a system like this to work. So once you factor in all of all of those things, I think research is going to be pretty, pretty busy for the next five years, at least.

1:12:19James Wilson: I very much like the picture that you painted there. And I'd add one more element that has been something I've been thinking about, which is asking the question of how long is a researcher going to be valuable here assumes that the model continues to advance and the researcher does not. And I think that is like patently false as an assumption, right? I think there is a very real trajectory here where, again, let's take stock of the fact that yes, you've proven that AI can do novel security research and not discounting that novelty but the the what enabled that novelty was deliberate decisions you made at various points along the way and your if your ability to make those decisions to find the fertile areas to go and explore to know how to to create that cascade loop if that just increases and gets better and better through your experience with creating things like this and exploring like you know if we can continue to do that as researchers then surely as the models capabilities increase they might close off the things that we had to do manually somewhere, but there'll only be more and more things that we can do as long as we as research continue our knowledge and experience and experimentation as well.

1:13:24James Wilson: Does that ring true to you or am I two rose-colored glasses? No, I think that's pretty much right. So, I mean, what I can definitely talk about accurately is right now. And I can say right now, researchers can deliver more value than they, more rapidly than they ever have been able to in the past uh it used to be you know on on portsmouth research with full-time researchers that used to be a massive advantage over everybody else that's getting like at most 20 research time and now it really like it really feels like that advantage is gone because because in your 20 time you can do so much so fast you can do things that previously would have taken us a year to do manually.

1:14:11James Wilson: Right, which is a great segue into as we wrap this up. James Kettle, what's next? Where do you go from here? Well, I can tell you one thing. I'm definitely not going to do another Black Hat presentation on HP desync attacks. That was my fifth presentation on that topic and I'm so done with it. I'm going to hand it over to someone else. Let's play devil's advocate here. You find something amazing. How amazing would it have to be to make you say, okay, talk number six coming up? I have some ideas. So I think right now, because research is so easy, you need to pick something that's ridiculously ambitious.

1:14:56You need to pick something that everyone thinks is impossible. And that's what I'm going to try and do. yeah obviously at this stage well it might be impossible so we'll see what happens but if it's not impossible it's going to be a very very good year and look I'm being cheeky

1:15:18James Wilson: asking can you give us any sense of what the the arena of that impossibility is that you're looking at because this whole thing began with literally I think it was in the document the very opening of your research was something like you know actually no it wasn't that you thought it was impossible. You said it sounded like this sounded like it was a really bad idea. So I did it. So can we get any flavor of what this impossibility is that you've now got in your in your sights? I guess all I can say is so because research is so easy now, you can do so much so fast. And I need to come up with something that will not get done and published by anyone else before August next year, right?

1:16:01So it's like, it's like something that I would say, with you, with the current models, you can't do it. But not only that, but it's the, I need to try the kind of thing that no one would try.

1:16:14James Wilson: Right. Right. Because they would just be like, it's not going to work. Interesting. Okay, listen, I won't try to press you any further on getting exactly what it is. That's as much as you're going to get. Yeah, I very much get that impression. But suffice to say, and I think I even said this to you last time we caught up, I am equal parts excited and terrified by the fact that you are going to explore something that is so impossible, because no doubt what you find out of this will be incredible. And hopefully it's the next time we catch up is to talk about exactly what the results from that is.

1:16:46James Wilson: But until then, James Kettle, Director of Research at Portsmouth, mate, it is an absolute privilege and an honor that you would spend the time to talk to talk to me about all this stuff thank you very very much and now just lastly has this already been open source is it already out there where can folks find all about this hdv terminator work uh you can find the whole thing linked from portswigger.net slash research uh and yeah the entire thing is is open source and there's a white paper out there. Yeah. Enjoy. Have at it. All right, mate, we'll wrap it up there. Again, thank you so much. Thanks.