WEBVTT 1 00:00:00.120 --> 00:00:02.799 Have you ever looked at a piece of software, you know, 2 00:00:02.879 --> 00:00:05.480 an app or maybe part of your OS, and just 3 00:00:05.559 --> 00:00:08.599 wondered what's really going on under the hood, Especially when 4 00:00:08.679 --> 00:00:13.320 all you've got is that compiled binary, that black box 5 00:00:13.400 --> 00:00:16.320 of machine language. How do you even start to peel 6 00:00:16.359 --> 00:00:17.199 back those layers? 7 00:00:17.440 --> 00:00:18.519 How do you see inside? 8 00:00:18.679 --> 00:00:21.480 Our deep dive today is all about cracking that open 9 00:00:22.239 --> 00:00:28.079 We're talking GIEDRA. It's a real powerhouse for software reverse engineering. Sorry. 10 00:00:28.199 --> 00:00:31.079 Absolutely think of it like a universal translator from machine 11 00:00:31.079 --> 00:00:31.920 code exactly. 12 00:00:32.000 --> 00:00:35.320 Takes that dense, inscrutable stuff and makes it well understandable. 13 00:00:35.399 --> 00:00:38.359 And here's the kicker, right, GUIDRA wasn't just built by 14 00:00:38.399 --> 00:00:40.920 some startup. This thing came out of the NSA. 15 00:00:41.240 --> 00:00:44.679 Yeah, a National security agency, developed in house. 16 00:00:44.479 --> 00:00:48.719 And then amazingly they released it open source to the public, 17 00:00:48.719 --> 00:00:49.039 which was. 18 00:00:49.000 --> 00:00:50.119 A pretty big deal at the time. 19 00:00:50.240 --> 00:00:53.479 Still is it really is? So this isn't some niche tool, 20 00:00:53.600 --> 00:00:57.159 it's government grade stuff for understanding compiled code, and now 21 00:00:57.399 --> 00:01:00.159 you know, anyone can use it. So our mission today 22 00:01:00.200 --> 00:01:03.119 is to unpack what GEDRA can do from just looking 23 00:01:03.119 --> 00:01:08.920 at a file to really advance stuff like customization, even 24 00:01:09.000 --> 00:01:10.719 tackling antire tricks. 25 00:01:10.760 --> 00:01:14.079 Yeah, it's about getting you informed about that digital. 26 00:01:13.760 --> 00:01:15.159 Core, giving you that shortcut. 27 00:01:15.319 --> 00:01:17.640 What's really cool is how Geedra kind of levels the 28 00:01:17.640 --> 00:01:20.760 playing field. It gives you insights into binaries that would 29 00:01:20.760 --> 00:01:25.120 otherwise just be opaque. Whether you're a pro reverse engineer 30 00:01:25.159 --> 00:01:27.959 looking at malware or just you know, super curious about 31 00:01:28.000 --> 00:01:31.840 how software actually works. Guidra lets you see that digital core. 32 00:01:32.079 --> 00:01:34.400 Okay, so before we jump right into Gidra itself, let's 33 00:01:34.519 --> 00:01:36.799 back up a bit. Why do we even need tools 34 00:01:36.840 --> 00:01:39.680 like this? Why look inside compiled software? Shouldn't we just 35 00:01:39.840 --> 00:01:40.760 I don't know, trust it? 36 00:01:41.159 --> 00:01:45.560 Well? Ideally maybe, but the real world's mess here. A 37 00:01:45.680 --> 00:01:47.879 huge reason is vulnerability. 38 00:01:47.280 --> 00:01:49.519 Analysis, finding security holes. 39 00:01:49.239 --> 00:01:53.439 Exactly, discovering and analyzing potentially exploitable flaws. You might use 40 00:01:53.439 --> 00:01:56.519 fuzzing dynamic stuff to find crashes, but Guedra lets you 41 00:01:56.560 --> 00:02:00.640 do static analysis to really understand if something's exploitable and 42 00:02:00.760 --> 00:02:04.200 how what are the conditions? Static analysis is key? There? 43 00:02:04.239 --> 00:02:05.159 Gotcha? What else? 44 00:02:05.439 --> 00:02:09.879 Then? There's software interoperability, big one. If something's only released 45 00:02:09.919 --> 00:02:12.800 as a binary, making other software work with it, or 46 00:02:12.840 --> 00:02:15.479 writing plugins, it's incredibly hard. 47 00:02:15.639 --> 00:02:18.719 Ah like writing drivers for hardware maybe. 48 00:02:18.439 --> 00:02:22.919 Perfect example, drivers for hardware that only officially supports, say Windows, 49 00:02:22.919 --> 00:02:25.840 but you want it on Linux, you'll probably need to 50 00:02:25.840 --> 00:02:29.599 do some serious reverse engineering, maybe even beyond drivers into 51 00:02:29.639 --> 00:02:30.199 the firmware. 52 00:02:30.280 --> 00:02:31.280 Okay, that makes sense. 53 00:02:31.360 --> 00:02:35.199 And then there's always the let's call it source code recovery. 54 00:02:34.800 --> 00:02:36.879 Angle, right, trying to get back to something readable. 55 00:02:36.960 --> 00:02:39.520 Yeah, you'll never get the original source code back perfectly 56 00:02:39.719 --> 00:02:42.439 with comments and all that. We can't do something readable 57 00:02:42.439 --> 00:02:47.000 from a binary. That's still super attractive competitive analysis, understanding 58 00:02:47.000 --> 00:02:49.680 old systems. Lots of reasons. 59 00:02:49.719 --> 00:02:51.960 Okay, I get the why, But what makes it so 60 00:02:52.120 --> 00:02:56.039 darn difficult going from that compiled binary back to something 61 00:02:56.439 --> 00:02:59.960 human readable. You said it's like rebuilding a cake from crumb. 62 00:03:00.439 --> 00:03:03.199 That's a good analogy. The core problem is the compilation 63 00:03:03.319 --> 00:03:04.319 process itself. 64 00:03:04.560 --> 00:03:07.520 It's lossy, lossy meaning information gets thrown away. 65 00:03:07.599 --> 00:03:10.800 Exactly when you compile C plus plus or Java down 66 00:03:10.840 --> 00:03:14.560 to machine code. Tons of useful info is just gone. 67 00:03:14.800 --> 00:03:19.840 Variable names, function names, comments, forget it. Wow, even variable types. 68 00:03:20.000 --> 00:03:22.960 At the machine level, GIDRA might see, say thirty two 69 00:03:23.000 --> 00:03:25.599 bits of data being moved. Is that an integer, a 70 00:03:25.639 --> 00:03:28.319 floating point number, a memory address, a pointer. 71 00:03:28.520 --> 00:03:29.039 It doesn't know. 72 00:03:29.319 --> 00:03:30.960 It has to infer it, it has to look at 73 00:03:30.960 --> 00:03:32.840 how that data is used later on to make an 74 00:03:32.960 --> 00:03:36.879 educated guess ah, and that ambiguity that inferenced. That's why 75 00:03:36.919 --> 00:03:40.159 decompilation is still a really active research area in computer science. 76 00:03:40.159 --> 00:03:41.400 It's fundamentally hard. 77 00:03:41.240 --> 00:03:43.919 So gijra's first big job is to try and bridge 78 00:03:43.960 --> 00:03:46.759 that gap, to get those machine code crumbs into some 79 00:03:46.840 --> 00:03:49.599 kind of order, and that starts with disassembly right. 80 00:03:49.520 --> 00:03:52.879 Right at its most basic level. GIDRA takes the machine language, 81 00:03:53.120 --> 00:03:56.319 those raw binary patterns OPT codes and turns them into 82 00:03:56.360 --> 00:03:57.240 assembly language. 83 00:03:57.240 --> 00:03:59.759 The mnemonics like a push and mov. 84 00:04:00.000 --> 00:04:05.439 Exactly, those short memorable sequences pH EBP, mv EAX, stuff 85 00:04:05.479 --> 00:04:08.639 like that. It makes the raw instructions way easier for 86 00:04:08.719 --> 00:04:09.879 humans to read and track. 87 00:04:10.199 --> 00:04:13.479 But even that basic step isn't simple, not entirely. 88 00:04:14.039 --> 00:04:17.360 First, Geedra has to figure out what's actually code versus 89 00:04:17.399 --> 00:04:18.680 what's just data stored in. 90 00:04:18.639 --> 00:04:20.519 The program because they can be mixed together. 91 00:04:20.879 --> 00:04:25.120 They often are. Luckily standard file formats like PE for 92 00:04:25.199 --> 00:04:29.439 Windows or ELF for Linux and Unix have headers. These 93 00:04:29.480 --> 00:04:32.199 headers give GEDRA clues about where the code sections likely 94 00:04:32.240 --> 00:04:32.959 start and end. 95 00:04:33.120 --> 00:04:33.360 OK. 96 00:04:34.040 --> 00:04:36.800 Then it has to match the binary opcodes it finds 97 00:04:37.079 --> 00:04:40.519 to the right assembly mnemonic that's mostly a table look up, 98 00:04:40.800 --> 00:04:43.399 but it gets tricky with things like instruction prefixes or 99 00:04:43.480 --> 00:04:46.279 variable length instructions, which you see a lot in say 100 00:04:46.519 --> 00:04:48.120 Intel by eighty six architecture. 101 00:04:48.199 --> 00:04:50.720 Right, So, assuming it figures out the instructions, how does 102 00:04:50.720 --> 00:04:53.199 it know which one comes next. Programs don't just run 103 00:04:53.240 --> 00:04:54.639 straight down, they jump around. 104 00:04:54.720 --> 00:04:57.839 That's the next big challenge navigating control flow. A really 105 00:04:57.879 --> 00:05:01.480 simple approach is linear sweep, just assemble one instruction after 106 00:05:01.519 --> 00:05:01.759 the other. 107 00:05:01.839 --> 00:05:02.800 But that breaks easily. 108 00:05:03.040 --> 00:05:06.000 Oh yeah, it gets totally confused by jumps and branches, 109 00:05:06.360 --> 00:05:09.600 and it can easily misinterpret data as code. So GIDRI 110 00:05:09.759 --> 00:05:12.040 uses a much smarter method called recursive descent. 111 00:05:12.480 --> 00:05:14.639 Recursive descent how does that work? 112 00:05:15.000 --> 00:05:17.720 So when it hits a conditional jump like jump if 113 00:05:17.720 --> 00:05:20.800 not zero, it basically says, okay, the program could go 114 00:05:20.879 --> 00:05:24.560 this way, or it could just continue straight on. It 115 00:05:24.600 --> 00:05:27.360 picks one path to follow immediately and puts the other 116 00:05:27.360 --> 00:05:29.560 path's starting address on a list to check out later, 117 00:05:29.759 --> 00:05:32.800 a to do list pretty much a list of deferred addresses. 118 00:05:33.000 --> 00:05:35.319 If it's an unconditional jump, it tries to figure out 119 00:05:35.319 --> 00:05:36.480 the target and just goes there. 120 00:05:36.600 --> 00:05:39.199 Okay, that sounds much more robust, but What about jumps 121 00:05:39.199 --> 00:05:40.639 where the target isn't obvious. 122 00:05:40.759 --> 00:05:43.600 Ah. Yeah, that's where recursive descent hits its limits too, 123 00:05:44.120 --> 00:05:47.920 things like jump racks in I two. The target addresses 124 00:05:48.000 --> 00:05:50.279 whatever value is in the racks register at runtime. 125 00:05:50.480 --> 00:05:53.000 So GIDRA can't know that just by looking at the code. 126 00:05:53.040 --> 00:05:57.839 Nope, static analysis can't predict runtime values. Or think about 127 00:05:57.839 --> 00:06:01.160 a reinstruction return from function That tells you nothing about 128 00:06:01.160 --> 00:06:02.519 where execution will go next. 129 00:06:02.560 --> 00:06:03.160 So what does it do? 130 00:06:03.240 --> 00:06:05.879 Then? That's when it goes back to its to do list. 131 00:06:06.279 --> 00:06:08.279 It picks up one of those deferred addresses it saved 132 00:06:08.279 --> 00:06:12.079 earlier and starts disassembling from there. That's the recursive part 133 00:06:12.120 --> 00:06:15.319 of the name. It keeps exploring all these potential paths 134 00:06:15.680 --> 00:06:18.639 until it's mapped out as much of the program's structure 135 00:06:18.639 --> 00:06:19.279 as possible. 136 00:06:19.399 --> 00:06:23.000 Wow. Okay, so it's not just translating, it's actively exploring 137 00:06:23.040 --> 00:06:24.439 and mapping the possibilities. 138 00:06:24.519 --> 00:06:26.199 Quite the detective, you could say that. 139 00:06:26.519 --> 00:06:30.720 So GIDRA does all this heavy lifting with disassembly. How 140 00:06:30.759 --> 00:06:34.680 does a user someone sitting down with it, actually get started? 141 00:06:34.720 --> 00:06:35.759 What's the entry point? 142 00:06:35.920 --> 00:06:38.759 It's actually pretty user friendly. You launch gedra first time, 143 00:06:38.759 --> 00:06:41.319 you'll see the license agreement. Click through that. Then you 144 00:06:41.319 --> 00:06:43.399 get a tip of the day and the main Gidra 145 00:06:43.480 --> 00:06:46.519 project window pops up. Okay, your first real step is 146 00:06:46.560 --> 00:06:49.639 to create a project. Geedra uses this project to keep 147 00:06:49.680 --> 00:06:53.519 everything organized. The file you're analyzing, your notes, everything. You 148 00:06:53.600 --> 00:06:56.879 choose between non shared or shared. For working alone, you 149 00:06:57.000 --> 00:07:00.519 just pick non shared, give it a directory and a name. Simple, 150 00:07:00.680 --> 00:07:01.079 got it. 151 00:07:01.240 --> 00:07:03.399 Project setup. Then you bring in the file. 152 00:07:03.639 --> 00:07:07.560 Right, you import the file either file import file or 153 00:07:07.639 --> 00:07:10.600 just drag and drop it onto the project window. Geedra 154 00:07:10.680 --> 00:07:12.959 looks at the file, tries to figure out what it 155 00:07:13.000 --> 00:07:17.879 is pe elf, macho, and suggests a format a loader. 156 00:07:17.600 --> 00:07:19.399 And you usually just accept the default. 157 00:07:19.480 --> 00:07:24.079 Often yeah, getar's pretty good at recognizing common formats. If 158 00:07:24.079 --> 00:07:26.560 it's something weird or just raw binary code, you might 159 00:07:26.560 --> 00:07:29.160 select raw binary and maybe give it some hints. There 160 00:07:29.199 --> 00:07:31.480 are options you can tweak as you get more experienced, 161 00:07:31.680 --> 00:07:34.040 like telling it to load external libraries. 162 00:07:34.120 --> 00:07:36.120 Okay, file imported. What happens then? 163 00:07:36.480 --> 00:07:40.000 Then Gidra asks if you want to autoanalyze it, and 164 00:07:40.079 --> 00:07:41.680 you almost always say yes. 165 00:07:42.000 --> 00:07:43.160 That's where the magic happens. 166 00:07:43.240 --> 00:07:45.399 That's where a ton of automated work kicks in. Getra 167 00:07:45.480 --> 00:07:49.480 starts identifying functions finding data, recognizing common code patterns, building 168 00:07:49.519 --> 00:07:52.279 cross references, all that stuff we talked about. You can 169 00:07:52.319 --> 00:07:54.480 actually watch its progress in the bottom right of the 170 00:07:54.480 --> 00:07:57.279 main window the cod browser, or look at the detailed 171 00:07:57.319 --> 00:07:57.839 log file. 172 00:07:57.879 --> 00:08:00.160 So it does a massive amount of groundwork automatically. 173 00:08:00.480 --> 00:08:04.800 Absolutely, it takes that raw imported binary and brings it 174 00:08:04.839 --> 00:08:07.759 into a much more structured, analyzed state ready for you 175 00:08:07.800 --> 00:08:09.560 to start exploring. It really guides you in. 176 00:08:09.879 --> 00:08:13.319 Okay, So the auto analysis finishes and you're dropped into 177 00:08:13.360 --> 00:08:16.720 the Gidra code Browser. That's the main workspace, right, What 178 00:08:16.759 --> 00:08:18.319 does that look like? What are the key parts? 179 00:08:18.600 --> 00:08:21.480 Code browser is your command center. It's a multi window interface, 180 00:08:21.959 --> 00:08:26.120 quite rich by default. You'll likely see a few key windows, 181 00:08:26.319 --> 00:08:28.600 but let's focus on maybe the three most important ones 182 00:08:28.600 --> 00:08:31.360 to start. Okay, First, there's the listing window. This is 183 00:08:31.360 --> 00:08:35.519 your assembly view. The direct translation of machine code into mnemonics. 184 00:08:35.960 --> 00:08:37.799 You see addresses the bites. 185 00:08:37.480 --> 00:08:39.759 The instructions, and those arrows you mentioned. 186 00:08:39.519 --> 00:08:43.480 Yeah, crucial feature flow arrows. They graphically show you where 187 00:08:43.519 --> 00:08:47.120 jumps and calls go. Solid arrows for unconditional jumps, dash 188 00:08:47.200 --> 00:08:50.360 for conditional ones, hover over them, double click to follow them. 189 00:08:50.799 --> 00:08:53.440 Makes tracing the program's path so much easier than just 190 00:08:53.440 --> 00:08:54.320 reading addresses. 191 00:08:54.480 --> 00:08:56.279 Helps visualize the flow exactly. 192 00:08:56.919 --> 00:09:00.000 Then right next to it often is the decompiler window. 193 00:09:00.159 --> 00:09:01.440 Ah, the crown jewel. 194 00:09:01.840 --> 00:09:05.519 Arguably yes, this is where GADRA tries its best to 195 00:09:05.600 --> 00:09:09.960 reconstruct high level C like source code from the assembly. 196 00:09:10.840 --> 00:09:11.840 How good is it? 197 00:09:11.840 --> 00:09:14.960 It's often remarkably good. It gives you a much much 198 00:09:15.039 --> 00:09:17.240 higher level understanding of what the code is trying to 199 00:09:17.279 --> 00:09:20.639 do the logic compared to just staring at assembly. Now, 200 00:09:20.639 --> 00:09:21.879 it's not perfect. 201 00:09:21.600 --> 00:09:24.080 Right because of that lossy compilation precisely. 202 00:09:24.159 --> 00:09:27.039 Sometimes it has to guess types, maybe it overuses casts, 203 00:09:27.200 --> 00:09:29.799 and it always generates C even if the original code 204 00:09:29.879 --> 00:09:32.200 was C plus plus or something else. But still it's 205 00:09:32.240 --> 00:09:35.240 incredibly valuable for quickly grasping function logic. 206 00:09:35.440 --> 00:09:39.399 Okay, listing for assembly decompiler for pseudo C. What's the 207 00:09:39.440 --> 00:09:40.440 third key window? 208 00:09:40.600 --> 00:09:43.399 The symbol tree window. This is all about program structure. 209 00:09:43.639 --> 00:09:46.519 It shows you information extracted from the binary symbol tables 210 00:09:46.639 --> 00:09:50.639 if they exist, like function names, functions, labels, global variables, classes, 211 00:09:50.720 --> 00:09:54.360 name spaces, and really importantly, imports and exports. 212 00:09:54.519 --> 00:09:59.000 Imports being stuff the program uses from outside, like libraries. 213 00:09:58.639 --> 00:10:02.960 YEP functions imports from shared libraries and exports are the 214 00:10:03.120 --> 00:10:05.840 entry points into this file. Things it provides for others, 215 00:10:06.120 --> 00:10:09.159 including the main program entry point often called entry. 216 00:10:09.000 --> 00:10:11.960 Or start, and this helps you navigate massively. 217 00:10:12.480 --> 00:10:15.480 It's also where you often spot C plus plus code 218 00:10:15.600 --> 00:10:19.519 because of name mangling. C plus plus compilers tweak function 219 00:10:19.639 --> 00:10:23.240 names to handle overloading adding extra characters. GIDRA shows you 220 00:10:23.279 --> 00:10:26.080 these mangled names and often tries to demangle them back 221 00:10:26.120 --> 00:10:30.039 to something readable. Super useful for understanding C plus plus binaries. 222 00:10:30.279 --> 00:10:34.240 So these three windows listing, Decompiler, symbol tree give you 223 00:10:34.639 --> 00:10:37.120 different complementary views into the binary. 224 00:10:37.200 --> 00:10:40.279 That's the idea assembly for the ground truth dcompiler for 225 00:10:40.360 --> 00:10:44.240 high level logic, Symbol tree for overall structure and external connections. 226 00:10:44.559 --> 00:10:46.360 GET helps you bring order to the chaos. 227 00:10:46.519 --> 00:10:48.960 It's like giving you different lenses to look through. Okay, 228 00:10:48.960 --> 00:10:51.480 so you have these views, how do you actually see 229 00:10:51.480 --> 00:10:54.279 the connections? How does function A relate to function B? 230 00:10:54.840 --> 00:10:56.559 Or where is this piece of data used? 231 00:10:56.679 --> 00:10:59.360 This where cross references or xrafs come in. 232 00:11:00.120 --> 00:11:03.000 Absolutely fundamental the glue holding the program together. 233 00:11:03.360 --> 00:11:06.000 Exactly what they are. Think of every address in the 234 00:11:06.000 --> 00:11:10.120 program as a potential node in a giant graph. Xrfs 235 00:11:10.200 --> 00:11:11.840 are the edges connecting those notes. 236 00:11:11.879 --> 00:11:12.720 How do they show up? 237 00:11:12.840 --> 00:11:14.919 In the listing window? Next to an instruction or a 238 00:11:15.000 --> 00:11:19.720 data definition, you'll often see something like XRF three function 239 00:11:19.799 --> 00:11:23.840 AC data location R. It tells you what other locations refer. 240 00:11:23.639 --> 00:11:26.080 To this spot, and the letters mean different things. Are 241 00:11:26.879 --> 00:11:28.759 WCB right. 242 00:11:29.080 --> 00:11:32.519 For data references, you'll see R for read, W for wright. 243 00:11:32.639 --> 00:11:35.639 If its address is taken used as a pointer for 244 00:11:35.759 --> 00:11:38.840 code references, C means it's being called like a function call, 245 00:11:39.080 --> 00:11:40.639 and J means it's being jumped to. 246 00:11:41.120 --> 00:11:43.200 Okay, so how would you use that in practice? 247 00:11:43.519 --> 00:11:46.200 Let's say you find a suspicious string in the data section, 248 00:11:46.320 --> 00:11:49.000 maybe something like enter password. You can look at the 249 00:11:49.080 --> 00:11:51.559 xrfs to that string's address, and that tells you it'll 250 00:11:51.559 --> 00:11:54.440 point you directly to the code locations that use that string, 251 00:11:54.759 --> 00:11:56.519 so you can instantly jump to the part of the 252 00:11:56.519 --> 00:11:58.840 code that's probably handling the password input. 253 00:11:59.039 --> 00:12:01.000 AH very power erful for tracking. 254 00:12:00.759 --> 00:12:05.200 Things down incredibly or flip it around. If you identify 255 00:12:05.200 --> 00:12:07.440 a function that looks vulnerable, you can look at its 256 00:12:07.519 --> 00:12:11.879 XRIs to see which other functions call this potentially dangerous function. 257 00:12:12.360 --> 00:12:16.120 GEDRA has dedicated windows just for managing and exploring these references. 258 00:12:16.399 --> 00:12:19.960 It lets you build that mental map of dependencies. 259 00:12:19.399 --> 00:12:23.360 Beyond just lists of references. Does giredra help visualize these connections? 260 00:12:23.480 --> 00:12:26.919 Yes, absolutely, okay. Graphs are another strong point. The main 261 00:12:26.960 --> 00:12:29.399 one is the function graph few what does that show? 262 00:12:29.639 --> 00:12:32.080 It takes a single function and displays it as a 263 00:12:32.080 --> 00:12:35.600 flood chart. Each node is a basic block, a sequence 264 00:12:35.600 --> 00:12:38.039 of instructions with no jumps in or out except at 265 00:12:38.039 --> 00:12:40.919 the beginning and end. The edges show the control flow 266 00:12:40.960 --> 00:12:43.200 that jumps and branches between blocks. 267 00:12:42.799 --> 00:12:45.159 So you can see loops and conditional paths visually. 268 00:12:45.240 --> 00:12:48.799 Precisely. You can zoom in, pan around, even collapse blocks 269 00:12:48.840 --> 00:12:52.159 to simplify complex functions. It makes understanding the logic flow 270 00:12:52.240 --> 00:12:55.519 much more intuitive than just reading linear assembly. Guedra also 271 00:12:55.559 --> 00:12:58.639 offers function call graphs, which show the bigger picture how 272 00:12:58.679 --> 00:13:01.600 different functions across the entire program call each other. 273 00:13:01.840 --> 00:13:05.279 So putting it together, the xrafs and graphs really let 274 00:13:05.360 --> 00:13:08.600 you untangle that complex web inside a binary. 275 00:13:08.720 --> 00:13:11.720 They make the invisible structure visible, letting you navigate and 276 00:13:11.759 --> 00:13:15.279 comprehend behavior that would otherwise be incredibly hard to follow. 277 00:13:15.759 --> 00:13:18.639 Now, Geidra sounds amazing out of the box, but you 278 00:13:18.720 --> 00:13:21.759 mentioned it's extensible. What if it doesn't do exactly what 279 00:13:21.799 --> 00:13:24.320 you need, or you want to automate something repetitive. 280 00:13:24.600 --> 00:13:29.440 Great question. That's where Giedra's extensibility really shines. If you 281 00:13:29.480 --> 00:13:31.759 need a feature Gedra doesn't have, or you want to 282 00:13:31.799 --> 00:13:35.759 automate a tedious analysis task, you often can the primary 283 00:13:35.799 --> 00:13:37.000 ways through giedras scripting. 284 00:13:37.519 --> 00:13:41.440 Scripting like writing small programs to control Gijra exactly. 285 00:13:41.840 --> 00:13:44.480 You can write scripts in Java or Python. There's a 286 00:13:44.519 --> 00:13:47.559 built in script manager to organize, edit and run them. 287 00:13:47.600 --> 00:13:48.480 What can scripts do? 288 00:13:48.879 --> 00:13:51.440 Lots of things? They have access to a simplified flat 289 00:13:51.480 --> 00:13:54.080 API that lets you interact with the program being analyzed. 290 00:13:54.279 --> 00:13:56.840 You can get the current address, read or write bytes, 291 00:13:57.159 --> 00:14:01.840 find specific byte sequences, iterate through funds, examine instructions. 292 00:14:02.000 --> 00:14:05.039 So you could write a script to say, find all 293 00:14:05.080 --> 00:14:07.440 functions that use a specific instruction. 294 00:14:07.320 --> 00:14:10.759 Easily, or account how many times a certain function is called, 295 00:14:11.360 --> 00:14:14.679 or automatically rename functions based on patterns you find, or 296 00:14:14.679 --> 00:14:17.799 even modify the program's memory. If you're doing emulation or patching, 297 00:14:18.159 --> 00:14:21.360 you can print results to the console, add comments automatically. 298 00:14:21.679 --> 00:14:23.840 It's very flexible for automating tasks. 299 00:14:24.440 --> 00:14:28.559 Beyond simple scripts, can you add bigger pieces of functionality. 300 00:14:28.720 --> 00:14:33.840 Yes, you can develop custom analyzers. Gadra's autoanalysis uses many 301 00:14:33.879 --> 00:14:37.559 built in analyzers. One example is the function id analyzer, 302 00:14:37.879 --> 00:14:40.840 which tries to identify common library functions by matching their 303 00:14:40.840 --> 00:14:44.559 code patterns against pre built databases fight dates. 304 00:14:44.360 --> 00:14:47.360 So it labels things like print automatically, right. 305 00:14:47.240 --> 00:14:49.440 If it recognizes the pattern. But you can build your 306 00:14:49.440 --> 00:14:53.000 own analyzers in Java using gidra's development framework in Eclipse. 307 00:14:53.240 --> 00:14:56.360 Maybe an analyzer that specifically looks for return oriented programming 308 00:14:56.440 --> 00:14:59.879 ROP gadgets those short instruction sequences useful for exploitation. 309 00:15:00.200 --> 00:15:02.080 Okay, and you mentioned loaders earlier. 310 00:15:02.279 --> 00:15:06.600 Yes, custom loadors. If Gidra doesn't recognize a specific file format, 311 00:15:06.759 --> 00:15:10.360 maybe some custom firmware image or packed executable, you can 312 00:15:10.399 --> 00:15:13.399 write a loader module to teach Gidra how to interpret it, 313 00:15:13.440 --> 00:15:15.360 how to map it into memory for analysis. 314 00:15:15.480 --> 00:15:18.000 So you could write a loader for maybe shell code 315 00:15:18.080 --> 00:15:19.840 embedded inside a word document. 316 00:15:20.080 --> 00:15:23.279 Potentially. Yes, if you can write code to extract the 317 00:15:23.279 --> 00:15:25.559 shell code and tell Gidra where to load it and 318 00:15:25.600 --> 00:15:28.480 how it's structured, then gidrick can analyze. 319 00:15:27.960 --> 00:15:30.799 It, and the deepest level of customization. 320 00:15:30.320 --> 00:15:33.840 That would be processor modules. These define how gidra actually 321 00:15:33.879 --> 00:15:38.320 disassembles instructions for a given CPU architecture. Gidri uses its 322 00:15:38.320 --> 00:15:42.440 own language called s LAAG. For this. You could potentially 323 00:15:42.480 --> 00:15:45.759 modify existing processor definitions or even add support for a 324 00:15:45.759 --> 00:15:48.240 whole new processor. Although that's quite advanced. 325 00:15:48.279 --> 00:15:51.039 Wow, And can you automate all this without the GI. 326 00:15:51.159 --> 00:15:53.679 Yep headless mode. You can run gidra from the command 327 00:15:53.759 --> 00:15:56.039 line using Analyze headless. You can tell it to import 328 00:15:56.080 --> 00:15:59.720 a file, run the AutoAnalyzers, run spasific scripts, bulkitscript, and 329 00:15:59.759 --> 00:16:02.919 out results all without ever opening the graphical interface. 330 00:16:03.080 --> 00:16:03.320 Oh. 331 00:16:03.480 --> 00:16:05.559 Great for batch processing lots of files. 332 00:16:05.799 --> 00:16:08.399 So gidra isn't just a tool, It's really a platform. 333 00:16:08.679 --> 00:16:11.240 You can shape it, extend it, automate it to tackle 334 00:16:11.399 --> 00:16:12.519 very specific problem. 335 00:16:12.679 --> 00:16:14.440 That's exactly right. You're not just using it, you can 336 00:16:14.480 --> 00:16:15.080 build upon it. 337 00:16:15.279 --> 00:16:18.960 Okay, let's talk about the real world, which, as you said, 338 00:16:19.159 --> 00:16:24.399 is messy. Reverse engineering isn't always against clean, straightforward code. 339 00:16:24.799 --> 00:16:29.480 What about differences between compilers or when software deliberately tries 340 00:16:29.519 --> 00:16:30.879 to hide what it's doing. 341 00:16:31.399 --> 00:16:35.480 Yeah, those are major hurdles. First, compiler variations, the exact 342 00:16:35.480 --> 00:16:39.360 same C plus plus code can produce wildly different assembly 343 00:16:39.600 --> 00:16:43.159 depending on the compiler GCC versus CLIG versus Microsoft's compiler, 344 00:16:43.360 --> 00:16:46.240 and even just the optimization level used like Nanniko two 345 00:16:46.399 --> 00:16:49.480 versus a debug build. How different, very different. A simple 346 00:16:49.519 --> 00:16:52.480 switch statement might become an efficient jump table or slow 347 00:16:52.559 --> 00:16:56.519 series of comparisons. Debug builds often have extra checks and 348 00:16:56.600 --> 00:17:00.000 simple information, while release builds are stripped and optimized. 349 00:17:00.159 --> 00:17:02.120 What about optimizations like inlining. 350 00:17:02.279 --> 00:17:05.279 That's a big one. Function inlining can completely remove a 351 00:17:05.279 --> 00:17:08.200 function call. Pasting the function's code directly where it was 352 00:17:08.200 --> 00:17:11.599 called makes following the logic harder because the explicit call 353 00:17:11.680 --> 00:17:12.680 is gone. 354 00:17:12.480 --> 00:17:15.039 And C plus plus adds its own wrinkles. 355 00:17:15.119 --> 00:17:19.599 Oh yes, things like run time type information RTTI use 356 00:17:19.680 --> 00:17:23.319 for features like dynamic AST. Guidra has analyzers for some 357 00:17:23.480 --> 00:17:26.680 RTTI formats, but often relies on that name. Mangling we 358 00:17:26.759 --> 00:17:30.279 talked about. If a binary is stripped, meaning simple information 359 00:17:30.400 --> 00:17:34.279 is removed, finding C plus plus structures gets much harder. 360 00:17:35.119 --> 00:17:38.519 Even finding the main entry point main function in a 361 00:17:38.559 --> 00:17:42.599 stripped binary requires knowing how the specific compiler sets things. 362 00:17:42.440 --> 00:17:44.839 Up, So just the compiler choices make a big difference. 363 00:17:44.880 --> 00:17:48.079 What about intentional roadblocks anti reverse engineering? 364 00:17:48.240 --> 00:17:51.559 That's the next level of challenge obfuscation is about making 365 00:17:51.559 --> 00:17:56.559 the binary intentionally confusing many ways, inserting junk code instructions 366 00:17:56.559 --> 00:17:58.640 that don't actually do anything but look like real code 367 00:17:58.680 --> 00:18:02.839 to confuse the disassembler using obscure jump targets, maybe jumping 368 00:18:02.839 --> 00:18:06.119 into the middle of another valid instruction. Sometimes they'll load 369 00:18:06.160 --> 00:18:09.720 libraries dynamically using OS functions like load library instead of 370 00:18:09.720 --> 00:18:13.400 standard imports, hiding dependencies. Or they might use hashes of 371 00:18:13.400 --> 00:18:17.119 function names instead of plane strings, making simple stream searches less. 372 00:18:16.920 --> 00:18:19.680 Effective, trying to break the analysis tools exactly. 373 00:18:20.119 --> 00:18:23.559 And then there's anti dynamic analysis detecting if the program 374 00:18:23.599 --> 00:18:27.440 is running inside a virtual machine or a sandbox, looking 375 00:18:27.480 --> 00:18:31.799 for specific files, registry keys, or artifacts left by virtualization 376 00:18:32.000 --> 00:18:36.519 software like VMware tools. If detected, the program might just 377 00:18:36.599 --> 00:18:38.160 refuse to run or behave. 378 00:18:37.920 --> 00:18:41.559 Differently sneaky and anti debugging yep. 379 00:18:41.440 --> 00:18:44.680 Actively trying to stop debuggers. Yeah, they might intentionally trigger 380 00:18:44.720 --> 00:18:48.000 exceptions that debuggers handled differently, or on Linux Unix they 381 00:18:48.079 --> 00:18:51.200 might use tricks with the sirtrace system call, which debuggers 382 00:18:51.200 --> 00:18:54.119 like GDB rely on to prevent a debugger from attaching 383 00:18:54.119 --> 00:18:54.799 in the first place. 384 00:18:54.880 --> 00:18:57.200 It really is an arms race. So faced with all this, 385 00:18:57.559 --> 00:18:58.880 can GUDRA still. 386 00:18:58.640 --> 00:19:02.240 Help it absolutely can. Static analysis is often key to 387 00:19:02.279 --> 00:19:05.359 defeating these techniques For things like packed or encrypted code 388 00:19:05.559 --> 00:19:08.079 where the real code is hidden initially. You could sometimes 389 00:19:08.119 --> 00:19:11.880 use GETRA scripting and emulation capabilities to simulate the unpacking 390 00:19:12.000 --> 00:19:13.039 or decryption routine. 391 00:19:13.160 --> 00:19:17.000 You run the deoccuscation code virtually sort of, you emulate 392 00:19:17.200 --> 00:19:18.279 just that small part. 393 00:19:18.680 --> 00:19:21.160 Let it decode the hidden section in memory, and then 394 00:19:21.200 --> 00:19:24.559 you can tell Guedro to reanalyze that now decoded memory. 395 00:19:24.759 --> 00:19:27.880 It lets use statically analyzed code that was initially hidden. 396 00:19:28.079 --> 00:19:31.079 Clever, and what about changing the binary? Can GEDRA help 397 00:19:31.119 --> 00:19:31.759 with patching? 398 00:19:32.079 --> 00:19:35.079 Yes? Patching binaries is another common use case. Maybe you 399 00:19:35.119 --> 00:19:38.119 want to change a string bypass a license check for 400 00:19:38.359 --> 00:19:41.319 educational purposes, of course, or fix a bug in a 401 00:19:41.359 --> 00:19:42.720