Episode 157: Crushing Pwn2Own & H1 with Kernel Driver Exploits

Title: Transcript - Fri, 16 Jan 2026 05:05:05 GMT
Date: Fri, 16 Jan 2026 05:05:05 GMT, Duration: [01:35:00.49]
[00:00:01.04] - Justin Gardner
Our bug bounty budget has been exhausted and I am going to assume that that's primarily because of the bugs that I submitted, because it was like 20 within the course of a couple months.

[00:00:18.80] - Justin Gardner
The best part of hacking, when you.

[00:00:20.39] - Hypr
Can just, you know, critical.

[00:00:29.30] - Justin Gardner
Yeah, soon. Packers. Just wanted to remind you that we're running the Crit Research lab over at Lab CTB show and in that lab we are accepting research submissions from you guys, the listeners. Okay? So if you've got a cool little piece of micro research, couple paragraphs, whatever, or if you've done like mega research but 5k words plus and you want to submit it, you can always submit it through the submission form at Lab CTPB show and we'll review it and pay you out a nice little stipend for your research if we host it on the research page. And of course we'll cover it on the pod. So to give you some extra distribution as well, we'd love to see more submissions from you guys. We've had some great ones so far. I've really been enjoying it. All right, let's go back to the show. Hackers. Welcome to the this Week in Bug Bounty segment. We've got some rapid fire news for you. First up is CVE2025 13467, which is a vulnerability discovered by some. Yes, we hack researchers actually I care and truff on a scope we've talked about on the POD Keycloak. Right. This is an authenticated Java deserialization via malicious LDAP server. So pretty sick bug. I think the keycloak scope is pretty awesome, so definitely check that out. GitHub.com/keycloak/key keycloak to get the source code there and do some source code audit. Up next, of course, and the big one for this week is James Kettle has opened the nominations for top 10 web hacking techniques of 2025. Go ahead and submit your favorite research. There's already an amazing list of research here within just a couple days. So one, this is a good reading list. And two, if you've got, you know, a favorite researcher, favorite research from 2025, this could be the place to drop it. Definitely a lot of really, really good bugs in here, including some from yours truly over at the Critical Thinking Research lab. So definitely submit your favorite research here. All right, with that, let's get to the show. All right, thank you for joining us everybody. This is my boy, Enrique. Hyper dude. And the reason why I hit him up for this podcast is because you look at his profile and. And he has a ton of hacker1 experience and pwn to own experience. Right. And that overlap is kind of crazy. So, Enrique, thanks for coming on in the pod today, dude, thank you so.

[00:02:59.47] - Hypr
Much for having me. I really love you guys show and happy to be here.

[00:03:02.68] - Justin Gardner
Thanks, man. I love. I'd love to hear that. That warms the heart. Whenever I see any like, you know, high quality hackers, you know, that are just, you know, watching the show and enjoying the content that, that really is, is fulfilling.

[00:03:14.90] - Hypr
Yeah, there's definitely not enough content for that market, so anybody doing that stuff is really great.

[00:03:21.37] - Justin Gardner
I appreciate that, man. All right, we got a ton to cover with you today. Thank you so much for the content you put out for the community. First, of course, we've got to put you through the CTBB wringer and ask you to share about a bug. And if I'm correct, the bug you want to share about is one of the ones that you mentioned or you wrote up on your blog. And this is CVE 2025, 2742, which is a heap overflow in the MediaTek kernel drivers. Is that right? Yes. Yeah. All right, awesome. Let me go ahead and share my screen here for the listeners and then we'll let you get to your explanation. Cool.

[00:03:59.99] - Hypr
So I guess just to start off, to give it a little bit of context, the MediaTek Wi Fi drivers have like a big, pretty complicated ioctal interface stuff for management and configuration. And there's a lot of things that are connected to userland daemons so that management of WI FI stuff can be done from userland into the kernel stuff. But yeah, this is a relatively straightforward heap overflow. At a really simple level, what happens is you initiate an ioctl, you send a structured data, a piece of structured data that includes fields that one of them is a pointer, another is a size indicator. Within this structure, the structure is received on the kernel side, it gets parsed, and there's a point in time where data gets copied in from the structure that got sent in from user space into a kernel structure so that it can be stored for further use in some of the configuration stuff. But really it comes down to the fact that one of the fields in that structure is a size field, and during the parsing and copying over of the data, that size field gets used to determine how much data needs to be copied out of one of the embedded buffers. As is usually the case with these issues, there is a lack of bounds checking on that size. So it becomes possible to provide more data than the Buffer can actually hold. One of the interesting things about the bug is that the size field that gets used without bounds checking here is a char type. So maximum value is 255, which can make exploitation a bit harder. You know, you can't just like kind of write forever until you find something interesting. But yeah, so a lot went into trying to figure out what was going on with the exploit and kind of. Or what was going on with the bug. Um, and kind of a part of all of this that had a big effect on the process was just the fact that the device that I had that was running the drivers and that had the like, chipset is just like some random Netgear router where like, I didn't have any kind of debugging capabilities or really much of anything.

[00:06:19.20] - Justin Gardner
Oh my God, you're doing this blind. Are you kidding me?

[00:06:23.12] - Hypr
Mostly, yeah. And also just anybody who's done stuff like that knows that, you know, not having a VM specifically for kernel stuff is really painful because the moment you crash the kernel, you have to go through another full reboot and go through all of that. The iteration speed is a bit slow, but yeah, ultimately I really just wanted to get one full exploit out of all these bugs since they had kind of stacked up on me and this ended up being just the most feasible. I kind of. Yeah, it's a bit funny, we can talk about it if you want, but like, at some point I had built up maybe 10 or 15 of these bugs, but hadn't written like an actual exploit. But I kind of saw an opportunity in the fact that it's like, okay, like I've got a lot of primitives to start with. There's like a lot of bugs that offer a lot of primitives to do stuff. And so I kind of took it as like a, an opportunity to kind of just like, say, okay, here's all I have. Here are all the primitives and then just sitting down and going, what, what can I do?

[00:07:26.73] - Justin Gardner
How do I.

[00:07:27.44] - Hypr
With these primitives, you know?

[00:07:28.73] - Justin Gardner
Yeah, that's super interesting actually, because, you know, one of the things that we talk about on the POD all the time is in the web world, right? Which is where we live is, you know, client side hacking versus server side hacking, right? And for us in the bug bounty black box environment, a lot of times server side hacking, you know, certainly it can be more, more complex where you're, you're trying to guess what's going on in the back end and stuff like that, but you don't have a lot of source code. And you don't see a lot of chaining in server side bugs, whereas in client side, one of the things I love the most is chaining. Right, yeah. Taking this XSS and then cookie bombing this and then, you know, leaking this, you know, all of that sort of thing. And actually you can kind of see this here in this environment as well. Like, how do I take these various primitives that I've done from this, you know, source code review or binary exploitation here and build a functional exploit with it? That's exciting.

[00:08:22.16] - Hypr
Yeah, yeah. Honestly, that's my favorite part of a lot of the hacking stuff is getting to that point. Right. Like, I like to think about it. Like, it's really like having a palette.

[00:08:32.24] - Justin Gardner
Right.

[00:08:32.55] - Hypr
Like being a painter and having a palette of colors that you have available and then getting creative to see how far you can kind of push the limited amount of control that you get.

[00:08:43.52] - Justin Gardner
Yeah, very nice, man. So you've got the heap overflow here, and then we can see the screenshot down below here where you actually start getting a shell. Can you give us anything about that? I know at the end of the blog post here you say, hey, there's another blog post coming, but can you tease that a little bit here?

[00:09:00.64] - Hypr
Yeah, yeah, no, totally. So, yeah, like I said, there was a bunch of bugs, and so I kind of was just going through them and trying to figure out which one to go after. Ultimately, I ended up choosing this one for a couple of reasons, but one of them just being the fact that the IOCTL handler could be reached without any authentication. So there are certain parts of the driver that did seem to be enforcing authorization checks and permission stuff, but there was also a lot that weren't. So this. I had started writing an exploit for some different one, but it had the kind of requirement that you had to have some level of permissions.

[00:09:39.54] - Justin Gardner
Okay, so let me ask. Let me pause you there and just ask a question about how this works, because I've never done any kernel driver exploitation here. So when you're saying it can be reached without any exploitation, are we thinking about this largely from the local privilege escalation perspective on that machine where you've got a user 0 permissions, can't do anything, Right? Yeah, but it can write to this handler and then it can use this to escalate privileges. Is that where we're at?

[00:10:07.79] - Hypr
Yeah, yeah, yeah. So like the ioctal stuff, it's funny too. I'll tell you this, right from the get go, a lot of this stuff is very new to Me also, I've looked into kernel stuff before, but this experience over the last couple of years was like my biggest dive into it. But yeah, in terms of like, ioctal. Right. I don't know whether that word or that phrase is going to mean anything to a lot of people, but yeah, it's basically an API in the Linux kernel. It's most mostly deprecated now, or as far as I know, it's not used a lot now. And I think it's partially because of all of these problems. But at a really fundamental level, it's just an API for user space to be able to interact and send messages or signals to things in the kernel, particularly like drivers and stuff. So it was really just like a primitive interface to interact with drivers from user space.

[00:10:56.74] - Justin Gardner
That's so sick, dude. Yeah, I mean, as soon as you say that it's an API for this, I'm like, oh my gosh, this sounds like amazing scope.

[00:11:04.04] - Hypr
Yeah. And I mean, I haven't looked enough, I haven't looked into this enough. But I think in a lot of maybe more modern kernel versions, the enforcement of just being able to issue the ioctl syscall is a lot stricter and you usually just can't do it as a fully unprivileged user. But one of the benefits of IoT in a lot of ways is that you do run into older kernels, older like code and stuff. So some of that is helpful.

[00:11:33.65] - Justin Gardner
Nice. Very good, man. Okay, so that's awesome scope.

