WEBVTT 1 00:00:00.080 --> 00:00:03.480 Welcome to the deep dive. Today. We're going deep, deep 2 00:00:03.520 --> 00:00:06.320 into reverse engineering. We've got a whole stack of stuff 3 00:00:06.320 --> 00:00:08.679 on By eighty six and By sixty four, oh and 4 00:00:08.800 --> 00:00:12.519 aram architectures two of course, and then to wrap things up, 5 00:00:12.560 --> 00:00:15.279 we're going to we're diving into the Windows kernel. 6 00:00:15.400 --> 00:00:17.559 Wow, that's quite the lineup. It sounds like we're in 7 00:00:17.600 --> 00:00:18.879 for a wild ride. 8 00:00:18.679 --> 00:00:22.399 Definitely, and judging by your sources, you're interested in not 9 00:00:22.559 --> 00:00:25.719 just like the theory, but like how this stuff actually 10 00:00:25.800 --> 00:00:26.920 works in the real world. 11 00:00:26.760 --> 00:00:29.839 Right, Absolutely, the practical applications are just as important as 12 00:00:29.839 --> 00:00:32.759 the underlying concepts. I mean, how can you really understand 13 00:00:32.799 --> 00:00:34.520 something without seeing it in. 14 00:00:34.520 --> 00:00:36.920 Action exactly and maybe even take a peek at how 15 00:00:36.960 --> 00:00:40.159 some less than ethical folks might be using this knowledge. 16 00:00:40.359 --> 00:00:42.880 Well, knowledge is a double edged sword, isn't it. It 17 00:00:42.880 --> 00:00:44.240 all depends on whose hands it's in. 18 00:00:45.079 --> 00:00:47.679 True enough, Now, you brought up a really interesting point 19 00:00:47.679 --> 00:00:50.560 earlier about how much easier it is to find information 20 00:00:50.640 --> 00:00:52.240 on reverse engineering these days. 21 00:00:52.399 --> 00:00:55.000 Yeah, it's night and day compared to just fifteen years ago. 22 00:00:55.320 --> 00:00:58.399 It's incredible how much this field has exploded. But with 23 00:00:58.439 --> 00:01:00.880 all this information out there, it can be tough to 24 00:01:00.920 --> 00:01:02.960 separate the wheat from the chaff right. 25 00:01:03.039 --> 00:01:05.400 And that's where a deep dive like this comes in handy. 26 00:01:05.439 --> 00:01:07.640 Don't you think we're not aiming to make you an 27 00:01:07.719 --> 00:01:11.799 instant expert, but we can at least lay a solid foundation. 28 00:01:12.000 --> 00:01:16.799 Exactly, And practical reverse engineering really emphasize that point too, like, 29 00:01:17.079 --> 00:01:19.959 you can't just jump into this stuff without a solid 30 00:01:20.040 --> 00:01:21.319 understanding of the basics. 31 00:01:21.480 --> 00:01:24.439 So let's just assume for a second that our listener 32 00:01:24.519 --> 00:01:27.640 already has that foundation. They've got the programming, the compilers, 33 00:01:27.680 --> 00:01:31.280 the operating system knowledge. If reverse engineering is like say, 34 00:01:31.400 --> 00:01:34.480 learning a foreign language, where would we even begin. 35 00:01:34.760 --> 00:01:37.560 Well, think of it this way. The compiled code, the 36 00:01:37.599 --> 00:01:41.280 assembly language that's essentially a machines language. Verse engineering is 37 00:01:41.319 --> 00:01:44.359 all about dissecting that code, figuring out what the original 38 00:01:44.400 --> 00:01:45.319 programmer intended. 39 00:01:45.480 --> 00:01:48.040 Okay, so we're trying to understand the machine's language. But 40 00:01:48.599 --> 00:01:50.359 how I mean it's not like we can just ask 41 00:01:50.400 --> 00:01:51.760 the machine what it's thinking. 42 00:01:51.519 --> 00:01:53.840 Right, I wish you were that easy. It's more like 43 00:01:54.319 --> 00:01:57.480 trying to understand a conversation by observing the subtle cues 44 00:01:57.519 --> 00:02:00.000 and gestures, even if you don't speak the language. 45 00:02:00.280 --> 00:02:03.040 Ah, I see, We're looking for those subtle hints, those 46 00:02:03.040 --> 00:02:06.200 little clues that revealed a bigger picture. Now your source 47 00:02:06.280 --> 00:02:09.759 is focused on by eighty six, by sixty four and arm. 48 00:02:10.199 --> 00:02:13.719 What makes these architectures so interesting for reverse engineering? 49 00:02:14.080 --> 00:02:17.680 Well, each architecture has its own Yeah, its own dialect, 50 00:02:17.800 --> 00:02:20.560 you could say, its own set of instructions and ways 51 00:02:20.560 --> 00:02:23.520 of handling data with by eighty six and by sixty four. 52 00:02:23.599 --> 00:02:26.000 For example, registers play a huge role. 53 00:02:26.240 --> 00:02:29.120 Registers, right, like little storage containers inside the processor. 54 00:02:29.360 --> 00:02:31.680 Yeah, but it's not just about what they store. It's 55 00:02:31.719 --> 00:02:34.639 about Well, take the e flag guess register. A lot 56 00:02:34.680 --> 00:02:36.759 of people just think it stores results, but it's actually 57 00:02:36.759 --> 00:02:37.840 telling us a lot more than that. 58 00:02:38.000 --> 00:02:40.680 Oh, you mean how it tells us how an operation went, 59 00:02:40.800 --> 00:02:42.560 not just the outcome precisely. 60 00:02:42.759 --> 00:02:45.159 E flag guess gives us insights into the conditions under 61 00:02:45.159 --> 00:02:47.599 which the code was executed. It's like imagine being able 62 00:02:47.639 --> 00:02:49.400 to see not just the outcome of a decision, but 63 00:02:49.479 --> 00:02:50.680 the factors that led to it. 64 00:02:50.800 --> 00:02:53.960 Wow, that's that's really powerful. It's like having access to 65 00:02:54.039 --> 00:02:56.960 the decision making process itself. What else makes by eighty 66 00:02:57.000 --> 00:02:58.319 six by sixty four standout? 67 00:03:00.319 --> 00:03:03.800 Movement is another area where those subtle details really matter. 68 00:03:04.159 --> 00:03:07.719 Take the SEES instruction, for instance, it's used to scan memory, 69 00:03:07.759 --> 00:03:10.520 and it's a fundamental part of functions like strallin. 70 00:03:11.039 --> 00:03:14.039 Strallin that rings a bell, doesn't it calculate the length 71 00:03:14.039 --> 00:03:15.199 of a string exactly. 72 00:03:15.439 --> 00:03:18.520 Even a simple operation like that relies on this memory 73 00:03:18.560 --> 00:03:19.400 scanning instruction. 74 00:03:19.639 --> 00:03:22.199 So even if we don't know exactly what SES does 75 00:03:22.240 --> 00:03:25.680 at a low level, just seeing it pop up tells us, hey, 76 00:03:25.759 --> 00:03:28.639 there's probably some string manipulation going on here. 77 00:03:28.759 --> 00:03:32.039 That's the idea. It's like recognizing landmarks in a foreign city. 78 00:03:32.319 --> 00:03:34.719 They help you orient yourself and understand the layout of 79 00:03:34.759 --> 00:03:35.199 the code. 80 00:03:35.240 --> 00:03:37.919 I like that analogy. So we're starting to see how 81 00:03:37.919 --> 00:03:40.560 these low level details can unlock the secrets of those 82 00:03:40.639 --> 00:03:43.639 higher level functions. What else should we know about by 83 00:03:43.759 --> 00:03:44.280 eighty six? 84 00:03:44.319 --> 00:03:47.280 By sixty four, Well, function calls and calling conventions are 85 00:03:47.360 --> 00:03:50.520 absolutely crucial. You can think of calling conventions as the 86 00:03:51.000 --> 00:03:55.240 rules of engagement for functions. They define how parameters are 87 00:03:55.319 --> 00:03:57.080 past and how results are returned. 88 00:03:57.360 --> 00:03:59.479 Oh so if a piece of code is breaking those rules, 89 00:03:59.560 --> 00:04:01.759 that might be a sign that something fishy is going on. 90 00:04:02.159 --> 00:04:07.759 Bingo malware, for example, might deliberately violate calling conventions to 91 00:04:07.800 --> 00:04:11.039 make the code harder to analyze. It's like speaking a 92 00:04:11.159 --> 00:04:14.639 language with a strange accent and unusual grammar. 93 00:04:14.439 --> 00:04:16.560 Makes it harder for others to understand what you're saying. 94 00:04:16.560 --> 00:04:21.279 That's a pretty sneaky tactic. Okay, so we've covered registers, data, movement, 95 00:04:21.399 --> 00:04:24.639 function calls. What about the overall flow of the code. 96 00:04:24.879 --> 00:04:28.920 How does assembly language handle things like loops and conditional statements. 97 00:04:29.120 --> 00:04:32.360 Well, assembly doesn't have explicit keywords like if or else, 98 00:04:32.879 --> 00:04:37.480 but it uses instructions like cmp and test for comparisons. 99 00:04:36.839 --> 00:04:40.519 Cmpn test okay, and based on those comparisons. 100 00:04:39.879 --> 00:04:43.199 The code can branch in different directions, effectively implementing those 101 00:04:43.279 --> 00:04:47.000 higher level constructs. It's all about manipulating the flow of execution. 102 00:04:47.279 --> 00:04:50.759 It's amazing how these simple instructions can create such complex behavior. 103 00:04:50.920 --> 00:04:53.399 So by understanding these branching mechanisms, we can start to 104 00:04:54.399 --> 00:04:56.959 trace the execution paths and figure out the logic behind 105 00:04:56.959 --> 00:04:58.199 the code exactly. 106 00:04:58.360 --> 00:05:00.879 It's like following a map where the road or instructions 107 00:05:01.079 --> 00:05:04.480 and the intersections are those branching points, and the choices 108 00:05:04.519 --> 00:05:07.959 made at each intersection they review the intended destination of 109 00:05:08.000 --> 00:05:08.480 the code. 110 00:05:09.360 --> 00:05:11.720 This is starting to feel less like deciphering a foreign 111 00:05:11.800 --> 00:05:15.160 language and more like navigating a maze. What else is 112 00:05:15.199 --> 00:05:17.480 there to know about by eighty six by sixty four. 113 00:05:17.839 --> 00:05:21.079 Address translation is another fundamental concept. You need to be 114 00:05:21.120 --> 00:05:24.240 able to distinct between virtual addresses, which is what your 115 00:05:24.279 --> 00:05:28.920 code sees, and physical addresses the actual locations in memory, right. 116 00:05:28.839 --> 00:05:31.639 That whole virtual memory thing. Why is that distinction so 117 00:05:31.720 --> 00:05:33.360 important in reverse engineering? 118 00:05:33.680 --> 00:05:36.480 Because it helps us understand how the operating system manages 119 00:05:36.519 --> 00:05:40.120 memory and how code interacts with different layers of the system, 120 00:05:40.439 --> 00:05:41.680 including the kernel space. 121 00:05:41.800 --> 00:05:44.399 Okay, so it's about understanding the boundaries and who has 122 00:05:44.439 --> 00:05:46.759 access to what. Now I know you brought a real 123 00:05:46.800 --> 00:05:49.879 world example to help solidify our understanding of by eighty 124 00:05:49.920 --> 00:05:52.959 six by sixty four. It looks like a snippet of malware. 125 00:05:52.720 --> 00:05:55.560 Right, this is sample g Let's see how the theory 126 00:05:55.560 --> 00:05:58.040 we've discussed applies to this nasty little piece of code. 127 00:05:58.079 --> 00:06:01.879 Notice anything interesting The SIDT instruction jumps out of me. 128 00:06:01.959 --> 00:06:04.279 That's it. Isn't that related to interrupts? 129 00:06:04.319 --> 00:06:07.000 You've got it the interrupt descriptor table to be precise, 130 00:06:07.079 --> 00:06:10.959 It's all about how the operating system handles interrupt. 131 00:06:10.720 --> 00:06:14.439 Interrupts, right, like urgent messages that need immediate attention. So 132 00:06:14.560 --> 00:06:17.560 if this malware is messing with the interrupt descriptor table. 133 00:06:17.720 --> 00:06:21.079 It could potentially redirect those messages to its own code, 134 00:06:21.360 --> 00:06:24.639 gaining control of critical system functions. It's a pre sneaky 135 00:06:24.639 --> 00:06:26.040 way to hijack the system. 136 00:06:26.439 --> 00:06:29.920 Wow, so even the small snippet reveals a lot about 137 00:06:29.959 --> 00:06:33.639 the techniques used to hide malicious activities. This has been fascinating, 138 00:06:34.160 --> 00:06:36.319 But let's move on to the world of AARM. What 139 00:06:36.399 --> 00:06:39.079 are some of the key differences we should be aware of. 140 00:06:39.240 --> 00:06:41.560 Well, the first thing you'll encounter with AARM is something 141 00:06:41.560 --> 00:06:45.240 called thumb mode. It's like AARM has a split personality, 142 00:06:45.560 --> 00:06:48.680 unlike by eighty six with its distinct mode some mode. 143 00:06:48.759 --> 00:06:50.759 Okay, I'm intrigued. What's that all about? 144 00:06:51.079 --> 00:06:54.000 ARM can switch between ARM and thumb states on the fly. 145 00:06:54.439 --> 00:06:56.879 It's like trying to decipher a message where the language 146 00:06:56.879 --> 00:06:58.439 suddenly changes mid sentence. 147 00:06:58.600 --> 00:07:01.680 Wow. So ARM can change it's instruction set while it's running. 148 00:07:01.759 --> 00:07:04.680 That seems needlessly complicated, not at all. 149 00:07:04.839 --> 00:07:07.920 Thumb mode actually uses a more compact instruction set, which 150 00:07:07.959 --> 00:07:10.680 is perfect for smaller devices or when code size needs 151 00:07:10.720 --> 00:07:12.600 to be minimized. It's all about efficiency. 152 00:07:13.360 --> 00:07:16.199 Ah, So it's like having two tools in one, each 153 00:07:16.240 --> 00:07:19.240 optimized for different situations. But I can see how that 154 00:07:19.279 --> 00:07:21.439 would make reverse engineering a bit more challenging. 155 00:07:21.879 --> 00:07:24.959 Definitely adds a layer of complexity now compared to by 156 00:07:25.000 --> 00:07:29.160 eighty six by sixty four, AARM has fewer general purpose registers, 157 00:07:29.399 --> 00:07:31.160 but they each have a very specific role. 158 00:07:31.399 --> 00:07:34.360 Okay, fewer registers, but each one with a specific purpose. 159 00:07:34.560 --> 00:07:38.000 Does ARM have anything similar to the e F flags 160 00:07:38.040 --> 00:07:39.439 register we talked about earlier? 161 00:07:39.560 --> 00:07:43.319 It does. It's called the Current Program Status Register or CTSR. 162 00:07:43.560 --> 00:07:46.040 Like E flags, it holds all sorts of information about 163 00:07:46.040 --> 00:07:49.240 the processor state, including those all important condition flags. 164 00:07:49.319 --> 00:07:52.160 Condition flags, right, those were crucial and by eighty six 165 00:07:52.199 --> 00:07:55.040 by sixty four, but I'm guessing they work differently in AR. 166 00:07:55.519 --> 00:07:58.879 You're right to be cautious. Aarm's condition flags have their 167 00:07:58.920 --> 00:08:01.800 own quirks and the influence branching in a way that's 168 00:08:01.839 --> 00:08:04.800 unique to this architecture. It's another reminder that we can't 169 00:08:04.800 --> 00:08:07.199 just apply by eighty six logic to ARM and expect 170 00:08:07.199 --> 00:08:07.639 it to work. 171 00:08:07.839 --> 00:08:11.079 So each architecture has its own personality, its own way 172 00:08:11.079 --> 00:08:11.839 of doing things. 173 00:08:12.240 --> 00:08:15.560 Got it. What about data movement in ARM? How does 174 00:08:15.600 --> 00:08:16.879 that compare to GAYD six. 175 00:08:17.319 --> 00:08:21.279 You'll see familiar instructions like LDR and str for loading 176 00:08:21.319 --> 00:08:24.279 and storing data from memory. But unlike bay At six, 177 00:08:24.639 --> 00:08:27.399 ARM doesn't have those direct memory to memory moves. It 178 00:08:27.439 --> 00:08:29.959 relies more on registers as intermediaries. 179 00:08:30.079 --> 00:08:32.000 So it's a more restricted model. 180 00:08:32.159 --> 00:08:35.639 You could say that, and you'll also encounter those push 181 00:08:35.720 --> 00:08:39.399 and pop instructions essential for function calls and managing local 182 00:08:39.480 --> 00:08:40.399 variables on the stack. 183 00:08:40.440 --> 00:08:43.759 Okay, those sound familiar. Anything else about the ARM instruction 184 00:08:43.879 --> 00:08:45.240 set that really stands out? Oh? 185 00:08:45.320 --> 00:08:49.799 Absolutely, Arm's conditional execution is really something else. Imagine a 186 00:08:49.879 --> 00:08:53.440 single instruction that can set the conditions for multiple following instructions. 187 00:08:53.480 --> 00:08:56.559 Wait, so it's like a shorthand way of implementing conditional logic. 188 00:08:56.879 --> 00:08:59.840 That's exactly what aarm's IT blocks allow you to do. 189 00:09:00.240 --> 00:09:02.559 It's one of the things that makes reverse engineering airms 190 00:09:02.600 --> 00:09:04.960 so interesting. You have to be aware of these subtle 191 00:09:05.159 --> 00:09:08.600 yet powerful features that can really influence the flow of execution. 192 00:09:09.000 --> 00:09:12.480 It's like those condition flags have a ripple effect, influencing 193 00:09:12.559 --> 00:09:15.279 everything that comes after them. Now, I know you also 194 00:09:15.360 --> 00:09:18.679 brought a sample of ARM malware for us to dissect. 195 00:09:18.759 --> 00:09:21.159 Right, this is sample K. Let's take a look at 196 00:09:21.200 --> 00:09:24.480 how this malware takes advantage of arm's unique features and 197 00:09:24.559 --> 00:09:28.440 what challenges it presents for reverse engineers. The first thing 198 00:09:28.480 --> 00:09:31.759 that jumps out is the extensive use of conditional execution. 199 00:09:32.399 --> 00:09:35.120 So it's using those IT blocks we talked about makes sense. 200 00:09:35.120 --> 00:09:38.759 It's like a dynamic maze where the walls can shift 201 00:09:38.799 --> 00:09:40.799 based on certain conditions precisely. 202 00:09:41.200 --> 00:09:44.080 And to make matters worse, it also leverages the link 203 00:09:44.080 --> 00:09:48.279 register in some interesting ways, perhaps storing data temporarily or 204 00:09:48.320 --> 00:09:50.559 even using it to obtuscate the flow of control. 205 00:09:50.720 --> 00:09:53.279 It's like taking those unique features of ARM and turning 206 00:09:53.279 --> 00:09:56.240 them into weapons to hide its malicious activities. This is 207 00:09:56.279 --> 00:09:58.399 getting pretty intense. We've covered a lot of ground with 208 00:09:58.519 --> 00:10:01.320 BY eighty six, BY sixty four and AIRM, but there's 209 00:10:01.399 --> 00:10:03.399 one more piece of the puzzle. We need to address 210 00:10:03.919 --> 00:10:05.039 the Windows. 211 00:10:04.600 --> 00:10:07.039 Kernel, the heart of the operating system exactly. 212 00:10:07.600 --> 00:10:10.840 But diving into kernel level code can be pretty intimidating. 213 00:10:11.039 --> 00:10:13.200 What are the essential concepts we need to grasp. 214 00:10:13.559 --> 00:10:16.840 Let's start with that concept of user space versus kernel space, 215 00:10:17.120 --> 00:10:20.320 that layered cake we talked about earlier. Kernel code has 216 00:10:20.399 --> 00:10:25.519 complete access to the system, while user mode code is well, 217 00:10:25.519 --> 00:10:26.600 it's restricted, right. 218 00:10:27.000 --> 00:10:30.200 The kernel is like the ultimate authority, calling all the shots. 219 00:10:30.960 --> 00:10:34.759 So how do these two spaces interact? How does user 220 00:10:34.799 --> 00:10:37.000 mode code request services. 221 00:10:36.519 --> 00:10:40.039 From the kernel through system calls? User mode code uses 222 00:10:40.080 --> 00:10:44.399 specific mechanisms like interrupts or special instructions depending on the architecture. 223 00:10:44.519 --> 00:10:46.840 It's like knocking on the kernel's door and asking. 224 00:10:46.559 --> 00:10:49.200 For something, and the kernel has a system for handling 225 00:10:49.240 --> 00:10:52.480 these requests, making sure they're legitimate and granting access to 226 00:10:52.519 --> 00:10:53.759 the appropriate resources. 227 00:10:54.120 --> 00:10:57.720 Exactly. The kernel has tables that map system call numbers 228 00:10:57.720 --> 00:11:00.639 to the actual functions that handle those requests. And guess what, 229 00:11:00.679 --> 00:11:03.080 if malware wants to get sneaky, it might try to 230 00:11:03.120 --> 00:11:04.120 manipulate those tables. 231 00:11:04.120 --> 00:11:06.519 Oh no, So it's like setting up a fake door 232 00:11:06.559 --> 00:11:08.840 that looks like the real one, tricking the user mode 233 00:11:08.840 --> 00:11:10.799 code into making requests to the wrong place. 234 00:11:11.000 --> 00:11:14.360 Exactly. It's a common technique used by rootkits, those stealthy 235 00:11:14.399 --> 00:11:17.080 types of malware that try to burrow deep into the system. 236 00:11:17.159 --> 00:11:20.120 This is getting scary. It's like a constant battle between 237 00:11:20.159 --> 00:11:22.879 those trying to protect the system and those trying to 238 00:11:22.919 --> 00:11:26.720 exploit it. What else is crucial for understanding the kernel? 239 00:11:27.120 --> 00:11:30.799 IRQL or interrupt request level is a pretty important concept, 240 00:11:30.840 --> 00:11:32.799 even though it can be a bit abstract. It's a 241 00:11:32.799 --> 00:11:36.679 way of managing the system's interruptability, determining what code can 242 00:11:36.759 --> 00:11:38.720 run and how interrupts are handled. 243 00:11:38.799 --> 00:11:40.960 So it's like a priority system. Some code gets to 244 00:11:41.039 --> 00:11:41.960 jump to the funnel line. 245 00:11:42.000 --> 00:11:44.399 You got it. There are two key levels to be 246 00:11:44.440 --> 00:11:49.200 aware of, passive level and dispatch level. Most user mode 247 00:11:49.240 --> 00:11:51.679 code and much of the kernel runs at passive level, 248 00:11:51.720 --> 00:11:55.480 which is the normal interruptible state. But dispatch level that's 249 00:11:55.519 --> 00:11:58.960 for critical code that can't be interrupted like thread scheduling. 250 00:11:58.759 --> 00:12:00.879 Makes sense, can have the system crashing just because some 251 00:12:01.000 --> 00:12:03.720 random process needs attention. What else is there to know 252 00:12:03.759 --> 00:12:04.759 about the kernel? Well? 253 00:12:04.799 --> 00:12:07.639 You also provided sources on linked lists and how the 254 00:12:07.679 --> 00:12:11.399 Windows kernel uses them extensively for managing things like processes, threads, 255 00:12:11.600 --> 00:12:12.639 and loaded modules. 256 00:12:12.960 --> 00:12:15.679 Linked lists, right, those are those data structures where each 257 00:12:15.679 --> 00:12:18.080 element points to the next one. But what makes them 258 00:12:18.120 --> 00:12:20.080 so special in the context of the kernel. 259 00:12:20.240 --> 00:12:23.080 The kernel uses them everywhere to keep track of all 260 00:12:23.120 --> 00:12:26.720 sorts of things. Understanding how they're used and manipulated is 261 00:12:26.919 --> 00:12:31.080 essential for reversing kernel level code. They're like the organizational 262 00:12:31.120 --> 00:12:32.120 structure of the kernel. 263 00:12:32.240 --> 00:12:34.440 So if you want to understand how the kernel keeps 264 00:12:34.480 --> 00:12:37.519 track of everything, you need to understand how it uses linked. 265 00:12:37.200 --> 00:12:41.720 Lists precisely, and there are specific functions for manipulating linked 266 00:12:41.720 --> 00:12:46.320 lists like insert headlist and remove entry list. Now, imagine 267 00:12:46.360 --> 00:12:48.159 malware that wants to hide itself. 268 00:12:48.159 --> 00:12:51.120 It could like remove its entry from a linked list right, 269 00:12:51.240 --> 00:12:53.279 making it invisible to security tool. 270 00:12:53.159 --> 00:12:55.840 You got it. Or it could try to insert itself 271 00:12:55.879 --> 00:12:58.879 into a critical list to gain control of a system process. 272 00:12:59.399 --> 00:13:02.399 Even something as seemingly basic as a link list can 273 00:13:02.480 --> 00:13:04.399 be exploited for malicious purposes. 274 00:13:04.519 --> 00:13:07.720 It's amazing how something so fundamental can be twisted for evil. 275 00:13:08.000 --> 00:13:10.759 This is mind blowing. Now. You mentioned earlier that the 276 00:13:10.840 --> 00:13:14.080 kernel doesn't always operate in a neat sequential manner. 277 00:13:13.919 --> 00:13:17.200 Right, that's the whole idea of asynchronous execution. Things can 278 00:13:17.240 --> 00:13:20.240 happen out of order in parallel. You have things like 279 00:13:20.360 --> 00:13:22.519 dpcs and work items running code in the. 280 00:13:22.519 --> 00:13:26.000 Background, So it's like having multiple tasks running at the 281 00:13:26.000 --> 00:13:28.000 same time behind the scenes exactly. 282 00:13:28.440 --> 00:13:30.720 And this adds a whole other layer of complexity to 283 00:13:30.799 --> 00:13:34.360 reverse engineering because you can't just follow the code linearly anymore. 284 00:13:34.720 --> 00:13:37.559 You need to be aware of these background tasks and 285 00:13:37.600 --> 00:13:39.360 how they might be interacting with the system. 286 00:13:39.639 --> 00:13:42.200 Okay, this is getting pretty complex. But I think I'm 287 00:13:42.240 --> 00:13:45.799 starting to see why understanding the kernel is so crucial 288 00:13:46.320 --> 00:13:49.240 for advance reverse engineering. Now, I know you've brought some 289 00:13:49.279 --> 00:13:52.000 real world examples of rootkit code to show us how 290 00:13:52.000 --> 00:13:54.320 this all plays out, and practice. 291 00:13:53.720 --> 00:13:56.960 You got it. We've got sample F and sample I, 292 00:13:57.519 --> 00:13:59.960 both of which interact to the kernels in pretty interesting ways. 293 00:14:00.360 --> 00:14:02.879 Let's start with Sample F. What do you notice about it? 294 00:14:03.159 --> 00:14:06.039 Hmmm, well, it seems to be modifying the system service 295 00:14:06.039 --> 00:14:10.159 descripture table. Isn't that the table that maps system calls 296 00:14:10.200 --> 00:14:12.039 to their handlers bingo? 297 00:14:12.600 --> 00:14:16.039 It's redirecting system calls to its own malicious code. 298 00:14:16.120 --> 00:14:19.759 So it's basically taking control of those system calls, intercepting 299 00:14:19.799 --> 00:14:22.039 them before they can reach their intended destination. 300 00:14:22.279 --> 00:14:25.039 And to make matters worse, it does all this while 301 00:14:25.120 --> 00:14:28.840 running at a high IRQL, making it difficult to interrupt. 302 00:14:29.080 --> 00:14:32.000 It's like a thief disabling the alarm system before breaking in. 303 00:14:32.480 --> 00:14:36.039 It's trying to be as stealthy and as disruptive as possible. 304 00:14:36.080 --> 00:14:38.320 This is like something out of a spy movie. What 305 00:14:38.399 --> 00:14:40.759 about Sample I? Does it use similar techniques? 306 00:14:40.840 --> 00:14:44.080 Sable A is even more sophisticated. It not only hooks 307 00:14:44.120 --> 00:14:47.440 system calls, but It also manipulates linked lists to hide. 308 00:14:47.240 --> 00:14:50.600 Itself, so it's covering its tracks, erasing any evidence of 309 00:14:50.639 --> 00:14:52.080 its presence exactly. 310 00:14:52.120 --> 00:14:54.480 It's like a masterclass in stealth and evasion. 311 00:14:54.960 --> 00:14:58.200 This has been an incredible deep dive. We've explored by 312 00:14:58.279 --> 00:15:02.039 eighty six, by sixty four, arm architectures and even the 313 00:15:02.039 --> 00:15:04.840 Windows kernel. I feel like I've learned so much, but 314 00:15:04.919 --> 00:15:07.240 it's clear there's still so much more to discover. 315 00:15:07.559 --> 00:15:09.840 You've done a great job grapping these concepts. It's a 316 00:15:09.879 --> 00:15:12.279 complex field, but you're clearly a natural at this. 317 00:15:12.720 --> 00:15:16.240 Thanks. I'm definitely feeling more confident about tackling these challenges. 318 00:15:16.960 --> 00:15:19.120 What would you say are the most important takeaways for 319 00:15:19.200 --> 00:15:21.240 someone just starting out in reverse engineering? 320 00:15:21.600 --> 00:15:25.799 A solid understanding of those fundamentals is crucial. Computer architecture, 321 00:15:25.879 --> 00:15:29.559 assembly language, operating systems, and don't be afraid to get 322 00:15:29.600 --> 00:15:33.600 your hands dirty, analyze real world code, experiment and learn 323 00:15:33.600 --> 00:15:34.440 from your mistakes. 324 00:15:34.639 --> 00:15:37.799 That's great advice. And as we've seen, reverse engineering isn't 325 00:15:37.840 --> 00:15:42.320 just a theoretical exercise. It is real world applications in cybersecurity, 326 00:15:42.440 --> 00:15:44.960 software development, and digital forensics. 327 00:15:45.039 --> 00:15:48.639 Absolutely, and as technology continues to evolve, the role of 328 00:15:48.679 --> 00:15:50.840 reverse engineering will only become more critical. 329 00:15:51.159 --> 00:15:53.679 This has been an amazing journey, but I think we 330 00:15:53.759 --> 00:15:55.720 need to take a break here. Ready to move on 331 00:15:55.799 --> 00:15:58.120 to part two where we delve deeple into the world 332 00:15:58.240 --> 00:15:59.159 of oppuscation. 333 00:15:59.440 --> 00:16:01.600 Absolutely Part two is going to be a wild ride. 334 00:16:02.240 --> 00:16:04.679 Welcome back. We've laid a pretty solid foundation in this 335 00:16:05.440 --> 00:16:08.559 world of reverse engineering. Now let's dive into a fascinating 336 00:16:08.600 --> 00:16:11.240 aspect of this field. It's called obfuscation. 337 00:16:11.679 --> 00:16:16.360 Obfuscation, the word itself sounds like intentionally confusing. Is that 338 00:16:16.440 --> 00:16:18.759 the whole point to make code difficult to understand? 339 00:16:19.080 --> 00:16:23.120 Precisely, it's the art of hiding the true intentive code 340 00:16:23.440 --> 00:16:27.720 while still preserving its functionality. Like think of it as 341 00:16:27.759 --> 00:16:31.200 a magician's sleight of hand. You know, the trick still works, 342 00:16:31.600 --> 00:16:33.960 but the method is completely concealed. 343 00:16:33.759 --> 00:16:36.720 So it's like speaking in code, making sure only those 344 00:16:36.759 --> 00:16:39.000 in the know can understand the message. 345 00:16:39.519 --> 00:16:41.799 That's a great analogy. Just like there are tons of 346 00:16:41.799 --> 00:16:45.559 ways to encode messages, there are different techniques for obfuscating code. 347 00:16:45.720 --> 00:16:48.480 One common one is manipulating the control flow. 348 00:16:48.720 --> 00:16:51.919 Control flow right, that's how the program executes instructions like 349 00:16:52.320 --> 00:16:55.440 it's a roadmap, guiding the execution from one point to another. 350 00:16:55.559 --> 00:16:59.720 You got it. Obfuscators can introduce like unnecessary jumps or 351 00:17:00.200 --> 00:17:04.519 convoluted loops. They might even like interleave unrelated code segments 352 00:17:04.519 --> 00:17:05.960 to make it harder to follow the logic. 353 00:17:06.119 --> 00:17:08.240 So it's like taking a straightforward map and turning it 354 00:17:08.279 --> 00:17:10.680 into a tangled web of paths exactly. 355 00:17:11.160 --> 00:17:14.119 And this can be really effective against automated analysis tools, 356 00:17:14.279 --> 00:17:17.039 you know, those that rely on predictable patterns. It throws 357 00:17:17.039 --> 00:17:18.240 a wrench in the whole system. 358 00:17:18.359 --> 00:17:20.799 So it's a way to outsmart the machines by making 359 00:17:20.880 --> 00:17:24.559 the code look less like well machine generated and more 360 00:17:24.599 --> 00:17:27.839 like something a human wrote, with all its quirks and complexities. 361 00:17:28.119 --> 00:17:30.839 You're catching on quickly. It's like an ongoing arms race, 362 00:17:31.000 --> 00:17:33.000 you know, between those who want to protect their code 363 00:17:33.240 --> 00:17:36.119 and those who are trying to understand it. Speaking of which, 364 00:17:36.359 --> 00:17:39.240 our sources mentioned something called opaque predicates. 365 00:17:39.640 --> 00:17:44.200 Opaque predicates, Hmmm, those sound intriguing. What are those all about? 366 00:17:44.440 --> 00:17:47.559 Think of them like riddles embedded in the code, conditions 367 00:17:47.559 --> 00:17:50.480 that are deliberately designed to be super hard to analyze, 368 00:17:50.799 --> 00:17:55.119 often involving like complex calculations or even external factors that 369 00:17:55.160 --> 00:17:56.920 are unknown at compile time. 370 00:17:57.200 --> 00:17:59.720 So it's like creating a puzzle within a puzzle, make 371 00:17:59.759 --> 00:18:02.559 it's so difficult to determine which pass the code will take, 372 00:18:02.640 --> 00:18:04.240 the reverse engineer just gives. 373 00:18:04.079 --> 00:18:06.799 Up, Yeah, that's the idea. And these techniques can be 374 00:18:06.799 --> 00:18:11.720 pretty sophisticated, ranging from like simple tricks to super elaborate schemes. 375 00:18:11.880 --> 00:18:14.319 It's like the difference between hiding something in plain sight 376 00:18:14.480 --> 00:18:17.519 and creating an elaborate escape room. Sound like obfuscation is 377 00:18:17.559 --> 00:18:19.119 a whole field of study in itself. 378 00:18:19.480 --> 00:18:21.880 It definitely is, and it's tied to other areas like 379 00:18:21.960 --> 00:18:27.799 software protection, anti tampering, and digital rights management. Anything focused 380 00:18:27.839 --> 00:18:29.680 on controlling how software. 381 00:18:29.319 --> 00:18:32.680 Is used, really right, because in those cases you're trying 382 00:18:32.680 --> 00:18:36.039 to protect something valuable, whether it's you know, intellectual property 383 00:18:36.279 --> 00:18:39.559 data or the integrity of a system. But if someone's 384 00:18:39.640 --> 00:18:42.799 really determined to understand the code, are there ways to 385 00:18:42.880 --> 00:18:44.079 reverse these techniques? 386 00:18:44.279 --> 00:18:49.079 Absolutely? De Abfuscation is like the countermeasure to obfuscation. It's 387 00:18:49.119 --> 00:18:50.880 a fascinating field in its own right. 388 00:18:51.000 --> 00:18:54.720 So it's like having a codebreaker, someone who specializes in 389 00:18:54.759 --> 00:18:57.079 deciphering those secret messages exactly. 390 00:18:57.160 --> 00:19:00.599 And just like there are different encoding techniques, the multiple 391 00:19:00.599 --> 00:19:04.559 approaches to deobfuscation, each with its own strengths and weaknesses. 392 00:19:05.240 --> 00:19:08.400 Our sources mentioned something called pattern based deobfuscation. 393 00:19:08.839 --> 00:19:12.200 Pattern based that almost sounds well simple. 394 00:19:12.480 --> 00:19:16.839 It's essentially about identifying common patterns in obfuscated code and 395 00:19:16.920 --> 00:19:19.880 developing rules to transform it back into a more readable form. 396 00:19:20.000 --> 00:19:22.160 So it's like having a cheat sheet for those obfuscation 397 00:19:22.200 --> 00:19:23.160 tricks you got. 398 00:19:23.200 --> 00:19:27.000 It works pretty well against simple obfuscators, you know, those 399 00:19:27.039 --> 00:19:29.720 relying on a limited set of patterns. But what happens 400 00:19:29.720 --> 00:19:31.880 when you encounter something more complex. 401 00:19:31.920 --> 00:19:35.400