WEBVTT 1 00:00:00.160 --> 00:00:03.680 Welcome to the deep dive. Today. We're really getting into 2 00:00:03.680 --> 00:00:06.000 the weeds with Windows System Programming. 3 00:00:06.160 --> 00:00:09.320 Yeah, this is part two, building on those fundamentals exactly. 4 00:00:09.439 --> 00:00:12.759 We're thinking about our listener, the learner who's maybe bumped 5 00:00:12.800 --> 00:00:18.480 into terms like DLLs, memory management, security, maybe even performance analysis. 6 00:00:17.920 --> 00:00:22.160 Right and wants to get a clearer picture without drowning 7 00:00:22.160 --> 00:00:23.640 in super technical details. 8 00:00:23.760 --> 00:00:26.719 Our goal is to give you the learner, that clearer, 9 00:00:26.879 --> 00:00:28.399 more insightful understanding. 10 00:00:28.440 --> 00:00:30.879 Think of it like getting the essential toolkit for these 11 00:00:30.920 --> 00:00:34.479 complex topics. Wow, we want those aha moments, not just 12 00:00:34.520 --> 00:00:35.920 the list of functions for sure. 13 00:00:36.359 --> 00:00:39.960 And we're drawing heavily from Windows ten System Programming Part two. 14 00:00:40.240 --> 00:00:42.960 It's a great resource for digging into the advanced Windows 15 00:00:43.000 --> 00:00:43.799 API stuff. 16 00:00:44.039 --> 00:00:46.600 It really tries to bridge that gap for programmers working 17 00:00:46.600 --> 00:00:50.320 with modern Windows, covering well everything from memory tricks to 18 00:00:50.640 --> 00:00:51.560 security layers. 19 00:00:51.759 --> 00:00:56.719 So our mission today extract the really crucial, the fascinating. 20 00:00:56.119 --> 00:00:59.399 Bits exactly, give you those key insights that solid foundation 21 00:00:59.759 --> 00:01:03.560 will hit advanced memory management, the whole world of DLLs. 22 00:01:03.280 --> 00:01:06.079 The complexities of Window security, and. 23 00:01:07.280 --> 00:01:10.640 The tools you need for debugging and diagnostics when things 24 00:01:11.359 --> 00:01:12.079 go sideways. 25 00:01:12.159 --> 00:01:14.760 Okay, let's kick things off with memory management. We're going 26 00:01:14.840 --> 00:01:16.239 way beyond the basics here. 27 00:01:16.359 --> 00:01:20.799 Definitely think raw control. First up is virtual memory allocation 28 00:01:21.760 --> 00:01:24.760 virtual alec and uh virtual alex. 29 00:01:25.000 --> 00:01:26.799 What's the core difference there, y x. 30 00:01:27.079 --> 00:01:30.920 Well, virtual ALIC is for your own processes memory. Virtual 31 00:01:30.920 --> 00:01:34.159 alec though, that lets you allocate memory inside another process, 32 00:01:34.439 --> 00:01:36.079 assuming you have the permissions of course. 33 00:01:36.239 --> 00:01:39.560 Ah. Okay, so that's key for things like debuggers, right 34 00:01:39.840 --> 00:01:41.599 reaching into another program. 35 00:01:41.239 --> 00:01:44.879 Space Precisely, it's fundamental for those kinds of tools. But 36 00:01:44.920 --> 00:01:47.840 it also hints at more complex system interactions. 37 00:01:47.959 --> 00:01:50.840 But that sounds potentially risky. How is that controlled? 38 00:01:50.959 --> 00:01:54.519 Security is paramount? You need specific privileges to target another 39 00:01:54.560 --> 00:01:57.480 process with virtual alex. We'll touch more in security later, 40 00:01:57.560 --> 00:02:00.719 but it's tightly controlled. It makes it a powerful tool, 41 00:02:01.000 --> 00:02:02.439 but not easily misused. 42 00:02:02.560 --> 00:02:05.959 Okay, makes sense now the book mentioned something specific about 43 00:02:06.000 --> 00:02:09.240 security with these functions. Committed pages get zamboed out. 44 00:02:09.560 --> 00:02:13.520 Yes, that's crucial. When Windows commits memory using virtual alec 45 00:02:13.639 --> 00:02:16.919 or x, it wipes it clean, fills it with zeros. 46 00:02:17.360 --> 00:02:18.520 Why do that extra step? 47 00:02:19.039 --> 00:02:23.759 It prevents information leakage. You don't want one process accidentally 48 00:02:23.800 --> 00:02:27.800 seeing leftover data from whatever process. Use that physical. 49 00:02:27.479 --> 00:02:29.840 Memory before think of it, like wiping a whiteboard. 50 00:02:29.919 --> 00:02:33.560 Got it, unlike say, malik, which might just give you whatever. 51 00:02:33.360 --> 00:02:35.439 Was there exactly a clean slate every time. 52 00:02:35.680 --> 00:02:39.319 Now Reserving versus committing memory why the two stages. 53 00:02:39.479 --> 00:02:42.639 It's like planning versus building. Reserving is like staking out 54 00:02:42.639 --> 00:02:44.840 a claim in the virtual address space. You say this 55 00:02:44.960 --> 00:02:46.360 range is mine, nobody else. 56 00:02:46.240 --> 00:02:48.159 Touch it, okay, prevents conflicts, right. 57 00:02:48.400 --> 00:02:50.759 Committing is when you actually tell the system, okay, I 58 00:02:50.840 --> 00:02:54.439 need physical memory RAM or page filespace backing this part 59 00:02:54.439 --> 00:02:56.879 of my reserve space. You make it usable so you. 60 00:02:56.879 --> 00:02:59.120 Can reserve a big chunk, but only commit what you 61 00:02:59.159 --> 00:03:00.520 actually need right now. 62 00:03:00.240 --> 00:03:03.639 Precisely reserve the whole plot, build houses one by one, 63 00:03:03.759 --> 00:03:04.360 very efficient. 64 00:03:04.719 --> 00:03:07.479 What about these memory set and members Satendo flags. They 65 00:03:07.479 --> 00:03:10.360 sound a bit niche, they are, Yeah. Member set basically 66 00:03:10.439 --> 00:03:13.039 tells Windows, hey, I don't care about the contents of 67 00:03:13.080 --> 00:03:15.759 this committed memory anymore. Feel free to take the physical 68 00:03:15.759 --> 00:03:18.639 pages back if needed, but leave it allocated. 69 00:03:18.400 --> 00:03:21.159 Sort of like marking it as discardible. 70 00:03:20.719 --> 00:03:23.800 Kind of, and memorys Tottendo's signals you might need it again, 71 00:03:24.120 --> 00:03:26.639 but there's no guarantee the old data is still there. 72 00:03:26.759 --> 00:03:30.879 If the physical pages got reused, it's for specific optimation scenarios. 73 00:03:30.960 --> 00:03:33.599 Okay, Now that micro excel to example in the book 74 00:03:33.680 --> 00:03:37.680 using page based allocation and exception handling. That's the takeaway there. 75 00:03:37.800 --> 00:03:40.800 It's clever. Virtual allock works on pages right, usually four 76 00:03:40.879 --> 00:03:46.280 kb chunks, so microcell reserves a huge virtual address space 77 00:03:46.360 --> 00:03:47.080 for its grid. 78 00:03:47.439 --> 00:03:50.120 It doesn't actually commit most of it initially exactly. 79 00:03:50.439 --> 00:03:52.759 Then if you try to access to sell in an 80 00:03:52.840 --> 00:03:56.159 uncommitted part, it triggers an access violation and exception. 81 00:03:56.560 --> 00:03:56.759 Ah. 82 00:03:57.000 --> 00:04:00.240 The application catches that specific exception, commits the record fired 83 00:04:00.280 --> 00:04:03.560 page using virtualolock inside the exception handler, and then tells 84 00:04:03.560 --> 00:04:05.719 the CPU Okay, try that instruction again. Wow. 85 00:04:05.800 --> 00:04:08.280 So it looks like a massive spreadsheet but only uses 86 00:04:08.400 --> 00:04:11.280 RAM for the bits you're actually using Memory on demand. 87 00:04:11.080 --> 00:04:14.960 BINGO super efficient for potentially huge data sets. 88 00:04:15.080 --> 00:04:20.040 Brilliant. Okay. Let's shift gears slightly within memory management working sets. 89 00:04:20.600 --> 00:04:21.759 What are those? Exactly? 90 00:04:21.920 --> 00:04:25.040 A process is working set is basically the set of 91 00:04:25.079 --> 00:04:28.360 its memory pages currently residing in physical RAM, stuff it 92 00:04:28.360 --> 00:04:30.399 can access without a page fault. 93 00:04:30.240 --> 00:04:34.000 So the stuff it needs readily available for good performance exactly. 94 00:04:34.480 --> 00:04:37.439 The memory manager tries to keep the actively used pages 95 00:04:37.480 --> 00:04:40.600 in the working set and juggles this across all running 96 00:04:40.639 --> 00:04:42.439 processes to keep the system. 97 00:04:42.079 --> 00:04:44.439 Responsive, and if a page isn't used for a while, 98 00:04:44.639 --> 00:04:47.000 it might get kicked out of the working set. The 99 00:04:47.000 --> 00:04:49.560 book mentions soft page faults though. 100 00:04:49.519 --> 00:04:51.959 Right, If a page is removed from the working set 101 00:04:51.959 --> 00:04:55.319 but it's still somewhere else in RAM, accessing it causes 102 00:04:55.319 --> 00:04:58.399 a soft page fault. The system can quickly map it 103 00:04:58.439 --> 00:05:00.279 back in minimal delay. 104 00:05:00.160 --> 00:05:01.839 As opposed to a hard page fault. 105 00:05:01.959 --> 00:05:04.000 Yeah, a hard fault happens when the page isn't in 106 00:05:04.079 --> 00:05:06.360 RAM at all, it's been paged out to disc. That 107 00:05:06.399 --> 00:05:08.560 requires reading it back from the disc, which is much 108 00:05:08.639 --> 00:05:09.199 much slower. 109 00:05:09.279 --> 00:05:12.519 Gotcha. Now, can you actually control the working set size? 110 00:05:12.560 --> 00:05:15.439 The book mentions set process working set size and empty 111 00:05:15.480 --> 00:05:16.040 working set. 112 00:05:16.160 --> 00:05:19.319 You can influence it. Yeah, Set process working set size 113 00:05:19.480 --> 00:05:23.560 lets you suggest minimum and maximum sizes useful if you 114 00:05:23.600 --> 00:05:25.360 really need certain things to stay in RAM. 115 00:05:25.480 --> 00:05:26.800 And empty working set. 116 00:05:26.680 --> 00:05:30.079 That's more aggressive, especially with size at one. It tells 117 00:05:30.079 --> 00:05:33.079 the system trim this process is working set way down. 118 00:05:33.720 --> 00:05:35.560 Maybe if it's going idle for a long time. You 119 00:05:35.600 --> 00:05:37.079 free UPRAM for others. 120 00:05:36.959 --> 00:05:39.079 And tools like the working sets app let you see 121 00:05:39.120 --> 00:05:39.800 the stuff they do. 122 00:05:39.920 --> 00:05:42.560 Yeah, though you usually need admin rights to peek into 123 00:05:42.639 --> 00:05:44.600 other processes working sets in detail. 124 00:05:44.959 --> 00:05:50.079 Right makes sense? Okay, Next memory topic peeps beyond the 125 00:05:50.079 --> 00:05:54.000 standard library malick free. What Windows specifics are there? 126 00:05:54.160 --> 00:05:57.439 Well? Windows provides heap walk to look inside the default 127 00:05:57.480 --> 00:06:00.199 heap of the current process, but just the current one. 128 00:06:00.360 --> 00:06:02.480 What if you need to look at another processes heap, 129 00:06:02.680 --> 00:06:04.000 like for debugging, Then. 130 00:06:03.839 --> 00:06:06.480 You turn to the tool help library use functions like 131 00:06:06.560 --> 00:06:09.120 create tool help thirty two snapshot with the right flags. 132 00:06:09.360 --> 00:06:11.560 Then heap thirty two list first next to get the 133 00:06:11.560 --> 00:06:14.040 heap list for the target process, and heap thirty two 134 00:06:14.040 --> 00:06:16.240 first next to examine the blocks within each heap. 135 00:06:16.360 --> 00:06:19.319 Okay, a bit more involved for external processes. The book 136 00:06:19.360 --> 00:06:22.000 also talks about heap coalescing and heap compact. 137 00:06:22.439 --> 00:06:27.000 Right coalescing is when the heat manager automatically merges adjacent 138 00:06:27.079 --> 00:06:30.040 free blocks back together into bigger free blocks. 139 00:06:30.360 --> 00:06:33.600 Helps fight fragmentation like tidying up the free space. 140 00:06:33.439 --> 00:06:36.279 Exactly normally as automatic, but you can disable it with 141 00:06:36.319 --> 00:06:40.079 a global flag maybe for some micro optimization. Heap compact 142 00:06:40.199 --> 00:06:43.720 lets you force a coalescing operation if it's disabled, or 143 00:06:43.959 --> 00:06:45.560 just generally try to compact the heap. 144 00:06:45.839 --> 00:06:49.319 Interesting trade off there now a UMA non uniform memory 145 00:06:49.360 --> 00:06:52.920 access sounds like it's mainly for big muzzy processor machines. 146 00:06:53.000 --> 00:06:57.040 Absolutely on systems with multiple CPU sockets and dedicated memory banks. 147 00:06:57.120 --> 00:07:00.519 For each access time can vary depending on whether a 148 00:07:00.519 --> 00:07:03.680 CPU is accessing its local memory or memory attached to 149 00:07:03.720 --> 00:07:06.160 another CPU. That's the non uniform part. 150 00:07:06.399 --> 00:07:07.800 So how does Windows help with that? 151 00:07:08.360 --> 00:07:10.959 There are functions like get new mode Processor mask X 152 00:07:11.000 --> 00:07:14.959 to figure out the system's new MAY topology, which processors 153 00:07:14.959 --> 00:07:18.480 belong to which node, and then critically, functions like virtual 154 00:07:18.519 --> 00:07:21.519 alkix NUMA or the newer virtual loc too let you 155 00:07:21.560 --> 00:07:25.079 specifically allocate memory on a preferred UMA node. 156 00:07:25.079 --> 00:07:26.800 So you can try and keep memory close to the 157 00:07:26.839 --> 00:07:27.839 CPU that's going to use. 158 00:07:27.800 --> 00:07:32.079 It most precisely. For high performance computing or large database servers, 159 00:07:32.600 --> 00:07:36.839 NUMA aware allocation can give a noticeable performance boost. It's 160 00:07:36.879 --> 00:07:39.000 about minimizing that cross node latency. 161 00:07:39.160 --> 00:07:42.800 Makes sense, okay. Last item in our memory deep dive 162 00:07:43.600 --> 00:07:48.120 memory mapped files or MMFs. These sound quite powerful. 163 00:07:48.199 --> 00:07:51.360 They really are. Mapewol file is the core function. You 164 00:07:51.439 --> 00:07:54.160 take a file mapping object which might represent an actual 165 00:07:54.160 --> 00:07:57.399 file on disc or not, and map it directly into 166 00:07:57.439 --> 00:07:59.319 your process's virtual address. 167 00:07:58.920 --> 00:08:02.360 Space, So accessing the file becomes like accessing RAM essentially. 168 00:08:02.439 --> 00:08:05.040 Yes, The OS handles the magic of loading data from 169 00:08:05.040 --> 00:08:07.879 the file into memory when needed and writing changes back. 170 00:08:08.079 --> 00:08:10.240 It's very efficient for file io. 171 00:08:10.279 --> 00:08:12.120 And great for inner process communication. 172 00:08:12.279 --> 00:08:16.160 Right IPC Absolutely, It's a classic high performance IPC technique. 173 00:08:16.160 --> 00:08:18.959 On a single machine, multiple processes map the same file 174 00:08:19.000 --> 00:08:21.639 mapping object, and boom, they're sharing the same physical memory. 175 00:08:21.920 --> 00:08:24.079 No need to copy data back and forth through pipes 176 00:08:24.120 --> 00:08:24.680 or sockets. 177 00:08:24.800 --> 00:08:27.480 Super efficient. The book mentions mapuof f alex NUMA. I 178 00:08:27.600 --> 00:08:29.680 guessing that's the NUMA version you got. 179 00:08:29.680 --> 00:08:32.919 It allows specifying a preferred UMMA node for the mapping, 180 00:08:33.240 --> 00:08:34.879 just like with virtual alex NUMA. 181 00:08:34.960 --> 00:08:39.320 Now this is cool. Anonymous MMFs you can share memory 182 00:08:39.360 --> 00:08:42.000 without even having a file on disc. How does that work? 183 00:08:42.159 --> 00:08:45.159 Right? Instead of being backed by a file, anonymous MMFs 184 00:08:45.200 --> 00:08:48.080 are backed by the system's page file. The key is 185 00:08:48.080 --> 00:08:50.720 you still get a handle to the mapping object. You 186 00:08:50.720 --> 00:08:53.399 can pass this handle or often just the starting memory 187 00:08:53.440 --> 00:08:55.720 address after mapping to another process. 188 00:08:55.759 --> 00:08:56.440 How do you pass it? 189 00:08:56.519 --> 00:09:00.519 Any standard IPC mechanism, window messages, named pipes, even just 190 00:09:00.519 --> 00:09:03.480 a shared variable in a DLL. The both processes load 191 00:09:04.200 --> 00:09:07.279 the second process then uses that handle or address to 192 00:09:07.360 --> 00:09:10.360 map the same anonymous shared memory region into its own space. 193 00:09:10.600 --> 00:09:13.440 That sounds incredibly simple for sharing data, just pass a pointer. 194 00:09:13.600 --> 00:09:17.080 Essentially, it's a very elegant approach for certain kinds of IPC, and. 195 00:09:17.080 --> 00:09:20.919 One less thing on mmf's MEMO large pages. What's the 196 00:09:20.960 --> 00:09:21.639 benefit there? 197 00:09:22.000 --> 00:09:25.360 Standard memory pages are small, typically for KB. Large pages 198 00:09:25.360 --> 00:09:27.720 are much bigger, maybe two memb or even one GB 199 00:09:27.879 --> 00:09:30.879 on some systems. Using large pages for memory mapping can 200 00:09:30.919 --> 00:09:34.679 reduce TLB pressure. That's the translation look aside buffer cash 201 00:09:34.720 --> 00:09:38.200 and potentially improve performance for applications accessing large amounts of 202 00:09:38.240 --> 00:09:38.919 map data. 203 00:09:39.000 --> 00:09:40.200 But there are requirements. 204 00:09:40.279 --> 00:09:43.679 Yes, you need the Sellock memory privilege which is granted 205 00:09:43.679 --> 00:09:46.960 by default, and the file mapping object itself must have 206 00:09:47.039 --> 00:09:49.879 been created with the c clarch pages flag. So it's 207 00:09:49.879 --> 00:09:51.879 an optimization for specific scenarios. 208 00:09:52.039 --> 00:09:54.960 Whow okay, that covers a lot of ground on memory. 209 00:09:55.559 --> 00:09:59.320 Let's switch gears now to dynamic link libraries DLLs. Everyone 210 00:09:59.320 --> 00:10:01.919 knows they're about res usable code, but how does Windows 211 00:10:01.919 --> 00:10:03.000 actually handle them? 212 00:10:03.279 --> 00:10:06.480 Right? Dls are fundamental in Windows. The book gets into 213 00:10:06.759 --> 00:10:10.279 how they're linked implicitly versus explicitly how they get loaded 214 00:10:10.360 --> 00:10:10.720 is key. 215 00:10:10.799 --> 00:10:13.639 Okay, implicit linking first, that's the common way where the 216 00:10:13.679 --> 00:10:16.639 OS just loads the DLLs your program needs when it starts. 217 00:10:16.639 --> 00:10:19.840 Pretty much when your ex loads, the Windows loader looks 218 00:10:19.879 --> 00:10:22.559 at its import table to see which DLLs and functions 219 00:10:22.600 --> 00:10:25.159 it needs. Then it has to find those ds. 220 00:10:25.320 --> 00:10:27.960 Is there a specific search order? Where does it look 221 00:10:28.120 --> 00:10:28.519 there is? 222 00:10:28.679 --> 00:10:31.399 It's a defined path. First, it checks if the DLL 223 00:10:31.480 --> 00:10:33.799 is in the known DS list. These are core system 224 00:10:33.879 --> 00:10:37.080 ds always loaded from the system directory for security on 225 00:10:37.159 --> 00:10:39.879 performance helps prevent DLL hijacking. 226 00:10:39.960 --> 00:10:42.519 Okay, known ds first, Then. 227 00:10:42.559 --> 00:10:46.679 Then the directory the ex itself is in. After that 228 00:10:46.840 --> 00:10:50.039 the process is current working directory, then the system directory 229 00:10:50.080 --> 00:10:53.559 System thirty two, the Windows directory, and finally all the 230 00:10:53.559 --> 00:10:55.679 directory is listed in the path environment variable. 231 00:10:55.879 --> 00:10:58.200 That order seems important for deployment. What if it can't 232 00:10:58.240 --> 00:11:00.200 find a needed DLL, usually. 233 00:11:00.159 --> 00:11:02.679 Get that dreaded error message box saying that DLL is 234 00:11:02.720 --> 00:11:06.720 missing and the application just won't start. Process terminates. Figure 235 00:11:06.720 --> 00:11:09.000 fifteen to seven in the book shows a typical example. 236 00:11:09.200 --> 00:11:13.279 Not very helpful. Sometimes you mentioned known DLLs helping prevent hijacking. 237 00:11:13.360 --> 00:11:15.879 Yeah, By forcing the load from the system directory to 238 00:11:15.919 --> 00:11:20.039 find in the registry HKLM no ds, it stops malware 239 00:11:20.120 --> 00:11:23.519 potentially placing a malicious version of a core DLL in 240 00:11:23.639 --> 00:11:26.600 say the application directory to get loaded instead. 241 00:11:26.480 --> 00:11:29.200 Smart Okay, so that's implicit. What about explicit linking. 242 00:11:29.360 --> 00:11:32.639 Explicit linking is where you, the programmer, take control. You 243 00:11:32.759 --> 00:11:35.440 use load library to load a DLL specifically when you 244 00:11:35.480 --> 00:11:37.879 need it, and free library to unload it later. 245 00:11:38.000 --> 00:11:39.080 When would you do that. 246 00:11:39.120 --> 00:11:41.799 Perfect For things like plugins, you load the plug in 247 00:11:41.919 --> 00:11:45.279 DLL only when the user activates that feature. Or maybe 248 00:11:45.360 --> 00:11:47.440 if a feature depends on a DLL that might not 249 00:11:47.480 --> 00:11:50.440 be installed, you can try to load library and if 250 00:11:50.480 --> 00:11:52.960 it fails, you can handle it gracefully. Maybe disable the 251 00:11:53.000 --> 00:11:54.639 feature instead of crashing. 252 00:11:54.759 --> 00:11:58.600 Gives you more control and resilience. The book also mentions 253 00:11:58.600 --> 00:12:02.440 set default deal directories and adult directory customizing the search 254 00:12:02.519 --> 00:12:03.720 path exactly. 255 00:12:04.279 --> 00:12:07.240 These let you modify how the loader searches for DLLs, 256 00:12:07.639 --> 00:12:10.960 especially for explicit loads via load library. Set the fault 257 00:12:10.960 --> 00:12:13.960 deal directories can restrict the search, for instance, only to 258 00:12:14.039 --> 00:12:17.919 the system directory or directories added with adult directory. 259 00:12:17.440 --> 00:12:20.159 And adult directory adds a specific path to the search 260 00:12:20.200 --> 00:12:20.799 list right. 261 00:12:21.000 --> 00:12:23.480 There are various flags you can use, like application diet, 262 00:12:23.600 --> 00:12:26.279 user at I ers System thirty two, Table fifteen to 263 00:12:26.360 --> 00:12:29.039 one lays them all out. It gives you finer control 264 00:12:29.039 --> 00:12:33.360 over dependencies, which can be important for security and avoiding conflicts. 265 00:12:33.080 --> 00:12:36.159 Useful for complex setups. Now, deal main. That's an entry 266 00:12:36.159 --> 00:12:37.080 point for a DLL. 267 00:12:37.240 --> 00:12:40.120 Correct, It's a function the loader calls inside the DLL 268 00:12:40.159 --> 00:12:44.039 for various events when the dealers first loaded into a process, 269 00:12:44.480 --> 00:12:48.480 DL processed, attack, when it's unloaded, delll process attached, and 270 00:12:48.559 --> 00:12:51.799 also potentially when threads are created, DL thread attached or 271 00:12:51.840 --> 00:12:54.440 exit deal thread attached within that process. 272 00:12:54.639 --> 00:12:56.000 Why the thread notifications. 273 00:12:56.440 --> 00:12:59.759 Some DLLs might need to do per thread initialization or cleanup, 274 00:13:00.360 --> 00:13:02.440 but often they don't, so you can call disabled thread 275 00:13:02.440 --> 00:13:05.440 library calls as an optimization to tell the loader, hey, 276 00:13:05.440 --> 00:13:08.559 don't bother calling my dealmain for thread events saves a 277 00:13:08.559 --> 00:13:09.240 bit of overhead. 278 00:13:09.320 --> 00:13:12.159 Okay, but the book has a big warning about delmain 279 00:13:12.279 --> 00:13:15.240 and something called the loader lock sounds serious. 280 00:13:15.360 --> 00:13:17.759 It is very serious. The loader lock is an internal 281 00:13:17.799 --> 00:13:21.480 lock the system uses while loading or unloading DLLs, including 282 00:13:21.480 --> 00:13:24.919 when it calls delmain. The danger is deadlock if your 283 00:13:24.960 --> 00:13:27.519 delmain code tries to do something that also requires the 284 00:13:27.559 --> 00:13:31.360 loader lock, like calling load library itself or get module handle, 285 00:13:31.720 --> 00:13:34.919 or maybe waiting on another synchronization object that some other 286 00:13:35.000 --> 00:13:37.200 thread holds while it's waiting for the loader lock. 287 00:13:37.320 --> 00:13:38.919 Everything grinds to a halt. 288 00:13:39.120 --> 00:13:43.960 Exactly deadlock your process hangs. The strong advice is keep 289 00:13:44.039 --> 00:13:48.679 dealmain simple, do minimal initialization, don't call functions that might 290 00:13:48.720 --> 00:13:52.480 load other DLLs or wait on complex synchronization. It's a 291 00:13:52.519 --> 00:13:53.720 notorious trap. 292 00:13:53.519 --> 00:13:55.799 Definitely something to watch out for. Okay, let's talk about 293 00:13:55.840 --> 00:13:58.360 DL injection and hooking. This sounds like it could be 294 00:13:58.519 --> 00:14:02.200 used for interesting purposes. 295 00:14:02.320 --> 00:14:04.720 Interesting is one word for it. Yes, it can be 296 00:14:04.799 --> 00:14:09.080 used for legitimate tools like debuggers, monitoring utilities, accessibility aids, 297 00:14:09.360 --> 00:14:12.720 but also for malware. DLL injection is basically forcing another 298 00:14:12.759 --> 00:14:15.879 process to load a DLL it wasn't intending to load. 299 00:14:16.200 --> 00:14:17.480 How is that typically done? 300 00:14:17.600 --> 00:14:20.399 One common method uses create a remote thread. You need 301 00:14:20.399 --> 00:14:23.440 privileges first like process vm right and process create thread. 302 00:14:23.840 --> 00:14:26.559 Then you use virtual allox to allocate some memory in 303 00:14:26.600 --> 00:14:27.399 the target. 304 00:14:27.039 --> 00:14:30.159 Process, write the pass to your DLL into that memory. 305 00:14:29.960 --> 00:14:32.159 Right using right process memory. Then you call create a 306 00:14:32.200 --> 00:14:34.360 remote thread, telling it to start a new thread in 307 00:14:34.399 --> 00:14:37.960 the target process, executing the load library function and passing 308 00:14:37.960 --> 00:14:40.519 it the address of the DLL path you just wrote. 309 00:14:40.559 --> 00:14:43.639 So you trick the other process into loading your code essentially. 310 00:14:43.720 --> 00:14:43.960 Yes. 311 00:14:44.120 --> 00:14:46.960 The book also mentions set Windows hook x. How does 312 00:14:47.000 --> 00:14:48.600 that fit in can it cause injection? 313 00:14:49.159 --> 00:14:52.639 It can? Yes. Set Windows sookx lets you install hooks 314 00:14:52.639 --> 00:14:56.399 to intercept system events, keyboard input, mouse messages, window messages, 315 00:14:56.399 --> 00:14:59.039 et cetera. If you install a global hook or one 316 00:14:59.080 --> 00:15:01.360 the target's threads in another process. 317 00:15:01.120 --> 00:15:03.519 The hook procedure itself needs to run in that other 318 00:15:03.600 --> 00:15:05.320 process's context. 319 00:15:04.879 --> 00:15:07.639 Exactly, and for that to happen, the hook procedure must 320 00:15:07.679 --> 00:15:10.720 be located inside a DLL. When you install such a hook, 321 00:15:11.039 --> 00:15:15.440 Windows automatically injects that DLL into all the relevant target processes, 322 00:15:15.679 --> 00:15:17.159 so your hook code can run there. 323 00:15:17.559 --> 00:15:21.240 Ah, So the hooking mechanism itself performs the injection correct. 324 00:15:21.279 --> 00:15:24.120 The example in the book uses a whgt methage hook 325 00:15:24.480 --> 00:15:27.679 to snoop on keyboard input in notepad, and the hook 326 00:15:27.720 --> 00:15:29.840 code has to be in an injected dlll. 327 00:15:29.600 --> 00:15:33.639 Okay, then there's itIt hooking Import address table hooking sounds 328 00:15:33.720 --> 00:15:34.399 very low level. 329 00:15:34.480 --> 00:15:38.000 It is super low level. Every module EXE DL has 330 00:15:38.000 --> 00:15:40.519 an import address table that lists the functions that imports 331 00:15:40.559 --> 00:15:43.159 from other ds, along with the memory addresses where those 332 00:15:43.200 --> 00:15:46.919 functions actually live. IAT hooking involves finding the entry for 333 00:15:46.960 --> 00:15:48.200 a specific function in. 334 00:15:48.080 --> 00:15:50.159 That table and overwriting the address. 335 00:15:50.559 --> 00:15:53.399 Yes, you overwrite the address with the address of your 336 00:15:53.399 --> 00:15:56.519 own function, the hook function, so whenever the original code 337 00:15:56.600 --> 00:15:59.600 tries to call the imported function, it gets redirected to 338 00:15:59.639 --> 00:16:00.240 your code. 339 00:16:00.120 --> 00:16:03.200 Instead, like intercepting the call. The book uses getsi's color 340 00:16:03.240 --> 00:16:04.399 as an example. 341 00:16:04.080 --> 00:16:07.080 Right replacing calls to the real getsy's color with calls 342 00:16:07.080 --> 00:16:10.120 to a custom getsi's color hooked. You have to parse 343 00:16:10.159 --> 00:16:13.679 the module's pe header structure to find the import descriptors, 344 00:16:14.039 --> 00:16:17.200 locate a target DLL like user thirty two dot dll, 345 00:16:17.559 --> 00:16:19.759 find the function pointer, and then patch it. 346 00:16:20.200 --> 00:16:22.559 But the book flags this as tricky. 347 00:16:22.440 --> 00:16:25.200 Very tricky. First, the exact way you patch the address 348 00:16:25.200 --> 00:16:28.159 depends heavily on the CPU architecture. By eighty six by 349 00:16:28.200 --> 00:16:31.519 sixty four arm are all different. Second, you must do 350 00:16:31.600 --> 00:16:34.440 the patch atomically. If another thread tries to call the 351 00:16:34.480 --> 00:16:39.039 function while you're halfway through changing the address, crash yaikes. Yeah. 352 00:16:39.120 --> 00:16:42.480 It requires careful synchronization and knowledge of assembly or low 353 00:16:42.559 --> 00:16:46.720 level intrinsics. It's powerful, but complex and often fragile. Higher 354 00:16:46.799 --> 00:16:49.759 level hooking mechanisms are usually preferred if they can do 355 00:16:49.799 --> 00:16:50.200 the job. 356 00:16:50.519 --> 00:16:53.879 Good to know, okay, that wraps up DLLs. Let's move 357 00:16:53.919 --> 00:16:56.840 into our third major area, Windows security. 358 00:16:57.120 --> 00:17:01.039 This is huge, absolutely massive, and crucial. The book breaks 359 00:17:01.039 --> 00:17:03.559 it down into key components, show nicely in figure sixteen 360 00:17:03.600 --> 00:17:10.039 to one SIDS, tokens, access masks, privileges, security descriptors, UAC 361 00:17:10.359 --> 00:17:11.319 integrity levels. 362 00:17:11.480 --> 00:17:15.119 Let's start with sids security identifiers. These are the unique 363 00:17:15.160 --> 00:17:16.359 ideas for users and. 364 00:17:16.319 --> 00:17:21.759 Groups and computers services. Basically any security principle, every user account, 365 00:17:21.759 --> 00:17:25.480 every group gets a unique SID. The book shows using 366 00:17:25.519 --> 00:17:28.079 creat well known SID to get the sids for standard 367 00:17:28.119 --> 00:17:30.720 built in accounts and groups like local system or. 368 00:17:30.799 --> 00:17:32.599 Everyone, and you can convert them to strings. 369 00:17:32.720 --> 00:17:34.960 YEP converts cit as strings in gives you that familiar 370 00:17:35.000 --> 00:17:37.799 S one five format and look up accounts. It goes 371 00:17:37.839 --> 00:17:40.799 the other way, finds the account name like administrators for 372 00:17:40.839 --> 00:17:43.680 a given SID. It also tells you the SID type, user, group, 373 00:17:43.680 --> 00:17:44.079 et cetera. 374 00:17:44.279 --> 00:17:46.559 Okay, next, it up tokens. What's their role? 375 00:17:46.799 --> 00:17:49.079 An access token is like a security passport for a 376 00:17:49.119 --> 00:17:51.519 process or thread. When you log in, the system creates 377 00:17:51.519 --> 00:17:54.119 a token holding your user SID, all the group sids 378 00:17:54.119 --> 00:17:55.920 you belong to, analyst of your privileges. 379 00:17:55.960 --> 00:17:59.920 Privileges like being able to debug other processes. 380 00:17:59.640 --> 00:18:02.839 Exactly, or shut down the system or change the system time. 381 00:18:02.920 --> 00:18:06.599 These are distinct from general user rights. Most privileges are 382 00:18:06.599 --> 00:18:09.960 actually disabled by default in your token, even if you're 383 00:18:09.960 --> 00:18:12.519 an admin. You have to explicitly enable them if you 384 00:18:12.519 --> 00:18:16.400 need them. See Change Notified Privileges. One exception usually enabled. 385 00:18:16.559 --> 00:18:18.440 Process Explorer shows this clearly. 386 00:18:18.880 --> 00:18:21.920 How do you check or change privileges in a token? 387 00:18:22.079 --> 00:18:27.480 Programmatically you use get token information to query the token's contents, 388 00:18:27.559 --> 00:18:32.039 including privileges, and adjust token privileges to enable, disable, or 389 00:18:32.079 --> 00:18:35.119 remove them. But you need the token adjust privileges right 390 00:18:35.160 --> 00:18:36.680 on the token handle first. 391 00:18:36.519 --> 00:18:39.119 And privileges have those weird names like c DE bug 392 00:18:39.160 --> 00:18:40.119 privilege they do. 393 00:18:40.400 --> 00:18:42.559 You use look of privilege value to get the internal 394 00:18:42.599 --> 00:18:45.880 identifier the LOUE for a privileged name before you can 395 00:18:45.960 --> 00:18:47.160 use adjust token privileges. 396 00:18:47.200 --> 00:18:50.079 The book also talks about primary versus impersonation tokens. 397 00:18:50.200 --> 00:18:53.480 Right, your main process token is the primary token, but 398 00:18:53.559 --> 00:18:57.440 a thread, particularly in a server process, might temporarily impersonate 399 00:18:57.480 --> 00:19:01.079 a client. Using an impersonation token means the thread acts 400 00:19:01.279 --> 00:19:04.920 with the client security context. They're sids their privileges. 401 00:19:05.000 --> 00:19:05.799