[00:11:38.22] - Hypr
Yeah, go ahead. Yeah, just kind of wrap up on that or give a little bit more detail. So the, the, the, the, the handler is reachable locally and it's called. Ultimately, I ended up kind of going with this bug because it gave me a really easy way to do the final exploit is a corruption of a free list pointer in the kernel, like in the slab that has all the stuff for this particular size of allocation. So there's a lot of context there with what all of that means a bit. But basically just, it's a lot like, if anyone familiar with userland heap stuff, right, There's a linked list of pointers that point at the free chunks that are available. So the exploit really just relies on being able to write slightly out of bounds, which, going slightly out of bounds of the chunk that you're in, you immediately hit the metadata part of the next chunk. And yeah, if it's a free chunk, you essentially just get an arbitrary allocation back where the field that has the pointer that's supposed to be the next free chunk you override it with some other address that you want and then some subsequent allocation that then goes to pull that chunk, gives you the address of whatever, you know, whatever, whatever you overwrote it with.

[00:13:00.29] - Justin Gardner
Sure, sure. Okay, yeah. And, and how does that get all the way to the end there then?

[00:13:06.53] - Hypr
Yeah, so from there there's kind of a lot of approaches that you can go once you've got a little bit of this going. But ultimately. Right, the goal is to get a shell. At least for me, with anything like this, the goal is to get a shell and to, like, escalate privileges. So a really classic technique for this stuff is modifying the mod probe path. So there's a variable, like a global variable in the kernel that is called modprobe path. So anybody familiar with Linux knows that modprobe is like a binary that's used from user space to load kernel drivers at runtime.

[00:13:46.11] - Justin Gardner
Right, Okay, I see where we're going now.

[00:13:48.86] - Hypr
Yeah, yeah. So the kernel keeps this variable that has this string path to where the binary is supposed to be in user space. So generally once you get arbitrary write in the kernel, a really straightforward thing to do is to just go overwrite that string so that you point it at some other binary that you control or that you've dropped onto the system. And then the final part of that chain is basically that the reason that the kernel keeps this path is that at different points it wants to be able to dynamically load drivers when it detects that it doesn't have support for something. And commonly the thing that gets talked about a lot with this attack type is execution handlers. When you go to execute something and it's not an elf or not executable as an elf, the way that the kernel expects, there's a process in the kernel that will try to determine whether it can load some kind of kernel driver that has that level of support. So it'll go through this process of invoking that mod probe binary to try to do all of that. So once you've got that overwritten, you kind of just go with like a fake binary with trash in it, or just a fake file with trash in it, and you try to execute it directly to force the kernel to then go use the path that you've overwritten, and ultimately through there, you eventually end up with a shell. You get some level of execution.

[00:15:14.55] - Justin Gardner
That's beautiful. I did not know about that trick. I mean, obviously because I haven't done any kernel driver exploitation, but that, I mean, that seems like a really nice way to get all the way to the end to an actual shell. That's sick, dude. Well done.

[00:15:28.00] - Hypr
Yeah. Honestly. Anybody?

[00:15:30.15] - Justin Gardner
Applause here.

[00:15:31.44] - Hypr
Thank you. Thank you. Yeah, with, with any of this kind of stuff, especially in the kernel, the biggest challenge once you've got a bug and once you've kind of like gone through exploitation is you can get all the way to like 80. But the thing is, what you're doing is really messed up, right? You're in the kernel, you've corrupted memory and you're doing all kinds of crazy stuff in the kernel, which is the thing that's running the entire os, right? So if something ends up in a bad state or if you just don't, one of the big things is just basically the context stuff, right? Like the kernel operates in an entirely different context, which doesn't really have the same concept of like user space that you do. So like executing a binary, for example, is not straightforward. If you're trying to do it outside of one of these mechanisms like the mod probe passing, it's very much not straightforward because you cannot just start execution of a user and binary from within the kernel without a lot of memory mapping stuff happening and a lot of complex stuff. It gets very difficult. The mod probe pathing is the shortest way to short circuit a lot of those issues and get to directly executing some user land piece of code without having to deal with a lot of the other noise.

[00:16:48.62] - Justin Gardner
Wow, dude, very nice. That is good context for us. I did not know that. And that actually shines a little light on this scope actually being pretty challenging because one of the things that I was going to ask you about this was it looks like you have access to the source code for these drivers, right? This is released stuff. Yeah. Or no, the source code, as far.

[00:17:12.74] - Hypr
As I know, is not supposed to be released stuff, so.

[00:17:16.75] - Justin Gardner
Yes. So what we're looking at here is this is reverse engineered from the binary or what is this source code in your write up?

[00:17:26.26] - Hypr
The source code that's in the write up are reproductions of the bug as they actually exist in the code. I mean, it's really not a secret, so I don't really mind talking about it. There are places online, if you look around where if you know what to look for and stuff, you can find leaks of the source code.

[00:17:44.82] - Justin Gardner
Yeah, okay, that makes sense. Yeah. And I was, I was kind of. I did that before this episode. So I was, I was kind of like, oh, look, it's the source code. Like that's super helpful, you know, And I think that this is one of the things that is kind of tricky, right, with. With like, you know, some Iot assessments where you just get. You pull a binary off the device and now you're like, okay, I've got to, like, emulate it and like, you know, hook up the debugger and actually like reverse engineer this binary and Ghidra or whatever. But this is a little bit nicer where you actually have the C source code and you can kind of look through it. But then on the flip side of that, you've got. Okay, well, I've got to deal with this kernel land execution stuff versus user land, and that adds a bunch of complicating factors to the exploitation, it sounds like.

[00:18:32.35] - Hypr
Yeah, yeah. So the code helps a lot. And frankly, I'm. I can do some reverse engineering. I'm familiar enough with like x86 and arm and stuff to do a bit of it, but I don't like it forever already.

[00:18:47.51] - Justin Gardner
Like, imagine doing this with just the binary, you know.

[00:18:51.92] - Hypr
Yeah, exactly, exactly. So some level of help there is always good.

[00:18:57.03] - Justin Gardner
Very cool. Okay, so two questions based off of what you just asked, I am going to. Yeah, I guess we'll just jump right into the content because I did give you a little bit of an intro before. I know, I know. Do you have anything else you want me to include in the intro? I know you have a website that is coffinsack, right?

[00:19:13.94] - Hypr
Yes. Blog.coffins.com.

[00:19:16.33] - Justin Gardner
Okay, awesome. Yeah. So Coffin Sec and, you know, doing Pone to Own. Doing Hacker one. Yeah. Very, very impressive resume. So with that, we'll jump into the actual questions here that I have about your bug. One thing that was really interesting, that stood out from that explanation, man, was that you said you didn't have an emulation environment in a debugger setup. Okay, so additional context on Enrique's background here. He's a member of Summoning Team, Right. And he's the second member of Summoning Team we have had on the pod. Right. Sina also came on the podcast a while back, and one of the things he stressed in his episode was you gotta freaking put in the time and get a debugger's head. So when you come like. He spent a very long time on the episode explaining how essential that is. So for you to come in here and say, yeah, I just yeeted it out there, you know, restarted my router 57 million times.

[00:20:11.75] - Hypr
Yeah.

[00:20:12.78] - Justin Gardner
I'm curious, you know, if you agree at a fundamental level or disagree with Sina at a fundamental level about that or was it just the way you decided to do it. In this specific scenario, yeah.

[00:20:26.71] - Hypr
So very, very much, 100% agree with Sina's. Take 10 out of 10 times. I'd rather have a full debugger and environment for all of that because it makes the process a lot easier. And especially when it comes to any kind of binary exploitation, everything's happening in memory, everything's fully abstracted away from you, and there's a lot of other stuff kind of happening at the same time that is just not really on your mind. So having the ability to actually inspect what's happening, to catch different things that might influence your ability to complete the exploit and stuff, fully always useful. So I would always go that route if I can.

[00:21:04.78] - Justin Gardner
But why didn't you?

[00:21:06.54] - Hypr
Yeah. So IOT is a bit of a complicated beast most times, right. On an IoT device, if you're doing user space stuff, it's not too hard to statically compile GDB for ARM or whatever and then drop that binary and then you have an actual debugger for the kernel that is a lot more complicated. So there are ways.

[00:21:29.93] - Justin Gardner
Oh, shit. Yeah. No. Oh my gosh, I totally didn't even think about that. How the heck do you even do that with a kernel? What the frick?

[00:21:38.21] - Hypr
Yeah, so the thing that a lot of people that you'll see mentioned a lot, but I've never actually done and just. Yeah, it's never actually presented itself as an option to me, is jtag. So that's like a hardware interface kind of directly on the board where you can connect to specific pins and ultimately control the entire cpu and through that get a real kernel debugging environment. But those pins aren't always exposed, especially on devices that have already been shipped out for consumer use and stuff. You won't always find that. And I just have never gotten around to actually trying it out. But yeah, in this particular case, it just happened to be that I found kernel bugs and the Netgear device that I had. Right. Like, IOT is complicated also because you can think like, oh, okay, you know what? This is a Linux kernel. I can go get the same version of the Linux kernel, compile it, and then install it. Except when you get to the install it part, the mechanism to do that is not really super straightforward. And most times will actually require either finding an interface on the device that will allow you to do that, which isn't like guaranteed or like full on hooking into the Flash chip and trying to overwrite the segment of memory that has the kernel image with your own. So that gets very complicated and I feel like there you also start going into the territory of potentially bricking the devices.

[00:23:10.56] - Justin Gardner
Yeah. And all of this is now crossing into the hardware hacking realm, like hooking up jtag, flashing these chips. Geez.

[00:23:20.15] - Hypr
Yeah. So the choice to go blind was really just a matter of necessity or a matter of, you know, saying I want to have an exploit written for one of these bugs and ultimately I'm not going to be able to get a debugger here, so I'm either going to have to figure something out or just like let it go. And I didn't want to let it go.

[00:23:38.86] - Justin Gardner
Wow, dude, that's freaking sick. So I'm just trying to, I came trying to wrap my head around how you even did this like, with, with, without, like how did you craft this, this full exploit without knowing, being able to see, you know, I don't know man, that's just some crazy shit. Like there's not really a real question in that. I'm just like, yeah, sure, do you have any tips on how to do that without a debugger?

[00:24:04.64] - Hypr
I mean, honestly, like a lot of the time that I spent during trying to figure out the exploit and all that stuff was reading write ups and reading kernel source code.

[00:24:16.93] - Justin Gardner
Right.

