WEBVTT 1 00:00:00.040 --> 00:00:01.879 Ever wonder what happens in that split second when you 2 00:00:01.919 --> 00:00:02.720 click on a program. 3 00:00:02.799 --> 00:00:05.160 It seems so simple, doesn't it, Yeah, exactly. 4 00:00:05.000 --> 00:00:08.519 But apparently it kicks off this incredibly complex series of 5 00:00:08.560 --> 00:00:11.679 events deep inside your Windows system. 6 00:00:11.800 --> 00:00:14.839 It's a whole journey. And you know, as we'll find out, 7 00:00:14.919 --> 00:00:19.199 that complexity can sometimes well, it can open doors for vulnerabilities. 8 00:00:19.359 --> 00:00:22.120 Right, So today we're doing a deep dive into that 9 00:00:22.199 --> 00:00:26.280 hidden world Windows internals. We're using that book you shared, 10 00:00:26.440 --> 00:00:28.960 Windows ABT Warfare as our guide. 11 00:00:29.000 --> 00:00:32.520 That's the one. And yeah, this isn't your average user guide. 12 00:00:32.600 --> 00:00:35.399 It's really aimed at people who want to get under 13 00:00:35.439 --> 00:00:37.479 the hood of Windows security. 14 00:00:37.039 --> 00:00:39.280 Wise, like engineers, malware folks. 15 00:00:39.000 --> 00:00:43.039 Exactly, Windows engineers, malware researchers, ethical hackers, people like that. 16 00:00:43.079 --> 00:00:46.159 It gets really hands on with stuff like reverse engineering, 17 00:00:46.240 --> 00:00:49.320 exploit development, how attacks actually work at a low level. 18 00:00:49.439 --> 00:00:51.960 Okay, So our mission today then is to pull out 19 00:00:52.039 --> 00:00:55.799 the really crucial, maybe even the mind blowing stuff from 20 00:00:55.840 --> 00:00:56.200 this book. 21 00:00:56.320 --> 00:00:57.679 Yeah, to still it down right. 22 00:00:57.880 --> 00:01:01.759 We want to give you the listener those aha moments 23 00:01:01.960 --> 00:01:04.959 about how Windows programs get built, how they run. 24 00:01:04.920 --> 00:01:08.280 And critically, how that whole process can be targeted, how 25 00:01:08.359 --> 00:01:10.599 it can be manipulated by attackers. 26 00:01:10.159 --> 00:01:13.000 Exactly, trying to cut through some of the heavy technical 27 00:01:13.120 --> 00:01:15.319 jargon and make it, you know, engaging. 28 00:01:15.439 --> 00:01:18.000 Absolutely think of it as a guided tour of Windows 29 00:01:18.040 --> 00:01:21.519 Core using the book's insights. We'll hit the key mechanisms, 30 00:01:21.560 --> 00:01:23.120 the security side of things, so. 31 00:01:23.079 --> 00:01:25.959 You get a quick but hopefully thorough grasp of some 32 00:01:26.000 --> 00:01:27.120 fundamental ideas. 33 00:01:27.280 --> 00:01:31.120 Right, and this knowledge is honestly pretty powerful, whether you 34 00:01:31.200 --> 00:01:34.359 just want to stay informed, or understand software better, or 35 00:01:34.359 --> 00:01:36.959 maybe even prep for some technical cybersecurity chats. 36 00:01:37.040 --> 00:01:39.640 Okay, let's get started in time for that deep dive 37 00:01:39.680 --> 00:01:44.480 into Windows APT warfare, uncovering how programs come alive and 38 00:01:44.519 --> 00:01:47.200 why that's maybe a double edged sword sometimes. 39 00:01:46.959 --> 00:01:48.920 Let's do it. We should probably start right at the 40 00:01:48.920 --> 00:01:52.280 beginning the journey. A simple C program takes from code 41 00:01:52.280 --> 00:01:56.159 someone writes to well to a running process on your. 42 00:01:56.040 --> 00:02:00.000 Machine, even just Hello World, Right, seems basic, but there's 43 00:02:00.120 --> 00:02:01.879 a whole transformation happening behind. 44 00:02:01.680 --> 00:02:04.239 The scenes totally. First up, you've got the C compiler. 45 00:02:04.439 --> 00:02:06.000 Okay, what's its job? Exact? 46 00:02:06.159 --> 00:02:10.039 It basically translates that human readable C code into assembly 47 00:02:10.159 --> 00:02:11.520 language assembly. 48 00:02:12.000 --> 00:02:13.960 Now, for those of us maybe not deep into coding, 49 00:02:14.479 --> 00:02:17.000 how's that different? From C. Why does that matter here? 50 00:02:17.080 --> 00:02:20.800 Good question. C is relatively high level, closer to how 51 00:02:20.800 --> 00:02:24.000 we think. Assembly is much much closer to what the 52 00:02:24.000 --> 00:02:27.240 computer's processor actually understands. 53 00:02:26.479 --> 00:02:28.639 So like direct instructions for the chip. 54 00:02:28.479 --> 00:02:32.199 Pretty much each assembly line is usually one tiny instruction 55 00:02:32.240 --> 00:02:35.520 for the processor. And understanding that level is key because 56 00:02:35.560 --> 00:02:39.439 a lot of core Windows functions and definitely malware operate 57 00:02:39.560 --> 00:02:39.960 down there. 58 00:02:40.039 --> 00:02:43.319 Okay, so C to assembly, then what there's an assembler 59 00:02:43.319 --> 00:02:43.840 involved too? 60 00:02:44.080 --> 00:02:46.840 Yep. The assembler takes that assembly code and turns it 61 00:02:46.840 --> 00:02:48.800 into the actual machine code. 62 00:02:48.560 --> 00:02:51.000 The raw binary ones and zeros. 63 00:02:51.120 --> 00:02:53.400 That's it, the processor's native language. 64 00:02:53.680 --> 00:02:58.080 The book mentioned tools like TDMGCC visual Studio, those are 65 00:02:58.120 --> 00:02:59.759 the things doing this compiling and. 66 00:02:59.719 --> 00:03:04.199 A SI exactly those tools integrated development environments. They handle 67 00:03:04.240 --> 00:03:06.879 all these steps for you, packaging your C code into 68 00:03:06.919 --> 00:03:08.240 that final runnable file. 69 00:03:08.639 --> 00:03:11.280 But it's not just the machine code thrown into a file, 70 00:03:11.400 --> 00:03:15.759 is it? The Windows linker steps in here? Sounds important? 71 00:03:15.759 --> 00:03:19.319 Oh, absolutely crucial. The linker takes all the compiled machine code, 72 00:03:19.680 --> 00:03:23.879 grabs any other bits of the program needs like libraries, data, 73 00:03:24.319 --> 00:03:27.080 and packages it all up, packages it into the portable 74 00:03:27.120 --> 00:03:30.599 executable format, the PE format. That's your standard dot ex 75 00:03:30.800 --> 00:03:32.159 file in Windows. 76 00:03:31.759 --> 00:03:34.599 Okay, PE format. What key things does the linker pack 77 00:03:34.719 --> 00:03:36.599 in there? The book's mentioned a few. 78 00:03:36.520 --> 00:03:39.560 Right, Well, it sets a default image based address often 79 00:03:39.680 --> 00:03:42.639 zero by four hundred thousand. That's like the program's preferred 80 00:03:42.680 --> 00:03:46.120 home in memory referred okay, And it organizes everything into 81 00:03:46.159 --> 00:03:48.520 sections within that PE file, like. 82 00:03:48.439 --> 00:03:50.199 The dot text section. What's that for? 83 00:03:50.319 --> 00:03:53.439 That's where the actual executable code lives. Then you've got 84 00:03:53.479 --> 00:03:56.800 dot I data read only data like text string exactly 85 00:03:56.879 --> 00:04:00.000 like your Hello World string. And then there's dot iData 86 00:04:00.159 --> 00:04:03.280 that holds the import address table or IAT BIAT. 87 00:04:03.840 --> 00:04:05.919 Something tells me we'll be hearing more about that one. 88 00:04:06.000 --> 00:04:06.759 What's its job? 89 00:04:07.000 --> 00:04:09.919 Think of it like your program's phone book for outside help. 90 00:04:10.199 --> 00:04:12.439 It lists all the functions your program needs to call 91 00:04:12.479 --> 00:04:16.079 from other places, usually Windows own libraries. 92 00:04:15.840 --> 00:04:19.720 The DLLs, so it knows who to call for certain tasks, right, And. 93 00:04:19.680 --> 00:04:22.600 When your program runs, Windows uses the IAT to find 94 00:04:22.639 --> 00:04:26.759 the actual memory addresses of those functions. But crucially, if 95 00:04:26.800 --> 00:04:29.199 an attacker can rewrite those phone numbers. 96 00:04:29.160 --> 00:04:32.480 Ah, they can redirect calls to their own code exactly. 97 00:04:32.720 --> 00:04:35.079 It's a key vulnerability point. We'll definitely come back to 98 00:04:35.160 --> 00:04:38.519 that The linker also adds the optional header tons of 99 00:04:38.560 --> 00:04:40.199 metadata the loader needs later. 100 00:04:40.480 --> 00:04:43.759 Okay, so we've got this static PE file on disc 101 00:04:44.199 --> 00:04:47.279 How does it become a living, breathing process in memory. 102 00:04:47.879 --> 00:04:50.600 That's the system application loader's job. Yep. 103 00:04:50.639 --> 00:04:53.240 The loader takes that PE file and brings it to life. 104 00:04:53.480 --> 00:04:57.279 It reads those sections code data imports, and carefully places 105 00:04:57.360 --> 00:04:58.399 them into memory. 106 00:04:58.079 --> 00:05:00.879 Following the instructions in the pehaders. 107 00:05:00.079 --> 00:05:03.759 Precisely using that base address as a starting point. It 108 00:05:03.800 --> 00:05:06.240 writes the sections to memory at the right offsets and 109 00:05:06.279 --> 00:05:08.759 does some initial setup to get the program ready to run. 110 00:05:09.000 --> 00:05:11.639 So it's not just copying, it's really constructing the process 111 00:05:11.639 --> 00:05:13.160 and memory more dynamic than. 112 00:05:13.040 --> 00:05:16.680 I thought, absolutely, and getting this initial journey CCODE to 113 00:05:16.759 --> 00:05:20.199 running process. It's fundamental. It really sets the stage for 114 00:05:20.240 --> 00:05:23.360 all the security stuff the book dives into later how 115 00:05:23.399 --> 00:05:25.079 this very process gets targeted. 116 00:05:25.279 --> 00:05:28.360 Right, So building on that, how the PE file gets made. 117 00:05:29.079 --> 00:05:32.360 Chapter two looks at how that static file actually lays 118 00:05:32.399 --> 00:05:35.279 out in memory when it's running process memory. 119 00:05:35.439 --> 00:05:37.879 Yeah, how those PE parts, the doss header, the NT 120 00:05:38.040 --> 00:05:40.279 headers with the file header, and the optional header, the 121 00:05:40.279 --> 00:05:44.040 section headers. How they all get mapped into the process's 122 00:05:44.120 --> 00:05:45.199 virtual memory space. 123 00:05:45.319 --> 00:05:47.839 It's all structured following the rules laid out in those 124 00:05:47.839 --> 00:05:48.800 headers exactly. 125 00:05:48.879 --> 00:05:51.399 The book talks about the file mapping process, how the 126 00:05:51.439 --> 00:05:54.920 system copies bits of the PE file into memory addresses. 127 00:05:55.240 --> 00:05:57.000 It uses things like size of headers. 128 00:05:57.040 --> 00:05:59.319 That's how big the header part is, right, and. 129 00:05:59.279 --> 00:06:03.120 Then to raw data and relative virtual address RVA guide 130 00:06:03.120 --> 00:06:05.480 where the content of each section goes in memory. 131 00:06:05.600 --> 00:06:09.160 RVA relative virtual address so like an offset from the. 132 00:06:09.160 --> 00:06:12.680 Start pretty much an address relative to the module's base 133 00:06:12.800 --> 00:06:16.839 address in memory. Understanding rva's is key if you ever 134 00:06:16.839 --> 00:06:19.560 want to pick apart a PE file or understand how 135 00:06:19.600 --> 00:06:20.800 things link up internally. 136 00:06:21.079 --> 00:06:25.519 Okay, and knowing how this mapping works leads into some well, 137 00:06:25.560 --> 00:06:28.360 some shadier techniques discussed in the book, Yeah, like PE 138 00:06:28.519 --> 00:06:30.480 infection or PE patching. 139 00:06:30.639 --> 00:06:34.639 Yeah. The core idea there is adding your own malicious section, 140 00:06:34.759 --> 00:06:36.040 maybe with some shell code. 141 00:06:36.160 --> 00:06:39.319 Shell code being that small, self contained bit of malicious. 142 00:06:38.920 --> 00:06:41.160 Code, right, You add that to a normal program. Then 143 00:06:41.199 --> 00:06:43.160 you tweak the program's entry point. 144 00:06:43.000 --> 00:06:45.720 So when the program starts, it runs the malicious code first. 145 00:06:45.839 --> 00:06:49.759 Exactly, it gets redirected. It sounds really hard to spot too, would. 146 00:06:49.519 --> 00:06:52.800 A normal user even notice anything? What are the signs? 147 00:06:53.160 --> 00:06:56.199 That's the tricky part. The original program might still seem 148 00:06:56.240 --> 00:06:58.759 to work fine afterwards, maybe it takes a bit longer 149 00:06:58.759 --> 00:07:02.680 to start unusual network activity. Security software might flag it, 150 00:07:02.720 --> 00:07:05.879 hopefully by spotting the extra section or the modified entry point. 151 00:07:05.920 --> 00:07:07.120 But yeah, it can be subtle. 152 00:07:07.160 --> 00:07:10.600 The book used that Pikachu volleyball example. Right, infecting pickaball 153 00:07:10.639 --> 00:07:11.199 dot ex. 154 00:07:11.720 --> 00:07:14.959 Yeah, you think you're launching a game, but note something 155 00:07:14.959 --> 00:07:17.399 else runs first really drives the point. 156 00:07:17.480 --> 00:07:21.240 Huh, definitely. And then there's process hollowing That sounds even sneakier. 157 00:07:21.319 --> 00:07:24.079 It's a step up, for sure. An attacker starts a 158 00:07:24.160 --> 00:07:29.000 legitimate process, say Google Update dot ex, but pauses it 159 00:07:29.040 --> 00:07:32.240 immediately creates it in a suspended state. 160 00:07:32.439 --> 00:07:35.120 Okay, so it's loaded but not running code yet. Right. 161 00:07:35.319 --> 00:07:38.639 Then they basically hollow it out. They unmap its original 162 00:07:38.680 --> 00:07:41.839 memory and replace it entirely with their own malicious code. 163 00:07:42.000 --> 00:07:44.720 So the legit process is just a shell, a container 164 00:07:44.800 --> 00:07:46.639 for the bad stuff exactly. 165 00:07:46.759 --> 00:07:50.720 And the really deceptive part, the process's internal data structures 166 00:07:50.920 --> 00:07:53.160 like the people we'll talk about, might still point to 167 00:07:53.199 --> 00:07:55.040 the original Google Update dot. 168 00:07:54.879 --> 00:07:56.959 Ex, so it looks legitimate to the system. 169 00:07:57.120 --> 00:08:00.000 It can. Yeah, the book even says sometimes the original 170 00:08:00.279 --> 00:08:04.079 digital signature can appear valid because the systems looking at 171 00:08:04.079 --> 00:08:07.560 the initial process information, not the hollowed out content, makes 172 00:08:07.560 --> 00:08:08.600 detection way harder. 173 00:08:08.720 --> 00:08:12.519 Wow hiding and plain sight. The book also mentions tiny linker. 174 00:08:12.560 --> 00:08:13.240 What's that about? 175 00:08:13.279 --> 00:08:15.959 Oh yeah, tiny linker, It's about building a really stripped 176 00:08:16.000 --> 00:08:18.879 down minimal compiler and linker. 177 00:08:19.160 --> 00:08:19.920 Why would you do that? 178 00:08:20.240 --> 00:08:23.959 Well, partly to understand the absolute bare minimum needed for 179 00:08:24.000 --> 00:08:26.800 a PE file, But attackers like it because they can 180 00:08:26.879 --> 00:08:31.959 create incredibly small executables, tiny payloads that might slip past 181 00:08:32.000 --> 00:08:35.440 some security checks that look for larger, more complex files. 182 00:08:35.559 --> 00:08:38.480 Okay, so from legit programs loading, we're already seeing how 183 00:08:38.519 --> 00:08:41.600 those mechanics get twisted. Chapter three moves on to how 184 00:08:41.679 --> 00:08:45.320 running programs talk to Windows Dynamic API calling. 185 00:08:45.399 --> 00:08:49.519 Right, programs need to ask Windows to do things open files, 186 00:08:49.600 --> 00:08:52.399 show Windows talk to the network. They do this by 187 00:08:52.399 --> 00:08:57.120 calling Windows APIs application programming interfaces. Often this happens right 188 00:08:57.159 --> 00:08:58.720 down at the assembly code level. 189 00:08:58.559 --> 00:09:00.480 And there are rules for how these calls are made. 190 00:09:00.480 --> 00:09:03.120 Conventions like WinAPI exactly. 191 00:09:03.360 --> 00:09:07.080 Calling conventions are like protocols for function calls. They dictate 192 00:09:07.120 --> 00:09:10.000 how arguments get passed on the stack in registers. Who 193 00:09:10.080 --> 00:09:13.200 cleans up the memory afterwards, where does a return value go? 194 00:09:13.559 --> 00:09:15.559 The book used message box as an example. 195 00:09:15.639 --> 00:09:17.799 The pop up box yeah, a classic example of the 196 00:09:17.840 --> 00:09:21.399 WinAPI convention. Parameters usually pushed onto the stack right to left, 197 00:09:21.639 --> 00:09:24.320 and the message box a function itself, cleans up the 198 00:09:24.360 --> 00:09:25.279 stack when it's done. 199 00:09:25.600 --> 00:09:29.360 Okay. Then the book introduces these really important but apparently 200 00:09:29.360 --> 00:09:32.960 often undocumented structures, the TEB and the PEB. 201 00:09:33.159 --> 00:09:37.000 Ah Yes, the thread environment block TB and the process 202 00:09:37.080 --> 00:09:40.840 environment block P. They hold a gold mine of info 203 00:09:40.960 --> 00:09:42.120 about a running program. 204 00:09:42.279 --> 00:09:45.960 So TEB is for threads, individual execution. 205 00:09:45.559 --> 00:09:49.720 Paths, exactly thread specific data. The book highlights fields like 206 00:09:49.879 --> 00:09:53.320 exceptionalists for error handling, stack base and stack limit defining 207 00:09:53.320 --> 00:09:57.720 the threads, stack memory, client TITE holding process and thread IDs. 208 00:09:57.519 --> 00:10:00.440 And crucially a pointer to the P right and. 209 00:10:00.399 --> 00:10:03.039 A pointer to itself. So the PAY, on the other hand, 210 00:10:03.080 --> 00:10:04.720 holds info for the entire process. 211 00:10:04.759 --> 00:10:05.799 What kind of stuff is in the P. 212 00:10:06.159 --> 00:10:09.279 Things like the being debugged flag. Malware hates debuggers, so 213 00:10:09.320 --> 00:10:11.639 they check this. There's the image base address where the 214 00:10:11.679 --> 00:10:15.960 main program module loaded process parameters, has info like command 215 00:10:16.039 --> 00:10:18.960 line arguments, and a really important one a pointer to 216 00:10:19.159 --> 00:10:20.159 pebble door data. 217 00:10:20.200 --> 00:10:23.440 Pebble door data sounds like it releads to loading things. 218 00:10:23.519 --> 00:10:26.279 It does. It's all about the modules, the DLLs that 219 00:10:26.320 --> 00:10:28.200 the process is loaded into its memory. 220 00:10:28.559 --> 00:10:31.399 So these TIB and PEB structures give a program context 221 00:10:31.480 --> 00:10:34.440 self awareness, and the book says you can sometimes access 222 00:10:34.440 --> 00:10:37.639 this info directly without using standard Windows functions. 223 00:10:37.840 --> 00:10:40.919 Yeah, especially in thirty two bit Windows. The FS segment 224 00:10:40.960 --> 00:10:44.120 register often points to the teb letting code access feels 225 00:10:44.120 --> 00:10:47.200 directly GS register in sixty four bit. This is how 226 00:10:47.279 --> 00:10:50.440 stealthy malware can gather info about its environment without making 227 00:10:50.559 --> 00:10:53.240 noisy API calls that security software might be watching. 228 00:10:53.399 --> 00:10:56.639 Sneaky at pebble. D R data structure sounds key then 229 00:10:56.960 --> 00:10:58.919 for tracking loaded DLLs. 230 00:10:58.600 --> 00:11:02.799 It is. It contains links inload order. Modulist tracks DLLs 231 00:11:02.799 --> 00:11:05.840 in the order they loaded. In memory order. Modulists tracks 232 00:11:05.840 --> 00:11:09.879 them by memory address, an initialization order. Modulist, well, that's 233 00:11:09.919 --> 00:11:11.120 about initialization order. 234 00:11:11.200 --> 00:11:14.120 And each entry in these lists is an LDR datable 235 00:11:14.279 --> 00:11:17.080 entry holding details about each DLL YEP. 236 00:11:17.039 --> 00:11:20.440 Things like the DLL's base address in memory dll base, 237 00:11:20.519 --> 00:11:23.679 its entry point, its size, its full path and file name, 238 00:11:23.759 --> 00:11:25.759 a full down name based a law name, even a 239 00:11:25.799 --> 00:11:27.919 load count showing how many times it's been referenced. 240 00:11:28.080 --> 00:11:31.080 Wow tons of detail, and the book explains how attackers 241 00:11:31.080 --> 00:11:31.519 can use this. 242 00:11:31.679 --> 00:11:34.639 Walk through these lists exactly. They can traverse the pet 243 00:11:34.759 --> 00:11:38.360 LDR structure follow the pointers in those link lists to 244 00:11:38.399 --> 00:11:41.240 find the base address of a specific DLL they need, 245 00:11:41.559 --> 00:11:43.879 like kernel thirty two dot dll. 246 00:11:43.559 --> 00:11:46.519 Without calling load library or get module handle. 247 00:11:46.559 --> 00:11:50.360 Right, they find it manually internally evades detection that might 248 00:11:50.399 --> 00:11:53.519 be watching those specific API calls. It's like using an 249 00:11:53.519 --> 00:11:56.639 internal undocumented map instead of asking for directions. 250 00:11:56.759 --> 00:11:59.039 Very clever. It gets worse the can thisss with these entries. 251 00:11:59.159 --> 00:12:02.039 Yeah. The book mentions techniques to actually modify the LDR 252 00:12:02.120 --> 00:12:06.360 datable entry structures. You could potentially rename a loaded DLL 253 00:12:06.360 --> 00:12:09.960 in memory, just change the name string to confuse analysis tools, 254 00:12:10.200 --> 00:12:14.519 or even unlink malicious DLL entirely from these lists hide module, 255 00:12:14.960 --> 00:12:17.919 making it invisible to standard enumeration methods. 256 00:12:18.000 --> 00:12:22.000 That's serious manipulation. The chapter also mentions parameter forgery changing 257 00:12:22.000 --> 00:12:23.159 command line arc briefly. 258 00:12:23.240 --> 00:12:26.360 Yeah, create a process suspended, then go into its PEB 259 00:12:26.440 --> 00:12:29.480 and fiddle with the process parameter structure to change what 260 00:12:29.559 --> 00:12:31.600 command line arguments it thinks it was launched. 261 00:12:31.600 --> 00:12:34.440 With so many ways to mess with a process. Once 262 00:12:34.480 --> 00:12:37.639 you understand these internals. Okay. Chapter four goes back to 263 00:12:37.679 --> 00:12:41.879 shell code, specifically how it finds those Windows API functions 264 00:12:41.919 --> 00:12:43.200 it needs. Right. 265 00:12:43.279 --> 00:12:46.879 Because shell cut often gets injected in weird ways, it 266 00:12:46.960 --> 00:12:49.960 can't rely on the normal loading process setting up that 267 00:12:50.039 --> 00:12:53.799 import address table IAT for it. It has to find 268 00:12:53.840 --> 00:12:56.559 functions itself dynamically at run time. 269 00:12:56.600 --> 00:12:59.919 And the key is the export address table the E within. 270 00:12:59.679 --> 00:13:03.639 Each LL Exactly, The ET is like the dla's public directory. 271 00:13:04.039 --> 00:13:06.600 It lists all the functions the DLA exports for others 272 00:13:06.639 --> 00:13:08.559 to use what's in the ET. It has a few 273 00:13:08.639 --> 00:13:11.559 key arrays. Address of functions points to the actual code 274 00:13:11.559 --> 00:13:15.399 for each exported function, as rva's address of names points 275 00:13:15.440 --> 00:13:17.720 to the names of the functions, and address of name 276 00:13:17.840 --> 00:13:20.120 ordinals maps the names to ordinal numbers. 277 00:13:20.159 --> 00:13:22.320 So shell code can read this ET to find the 278 00:13:22.360 --> 00:13:25.879 address of, say, create filet A inside kernel three D 279 00:13:25.960 --> 00:13:27.440 two dot DL precisely. 280 00:13:27.519 --> 00:13:29.519 The book even talks about building a simple tool to 281 00:13:29.559 --> 00:13:32.080 purse a DL's ET and list its exports. Then it 282 00:13:32.080 --> 00:13:34.799 shows how shell code uses the TBNP tricks we just 283 00:13:34.840 --> 00:13:38.120 discussed to first find the DL's base address and memory. 284 00:13:38.240 --> 00:13:40.639 Like finding kernel threet two dot DLL's. 285 00:13:40.200 --> 00:13:44.679 Address right, and then it manually parses that DL's PE 286 00:13:44.840 --> 00:13:47.919 headers to find the ET, and then searches through the 287 00:13:48.279 --> 00:13:51.639 ET's arrays address of names, address off name ordinals, address 288 00:13:51.639 --> 00:13:54.679 of functions to locate the exact memory address of the 289 00:13:54.679 --> 00:13:56.120 specific function at once. 290 00:13:56.080 --> 00:13:58.279 All without calling get proke address. 291 00:13:58.240 --> 00:14:01.600 Exactly, totally self sufficient, like a little detective inside the 292 00:14:01.639 --> 00:14:02.440 process memory. 293 00:14:02.519 --> 00:14:05.720 That's amazing. The chapter actually walks through writing by eighty 294 00:14:05.759 --> 00:14:07.279 six assembly shell code to do this. 295 00:14:07.480 --> 00:14:09.799 That sounds intense, it is definitely low level. The thirty 296 00:14:09.799 --> 00:14:12.240 two B shell code dot atism example in the book 297 00:14:12.279 --> 00:14:15.840 is detailed shows accessing TUB, finding PAYAB, walking the LDR 298 00:14:15.840 --> 00:14:19.159 list for kernel thirty two dot DL, parsing its headers, 299 00:14:19.399 --> 00:14:22.559 finding the EET, and then crawling the ET tables to 300 00:14:22.600 --> 00:14:25.240 get the address for fatal exit. It's a masterclass in 301 00:14:25.320 --> 00:14:27.000 manual low level function resolution. 302 00:14:27.080 --> 00:14:29.840 Phew. Okay, But for those not quite ready for assembly, 303 00:14:30.240 --> 00:14:33.320 the book mentions automating shell code generation from C or 304 00:14:33.399 --> 00:14:34.360 C plus plus AP. 305 00:14:34.480 --> 00:14:37.320 Yeah. Thankfully, there are tools and techniques to compile CC 306 00:14:37.480 --> 00:14:40.480 plus plus code down into position independent shell code, which 307 00:14:40.519 --> 00:14:43.559 makes it much more accessible. Kind of bridges the gap makes. 308 00:14:43.399 --> 00:14:47.559 Sense, okay. Chapter five dives deeper into the application loader itself, 309 00:14:47.639 --> 00:14:51.600 especially that import address table, the IAT. We keep mentioning. 310 00:14:51.720 --> 00:14:55.360 Yeah, the IAT is just so central to recap. It's 311 00:14:55.440 --> 00:14:58.559 that table of function pointers and module. When the loader 312 00:14:58.639 --> 00:15:02.120 loads your program at, the IAT sees which functions you 313 00:15:02.200 --> 00:15:04.039 need from other DLLs, goes. 314 00:15:03.879 --> 00:15:06.919 And finds the real addresses of those functions in memory. 315 00:15:06.639 --> 00:15:10.240 And patches the IAT, filling in those pointers. So when 316 00:15:10.279 --> 00:15:13.960 your code calls say create filarea, the IAT entry now 317 00:15:13.960 --> 00:15:17.279 points directly to the real create filia code loaded somewhere 318 00:15:17.320 --> 00:15:20.559 in memory, connects the dots exactly. It wires everything up. 319 00:15:20.799 --> 00:15:23.679 And the book then covers a really advanced technique loading 320 00:15:23.679 --> 00:15:27.360 and running a whole ex inside another process's memory, no 321 00:15:27.480 --> 00:15:28.679 separate file on disk. 322 00:15:28.799 --> 00:15:31.440 Yeah, super stealthy used by APT groups. 323 00:15:31.559 --> 00:15:34.679 Yeah, The book mentions threat actors like Mustang, Panda, APT 324 00:15:34.879 --> 00:15:37.960 forty one, and even tools like metasploit using this for 325 00:15:38.039 --> 00:15:41.559 stage payloads. It avoids creating a new process that security 326 00:15:41.559 --> 00:15:43.039 tools might immediately notice. 327 00:15:43.200 --> 00:15:46.039 Makes sense. Then there's IAT hooking, another way to mess 328 00:15:46.039 --> 00:15:47.399 with these function calls. Yep. 329 00:15:47.919 --> 00:15:51.159 With IAT hooking, you modify the IAT after the loader 330 00:15:51.200 --> 00:15:54.080 has filled it in. You change a pointer that should 331 00:15:54.120 --> 00:15:57.440 go to a legitimate function like message box A to 332 00:15:57.480 --> 00:16:00.320 point to your own malicious function instead, so. 333 00:16:00.279 --> 00:16:02.360 The program thinks it's calling the real function but gets 334 00:16:02.399 --> 00:16:03.519 hijacked exactly. 335 00:16:04.000 --> 00:16:06.840 The book uses message box A hijacking as an example. 336 00:16:07.039 --> 00:16:10.919 Legitimate uses exist, like in game plugins or sandboxes, but 337 00:16:11.120 --> 00:16:14.720 malware uses it to intercept data, redirect control flow, things 338 00:16:14.799 --> 00:16:15.080 like that. 339 00:16:15.360 --> 00:16:17.639 And then DLL sideloading comes up again. 340 00:16:17.559 --> 00:16:20.879 Right exploiting that search order program needs some dot DLL. 341 00:16:21.039 --> 00:16:24.519 Loader checks the program's own folder first, then system thirty two, 342 00:16:24.559 --> 00:16:27.559 et CETERA. Attacker puts a malicious sump dot DLL in 343 00:16:27.600 --> 00:16:28.960 the program's folder, and the. 344 00:16:28.919 --> 00:16:31.399 Loader finds and loads the malicious one before it ever 345 00:16:31.440 --> 00:16:32.480 looks in system thirty two. 346 00:16:32.639 --> 00:16:35.200 That's the idea. The book uses hijacking Chrome with a 347 00:16:35.240 --> 00:16:39.039 phadversion dot DLL as an example. Very common attack vector. 348 00:16:38.840 --> 00:16:40.600 And DLL proxying. What was that? 349 00:16:40.600 --> 00:16:44.600 That's a variation. The malicious DLL gets loaded via sideloading, 350 00:16:45.000 --> 00:16:48.279 but it actually exports all the same functions as the 351 00:16:48.320 --> 00:16:51.639 real DLL it replaced. When the program calls a function, 352 00:16:51.919 --> 00:16:55.559 the malicious DLL might do something bad first, then it 353 00:16:55.720 --> 00:16:59.559 proxies the call, passing it along to the actual legitimate DLL, 354 00:16:59.679 --> 00:17:00.919 which it loads itself. 355 00:17:00.960 --> 00:17:03.759 So the program still works, but the attacker gets their 356 00:17:03.799 --> 00:17:07.640 code executed too clever. Chapter five really shows the loading 357 00:17:07.680 --> 00:17:11.319 process is full of potential attack surfaces. Chapter six talks 358 00:17:11.359 --> 00:17:14.319 about PE module relocation. This is about loading things at 359 00:17:14.359 --> 00:17:17.960 different addresses exactly. Remember the linker sets a preferred image 360 00:17:17.960 --> 00:17:20.359 based address right like zero by four hundred thousand. 361 00:17:20.519 --> 00:17:23.240 In a running system, that address might already be taken 362 00:17:23.319 --> 00:17:26.240 by something else, So the program just fails, not necessarily. 363 00:17:26.279 --> 00:17:28.960 That's where relocation comes in. It's a mechanism built into 364 00:17:28.960 --> 00:17:31.799 the PE format that allows a module to be loaded 365 00:17:31.839 --> 00:17:34.519 and run correctly even if it lands at a different 366 00:17:34.519 --> 00:17:35.799 address than its preferred one. 367 00:17:35.880 --> 00:17:37.799 How does that work? Does something get adjusted? 368 00:17:38.000 --> 00:17:41.880 Yes, there's a relocation table inside the PE file. It 369 00:17:42.000 --> 00:17:44.599 lists all the places in the code and data that 370 00:17:44.640 --> 00:17:48.920 contain absolute memory addresses addresses that assume the module is 371 00:17:48.960 --> 00:17:50.599 loaded at its preferred image base. 372 00:17:50.759 --> 00:17:53.559 Ah. So if it loads somewhere else, those addresses would 373 00:17:53.559 --> 00:17:54.480 be wrong exactly. 374 00:17:54.880 --> 00:17:57.720 So when the LOADO puts the module at a different address, 375 00:17:57.799 --> 00:18:01.400 it reads this relocation table and goes through and fixes 376 00:18:01.519 --> 00:18:05.160 up all those listed addresses, adjusting them based on the 377 00:18:05.200 --> 00:18:06.640 actual load address. 378 00:18:06.359 --> 00:18:08.200 Making sure all the internal pointers are correct. 379 00:18:08.240 --> 00:18:11.160 For the new location precisely. The book mentions tiny loader 380 00:18:11.200 --> 00:18:14.799 again here showing how a custom loader like ploader dot 381 00:18:14.839 --> 00:18:18.920 cpp can handle this. It parses the relocation table and 382 00:18:18.960 --> 00:18:22.039 applies the fix ups when loading a module, often using 383 00:18:22.119 --> 00:18:24.839 virtual allock to get memory wherever it can, and then 384 00:18:24.960 --> 00:18:27.400 carefully patching the loaded code and data. 385 00:18:27.799 --> 00:18:30.720 Very important for those in memory loading techniques we discuss Okay, 386 00:18:30.880 --> 00:18:35.319 chapter seven packers. We've probably all run into packed executables. 387 00:18:35.480 --> 00:18:36.359 What's the deal with them? 388 00:18:36.400 --> 00:18:39.920 Packers are tools that basically wrap an executable. They compress it, 389 00:18:40.039 --> 00:18:43.640 maybe encrypt it, definitely obfuscate it. The original program gets 390 00:18:43.640 --> 00:18:45.920 bundled inside a shell or stub. 391 00:18:45.799 --> 00:18:48.599 So it's like putting the real program inside a protective. 392 00:18:48.160 --> 00:18:52.000 Box kind of yeah, or maybe a confusing box. The 393 00:18:52.000 --> 00:18:55.160 book shows how the memory layout changes. You often get 394 00:18:55.200 --> 00:18:59.519 a section marked readable, writeable and executable text up x, 395 00:18:59.519 --> 00:19:02.079 where the un packed code will go. You get a 396 00:19:02.119 --> 00:19:05.920 payload section holding the packed original program, and you get 397 00:19:05.960 --> 00:19:07.599 the packer stub COODE. 398 00:19:07.279 --> 00:19:09.400 And the stub is the code that does the unpacking. 399 00:19:09.559 --> 00:19:12.720 YEP. When you run the packed file, the stub executes first. 400 00:19:13.160 --> 00:19:16.200 Its job is to decompress or decrypt the payload into 401 00:19:16.200 --> 00:19:19.319