WEBVTT 1 00:00:00.000 --> 00:00:05.320 All right, throwing down the gauntlet today. Huh. Arm exploitation fascinating, 2 00:00:05.679 --> 00:00:08.640 a little daunting, to be honest, daunting. Yeah, but that's 3 00:00:08.640 --> 00:00:11.439 why we're here, absolutely, and to guide us through this 4 00:00:11.519 --> 00:00:14.720 digital jungle. We have, well, we've got Billy Ellis's book, 5 00:00:14.759 --> 00:00:19.800 Beginner's Guide to Exploitation on ARM good choice. It's from 6 00:00:19.839 --> 00:00:24.120 twenty seventeen. But the fundamentals of breaking into systems, I 7 00:00:24.160 --> 00:00:25.879 have a feeling those haven't changed too much. 8 00:00:26.039 --> 00:00:28.920 You're right, the core concepts are still very relevant. Like 9 00:00:29.320 --> 00:00:32.880 the tech landscape might change fast, but the foundation, the 10 00:00:32.960 --> 00:00:35.399 underlying principles, those remained pretty solid. 11 00:00:35.600 --> 00:00:39.000 Yeah, like learning chess, the pieces might change, but the strategies, 12 00:00:39.079 --> 00:00:41.880 you know, exactly. And this book, looking at the contents, 13 00:00:41.920 --> 00:00:44.039 it seems perfect for us. It's targeted at, you know, 14 00:00:44.079 --> 00:00:47.039 people starting out in mobile security, folks who want to understand, 15 00:00:47.079 --> 00:00:50.600 like how do you exploit vulnerabilities on devices with those 16 00:00:50.880 --> 00:00:51.880 ARM processors? 17 00:00:52.079 --> 00:00:53.920 Yeah, And I think what's really helpful is it's not 18 00:00:54.039 --> 00:00:57.840 just theory, you know, like it walks you through using tools, 19 00:00:57.880 --> 00:00:59.759 real tools like IDA pro and GDP. 20 00:01:00.000 --> 00:01:01.320 Oh. Yeah, those are the heavy hitters. 21 00:01:01.679 --> 00:01:04.159 They're like giving you X ray vision right into the 22 00:01:04.200 --> 00:01:05.480 heart of a compiled program. 23 00:01:05.959 --> 00:01:08.079 So before we get lost in the assembly code, let's 24 00:01:08.079 --> 00:01:11.000 take a step back. Okay, when we talk about hacking 25 00:01:11.280 --> 00:01:15.239 and binary exploitation, I mean, what are we actually talking about. 26 00:01:15.239 --> 00:01:16.200 What's the big picture? 27 00:01:16.280 --> 00:01:20.840 So it's all about understanding how software can be well manipulated, right, 28 00:01:21.599 --> 00:01:26.760 And this book it dives into discovering vulnerabilities by carefully, 29 00:01:27.280 --> 00:01:31.599 like meticulously analyzing the instructions of a compiled program. It's 30 00:01:31.599 --> 00:01:34.439 almost like detective work. You're examining the evidence, you know, 31 00:01:34.760 --> 00:01:36.519 to figure out how something happened. 32 00:01:36.560 --> 00:01:39.599 Okay, I like the detective analogy. But why should anyone 33 00:01:39.599 --> 00:01:41.719 be worried about this? Like? What kind of damage can 34 00:01:41.760 --> 00:01:43.120 a vulnerability really do? 35 00:01:43.719 --> 00:01:46.840 Okay, imagine a tiny crack in a dam. It might 36 00:01:46.920 --> 00:01:50.599 seem small, insignificant, but under the right pressure, that crack 37 00:01:50.640 --> 00:01:52.920 can grow and the whole thing collapses. Kind of like 38 00:01:52.920 --> 00:01:55.799 that with vulnerabilities. You know, a small vulnerability It might 39 00:01:55.799 --> 00:01:57.959 not seem like much, but it could be exploited and 40 00:01:57.959 --> 00:02:01.200 give an attack or like access to sensitive data or 41 00:02:01.439 --> 00:02:03.239 even control of the entire device. 42 00:02:03.599 --> 00:02:06.799 Yeah, not something I want happening to my phone. So 43 00:02:07.040 --> 00:02:11.159 the book uses Apple's iOS right and its devices as 44 00:02:11.240 --> 00:02:13.599 like a running example. Does that mean this is just 45 00:02:13.639 --> 00:02:15.000 an Apple problem? 46 00:02:15.159 --> 00:02:17.840 No, not at all. This goes way beyond Apple. Think 47 00:02:17.840 --> 00:02:20.639 of it this way. It uses ARM as an example. 48 00:02:20.960 --> 00:02:24.080 But these concepts they're kind of like universal loss the 49 00:02:24.159 --> 00:02:27.319 principles they apply to other architectures too, like by eighty six, 50 00:02:27.520 --> 00:02:31.000 which is in most laptops and desktops. So really, no 51 00:02:31.039 --> 00:02:34.719 matter what device you use, understanding these vulnerabilities it's crucial. 52 00:02:34.719 --> 00:02:36.439 It's like cybersecurity one oh one. 53 00:02:36.560 --> 00:02:39.759 So this is for everyone, basically anyone who uses technology, 54 00:02:39.800 --> 00:02:41.599 which is all of us. Okay, so we need to 55 00:02:41.599 --> 00:02:44.280 delve into the world of these ARM processors. Can you 56 00:02:44.319 --> 00:02:46.319 give us a quick one down on what an ARM 57 00:02:46.400 --> 00:02:47.840 processor actually is? 58 00:02:48.080 --> 00:02:48.360 Sure? 59 00:02:48.400 --> 00:02:51.080 So AARM processors they're kind of the unsung heroes of 60 00:02:51.120 --> 00:02:54.199 a whole mobile revolution, right, designed for energy efficiency, which 61 00:02:54.199 --> 00:02:56.599 is perfect for smartphones and tablets you know, where battery 62 00:02:56.639 --> 00:02:59.560 life is everything. They're like the marathon runners of processors 63 00:03:00.080 --> 00:03:03.439 for endurance, and they're everywhere too, right, everywhere billions of 64 00:03:03.479 --> 00:03:04.680 devices worldwide. 65 00:03:04.840 --> 00:03:08.159 Wow, that's a lot of devices potentially at risk. Okay, 66 00:03:08.240 --> 00:03:12.520 so how do these processors actually work? The book mentions registers? 67 00:03:12.919 --> 00:03:13.560 What are those? 68 00:03:14.080 --> 00:03:18.360 Think of registers as the processors like high speed scratch pad. 69 00:03:18.400 --> 00:03:22.280 They're tiny little storage units inside the CPU. They hold 70 00:03:22.319 --> 00:03:25.439 the data and instructions that the processor is actively working on, 71 00:03:25.479 --> 00:03:28.439 so it's like a super fast workspace for the processor. 72 00:03:28.599 --> 00:03:32.599 Okay, got it. But are all registers created equal or 73 00:03:32.639 --> 00:03:34.680 are some more important than others? 74 00:03:34.879 --> 00:03:37.960 Good question. When we're talking about exploitation. There are two 75 00:03:37.960 --> 00:03:41.759 that really stand out, the program counter or PC and 76 00:03:41.800 --> 00:03:45.479 the link register LR. These are crucial because they control 77 00:03:45.520 --> 00:03:48.280 the program's flow, like where it goes next in the code. 78 00:03:48.599 --> 00:03:50.639 Control those and you control the program. 79 00:03:50.680 --> 00:03:53.000 So if an attacker can tamper with these registers, they 80 00:03:53.000 --> 00:03:55.960 can essentially hijack the program, make it go wherever they 81 00:03:55.960 --> 00:03:56.879 want exactly. 82 00:03:56.960 --> 00:03:59.599 The book actually talks about this instruction called bl which 83 00:03:59.599 --> 00:04:01.879 allows a program to jump to a function and then 84 00:04:02.199 --> 00:04:06.000 importantly return to where it left off. But if someone 85 00:04:06.039 --> 00:04:08.639 messes with that return address stored in the LR, well, 86 00:04:08.639 --> 00:04:11.240 the program could end up taking a detour right into 87 00:04:11.280 --> 00:04:12.240 the attacker's trap. 88 00:04:12.479 --> 00:04:16.560 And that brings us to the infamous stack buffer overflow. 89 00:04:16.959 --> 00:04:19.040 Sounds scary? Can you break that down for us? Like? 90 00:04:19.079 --> 00:04:20.600 Why is it such a favorite for hackers? 91 00:04:20.680 --> 00:04:24.120 Okay, imagine a stack of plates right each time a 92 00:04:24.160 --> 00:04:26.839 program calls a function, it's like adding a plate to 93 00:04:26.920 --> 00:04:30.279 that stack. This creates what's called the stack frame. Now, 94 00:04:30.360 --> 00:04:32.720 let's say a function expects a small piece of data 95 00:04:33.040 --> 00:04:35.399 like a name, but you try to force a whole 96 00:04:35.480 --> 00:04:36.279 novel in there. 97 00:04:36.519 --> 00:04:39.319 Crash, the whole stack overflows, everything falls. 98 00:04:39.160 --> 00:04:43.360 Apart, right, And that's what attackers exploit. By exceeding that 99 00:04:43.399 --> 00:04:46.720 allocated space on the stack, they can overwrite crucial data 100 00:04:46.759 --> 00:04:48.959 like that return a dress we were just talking about, 101 00:04:49.079 --> 00:04:51.399 and this can send the program spiraling into chaos. 102 00:04:51.519 --> 00:04:55.000 Wow, so they're causing a controlled demolition inside the program's memory. 103 00:04:55.120 --> 00:04:58.199 And the book visualizes this with like a vulnerable C 104 00:04:58.399 --> 00:05:01.319 program and some really helpful diagrams of these stack frames. 105 00:05:01.560 --> 00:05:03.639 It's amazing how something as simple as triple m A 106 00:05:04.000 --> 00:05:07.040 can overwrite that return address and hijack the whole thing. 107 00:05:07.279 --> 00:05:10.759 It's simple, but that's the dangerous part. Often these stack 108 00:05:10.839 --> 00:05:14.639 buffer overflows are caused by just like minor coding errors, 109 00:05:15.040 --> 00:05:18.879 but the consequences they could be catastrophic the attacker. In 110 00:05:18.920 --> 00:05:23.199 this example, they redirect the execution to a function called secret. 111 00:05:23.360 --> 00:05:25.600 It's like finding a hidden back door, one that was 112 00:05:25.639 --> 00:05:26.639 never meant to be used. 113 00:05:26.839 --> 00:05:31.680 Okay, So attackers are hijacking programs, uncovering hidden functions, causing mayhem. 114 00:05:32.079 --> 00:05:32.720 What's next? 115 00:05:32.879 --> 00:05:33.120 Next? 116 00:05:33.160 --> 00:05:38.720 We enter the realm of GET this return oriented programming RP. 117 00:05:39.000 --> 00:05:41.160 That sounds, I don't know, like a spy movie or something. 118 00:05:41.199 --> 00:05:43.439 It kind of is. Think of a spy who like 119 00:05:43.759 --> 00:05:46.480 can't bring their own gadgets, They have to improvise using 120 00:05:46.480 --> 00:05:47.360 whatever's on site. 121 00:05:47.439 --> 00:05:48.040 That's ROP. 122 00:05:48.800 --> 00:05:51.319 Instead of injecting their own malicious code, they use these 123 00:05:51.319 --> 00:05:54.480 existing code snippets. They call them gadgets that are already 124 00:05:54.480 --> 00:05:55.639 in the program gadgets. 125 00:05:55.680 --> 00:05:59.079 So they're like repurposing existing code for their own evil deeds. 126 00:05:59.360 --> 00:06:01.480 But why do they do that? Wouldn't be easier to 127 00:06:01.519 --> 00:06:02.800 just inject their own code. 128 00:06:02.920 --> 00:06:06.199 That's where security mechanisms come in. Modern systems have something 129 00:06:06.199 --> 00:06:09.879 called data execution prevention or DEP. It's like a security 130 00:06:09.879 --> 00:06:12.839 guard for the memory, make sure only specific areas can 131 00:06:12.879 --> 00:06:13.839 execute code. 132 00:06:14.000 --> 00:06:17.000 AH. So ROP is a way to bypass the security 133 00:06:17.000 --> 00:06:17.959 guard exactly. 134 00:06:18.000 --> 00:06:20.959 It's like sneaking into the restricted area. The book has 135 00:06:20.959 --> 00:06:24.160 this great example of the baby ROP exploit where they 136 00:06:24.279 --> 00:06:26.959 use just two of these gadgets, they chain them together, 137 00:06:27.240 --> 00:06:29.439 and it ultimately executes a shell command. 138 00:06:29.519 --> 00:06:32.519 It's using the enemy's own weapons against them. Pretty clever. 139 00:06:32.600 --> 00:06:35.000 But wait, there's more. Right, the book has a whole 140 00:06:35.079 --> 00:06:38.920 chapter about patching data with ROP. What is that all about? 141 00:06:39.160 --> 00:06:39.879 So this is a. 142 00:06:39.879 --> 00:06:44.199 Less obvious use of ROP. It's not about directly executing code, 143 00:06:44.279 --> 00:06:49.040 but rather manipulating data. Imagine like a puppeteer pulling the strings. 144 00:06:49.240 --> 00:06:51.600 They can change variables within the program, make it dance 145 00:06:51.639 --> 00:06:52.120 to their tune. 146 00:06:52.199 --> 00:06:54.560 Okay, that sounds devia's But what can they do by 147 00:06:54.680 --> 00:06:57.079 just manipulating data? What's the big deal? 148 00:06:57.319 --> 00:07:01.120 Well, imagine bypassing those crucial security chains. Your operating system 149 00:07:01.160 --> 00:07:04.720 relies on things like signature verification. The book even mentions 150 00:07:04.759 --> 00:07:08.120 the boot process of iOS and how manipulating data could 151 00:07:08.120 --> 00:07:11.959 potentially compromise that whole process. It's all about finding those 152 00:07:12.000 --> 00:07:14.560 critical variables and tweaking them just enough. 153 00:07:14.720 --> 00:07:16.920 So is this where things like jail breaking come in. 154 00:07:17.199 --> 00:07:18.319 Yeah, that's a great example. 155 00:07:18.720 --> 00:07:22.040 Jail breaking often uses vulnerabilities to gain control over a 156 00:07:22.040 --> 00:07:26.560 device's file system and data manipulation through ROP that can be. 157 00:07:26.480 --> 00:07:27.399 A key to the kingdom. 158 00:07:27.600 --> 00:07:30.800 And the book uses this program ROPE Level three to 159 00:07:30.920 --> 00:07:34.600 demonstrate this. And here's the kicker. We don't even have 160 00:07:34.680 --> 00:07:37.360 the source code for it. It's like a real world 161 00:07:37.439 --> 00:07:40.360 scenario where you're facing an unknown program. 162 00:07:40.480 --> 00:07:40.800 Exactly. 163 00:07:40.879 --> 00:07:43.439 You got to think like an attacker. You're analyzing its behavior, 164 00:07:43.480 --> 00:07:46.120 trying to figure out how it works, but without the blueprint. 165 00:07:46.240 --> 00:07:49.279 Okay, so we've got these stack buffer overflows the wild 166 00:07:49.360 --> 00:07:53.279 world of rop. But the defenders, they weren't just sitting around, right, 167 00:07:53.319 --> 00:07:55.160 There had to be some defenses against this. 168 00:07:55.439 --> 00:07:58.639 Absolutely, security is a constant arms race, and one of 169 00:07:58.680 --> 00:08:01.800 the defenses out there is a dress space layout randomization. 170 00:08:01.959 --> 00:08:03.360 We call it ASLR for short. 171 00:08:03.480 --> 00:08:06.000 ASLR catchy, What does it do? 172 00:08:06.439 --> 00:08:09.439 Imagine playing hide and seek, but the hiding spots keep changing. 173 00:08:09.720 --> 00:08:13.399 That's ASLR. It takes key memory regions like the stack 174 00:08:13.439 --> 00:08:16.920 and libraries and randomizes their locations every time you run 175 00:08:16.959 --> 00:08:19.360 a program, so attackers have a harder time, you know, 176 00:08:19.399 --> 00:08:20.319 predicting where to strike. 177 00:08:20.399 --> 00:08:22.480 So it's like hitting a moving target exactly. 178 00:08:22.519 --> 00:08:25.519 It's a really powerful technique, makes exploitation much harder. 179 00:08:25.519 --> 00:08:28.879 But I know these attackers always a workaround, right, There's. 180 00:08:28.639 --> 00:08:31.959 Always a way, and in this case, it's through information leaks, 181 00:08:32.240 --> 00:08:35.240 tiny little cracks in the armor, finding those clues that 182 00:08:35.320 --> 00:08:38.559 reveal the memory layout. No matter how randomized it is. 183 00:08:38.639 --> 00:08:40.279 Like a digital trail of breadcrumbs. 184 00:08:40.639 --> 00:08:43.879 Yes, like rope level four, it has a vulnerability where 185 00:08:43.879 --> 00:08:46.600 it leaks an address in memory. Doesn't seem like much, 186 00:08:46.639 --> 00:08:49.399 but for an attacker it's a gold mine. They use 187 00:08:49.440 --> 00:08:52.399 it to calculate the slide, which is the difference between 188 00:08:52.399 --> 00:08:55.159 the randomized location and the original, and from there they 189 00:08:55.159 --> 00:08:57.720 can work out where everything else is their malicious code. 190 00:08:57.879 --> 00:09:00.519 So even a tiny leak can be fatal. And this 191 00:09:00.639 --> 00:09:02.799 chapter gets even more hands on. It has you writing 192 00:09:02.840 --> 00:09:06.159 a separate C program to carry out the exploit, taking. 193 00:09:05.879 --> 00:09:08.960 Into the next level showing how attackers craft custom tools 194 00:09:08.960 --> 00:09:10.080 to automate their attacks. 195 00:09:10.240 --> 00:09:12.720 This is getting pretty intense, and speaking of leaks, the 196 00:09:12.799 --> 00:09:15.600 next chapter goes even deeper into that world. It seems 197 00:09:15.600 --> 00:09:18.159 like attackers are always thirsty for that little bit of 198 00:09:18.159 --> 00:09:18.919 extra information. 199 00:09:19.240 --> 00:09:24.279 In hacking, information is power in format string vulnerabilities. They're 200 00:09:24.279 --> 00:09:27.600 a prime example of how even harmless coding errors can 201 00:09:27.720 --> 00:09:29.399 lead to serious information leaks. 202 00:09:30.080 --> 00:09:33.679 Format strings like those used in the print function and. 203 00:09:33.840 --> 00:09:36.879 C that's the one. The danger is when user input 204 00:09:36.919 --> 00:09:40.039 isn't sanitized properly before being used in functions like that. 205 00:09:40.480 --> 00:09:43.240 It's like giving someone a megaphone and letting them shout 206 00:09:43.279 --> 00:09:45.360 whatever they want with no filter chaos. 207 00:09:45.799 --> 00:09:47.440 I can see how that would be bad, right. 208 00:09:47.639 --> 00:09:51.159 For example, there's this format specifier percent percent. It can 209 00:09:51.200 --> 00:09:54.120 be abused to leak pointers from the stack, so it's 210 00:09:54.120 --> 00:09:56.000 like giving attackers a peak behind the curtain. 211 00:09:56.120 --> 00:09:58.480 And of course the book has Rope Level five, another 212 00:09:58.600 --> 00:10:01.399 vulnerable program, to to show us how this works. It's 213 00:10:01.399 --> 00:10:05.039 incredible how these seemingly minor coding oversights can be manipulated 214 00:10:05.080 --> 00:10:10.279 to like bypass ASLR and get to that arbitrary code execution. Right. 215 00:10:10.559 --> 00:10:13.120 That's like the holy grail for attackers. 216 00:10:12.600 --> 00:10:13.000 Isn't it? 217 00:10:13.000 --> 00:10:15.559 It is highlights the importance of secure coding. Even a 218 00:10:15.600 --> 00:10:17.799 small oversight it can have a huge impact. 219 00:10:17.879 --> 00:10:20.320 Okay, we've explored the stack how it can be turned 220 00:10:20.320 --> 00:10:23.600 against us, But there's another memory region right, the heap, 221 00:10:24.080 --> 00:10:27.000 and wouldn't you know it, a whole chapter on heap exploitation. 222 00:10:27.320 --> 00:10:27.799 The heap. 223 00:10:28.279 --> 00:10:31.440 Think of it as like the program's messy storage room. 224 00:10:32.000 --> 00:10:35.000 Unlike the stack, which is neat and predictable, the heap 225 00:10:35.039 --> 00:10:38.919 is more dynamic. Memory gets allocated and deallocated in a 226 00:10:39.000 --> 00:10:43.120 less organized way. And this, well, it can lead to vulnerabilities. 227 00:10:43.279 --> 00:10:44.919 That sounds like a recipe for disaster. 228 00:10:45.279 --> 00:10:49.080 It can be Heap buffer overflows are interesting because overflowing 229 00:10:49.120 --> 00:10:52.200 a chunk of memory, it can overwrite beta in those 230 00:10:52.240 --> 00:10:55.600 adjacent chunks could be anything, variables, even function pointers. 231 00:10:55.600 --> 00:10:58.759 Function pointers. So we're back to hijacking the program's flow. 232 00:10:58.879 --> 00:11:02.840 You got it, corrupting those pointers they redirect the program's execution. 233 00:11:03.720 --> 00:11:06.840 The book uses a simple program to show how overflowing 234 00:11:07.240 --> 00:11:10.759 like a username input can trigger shell commands. Just a 235 00:11:10.840 --> 00:11:12.639 simple input field can be weaponized. 236 00:11:12.840 --> 00:11:15.720 So it's all about understanding how things are connected, that 237 00:11:15.840 --> 00:11:18.720 even an isolated input field can have ripple effects. We've 238 00:11:18.759 --> 00:11:24.519 covered stock overflows, rop ASLR bypasses, information leaks, keep exploitation, 239 00:11:25.320 --> 00:11:28.039 anything else? What else do these attackers? How about their sleeves? 240 00:11:28.080 --> 00:11:30.600 Oh, we're just getting started. We still have the use 241 00:11:30.639 --> 00:11:32.600 after free vulnerability lurking in the. 242 00:11:32.559 --> 00:11:35.759 Heap Use after free. The name kind of gives it away. 243 00:11:36.000 --> 00:11:38.720 It does, but it's more complex than it sounds. It's 244 00:11:38.840 --> 00:11:42.480 when a program tries to access memory that has already 245 00:11:42.480 --> 00:11:45.240 been freed, like trying to enter a room that doesn't 246 00:11:45.240 --> 00:11:45.960 exist anymore. 247 00:11:46.000 --> 00:11:47.919 I'm sure that leads to some fun outcomes. 248 00:11:48.000 --> 00:11:51.759 Unpredictable to say the least, the program might access leftover data, 249 00:11:52.000 --> 00:11:55.480 corrupt memory, or even execute malicious code that's been carefully 250 00:11:55.480 --> 00:11:57.000 placed where that freed object was. 251 00:11:57.320 --> 00:11:58.080 It's a trapdoor. 252 00:11:58.399 --> 00:12:00.120 And what's the example in the book for this one? 253 00:12:00.320 --> 00:12:02.799 This one gets really interesting. They look at a vulnerability 254 00:12:02.840 --> 00:12:06.679 found in the iohid family kernel extension, part of the 255 00:12:06.720 --> 00:12:08.480 iOS xnu kernel. 256 00:12:08.600 --> 00:12:11.440 The kernel we're talking about the heart of the operating 257 00:12:11.480 --> 00:12:12.919 system here exactly. 258 00:12:13.360 --> 00:12:16.840 While the book simplifies it exploiting a real UAF in 259 00:12:16.879 --> 00:12:19.399 the kernel, it's much more complex because of all the 260 00:12:19.440 --> 00:12:23.759 security layers. But it shows even the most secure systems 261 00:12:24.000 --> 00:12:24.960 they can be vulnerable. 262 00:12:25.159 --> 00:12:27.480 It is a bit unsettling, makes you think twice about 263 00:12:27.480 --> 00:12:30.200 all those devices we rely on. But this book, it's 264 00:12:30.320 --> 00:12:32.720 just the beginning, right. There's a whole world of arm 265 00:12:32.799 --> 00:12:34.080 exploitation out there. 266 00:12:34.159 --> 00:12:37.679 We've just scratched the surface. There are more advanced techniques, 267 00:12:37.919 --> 00:12:42.159 heep spraying, exploiting race conditions. These require even more skill, 268 00:12:42.559 --> 00:12:44.200 but they can be very powerful. 269 00:12:44.320 --> 00:12:47.240 Heep spraying we touched on that briefly. It's like flooding 270 00:12:47.320 --> 00:12:49.960 the heap with so many objects, hoping your payload land 271 00:12:50.039 --> 00:12:51.480 somewhere predictable. 272 00:12:51.039 --> 00:12:52.720 Like a game of chance, but with strategy. 273 00:12:52.799 --> 00:12:54.240 And race conditions. What are those? 274 00:12:54.519 --> 00:12:58.639 They happen when multiple threads or processes try to access 275 00:12:58.639 --> 00:13:01.279 and change the same data at the same time. It's 276 00:13:01.320 --> 00:13:04.559 like a game of musical chairs. Whoever gets their first wins. 277 00:13:04.879 --> 00:13:08.240 So an attacker could manipulate the timing of these events 278 00:13:08.480 --> 00:13:10.639 make the program do something unexpected. 279 00:13:10.759 --> 00:13:14.360 Exactly exploiting race conditions requires a deep understanding of how 280 00:13:14.399 --> 00:13:19.279 programs work internally. It's a delicate dance timing and precision. 281 00:13:19.600 --> 00:13:22.960 It's amazing how complex this all is. This deep dive, 282 00:13:23.039 --> 00:13:26.480 it's like a crash course in exploit development. We didn't 283 00:13:26.480 --> 00:13:28.399 cover everything, but it's a good foundation. 284 00:13:28.720 --> 00:13:32.519 And remember this landscape is always changing. New vulnerabilities are 285 00:13:32.519 --> 00:13:35.279 discovered all the time. It's a constant back. 286 00:13:35.120 --> 00:13:38.320 And forth, a game of cat and mouse with high stakes. 287 00:13:39.440 --> 00:13:41.320 What are some things we didn't get to that you 288 00:13:41.360 --> 00:13:43.799 think would be good for our listeners to learn more about. 289 00:13:44.279 --> 00:13:48.240 We didn't really get into the advanced mitigation techniques, things 290 00:13:48.279 --> 00:13:52.960 like control flow Integrity CFI and SHADOWSTAX. These are designed 291 00:13:53.000 --> 00:13:55.480 to make it much harder for attackers to hijack the 292 00:13:55.519 --> 00:13:57.960 control flow even if there's a vulnerability. 293 00:13:58.240 --> 00:14:00.200 Powerful tools for the defenders then. 294 00:14:00.159 --> 00:14:02.279 They are and I think it's important to mention we 295 00:14:02.320 --> 00:14:04.200 focus a lot on the technical side, but there's the 296 00:14:04.279 --> 00:14:05.320 human element. 297 00:14:05.000 --> 00:14:06.440 Too, right, right. 298 00:14:06.120 --> 00:14:10.159 Social engineering, phishing attacks, human error, Those are often the 299 00:14:10.159 --> 00:14:13.559 weakest links. No matter how secure your systems are, if 300 00:14:13.559 --> 00:14:16.080 someone falls for a phishing email, well. 301 00:14:15.919 --> 00:14:18.360 It all falls apart. So it's not just about technical skills, 302 00:14:18.360 --> 00:14:19.240 but about awareness. 303 00:14:19.519 --> 00:14:23.919 Absolutely, building that human firewall, training people to recognize and 304 00:14:23.960 --> 00:14:27.759 respond to threats, but also remembering humans are part of 305 00:14:27.759 --> 00:14:28.519 the solution too. 306 00:14:28.600 --> 00:14:30.799 Oh, that's interesting. We often think of humans as the 307 00:14:30.840 --> 00:14:34.080 weak link, but you're saying they're also a strength exactly. 308 00:14:34.480 --> 00:14:39.200 Humans have creativity, intuition, We can identify patterns, make judgments 309 00:14:39.639 --> 00:14:40.799 things machines can't do. 310 00:14:41.080 --> 00:14:43.879 So it's about finding the right balance using the strength 311 00:14:43.960 --> 00:14:45.120 of both right. 312 00:14:45.000 --> 00:14:48.159 And that brings us to AI, artificial intelligence. It's making 313 00:14:48.159 --> 00:14:51.120 its way into cybersecurity and it has the potential to 314 00:14:51.279 --> 00:14:52.120 change everything. A. 315 00:14:52.360 --> 00:14:54.240 I knew you were going to bring that up. It's 316 00:14:54.320 --> 00:14:57.600 everywhere these days. How does it affect arm exploitation? 317 00:14:58.080 --> 00:15:01.639 AI can be used for both attack and defense. Imagine 318 00:15:01.679 --> 00:15:05.840 tools that can automatically scan for vulnerabilities, even create exploits, 319 00:15:06.240 --> 00:15:09.440 but it can also be used to enhance security, find anomalies, 320 00:15:09.480 --> 00:15:10.559 protect systems. 321 00:15:10.240 --> 00:15:12.440 Dolevile, edged sword them depends who's using. 322 00:15:12.320 --> 00:15:14.840 It exactly, and it's evolving so fast it's hard to 323 00:15:14.879 --> 00:15:17.360 keep up. We're just beginning to understand what it means 324 00:15:17.440 --> 00:15:19.080 for cybersecurity, but it's going to. 325 00:15:19.000 --> 00:15:19.960 Play a huge role. 326 00:15:20.240 --> 00:15:23.320 Well, this deep Dive has been quite a journey. We've 327 00:15:23.320 --> 00:15:26.440 gone from the guts of processors to the complexities of 328 00:15:26.480 --> 00:15:28.799 human behavior and now AI. 329 00:15:28.720 --> 00:15:30.120 And we've just scratched the surface. 330 00:15:30.639 --> 00:15:34.279 But the key takeaway is knowledge is power. The more 331 00:15:34.360 --> 00:15:37.360 you understand about how these things work, how attackers think, 332 00:15:37.600 --> 00:15:40.799 how to defend, the better prepared you'll be. This book 333 00:15:40.840 --> 00:15:43.720 is a great start, but it's a continuous process. 334 00:15:43.919 --> 00:15:47.120 Well said, And on that note, we'll take a short break. 335 00:15:50.039 --> 00:15:53.200 Welcome back to our deep dive. We've laid some groundwork, 336 00:15:53.279 --> 00:15:55.159 but let's not get too comfortable, right. 337 00:15:55.240 --> 00:15:56.840 Like, we've learned the alphabet, but now we've got to 338 00:15:56.879 --> 00:15:58.679 start making words exactly. 339 00:15:59.039 --> 00:16:02.080 And speaking of connect the dots. Remember those information leaks, 340 00:16:02.240 --> 00:16:04.120 the ones that can bypass ASLR. 341 00:16:04.279 --> 00:16:05.320 Oh yeah, Well, this. 342 00:16:05.320 --> 00:16:09.000 Next chapter it goes even deeper into that format. String vulnerabilities. 343 00:16:09.039 --> 00:16:11.320 How they can you know, spill the beans. 344 00:16:11.399 --> 00:16:13.840 It's amazing how a little coding error can turn into 345 00:16:14.399 --> 00:16:17.519 like a gold mine for attackers. Remember those print functions. 346 00:16:18.320 --> 00:16:22.159 They're for formatting and displaying information, but if you're not careful, 347 00:16:22.240 --> 00:16:26.159 they can accidentally reveal sensitive data like big time whoops, 348 00:16:26.960 --> 00:16:30.039 like leaving your bank pinna on a sticky note pretty much. 349 00:16:30.480 --> 00:16:33.759 So imagine an attacker they send a specially crafted string 350 00:16:33.879 --> 00:16:36.679 to a program using print, but it doesn't. 351 00:16:36.399 --> 00:16:37.559 Have good input validation. 352 00:16:37.960 --> 00:16:41.559 Oh, they can sneak in these format specifiers like per 353 00:16:41.639 --> 00:16:45.559 scene day that trick the function into revealing memory addresses. 354 00:16:46.080 --> 00:16:48.799 It's like asking a sneaky question that makes the program 355 00:16:48.879 --> 00:16:50.000 blurt out its secrets. 356 00:16:50.159 --> 00:16:53.360 So it's not just displaying information, it's manipulating how it's 357 00:16:53.399 --> 00:16:56.360 displayed to get at hidden data exactly. 358 00:16:56.480 --> 00:16:59.000 The book uses rope level five as an example. It's 359 00:16:59.080 --> 00:17:03.480 vulnerable and by exploiting this format string thing, attackers can 360 00:17:03.480 --> 00:17:07.319 bypass ASLR, figure out the memory layout and boom, arbitrary 361 00:17:07.319 --> 00:17:09.640 code execution. They've got the keys to the kingdom. 362 00:17:09.799 --> 00:17:12.839 It really shows how even those basic functions, if they're 363 00:17:12.880 --> 00:17:17.279 not used carefully, can have major consequences. Input validation, secure coding, 364 00:17:17.319 --> 00:17:17.759 that's key. 365 00:17:17.880 --> 00:17:18.720 Couldn't agree more. 366 00:17:18.880 --> 00:17:22.319 Okay, let's shift gears a bit heap exploitation. Remember the heap, 367 00:17:22.559 --> 00:17:24.319 that messy storage room for memory. 368 00:17:24.400 --> 00:17:25.200 Oh yeah, the heat. 369 00:17:25.240 --> 00:17:27.400 It's not as chaotic as it seems, though, right. 370 00:17:27.319 --> 00:17:28.000 Not entirely. 371 00:17:28.240 --> 00:17:31.440 Attackers have found ways, clever ways to exploit it. 372 00:17:31.720 --> 00:17:34.359 Heap buffer overflows. We talked about those a bit. Why 373 00:17:34.400 --> 00:17:35.279 are they such a big deal? 374 00:17:35.359 --> 00:17:39.240 Okay, Imagine the heap is like a neighborhood. Each house 375 00:17:39.319 --> 00:17:42.039 is a chunk of memory. Now one house has a 376 00:17:42.039 --> 00:17:44.759 wild party, spills over into the neighbor's yard. 377 00:17:44.960 --> 00:17:45.599 Sounds messy. 378 00:17:45.720 --> 00:17:48.559 That's a heap buffer overflow. It goes beyond its allocated space, 379 00:17:48.839 --> 00:17:53.279 spills into the next chunk. Could corrupt data, overwrite function pointers, 380 00:17:53.359 --> 00:17:55.000 all sorts of fun function pointers. 381 00:17:55.000 --> 00:17:57.160 There they are again, back to hijacking the flow. 382 00:17:57.279 --> 00:18:02.359 You got it, corrupt those pointers redirec execution. The book 383 00:18:02.440 --> 00:18:05.640 it uses this example where overflowing a username input can 384 00:18:05.680 --> 00:18:10.119 trigger shell commands. So even a simple input can be dangerous. 385 00:18:09.880 --> 00:18:12.839 Like finding a secret passage in a normal house leads 386 00:18:12.880 --> 00:18:15.680 to a hidden control room. And then I think we've 387 00:18:15.720 --> 00:18:18.440 reached the big battye of the heap. The us after 388 00:18:18.519 --> 00:18:19.720 free or UAF. 389 00:18:19.960 --> 00:18:20.640 The UAF. 390 00:18:21.200 --> 00:18:25.279 This one's tricky to understand and to exploit. It's when 391 00:18:25.279 --> 00:18:27.880 a program tries to access memory that's already been free, 392 00:18:28.000 --> 00:18:29.519 like entering a room this nighty there. 393 00:18:29.400 --> 00:18:32.799 Anymore, and that leads to nah. I can only imagine chaos. 394 00:18:33.359 --> 00:18:37.880 The program could access leftover data, corruct memory, even execute 395 00:18:37.920 --> 00:18:41.480 malicious code that's been placed right where that freed object was, 396 00:18:41.880 --> 00:18:43.079 like stepping on a trapdoor. 397 00:18:43.240 --> 00:18:46.720 So not just crashing the program, but actually running malicious. 398 00:18:46.200 --> 00:18:50.039 Code potentially, Yes, And the example they use it gets real. 399 00:18:50.680 --> 00:18:54.480 A vulnerability found in the iohte mamly kernel extension that's 400 00:18:54.519 --> 00:18:56.039 part of the iosx in U. 401 00:18:56.000 --> 00:18:58.160