[00:24:18.28] - Hypr
Because if you think about it in this kind of setup, you have to think about what can I get or what do I have available to try to determine what's happening and crashes or stack traces and all that stuff. It's somewhat useful and if that's all you have, that's all you're really going to get. So you have to just try to make do with it. But yeah, very much so. It's 90% of the time computers are deterministic, very deterministic, and if you understand what the code is and what's happening and generally what the functionality is, you can guess closely enough what's going on and then it's really just trial and error. It's send 10,000 bytes, see what happens, send 6,000 bytes, see what happens, and then restart it.

[00:25:07.55] - Justin Gardner
Every time though?

[00:25:09.67] - Hypr
Yeah, most times, most. Sometimes you get lucky and you get like a kernel oops, that doesn't actually fully reboot the system and it can recover. But yeah, that part was honestly my least favorite part of the entire thing, was just having to do that over and over and over again.

[00:25:23.99] - Justin Gardner
Oh my God, dude. I am kind of in awe, to be honest, of what that must have taken as far as mapping out, like reading the kernel source code, mapping stuff out in your brain, you know, figuring out where stuff maps onto the Actual, like, device and then doing all of that blind, without introspection with only stack traces and. Wow.

[00:25:46.72] - Hypr
Yeah. Honestly, like, yeah, it's, it's.

[00:25:50.96] - Justin Gardner
It.

[00:25:52.07] - Hypr
And we can talk about this a little bit more. But, like, I think this is one of the things or a case where I kind of. I feel like it's a strong argument for the, like, saying, you know, practicing with real world bugs will give you a certain amount of, like, experience or insight that you don't always necessarily get with, like, things like CTFs or things that are kind of constructed with the idea that there is a solution already, kind of a predetermined solution that you can take and these kinds of challenges. Right. Because throughout all of this, like, yeah, it was my first time looking into the kernel and kernel related stuff, but, you know, I kind of was forced to really conceptually understand, like, the model of what's happening to try to predict.

[00:26:37.75] - Justin Gardner
And like, you know, talk about trial by fire, dude. Oh, my God.

[00:26:41.59] - Hypr
Yeah, yeah, so, but great, great learning experience, honestly, because really, it solidifies it very. You know, you internalize it a lot more because you've observed a thousand or ten thousand iterations of how behavior changes slightly between different things.

[00:26:59.05] - Justin Gardner
Oh, my gosh. This might be one of the more awestrucking moments of the pod, to be honest. That's interesting. Okay, so without harping on that too much, I definitely do want to swing back around to the reproducing real world bugs and actually hacking versus ZTF and that whole thing. So we will pop back to that. But I do like how that correlates in here. The next question that I had was, how did you land on this octal stuff or ioctal. Am I pronouncing it right?

[00:27:28.69] - Hypr
Yeah, Ioctl. Yeah, yeah.

[00:27:30.69] - Justin Gardner
How did you land on that as far as the scope that you wanted to go after for these drivers?

[00:27:36.69] - Hypr
Yeah, that actually is a bit of a funny story or an interesting story. So a little bit of background on kind of everything that led up to this a few years ago or maybe two or three years ago, you know, when I was already doing a bit of this stuff. And so I had a kind of a habit of picking up random routers on Amazon and just kind of holding onto them and seeing whenever I had time or, you know, whatever. So I ended up picking up this Netgear router over the course of a year or so. I kind of kept coming back to it, doing some stuff. And at some point I found a bug that was from. I think it was in 2023. It's also on my blog, but it's in a user land daemon that's part of the media tag SDK.

[00:28:21.17] - Justin Gardner
Was this the wpa? Yes. The wap? Yeah, yeah, The WAP one. Yeah, yeah, yeah, if I can find it.

[00:28:30.06] - Hypr
The four exploits one.

[00:28:31.26] - Justin Gardner
Yeah. Wappd. Yeah, Here, here it is right here. Very nice. Yeah, that was, that was a sick, sick bug. There's four exploits that came together. That was awesome.

[00:28:41.50] - Hypr
Yeah, but, yeah, so during the whole process of kind of looking into this router, I came across this daemon and came across this bug, spent some time, wrote the exploit, did all that stuff. But so this daemon, because it's a part of the SDK, is kind of a core part of the configuration management of the wifi stuff. This daemon itself has endpoints which then map to ioctl calls so that you can do certain kinds of configuration of the WI FI stuff over the network. So that's really kind of what alerted me a little bit. As I was looking through the source code for wap, it became kind of clear to me that there is another part of this that I'm not seeing. This is interacting with another component that it expects to be there that I'm not seeing. That was really the thing that led me to. I don't know if people know this, but just a little bit of background. Yeah, companies like Netgear and stuff, right. They use a lot of open source code in their products, theoretically at least the GPL license and open source licenses dictate that they need to release the modified versions of the source code that's under those licenses. Companies aren't great about doing it always, but they sometimes do. And Netgear for the most part is good about putting that stuff up so you can download an archive of all of the GPL related code that they release. When I was doing the stuff for the WAP exploitation, like I said, I kind of realized that there's something here that I'm not seeing. There's another part of this, and it seems like it would be very specifically tied to the media tech stuff. So I wanted to try to find that. And ultimately that's what led me to finding the source code for the driver. It just happened to be the fact that Netgear, I think, accidentally included like the full SDK in the, in the GPL package. So having never really done kernel stuff though, I found that code and then I had it for maybe close to a year where I was going through it, doing source code review, found things that looked like bugs and things that I felt Pretty strongly were bugs, but I had no idea how to actually interact with that stuff at that time. I didn't really have so much of an idea of what the interfaces are for actually reaching a lot of this code and stuff. I had a small handful of bugs for a little while that I really didn't know how to trigger or how to even validate whether they were actual bugs or not really. It was just a lot of trial and error, a lot of reading up on kernel stuff. Ultimately over time I started piecing it together, I started experimenting a bit on the device. At some point I it clicked that there's a pretty common utility on Linux for Wi Fi stuff called iWpriv. And so this tool is explicitly for interacting with the custom handlers of drivers that expose private interfaces. So that was my first breakthrough in going like, oh, okay, through some user land thing of issuing this syscall, I can actually reach the different parts of this code that I've been looking at.

[00:32:08.48] - Justin Gardner
Such good scope, dude. Freaking good scope. Wow.

[00:32:11.35] - Hypr
Yeah, I mean it's huge, especially with the amount of code that comes in these drivers. Because a lot of the time, at least from what I've observed here, is there's a lot of code included that doesn't actually end up getting used. There's a lot of defines and things that dynamically end up determining what actually gets built in. A lot of that was also figuring out, okay, this is a bug, but is it actually compiled into this driver or this version or whatever? So yeah, it was really just a lot of trial and error. But I ultimately ended up figuring out, okay, this daemon is interacting with the driver through these IOCTL calls. I figured out that I had the driver code and then through kind of like comparison of string outputs and stuff, was able to map out, okay, this is where this is, this is what's getting a mapping of what the actual attack surface was going to be. And yeah, that was kind of like the path kind of from just starting off with the Netgear router, finding the bug in the WAPD daemon, and from that kind of going like, okay, if there's a bug here, there may be a bug in the kernel stuff. And really the thing that motivated me, I think a lot more than anything else was that having seen or having spent enough time with the WAPD daemon and understanding what it does and how it works, I realized that there was could potentially be a mechanism for exploiting a kernel level bug through the WAP daemon because of the interfaces that it had to the IOCTL handlers. Right. That there could be a way to do that. And that really piqued my interest because, you know, generally speaking, a lot of kernel bugs are not going to be remotely exploitable and if they are, you're going to have a hard time.

[00:33:57.05] - Justin Gardner
Oh, yeah.

[00:33:57.57] - Hypr
Like, it is not easy to get like remote exploits because you're a lot more limited with the kernel stuff. But yeah, that piqued my interest and I wanted to try to find a way to do that. Like, if I could find a kernel bug that was related to one of the handlers that the Web3 daemon was going to interact with, that maybe that could be done. That ended up being true, actually.

[00:34:19.19] - Justin Gardner
Yeah. Which is just freaking crazy. And I think. I think low level, a famous YouTuber that covers some, you know, low level hacking stuff covered your exploits in one of his videos. And yeah, dude, freaking scary. I think he was. It was kind of funny too, because I watched the beginning of the video and he's like, yeah, I was sitting at, at Twitch, you know, TwitchCon with John Hammond or whatever and we were chatting and then I saw this and I'm like, shit, you know, like, you know. Yeah, yeah, turn off his phone, Turn off, turn off phone. You know, because. Because, you know, it affects so many devices, so. Wow.

[00:34:54.46] - Hypr
Yeah, funny thing about that. I had no idea that that had been covered because I've watched a few of the episodes of that. Of his show and stuff, or of his channel. I had no idea until I was at Pone d' on in Ireland and Cena is the one that told me no way.

[00:35:08.26] - Justin Gardner
Really?

[00:35:08.53] - Hypr
Yeah. And that was the first time I'd ever seen it. And it was. Yeah, it was really cool though.

[00:35:11.98] - Justin Gardner
Got like 250,000 views too, you know. It's crazy.

[00:35:15.57] - Hypr
Yeah. And I had no idea, so. But it was a nice surprise.

[00:35:19.01] - Justin Gardner
Yeah, I'm sure. Wow, dude. Well, that is really sick. You uncovered some really amazing scope here that allows you to not only pivot from user land into kernel, but also a route from some wireless or remote level interfaces that could tunnel down into kernel level exploits. Super awesome. And yeah, break everything sort of vulnerabilities, which is what you'd really, really love to see. And that is where I kind of wanted to go with another question, which was like, when you, when you're doing this, are you like, are you specifically looking for remotely exploitable vulnerabilities or are you focused more on local privilege escalation? Is a little bit of both. Or are you just kind of mapping out the whole system in your head? And trying to understand, you know, where any of these vulnerabilities come in.

[00:36:15.50] - Hypr
Yeah. So it's, it's a bit different for different targets, but definitely, you know, my list of priorities always starts with remotely exploitable. Just because those are flashier, they're cooler to be able to show off a little bit about. So that's usually what I go for. So my initial thing is always what ports are listening, what stuff is exposed that could potentially have bugs that will be remotely exploitable. And from there it kind of just becomes like it's a process of elimination. So if it feels like there aren't any remotely exploitable bugs, then I'll start looking for remote stuff. Although the thing with IoT, especially stuff like routers and things.

[00:36:55.90] - Justin Gardner
Right. Is.

[00:36:58.53] - Hypr
Local privilege escalation is a much more pertinent risk in desktop environments, server environments, things where people are expected to directly log into the system and be able to interact at a shell level or even a little less than that. But IOT isn't really like that. So, you know, finding a local privilege escalation in a lot of ways and in a lot of cases isn't going to be super impactful or is impactful only with the assumption, Right. That some other bug has already been exploited and an attacker has already landed on the system and for unfortunate reasons or whatever. Right. Like, Most of these IoT devices are already running as root. So if you've already exploited a bug to land on the system, you don't need a local privilege escalation. Like, you're probably already root.

[00:37:49.09] - Justin Gardner
Yeah.

[00:37:50.44] - Hypr
So, yeah, generally my first focus ends up being on remotely exploitable. Like, what's the remotely breachable attack surface?

[00:37:58.57] - Justin Gardner
Sure. And that definitely applies to things like pone tone as well and gets you the highest rating in bug bounties as well. So that certainly makes sense. Okay, a couple more questions on the technical stuff relating to octal handers handlers. Is there a good way to enumerate these in the system without, like, you know, having to look at the source code? Can I, like, run something that will tell me? All right, these are the octal handlers that are listening on my, my, my system.

[00:38:28.94] - Hypr
Yeah, that's a really good question, and I don't know if I can answer it definitively. Like, there may be some ways to do this, but, like, I'll tell you a little bit of a funny anecdote. I guess at some point when I was doing the source code review and I at least had pieced together enough of an understanding of like, oh, this is what ioctal handlers are, and this is what you do to start an interaction with them. Right? That was really all I understood or all I knew. But I ended up writing the world's dumbest fuzzer, which was literally just start at hex 1000 to hex FFF, right? Because. Yeah, I'll explain a little bit of why that's. Basically, the ioctal handlers or whatever are determined by what's called a code or a command, which is just like an integer, some integer with a unique value that dictates that's the handler that's going to handle it. I had figured out, or through the code I had seen, okay, a lot of the ioctl handlers that I am aware of or that I've seen in the code are like hex1, f c0, hex, whatever. Had the same question. I wanted to know what is there and what is reachable? Because a lot of the IOCTL handlers that I was seeing in the code, I would issue the ioctl and get no response or get an error saying that it wasn't a valid one. There was a bit of the code has a lot of stuff that isn't actually reachable at runtime. Wrote the world's simplest buzzer, which was just iterate through all of the potential IOCTL codes and blast it with a huge block of A's or whatever. I legitimately found multiple bugs. No, just doing that.

[00:40:14.80] - Justin Gardner
Oh, my gosh, that.

[00:40:16.09] - Hypr
That may be less of a. I don't know, maybe.

[00:40:19.13] - Justin Gardner
Maybe I'm tripping, you know, like, maybe there, there are going to be some people listening to this podcast that have experience with kernel stuff and like. But I'm. This is not something that I've been like, super aware of. And. And I mean, there totally should be an ioctal scanner, right, that says, okay, you've got, you know, this, this, this code, this code, this code, this code, this code, you know, track down where these map to, you know, and that's your attack surface. Because even if you're. If you're dropped in an environment where you have no executable privileges at all. Right. You know, this is a great way to just hop the executable, you know, and go directly to the syscall, you know, into the kernel here. Yeah, very interesting. Yeah. Wow.

[00:40:56.61] - Hypr
Yeah. Yeah, it's. I. Now that you mention it, you know, it is interesting that. I mean, I haven't looked into it, so maybe that tool does exist, right? Maybe I didn't come across it. I think one of the reasons Though that I would say, or that I think maybe it's not something like that would be difficult to do. And the reason why I think IOCTL kind of as an API seems to be dying in the kernel or being deprecated, is that it very much so is behind. You're sending an opaque block of data. Each handler can dictate its own structure and its own stuff. So very easily you can just send a slightly wrongly formatted piece of data and it'll seem potentially like the IOCTL either fails or that it's not a valid one or whatever it is. So I can imagine it's probably very difficult to like comprehensively enumerate in a way that can feel like very accurate. And a lot of the stuff in the kernel itself actually doesn't seem to use IOCTL too much. My experience so far has been that it's really proprietary drivers that, that, that still tend to use it a lot more.

[00:42:03.32] - Justin Gardner
I'm looking right now just while you were doing that last explanation, there is something called Ioctor Hunter, but a lot of these seem to be targeting Windows drivers, which is interesting.

[00:42:14.03] - Hypr
Interesting.

[00:42:14.76] - Justin Gardner
So, yeah, I mean, I think there, there is some ioctal fuzzing, you know, that sort of thing. But then you've got to enumerate, like you said, the struct that's going to be, you know, put together from the data that gets passed in either way. Very interesting attack surface and not something I, I heard about very often in like local privilege escalation environments. So going back to, you know, finding vulnerabilities in this kernel code. Right. I don't know, I feel like this is kind of a silly question or takeaway, but really, what, what I saw as I was looking through your, your vulnerabilities in that one, that one write up where you dumped like, you know, 10 MediaTek CVs or whatever, was that there was some size value that was being, you know, integrated into the struct. Right. And then it wasn't checking that properly and, you know, that resulted in a vulnerability. So what I'm wondering is, are you looking at these input structs that are in the, you know, in the C code and doing it, I guess backwards from there and saying, okay, look, there's a size, you know, a size field of this struct here, let me go trace where that goes and see if it ever would allow for an overflow or whatever, or you working up from the handlers or what is your code analysis methodology look like there?

[00:43:37.98] - Hypr
Yeah, so for that kind of stuff, most of the times it doesn't end up being a matter of kind of like identifying the structure and identifying that there's a size field, sometimes that's relevant or sometimes if I come across that, like I'll kind of just make a mental note of it. But really most of the time it ends up being kind of a matter of, you know, I think over time, just as a matter of experience, you build up like heuristics and patterns and stuff that you kind of end up being very well tuned to noticing in code. And me personally, like, I like memory corruption bugs and that's really what I've, I tend to go for first. Like that's my first kind of thing to always look for. And one of the things with that is that I just kind of index a lot on memory copies, where MEM copies are happening, where that kind of stuff is happening. And really it ends up kind of just being a matter of, you know, here are all the places where memcpies are used and here are the places where like it's being used with some data that's coming from like an external source or whatever. And to be fair, it's not always, I don't always have the idea or even know that the data is coming from an external source, but really just seeing places where a memcpy is happening, a size value is being used and there isn't an immediate or obvious indicator that that size has been validated or verified against an upper bound value.

[00:45:08.73] - Justin Gardner
Okay, that makes sense. So you personally are working a little bit more from a sync to sync to source. Yeah, sort of flow here and, and drat. I don't like to hear that because like there's the ongoing debate with the pot. I mean everybody's got their own technique or whatever, but you know, for me I, I'm a big source guy. Like I, I really like look, having a, you know, list of all the sources and you know, seeing what, having a rough idea of what each one of these sources does and then sort of mentally modeling out in my head, okay, the functionality behind this source is a little, you know, or like I'm thinking about it in terms of web. So like you've got like a route with certain parameters or whatever. Right. The functionality behind this route, you know, this path seems like it could be a little bit sketchy. So let me go like, you know, dive down that, that path. So, but I mean, in this case, like you said, you're zeroed in on memory corruption versus you know, business logic stuff bypasses, you know.

[00:46:10.32] - Hypr
Yeah.

[00:46:11.44] - Justin Gardner
So it makes sense to work back from the actual syncs themselves.

[00:46:15.28] - Hypr
Yeah, I, you know, it's funny that you mentioned that like I sometimes I see people talk about their methodologies and I sometimes envy what to me seems like a much more methodical or kind of comprehensive approach to it. And I, you know, people are successful with it personally, I guess especially with like stuff like the kernel things and all of that. Like there are so many paths right. That like. Yeah, yeah. I feel like I would struggle trying to think of like first enumerate the sources and then enumerate the potential places that they can go. Yeah. Generally, I guess my approach with these kinds of things ends up being find the potential bug first and then determine whether the data that ends up, you know, in that vulnerable area can be controlled or to what extent it can be controlled.

[00:47:02.32] - Justin Gardner
Yeah, that makes sense. And that is something we've said many times as well on here, which is when you're dealing with a massive code base or environment, you kind of forced to go sync to source because you're going to spend so much time burning through all these sources, you know, that don't have anything interesting at the end. Yeah, I will say, you know, the con to that of course is the business side is like, you know, okay, especially in this environment. Right. If a low, low or no privilege user could interact with this iOctyle and, and change a setting on like an interface or something like that, that alone has impact, you know. Yeah, it's not, it's not necessarily like a, you know, privilege escalation rc, but that has impact in and of itself. But also as hunters, a lot of times we do need to be goal oriented and if you're doing something like pone to own, it's shell or bust, you know.

[00:47:53.55] - Hypr
Oh yeah, no. Is so much of a different beast in a lot of ways, approach wise.

[00:47:58.44] - Justin Gardner
Yeah, totally. And I'm going to go into your for the pwn to own stuff in a moment, so let me just see if. Okay. The last question I had specifically related to the media tech stuff was a lot of these vulnerabilities like you mentioned were coming from these IPRIV command line binaries. And I'm just thinking about this, you know, you sort of answered this already with like, okay, in Iot it doesn't, you know, if you, if you've got a shell, local privilege escalations aren't the biggest deal in the world. But like are you thinking more that they would be able to execute those that vulnerability as a low privilege user on the system or Are you thinking more like maybe there's some wrapper around it that's calling that command line utility that you might be able to get data through? Because I have seen that in these duct taped together IoT devices as well.

[00:48:51.03] - Hypr
Yeah, yeah, yeah. I mean, really, you know, I think anytime I find a bug or anything like that, that would be at least at the starting point, like, local only. Yeah. A part of that process is trying to determine like, is it used by something else or is there some kind of like, you know, whether it's one hop away or three hops away or ten.

[00:49:13.65] - Justin Gardner
Yeah.

[00:49:14.05] - Hypr
That you can ultimately get some data from the, like a fully external environment and stuff. But yeah, I mean, that ends up being just a matter of chance. Right. Like, and in a lot of ways that's kind of why I lean primarily and at first towards like the remotely exploitable stuff. Because, yeah, I mean there's, there's definitely value. And I mean, in this media tech thing, for example, Right. Local privilege escalation stuff may not be super impactful for this MediaTek or for this Netgear router or whatever. Right. Most of the stuff is already running as root, like I said. But the MediaTek code is used in a lot of places, not just in this Netgear router. Right. So there are a lot of environments that you just don't know stuff too.

[00:49:53.86] - Justin Gardner
Right.

[00:49:54.73] - Hypr
Yeah. I didn't even know about the Starlink thing until maybe a year in to having been looking into this stuff, I ended up spinning off a side project to see can I find more source code, because the fact that I came across this, I just tried to apply that same approach and I ended up running across the Starlink stuff, but. Yeah, exactly. Right. They're used in a lot of places. So even if on the particular device that I started on, the attack scenario isn't super realistic or isn't something that the vendor is going to be super concerned about. Things like different executing environments or different scenarios can fundamentally change that model.

[00:50:35.15] - Justin Gardner
Totally. Totally, 100%. And that kind of goes to where we wanted to go next, which is your experience with the Mediatek team. I was reading through your write up and it seems like unfortunately they're doing a lot of downgrading and excuses and it seems like you thought that the incentives for the bug bounty program weren't necessarily aligned for them. Can you talk to a little bit about your experience with that and as that correlates to local privilege escalations versus remote exploits and that sort of thing.

[00:51:04.84] - Hypr
Yeah, yeah, yeah. So, I mean, the experience was interesting, to say the least. Or to be diplomatic. Right. Yeah, I have.

[00:51:16.28] - Justin Gardner
Let me, let me preface this. We don't hold punches here on the. We don't pull punches here on the podcast. So, you know, feel free to say your, Say your piece, man. Yeah, for sure.

[00:51:25.05] - Hypr
Yeah. I mean, it was a learning experience in a lot of ways, but it very much soured me on the way that private bug. The incentive structures that private bug bounty programs in particular create.

[00:51:40.88] - Justin Gardner
Yes.

[00:51:42.65] - Hypr
You know, like, at a fundamental level. Right. Like, there is always a bit of.

[00:51:47.92] - Justin Gardner
A.

[00:51:50.09] - Hypr
Power asymmetry between like, vendors and researchers and stuff that, like, that's always true whether you're going through a private program or something else. Right. But yeah, so, so that's always the case. I think that some of the benefits that vendors get when they're doing private bug bounty in particular around like, non disclosure stuff, which, you know, I understand nondisclosure 100% when it comes to the details of the bugs disclosing early, like whatever it. Right. Like, like the details that are likely to affect customers and, and consumers and people who are actually using and would be affected. But, you know, a lot of those policies and a lot of those programs also tend to give vendors an easy way to behave in ways that I don't believe that they would behave in public or if they were, you know, under the impression that they would receive some public scrutiny.

[00:52:48.00] - Justin Gardner
Sure. Yeah.

[00:52:49.44] - Hypr
And I think that's just, you know, anything like, like bug bounty, maybe it's a little different. Right. There's money attached to it and all of that.

[00:52:55.90] - Justin Gardner
But.

[00:52:58.23] - Hypr
Coordinated disclosure is an act of good faith. Right. Like, researchers do not owe this or, you know, to vendors. So it is really unfortunate. And personally, it feels very like it bothers me a lot. It's really disrespectful because I'm like, professional. Right. Like, I try to be very professional. I'm reasonable. I don't push on things. Especially if I feel like it's like, you know, I'm splitting hairs. I'm trying to get this, you know, severity to go one way or another. Like, I don't do that stuff. So when I feel like, you know, a vendor is seemingly taking advantage of the fact that they have this degree of flexibility that I don't have or that I can't, like, hold them to account for, it's. It's really frustrating. And this just happened to be a situation where it was so egregious. Like, I couldn't, I couldn't believe it. Like, like, honestly, at multiple points I was convinced I was talking to an AI because I didn't believe that a person could be so obtuse to like not understand what I'm explaining to them or offer because, you know, self preservation and ego, I feel like would dictate that people would be embarrassed to make these kinds of arguments.

[00:54:06.82] - Justin Gardner
Yeah, dude, and I read through your post and yeah, without going into too much detail, it really, really does seem like, like that is the case. You know, some of the explanations were, were quite egregious. So it's unfortunate because clearly you put a lot of time and effort into that program and you have like something like 800 something rep on, on HackerOne with one private program, you know, wonder which one it is, you know. So yeah, that is, that is an unfortunate outcome. And I wanted to ask you where you stand on, you know, the HackerOne ecosystem in general. You know, will you continue to hack on, you know, kernel drivers, you know, for, for various products via that ecosystem or do you think that's soured you on that ecosystem in general?

[00:54:56.28] - Hypr
Yeah, you know, I've thought about this a lot. I've gone a little bit in different directions over the past couple of months, but like at a really fundamental level, yeah, it soured my experience with it because it's very stressful. Like, like I don't like sitting there having to think about arguments against what ends up feeling like really silly kind of, you know, hair splitting stuff. It's really frustrating and especially when it's like, dude, I'm not stupid. Like I've been doing this shit for years. Like it's, you know, and I get it, maybe people, you know, I sympathize with people on the inside of like bug bounty programs and who are having to deal with all kinds of, you know, ridiculous stuff being sent to them as well. But I would hope that they could differentiate pretty quickly. Like I'm not one of those people. Like I'm not giving them random stuff. Like I don't even report mediums most of the time.

[00:55:44.96] - Justin Gardner
Yeah.

[00:55:45.25] - Hypr
And maybe I should. And that's like a, you know, not benefiting them. But like so, so, so your impact.

[00:55:50.25] - Justin Gardner
Is 30, which is, you know, your average bug is between a high and a crit. So.

[00:55:55.65] - Hypr
Yeah, yeah, so, so, so yeah, it's, it's, it's very frustrating. Personally, I'm not super inclined to really take those things. And here's the thing, like I started submitting bugs to mediatech long before they invited me to the private bug bounty program. Right. Like ostensibly that's how you get invited to these things, right? You've. You've proven yourself. And so. So, yeah, it. It was not about the money for me. I do this stuff for fun. Like, frankly, like, it really is just interesting to me. And so, yeah, it. It has soured me in a big way mostly because, you know, throughout the whole experience, like, you get all these moments where it's like, it feels like you're being disrespected.

[00:56:38.67] - Justin Gardner
Right.

[00:56:39.03] - Hypr
Like, someone's just, like, really, like, thinks you're. You're dumb or something. Yeah.

[00:56:43.88] - Justin Gardner
And your. Your piece of work, you know, you said earlier it's like a palette, right? And you sit, you paint, you draw, you get it out, and then people are like, yeah, you know, and you're excited about it. You know, I do get that. Yeah.

[00:56:57.11] - Hypr
And look, I get it. I've worked on p. Cert teams.

[00:56:59.92] - Justin Gardner
Right.

[00:57:00.07] - Hypr
Yeah. Like, I understand, and I'll say this diplomatically. The business incent to try to shift things around a little bit or to, you know, interpret things slightly differently sometimes that's valid. You know, companies have different threat models, things that they're actually concerned about. And, yeah, not every bug has the same amount of impact on every system, so I get that. But, yeah, it very much is a disheartening kind of experience because it feels like you can't avoid it. And more than anything else, it's the feeling of powerlessness that it seems like you're kind of just backed into a corner, and it just. It's kind of like, accept it or move on because no one's really to help you.

[00:57:42.67] - Justin Gardner
I know you said that you're very professional about it. You're not trying to split hairs and stuff like that. I'm wondering, did you end up using HackerOne mediation for any of this? To try to get HackerOne to come on in and say, like, hey, actually you're tripping to MediaTek, or how did that work?

[00:58:00.75] - Hypr
Yeah, so I did. At some point.

[00:58:03.44] - Justin Gardner
The.

[00:58:03.84] - Hypr
The. At some point, I. And it's really. It was when the thing that I talked about on the blog post happened that was like my, like, final straw. I could not believe that was actually happening. So. So when that happened, I think it also very much solidified to me, like, they're being intentionally dishonest. Like, this is not a matter of, like, perception or anything like this. Like, it's intentionally dishonest. So I did go through the. The mediation route. You know, I had eight different support tickets open that didn't receive a single response for at Least a month or something. When they got a response, they asked me to either explain or to link to something else related to the ticket or whatever I did. Those tickets are still sitting there now, not really responsive. At some point in the conversation that I was having with MediaTek, I said bluntly, you're lying, you're being dishonest. I got a support ticket opened for a code of conduct violation. Apparently telling someone that they're lying is disrespectful and aggressive. And so that, that was really like, you know, I wouldn't hold it against the platform necessarily, like what MediaTek is doing and stuff, but then it's stuff like that where it goes. It's like, have you read through the, the conversation, like, okay, you can argue that me calling them liars is aggressive or disrespectful. How is it not disrespectful that they're treating me like I'm an idiot? Like they're, they're, they're making obviously dishonest arguments and stuff. So, again, well, I was respectful about it, but it was very much a bad experience.

[00:59:32.13] - Justin Gardner
You know, we, we just, we just met on this call today, you know, for the first time on this podcast, drop, drop me those ticket numbers. And I'm going to try to get, you know, some of my people at HackerOne to try to review those, because there are flaws in the systems, you know, as far as, as far as mediation goes and, and all that. But I think one of the other pieces is like, man, nobody, you know, there's, there's a handful of kernel driver hackers, you know, and you need to like, you know, that skill set is very, very niche, you know, and, and so they really, it should be treating you with more respect, I think. But, you know, it is, it is a part of the game. And I think that is some of the dark side of Bunk bounty is that sometimes you're going to run into this, and sometimes it's the company, sometimes it's the platforms, you know, missing, missing the mark. And for us, you know, for the successful hunters that have done this for a long time, it's a churn game. And, you know, you submit a couple bugs, you see, hey, they're gonna, they're not the kind of team I want to work with. And then you move along and you find teams that really respect you and you respect them and you pray to God they don't have turnover is the situation, you know, and you go from there. It's unfortunate, though, that a company that you've invested a lot of time and effort into it doesn't seem to be appreciating that. Sufficiently unfortunate.

[01:00:52.96] - Hypr
Just a last thing on that, which I think is not super important or critical, but it is something that I think provides a bit of insight into what happened and I'm proud of. At some point after I had submitted the majority of my bugs, I don't know whether this was sent to everybody or just sent to me, but I received a message from MediaTek essentially saying, essentially admitting our bug bounty budget has been exhausted. I am going to assume that that's primarily because of the bugs that I submitted, because it was like 20 within the course of a couple of months and in that message basically said, moving forward, we will no longer be offering monetary bounties for this line of chipsets, which is ones that I was reporting.

[01:01:41.03] - Justin Gardner
You're kidding.

[01:01:42.48] - Hypr
Yeah. No, no. So. So at that point, and I talked about a little bit in the, in the post, it was like it became obvious like, oh, this is going to be a problem. Someone's having to explain to some manager, some upper, like, you know, management, why the, why the budget got wiped out so quickly or whatever it is.

[01:01:58.07] - Justin Gardner
There you go, guys. The dark side of bug bounty. You see it here. It does happen. It does.

[01:02:02.51] - Hypr
It's business.

[01:02:03.11] - Justin Gardner
Yeah, it really is. And it's unfortunate because you did excellent work. Work, and we all know that. Thank you. And yeah, I mean, we've got a big community. Anybody in the community that, you know, has. Has good hardware hacking, you know, or Iot hacking kernel driver programs, please, please shoot them at us so we can get hyper in a place that he's going to be appreciated. But yeah, man, I did want to juxtapose that a little bit though, or maybe align it, I'm not sure with the PWN to own ecosystem. So could you talk to us a little bit about your experience at PWN to own, your experience with the vendors there and in as much detail as you can. You know, I know Pone Tone has got some gag order stuff in place, but what kind of vulnerabilities you were finding and how you're using your skills against that scope. Sure.

[01:02:53.51] - Hypr
Yeah. So, yeah, I mean, at a high level, I'll start off by saying I'm very new to the PWN to own world and ecosystem, and I owe a big thanks to Cena specifically. Yeah, yeah, that guy's a beast, man. It's crazy. But yeah, at some point last year he reached out to me on Twitter and just kind of asked like, I think it was shortly after I had published that blog post about the WAP debugs and stuff. But yeah, he reached out to me, asked me if I wanted to, you know, work together on some phone to own stuff. And specifically he had already found, I think he had two separate bugs that he. That he had found, but that I think he just needed some help basically. Writing the exploits for Thena is insane when it comes to bug finding and then exploit development stuff.

[01:03:49.26] - Justin Gardner
Right.

[01:03:51.46] - Hypr
But pwn to own, especially the way that Sina does it, is a lot of work. He goes for everything.

[01:03:57.94] - Justin Gardner
Right. That's great.

[01:04:01.15] - Hypr
Yeah.

[01:04:03.75] - Justin Gardner
Yeah.

[01:04:04.30] - Hypr
He asked me for help on a couple of these bugs. I ended up saying yes. Sure. It was maybe a month before the actual competition, so it was for you too. Yeah, yeah. And that's the thing. I generally never had to work with a timeline with like a hard cut off of like, I need to finish this by this date.

[01:04:23.19] - Justin Gardner
Right.

[01:04:23.82] - Hypr
But in a lot of ways I feel like I enjoy it. I can be a little easily distracted or can procrastinate a lot like if I don't have well defined kind of endpoints and stuff. But yeah, so we had about a month or a month and a half. I ended up helping him with that. We wrote the exploits. One funny little thing, you know, not to go into a lot of detail, but like both of the exploits ended up ultimately, like I was able to push them to the point where they were about 80% of the way there, but both ultimately were affected by aslr and in both cases we kind of. Our only choice was guess. Just try to guess in a loop. And at least once or twice in our testing. Right. Like it worked.

[01:05:07.88] - Justin Gardner
Yeah.

[01:05:08.61] - Hypr
And that's all we really had. So we just kind of had to hope for the best.

[01:05:11.76] - Justin Gardner
Yeah. Yeah.

[01:05:13.80] - Hypr
Those didn't end up hitting, or at least I think one of them didn't end up hitting. And the other one, it went slightly differently.

[01:05:20.65] - Justin Gardner
Yeah. Yeah. Wow, that's intense, man. Fricking Pontoan is no joke. You know, like you've got a couple minutes to get your X place running. You know, it's like stressful as heck, you know, like, like a lot of times in, in, in our bug bounty world, it'll be okay. We're going to start a video, we're going to run the exploit, you know, and then you see it work and, and then, you know, you submit the video, you submit the code and they're like, okay, good, you know, but you got to do it live at Pone to O and you got to do it with their systems, you know, like that you haven't.

[01:05:53.84] - Hypr
And I'm like, yeah, honestly, for me that's the scariest thing because like, in a lot of ways most things are deterministic enough that it's not going to change significantly. But really when you start, you know, poking at memory corruption stuff, you know, even just a slight change in the memory layout will break your exploit. And you know, there is some leeway, at least within your allotted time, where if your first try fails, you can go and try to like, you know, modify stuff or adjust things if you need to. But, but you only get three attempts, right. And so if it doesn't happen in that time, thankfully, I feel like I've been lucky enough in my couple of experiences where it was only that one time last year that it didn't really hit and I wasn't even there. Like I joined on a Zoom call because I didn't have my passport to travel at that time. And so. But yeah, I cannot imagine the pain that it must be to have gone through everything and then to have spent the money to travel depending on how far away you are and stuff and then to just have it, it not hit.

[01:06:54.25] - Justin Gardner
Yeah.

[01:06:55.05] - Hypr
So when you see those videos.

[01:06:56.73] - Justin Gardner
Yeah, that's one of the crazy things about Pontone too is like booking you but you're not getting flown out. You, you know, you have to go.

[01:07:04.17] - Hypr
Yeah, it's an investment and you know, if you only have one bug, it's probably, it's worth it for the experience if that's what you're interested in. But most times if you only have one bug, you're probably not going to make much money out of it.

[01:07:17.21] - Justin Gardner
Yeah, I would love to see Punta own step up their game a little bit with that, that, you know, like hacker, one life hack events, bug crowd, you know, Google meta, all of those life hacking events, they, they fly you out and they put you up, you know, if you qualify.

[01:07:30.65] - Hypr
Oh, I didn't know that, man.

[01:07:31.86] - Justin Gardner
It's, it's, it's nice, you know, and it is. I mean, obviously the pressure is on a little bit then too, right. You're like. But that's a good pressure, I think, you know.

[01:07:41.01] - Hypr
Yeah.

[01:07:41.46] - Justin Gardner
For a lot of these people are like, yeah, you know, actually they're flying me out of here, they're, they're putting me in a hotel. Like I'm going to give them something, it, you know.

[01:07:49.46] - Hypr
Yeah.

[01:07:49.94] - Justin Gardner
So I think they get a lot of ROI from that too.

[01:07:52.67] - Hypr
For sure, for sure. I mean, yeah, I think there's you know, people who participate in Phone to.

[01:07:58.15] - Justin Gardner
Own.

[01:08:00.82] - Hypr
There'S a lot of really specialized skills, a lot of really, you know, complicated work that goes into it and stuff. It, it is a little funny sometimes at the competitions where as someone who's written exploits and done all that stuff like you know, everything that goes into it, it. At the actual time of execution it is 3 seconds most times. You click enter and then it either worked or it didn't and then it's over. And I do like the fact that Dustin Childs and stuff. Like he seems to make it explicit. Like I know it seems like that was really easy. It was not like it was a lot of hours of work that went into making that work.

[01:08:36.02] - Justin Gardner
Yeah, yeah, dude, man. But what a beautiful, what a beautiful thing. You know as well at the end of the day when it does, you know when, when you get an exploit, it's really, it's really consistent and clean and it just, you know, you're forcing the stars to alive, you know, every time and it's like, ah, that's so beautiful. I, I, I did recently have a more, a little bit lower level bug than I normally do. It was a remote code execution and, and really like I had in a production system where we knew what the docker container was that we were running in, right. So I got the whole docker container set up. I emulated first. I tried to do it the quick and dirty way for sure hours.

[01:09:18.09] - Hypr
If it works, it works. Yeah, yeah.

[01:09:19.52] - Justin Gardner
I got to get the whole local system set up and I got it all set up and then of course it works a little bit better then. But yeah, man, I mean it is a beautiful thing when you finally get a consistent exploit but man, how difficult it is is to do it on somebody else's, you know, architecture in their ecosystem, on their devices. Geez, yeah, it's tricky. It's tricky.

[01:09:41.64] - Hypr
Yeah, it's a whole thing. And as anybody just, you know, I don't know if we'll talk about this at all, but just in case we don't. As anybody who's participated in PWN to Own will tell you, the biggest stress is not so much that running the exploit on the day of, it's the three or four days leading up to the actual competition where vendors seem to love pushing out their patches at the end. Absolute last minute.

[01:10:06.47] - Justin Gardner
Oh my God.

[01:10:07.43] - Hypr
And yeah, it's, it's really unfortunate especially if you know, you spent 10k or something to travel and then it's just gone.

[01:10:16.71] - Justin Gardner
Gone. Yeah, yeah, yeah, it's it's tricky, man. I feel like the PWN to OWN ecosystem is a little bit riskier. Like for me as a hacker when, when I accept a, you know, hacker one life hacking event, I'm pretty confident that I'm going to walk out of there with like, like a good chunk of change that's gonna, you know, provide for my family. I'm a full time hunter, so.

[01:10:36.68] - Hypr
Yeah.

[01:10:37.56] - Justin Gardner
You know, but with phone to Own it's like, okay, I'm, I'm flying out there. You know, they could push a thing at the last second where everything's completely different, you know.

[01:10:47.48] - Hypr
Yeah.

[01:10:48.36] - Justin Gardner
So. But the payouts are really big and the. I think that's the thing that, I.

[01:10:52.68] - Hypr
Think, yeah, that that's what balances out or at least for some people. I think that's enough of a motivating thing where it's like, yeah, you'll, you'll deal with some nonsense, but you, if, if you can get past that hurdle and your exploit works.

[01:11:02.60] - Justin Gardner
Yeah.

[01:11:03.01] - Hypr
You're probably going to get a pretty decent payout for sure.

[01:11:05.44] - Justin Gardner
And the prestige is really good too on the Ponton, I think, 100%.

[01:11:09.64] - Hypr
It's crazy. Yeah. I mean to anybody who's into this stuff and building up. Yeah. If only for the reputational gain.

[01:11:17.48] - Justin Gardner
Yeah.

[01:11:18.40] - Hypr
It is a great experience.

[01:11:19.85] - Justin Gardner
Yeah, totally, man. I'm excited. I really want to do one. Coming up soon, I've got a couple people from the critical thinking community that I might do a team with and, and just try to pick off one of these devices and do one. I think that'd be a lot of fun.

[01:11:33.01] - Hypr
I think honestly I'd be really interested to see kind of like having only done a bit of the web related stuff in the past. Yeah. Having those kinds of skills applied in these environments or in these kinds of things like for IoT or for car hacking stuff, I think it would be really interesting because you really very much do see a lot of memory corruption stuff like those kinds of things. But I am impressed when I see or read about exploit chains and these kinds of things that do start off with a web bug because ultimately in a lot of pone to own things, right. You need to get full remote access. And a lot of times if there just happens to not be a bug in one of the weird binary protocols, you have to go through the web stuff and try to figure out a way through that. So there's benefits in having that wide range of skills across different things.

[01:12:23.82] - Justin Gardner
For sure. Totally. There is. And it's interesting though because there have been a Couple of targets and producer Richard. We might have to bleep some of these, so check with me after on some of these. But at the Hacker one live hacking events, at one point we did have the routers as a target.

[01:12:40.98] - Hypr
Oh yeah.

[01:12:41.63] - Justin Gardner
And, and we were able to like completely shell those through a little bit of binary protocol, but mostly like web, web related interfaces and, and then also that right the, oh and that was, those were crazy. Crazy dude. And that was interesting. That wasn't all HTTP, it was a little bit SIP as well.

[01:13:00.71] - Hypr
Oh wow. Yeah, that's interesting.

[01:13:02.78] - Justin Gardner
It was. And those are like some of my finest memories, you know, my fondest memories in hacking. And that just tells me like, hey, maybe I should go after IOT stuff a little bit more because it is really freaking fun.

[01:13:15.82] - Hypr
Yeah, I mean I would definitely and especially yeah if you're coming from bug bounty stuff. If you're coming from web and you have interests in exploring like low level stu, there is a bit of a learning curve because there's hardware involved and it's a slightly different paradigm than you might be used to. But IoT is a great training ground. You're going to find bugs that you probably will not find on just a modern Linux distro. There's possibilities, there's opportunities to find real world bugs and to have an actual chance of successfully exploiting them with enough work.

[01:13:53.72] - Justin Gardner
I love looking at a device and being like I have a shell in that right now.

[01:13:58.51] - Hypr
Yeah, it is pretty cool.

[01:13:59.78] - Justin Gardner
That just makes me happy, you know. Yeah, that's awesome, man. Okay, all right, so we covered that a little bit. Can I, can I ask if, and you can decline to answer this if you'd like, but which one has been more financially successful for you? Pwn to own versus hacker1. Hacker1.

[01:14:19.94] - Hypr
Hacker1. If only for, if only for this media tech bug bounty program. Honestly, I think before the media tech bugs I don't think I ever got an actual monetary very bouncy from, from one of the programs. Like I had been part like the web stuff that I participated in was mostly like kudos stuff because I wasn't sure super keyed in on like web stuff, you know.

[01:14:40.57] - Justin Gardner
But yeah, that makes sense. I, I, I hope you give it another shot man. I know you're soured on it, but there are good programs and they will treat you well, especially with your very unique skill set. I'm wondering, moving forward, are you going to continue to focus on kernel driver stuff or are you going to also attack other things in the IoT ecosystem? What, what Kind of has your interest right now as far as hacking for the next year or so.

[01:15:04.85] - Hypr
Yeah, it's funny, I've been thinking about this a bit over the past couple of months. You know, a combination of having spent already a couple of years with the media tech stuff and then that the whole experience with the bug bounty thing, I kind of came out of that and went, okay, I'm done with media tech for now. Yeah, it was a good experience, right. But. But I also can't spend forever on this. And the version of the source code that I have was starting to get older and older and the bugs were starting to go away. So there's not going to be a lot of value in staying on that. But more broadly, I do like the kernel stuff. It's very interesting if not very complicated sometimes and a bit painful. Especially because just kernel stuff things in kernel world are led by people who. The kind of people who hold the belief that the code is the documentation. You're going to have to read the code if you want to understand anything. People are not writing super in depth documentation about this stuff. You just have to go look at the actual code. It makes a little bit more difficult. But the fact that, that the Linux kernel is open source, I will always have source code access, full debuggers, all of that stuff, it's really great. So I do want to keep exploring the kernel side of things and start moving more towards a bit away from the IoT and kind of more restricted environments of IoT to just more kind of like either desktop environment, server type stuff. But yeah, a part of me, it's been a few years. I do feel like I want to in a sense graduate a little bit out of the IOT world and you know, face get a little bit more challenges out of other space.

[01:16:55.00] - Justin Gardner
That's crazy. That's crazy to hear you say, oh yeah, kernel exploits and IoT devices. Not really doing it for me right now. That's crazy, man. Very cool. I did have, I guess, a topic that we were going to return to. Oh no. Let me hit you with this one question before we go over to the real world. Exploits versus ct. I did a little bit of OSINT while prepping for this and came across your GitHub repo kernel utils and it looks like this is some. Well, I'll read the about some scripts to automate setting up kernel research and development environments. Is this something that you can tell us a little bit about how to use or is this largely your own personal repository for these sort of things. Will other hackers be able to use it? It give me some info about this.

[01:17:44.86] - Hypr
Yeah, yeah, totally. So, yeah, I think it is useful or can be usable to other people. I definitely mostly wrote it for myself to kind of simplify some of this stuff. But yeah, the main thing with this repo is just like building a kernel is pretty straightforward in most cases. The most complicated part about building a kernel is the configuration part, which is really just like figuring out what you need to actually enable or what's important to enable or whatever it is, is. But from there it's a pretty straightforward process. This repo is really just a small collection of scripts. It originally started specifically for using Build root, which is a system that's used very frequently in embedded environments, which is just a packaging to combine the process of building a kernel and a root file system that can work together over time. I moved away from Build root and just doing directly downloading the kernel source. Really all this does is kind of just simplify the process of saying download the appropriate kernel source code. There are some preset configurations, like some really common ones for a minimal vm. So things like debugging capabilities. Yeah, it's really simple stuff. And then it combines something called Deep Bootstrapper. I don't know if that's what it's called actually, but Syscaller. Anyone who's familiar with Syscaller, it's like a Linux kernel fuzzing system. So they created this script that they have for. So just as a bit of context. Yeah, when you're doing kernel stuff and you're trying to compile a kernel and then boot it up in Kyma or whatever. Apart from the kernel, you need a root file system. Right. The actual thing that provides the user land. So yeah, Syscaller came up with this script that uses Debian's debut structure functionality to just quickly set up a root file system based on Debian.

[01:19:42.32] - Justin Gardner
Okay.

[01:19:43.28] - Hypr
So yeah, the repo kind of just combines the ability to pull down the code, compile a basic version of it, and then create a root file system that'll be compatible with it. And that's just like really the minimal kind of environment to start off with if you want to do kernel stuff.

[01:19:58.72] - Justin Gardner
Nice, nice. Okay, so essentially this is automation to get you a. A emulated environment where you're in user land, you've got the kernel running that you're trying to exploit and you can just go from there.

[01:20:11.85] - Hypr
Yeah, yeah. Like you have directly like the kernel sources and stuff. So a lot of the times, right, like yeah, you Might need to go in and make some changes, add some logging, some debug stuff to the kernel. So being able to kind of just quickly iterate on that.

[01:20:22.65] - Justin Gardner
Yeah, so a lot of this kernel stuff is such a brain for me, I can't wrap my head around it. So if you've got these, let's say you've got these kernel drivers, right? Is that something you would need to set up before? Or do you spin this up and then once you've got user land access, you install the kernel drivers or how does that normally go for you?

[01:20:43.61] - Hypr
Yeah, so, so for, for, for a situation kind of like with the MediaTek stuff, right? Like I have the kernel binaries that are on the act, or the, the driver binaries, right. The dot KO files that are on the router, but that's compiled for arm. And not only that, it's kind of sometime in a slightly weird way for the particular device most times, or at least in my experience, I've never been able to successfully go, I'm going to go build this kernel, just a clean kernel source tree, and then try to drop in the driver binaries and then just load them directly. Sometimes that'll work. One thing you do have to do is match the kernel version to the specific version that's built into the driver. There is a hard linking between versions. So that's sometimes a little complicated. It's also a little complicated when you have to build older kernels, because it sometimes means having to chase down tool chains because compilers have changed over time and older stuff will not compile in quite the same way or will have some issues. Just as a note, before I go into that, or before I get overwinded on that, a big part of this, a crazy big part of this is just learning how to compile stuff, learning how to modify, figuring out what's failing, what needs to happen. You know, sometimes directly modifying the code to actually work in your environment and stuff. So, yeah, that can get kind of complicated. This is actually a good segue into something that I think I thought was maybe worth mentioning is that.

[01:22:18.71] - Justin Gardner
At some.

[01:22:19.27] - Hypr
Point during the whole process, right, Like, I had no debugging capabilities, I had very limited access to be able to debug stuff. But I had the source code for the driver, and through a lot of trial and error and a lot of failures, I was able to figure out how to compile the kernel driver directly for x86 rather than for arm.

[01:22:44.05] - Justin Gardner
Right.

[01:22:48.05] - Hypr
That took a lot of work, and a lot of stuff is definitely not working correctly, but Getting to the point where I could build the actual drivers and produce binaries for x86 makes it a whole lot easier. X86 is everywhere, right? It is the de facto standard for pretty much everything. So your odds of being able to successfully compile almost any kernel version for x86 is pretty high. And so, yeah, directly dropping things in can get really complicated. But then you do have the option, right? When you do have source code, or even if you don't, it depends on how. How crazy you want to get with it, right? You don't even need to have source code, but figuring out what it takes or what needs to happen for you to actually load it into an emulated environment. And the thing is, most Times Outside of IoT, it's not super common. At least I don't think that you'll come across proprietary drivers that you're just getting the blob for. Right. But yeah, there's a lot of ways to kind of go about it. And ultimately I ended up being able to, like, I went the route of creating like an emulated Kimu PCI device because I found at some point that the kernel driver has some support for like a pci, like body for that chipset or whatever. So it would look for things on the PCI bus with matching IDs and load the driver. So I was like, okay, that's going to be my easiest path to actually if at least just getting the driver to load. Like, I don't care about it being able to actually send network data, right? Like WI fi frames or whatever. Like, that's not important.

[01:24:26.38] - Justin Gardner
Important.

[01:24:27.65] - Hypr
But yeah, I was at least able to get it to a point where it could load the driver and it would find the PCI device and stuff.

[01:24:34.85] - Justin Gardner
Wow.

[01:24:35.65] - Hypr
And that gave me at least somewhat of an environment that I could use for like, verifying some other bugs.

[01:24:41.46] - Justin Gardner
I think that's one of the really challenging things about this sort of security research. It was 100% getting things to compile, getting an emulation environment, getting any sort of attack environment, very difficult. And in some of these routes, routers, there isn't a natural way to get a shell sometimes, too. So you got to get a shell, you know, even if you're going to work on the actual device, Very, very challenging. Very, very cool scope, man.

[01:25:07.02] - Hypr
Yeah. I mean, the good thing about, I mean, really not, not just Iot, but anything where, you know, and I'll say this, this is kind of one of the things that I personally don't like all that much about, like the web Stuff is that it is so black box.

[01:25:20.50] - Justin Gardner
Yeah.

[01:25:20.73] - Hypr
Like it is so much like there's just a box somewhere that I'm sending things to and all I can do is kind of observe what it sends back and like that's valuable and you can do stuff with that. Right. But definitely the flexibility that you get when you have directly, like all the stuff means, yeah, I might not have the device, but I can harness this up in an emulator or I can, you know, whatever it is. Yeah. And you've got a lot more flexibility to kind of just force things if you need to.

[01:25:45.65] - Justin Gardner
Having the full code is unbelievable. I did want to ask, have you had any success using AI to help sort of limit the burden of getting all of this stuff compiled and set up and getting yourself an execution environment?

[01:26:01.40] - Hypr
Not a whole lot yet. It's funny, over the last two weeks, that's almost exactly what I have been doing. I haven't been super quick to jump on a lot of the AI stuff and I'm seeing it a lot more.

[01:26:12.89] - Justin Gardner
So.

[01:26:13.22] - Hypr
So it's like, okay, I'll check it out, see how it can be useful. To me though I have a lot of mixed feelings about the entire thing for things like that. Specifically, the thing that I'm trying to work on right now or builds is just an agentic thing to just say, here's the source code, read everything, read the build files, figure out what the sequence of compile commands is going to be to get this to build. Because that can save me so much time. And that's the stuff that I really do not like doing.

[01:26:44.97] - Justin Gardner
Doing.

[01:26:45.36] - Hypr
Yeah, yeah, so yeah, stuff like that. It's great.

[01:26:49.85] - Justin Gardner
Yeah, awesome, dude. And last topic, we'll swing around and then I'll let you go because I've kept you here for a while. Is this value of using real world bugs for exploit development versus CTFs. And we talked a little bit, we touched on this earlier. But you know, reading through your blog, I've seen you go back and reverse engineer some of these EDI bugs and stuff like that in other people's work? And you're doing this, as, you know, obviously a very competent hacker already. How much of that is currently a part of your workflow still? And what kind of value do you think that gives to the hacker as opposed to like CTFs?

[01:27:30.17] - Hypr
Do you mean like the workflow, like in terms of going back specifically for like end day stuff or just broadly.

[01:27:34.77] - Justin Gardner
Like, you know, end day stuff? I mean, I know, I know to some degree it helps you learn about the ecosystem and that sort of thing. But you know, if you're looking at that same target, that's, that's very valuable. But that just sort of juxtaposed with CTF in general.

[01:27:49.52] - Hypr
Yeah, yeah. So I mean, in regards specifically to like end day stuff, I've only done it a couple of times and it's really one of these things where like end days are the perfect midpoint between CTF bugs and real world bugs. Like, you know, the bug is there, you don't have to concern yourself. Because just as a side note here, one thing that I think is important that people understand is that bug finding and bug exploiting are very different skill sets, like fundamentally different skill sets in a lot of ways. Like they benefit each other. Like the knowledge does transfer a bit, but it's very complicated. And trying to do both at the same time, it can work for you. That's what I've done in a lot of ways. But it's very much been almost like a brute force approach in a lot of ways. It was just kind of like bashing my head against things until I kind of figure it out.

[01:28:38.13] - Justin Gardner
Yeah.

[01:28:38.77] - Hypr
But yeah, end days are I think, a perfect midpoint between fully kind of, you know, synthetic bugs and real world bugs. I don't do a lot of end day stuff now. It's one of the things that I always tell myself like, do it, if anything, for the exploit development practice. Because you know, if, if you do go the route of saying I'll only write exploits or do that stuff like when I found a bug, you're going to spend the majority of your time learning bug finding and only infrequently, depending on how frequently you bugs will you actually be writing the exploits. But yeah, I think in my experience approaching it from the perspective of either trying to find real bugs or just starting with a real bug gives you an opportunity that you don't always get with CTFs. With things that it's like a. I know CTFs can have multiple solutions. There isn't necessarily one static solution, but it is, is well understood. Understood well enough. Right. That somebody was able to create this kind of synthetic vulnerability. So I think that's great. And for learning the fundamental kind of concept around exploitation, that's fine. But what you'll find if you do plan on writing exploits for real world vulnerabilities is that that delta between just what the bug is, is and what environment the bug lives in and kind of what's around it ends up being really important. And a lot of times determining whether that bug is actually exploitable or not. That's why I kind of retained the like, you know, exploit or gtfo. Right. POC is not enough always. POC will tell you that the bug exists, not to what extent that bug is actually exploitable and what the impact actually is.

[01:30:32.34] - Justin Gardner
Absolutely, absolutely. Yeah, I totally agree with that. And I think also there's something really big about like trying to find what other people have discovered on an environment that you've hacked on. Like, that's one of the things that I do whenever I get to these live hacking events is, you know, I'll get there. I've just spent, you know, three weeks typically for hacker one, two weeks, you know, hacking on this target. I think I'm the world expert on, on this one little web app. And I go into the live hacking event like, all right, guys, show me something I don't know about this web app. And then the guys are like, did you find the three RCEs? And I'm like, damn it, you know.

[01:31:10.05] - Hypr
Like, like, you know, I get to.

[01:31:13.17] - Justin Gardner
The event, you know, and there's always somebody that knows something different, you know, about the app than you did. And wow, how valuable that is to reproduce their bugs and see what they found, you know, and understand your own method methodology on a real world target. That's massive. And I'm also just a big advocate of like, you spend time learning, you spend time doing CTFs, you spend time reversing in days, but at the end of the day, you got to pick a target, you got to go out there and you got to fail, fail, fail, fail, fail, fail, fail, fail for thousands of hours until you actually get to pone some stuff, you know.

[01:31:46.67] - Hypr
Yeah, yeah. And that's the thing, right? Like again, at a fundamental level, the process or the methodology or the technique of for, for completing for like an exploit is well known. It's pretty simple. It's like not simple. I won't say simple, but, but you know, you can, you can learn it well enough. But taking like, it's the difference between theory and practice, right? Like in a theoretical environment where you don't have to concern yourself with like all of the surrounding environment. Yeah, the bugs are relatively simple and you can learn to exploit those bugs in those environments and kind of feel very, you know, confident. Confident about like, oh, I know how to exploit these kinds of bugs. But it's in real world environments and real bugs that you get the, you know, especially. I mean, I'm definitely coming at it from like a binary exploitation, memory corruption perspective, but everything ends up Being the nuance. Everything ends up being the little details, the little things that you know about implementations or how something's going to behave that dictates whether you'll actually get a successful exploit or not. And I think a lot of those things you will, just not really. It'll take you a lot longer if you're going purely through CTFS and these kinds of things to be exposed to those problems. Because when you're trying to write a real exploit for something, right, and you run into this challenge, you're gonna have to decide, do I want to keep trying or do I want to keep trying to find a solution or do I give up? And, and ideally you'll keep trying at least until you feel like you've exhausted all of the options. But it's in that space where you learn the stuff that you end up realizing later on knowing that is super valuable. You run into bugs again. And it's those little things that aren't going to be like they're documented somewhere, but no one's calling them out as being important or significant for this exploit scenario or whatever. But so gaining the exposure to those situations and then having to be forced to like, figure out solutions, just it's, it's a really great learning experience. It's a lot more frustrating, but I do think a lot more frustrating, you get a lot more from it.

[01:33:55.22] - Justin Gardner
Yeah, totally agree, man. Hyper dude, thank you so much for, for coming on and sharing your wisdom with us and showing us the world of kernel driver exploitation. That's, that's pretty sick, dude. I'm very excited to take a look at that eventually.

[01:34:08.02] - Hypr
Um, thank you so much for having me. I really appreciate it.

[01:34:11.22] - Justin Gardner
Appreciate it. Yeah. Is there anything else you want to say as we, as we close out? Anything you want to shout out?

[01:34:18.34] - Hypr
No, I mean, yeah, I'm hyper dude. On Twitter. Hyper without an E. And yeah, check out my blog. I think it'll probably be linked somewhere, but it's blog.coffinsack.com.

[01:34:28.65] - Justin Gardner
Yeah, we'll put that down in the description below. All right, thanks everybody. Bye.

[01:34:32.42] - Hypr
Thank you.

[01:34:32.93] - Justin Gardner
Later. And that's a wrap on this episode of Critical Thinking. Thanks so much for, for watching to the end, y'. All. If you want more Critical Thinking content or if you want to support the show, head over to CTBB Show Discord. You can hop in the community. There's lots of great high level hacking discussion happening there. On top of master classes, hack alongs, exclusive content, and a full time hunters guild. If you're a full time hunter. It's a great time. Trust me. I'll see you there.