Speaker 1: Have you ever looked at a piece of software, you know,
Speaker 1: an app or maybe part of your OS, and just
Speaker 1: wondered what's really going on under the hood, Especially when
Speaker 1: all you've got is that compiled binary, that black box
Speaker 1: of machine language. How do you even start to peel
Speaker 1: back those layers?
Speaker 2: How do you see inside?
Speaker 1: Our deep dive today is all about cracking that open
Speaker 1: We're talking GIEDRA. It's a real powerhouse for software reverse engineering. Sorry.
Speaker 2: Absolutely think of it like a universal translator from machine
Speaker 2: code exactly.
Speaker 1: Takes that dense, inscrutable stuff and makes it well understandable.
Speaker 1: And here's the kicker, right, GUIDRA wasn't just built by
Speaker 1: some startup. This thing came out of the NSA.
Speaker 2: Yeah, a National security agency, developed in house.
Speaker 1: And then amazingly they released it open source to the public,
Speaker 1: which was.
Speaker 2: A pretty big deal at the time.
Speaker 1: Still is it really is? So this isn't some niche tool,
Speaker 1: it's government grade stuff for understanding compiled code, and now
Speaker 1: you know, anyone can use it. So our mission today
Speaker 1: is to unpack what GEDRA can do from just looking
Speaker 1: at a file to really advance stuff like customization, even
Speaker 1: tackling antire tricks.
Speaker 2: Yeah, it's about getting you informed about that digital.
Speaker 1: Core, giving you that shortcut.
Speaker 2: What's really cool is how Geedra kind of levels the
Speaker 2: playing field. It gives you insights into binaries that would
Speaker 2: otherwise just be opaque. Whether you're a pro reverse engineer
Speaker 2: looking at malware or just you know, super curious about
Speaker 2: how software actually works. Guidra lets you see that digital core.
Speaker 1: Okay, so before we jump right into Gidra itself, let's
Speaker 1: back up a bit. Why do we even need tools
Speaker 1: like this? Why look inside compiled software? Shouldn't we just
Speaker 1: I don't know, trust it?
Speaker 2: Well? Ideally maybe, but the real world's mess here. A
Speaker 2: huge reason is vulnerability.
Speaker 1: Analysis, finding security holes.
Speaker 2: Exactly, discovering and analyzing potentially exploitable flaws. You might use
Speaker 2: fuzzing dynamic stuff to find crashes, but Guedra lets you
Speaker 2: do static analysis to really understand if something's exploitable and
Speaker 2: how what are the conditions? Static analysis is key? There?
Speaker 1: Gotcha? What else?
Speaker 2: Then? There's software interoperability, big one. If something's only released
Speaker 2: as a binary, making other software work with it, or
Speaker 2: writing plugins, it's incredibly hard.
Speaker 1: Ah like writing drivers for hardware maybe.
Speaker 2: Perfect example, drivers for hardware that only officially supports, say Windows,
Speaker 2: but you want it on Linux, you'll probably need to
Speaker 2: do some serious reverse engineering, maybe even beyond drivers into
Speaker 2: the firmware.
Speaker 1: Okay, that makes sense.
Speaker 2: And then there's always the let's call it source code recovery.
Speaker 1: Angle, right, trying to get back to something readable.
Speaker 2: Yeah, you'll never get the original source code back perfectly
Speaker 2: with comments and all that. We can't do something readable
Speaker 2: from a binary. That's still super attractive competitive analysis, understanding
Speaker 2: old systems. Lots of reasons.
Speaker 1: Okay, I get the why, But what makes it so
Speaker 1: darn difficult going from that compiled binary back to something
Speaker 1: human readable. You said it's like rebuilding a cake from crumb.
Speaker 2: That's a good analogy. The core problem is the compilation
Speaker 2: process itself.
Speaker 1: It's lossy, lossy meaning information gets thrown away.
Speaker 2: Exactly when you compile C plus plus or Java down
Speaker 2: to machine code. Tons of useful info is just gone.
Speaker 2: Variable names, function names, comments, forget it. Wow, even variable types.
Speaker 2: At the machine level, GIDRA might see, say thirty two
Speaker 2: bits of data being moved. Is that an integer, a
Speaker 2: floating point number, a memory address, a pointer.
Speaker 1: It doesn't know.
Speaker 2: It has to infer it, it has to look at
Speaker 2: how that data is used later on to make an
Speaker 2: educated guess ah, and that ambiguity that inferenced. That's why
Speaker 2: decompilation is still a really active research area in computer science.
Speaker 2: It's fundamentally hard.
Speaker 1: So gijra's first big job is to try and bridge
Speaker 1: that gap, to get those machine code crumbs into some
Speaker 1: kind of order, and that starts with disassembly right.
Speaker 2: Right at its most basic level. GIDRA takes the machine language,
Speaker 2: those raw binary patterns OPT codes and turns them into
Speaker 2: assembly language.
Speaker 1: The mnemonics like a push and mov.
Speaker 2: Exactly, those short memorable sequences pH EBP, mv EAX, stuff
Speaker 2: like that. It makes the raw instructions way easier for
Speaker 2: humans to read and track.
Speaker 1: But even that basic step isn't simple, not entirely.
Speaker 2: First, Geedra has to figure out what's actually code versus
Speaker 2: what's just data stored in.
Speaker 1: The program because they can be mixed together.
Speaker 2: They often are. Luckily standard file formats like PE for
Speaker 2: Windows or ELF for Linux and Unix have headers. These
Speaker 2: headers give GEDRA clues about where the code sections likely
Speaker 2: start and end.
Speaker 1: OK.
Speaker 2: Then it has to match the binary opcodes it finds
Speaker 2: to the right assembly mnemonic that's mostly a table look up,
Speaker 2: but it gets tricky with things like instruction prefixes or
Speaker 2: variable length instructions, which you see a lot in say
Speaker 2: Intel by eighty six architecture.
Speaker 1: Right, So, assuming it figures out the instructions, how does
Speaker 1: it know which one comes next. Programs don't just run
Speaker 1: straight down, they jump around.
Speaker 2: That's the next big challenge navigating control flow. A really
Speaker 2: simple approach is linear sweep, just assemble one instruction after
Speaker 2: the other.
Speaker 1: But that breaks easily.
Speaker 2: Oh yeah, it gets totally confused by jumps and branches,
Speaker 2: and it can easily misinterpret data as code. So GIDRI
Speaker 2: uses a much smarter method called recursive descent.
Speaker 1: Recursive descent how does that work?
Speaker 2: So when it hits a conditional jump like jump if
Speaker 2: not zero, it basically says, okay, the program could go
Speaker 2: this way, or it could just continue straight on. It
Speaker 2: picks one path to follow immediately and puts the other
Speaker 2: path's starting address on a list to check out later,
Speaker 2: a to do list pretty much a list of deferred addresses.
Speaker 2: If it's an unconditional jump, it tries to figure out
Speaker 2: the target and just goes there.
Speaker 1: Okay, that sounds much more robust, but What about jumps
Speaker 1: where the target isn't obvious.
Speaker 2: Ah. Yeah, that's where recursive descent hits its limits too,
Speaker 2: things like jump racks in I two. The target addresses
Speaker 2: whatever value is in the racks register at runtime.
Speaker 1: So GIDRA can't know that just by looking at the code.
Speaker 2: Nope, static analysis can't predict runtime values. Or think about
Speaker 2: a reinstruction return from function That tells you nothing about
Speaker 2: where execution will go next.
Speaker 1: So what does it do?
Speaker 2: Then? That's when it goes back to its to do list.
Speaker 2: It picks up one of those deferred addresses it saved
Speaker 2: earlier and starts disassembling from there. That's the recursive part
Speaker 2: of the name. It keeps exploring all these potential paths
Speaker 2: until it's mapped out as much of the program's structure
Speaker 2: as possible.
Speaker 1: Wow. Okay, so it's not just translating, it's actively exploring
Speaker 1: and mapping the possibilities.
Speaker 2: Quite the detective, you could say that.
Speaker 1: So GIDRA does all this heavy lifting with disassembly. How
Speaker 1: does a user someone sitting down with it, actually get started?
Speaker 1: What's the entry point?
Speaker 2: It's actually pretty user friendly. You launch gedra first time,
Speaker 2: you'll see the license agreement. Click through that. Then you
Speaker 2: get a tip of the day and the main Gidra
Speaker 2: project window pops up. Okay, your first real step is
Speaker 2: to create a project. Geedra uses this project to keep
Speaker 2: everything organized. The file you're analyzing, your notes, everything. You
Speaker 2: choose between non shared or shared. For working alone, you
Speaker 2: just pick non shared, give it a directory and a name. Simple,
Speaker 2: got it.
Speaker 1: Project setup. Then you bring in the file.
Speaker 2: Right, you import the file either file import file or
Speaker 2: just drag and drop it onto the project window. Geedra
Speaker 2: looks at the file, tries to figure out what it
Speaker 2: is pe elf, macho, and suggests a format a loader.
Speaker 1: And you usually just accept the default.
Speaker 2: Often yeah, getar's pretty good at recognizing common formats. If
Speaker 2: it's something weird or just raw binary code, you might
Speaker 2: select raw binary and maybe give it some hints. There
Speaker 2: are options you can tweak as you get more experienced,
Speaker 2: like telling it to load external libraries.
Speaker 1: Okay, file imported. What happens then?
Speaker 2: Then Gidra asks if you want to autoanalyze it, and
Speaker 2: you almost always say yes.
Speaker 1: That's where the magic happens.
Speaker 2: That's where a ton of automated work kicks in. Getra
Speaker 2: starts identifying functions finding data, recognizing common code patterns, building
Speaker 2: cross references, all that stuff we talked about. You can
Speaker 2: actually watch its progress in the bottom right of the
Speaker 2: main window the cod browser, or look at the detailed
Speaker 2: log file.
Speaker 1: So it does a massive amount of groundwork automatically.
Speaker 2: Absolutely, it takes that raw imported binary and brings it
Speaker 2: into a much more structured, analyzed state ready for you
Speaker 2: to start exploring. It really guides you in.
Speaker 1: Okay, So the auto analysis finishes and you're dropped into
Speaker 1: the Gidra code Browser. That's the main workspace, right, What
Speaker 1: does that look like? What are the key parts?
Speaker 2: Code browser is your command center. It's a multi window interface,
Speaker 2: quite rich by default. You'll likely see a few key windows,
Speaker 2: but let's focus on maybe the three most important ones
Speaker 2: to start. Okay, First, there's the listing window. This is
Speaker 2: your assembly view. The direct translation of machine code into mnemonics.
Speaker 2: You see addresses the bites.
Speaker 1: The instructions, and those arrows you mentioned.
Speaker 2: Yeah, crucial feature flow arrows. They graphically show you where
Speaker 2: jumps and calls go. Solid arrows for unconditional jumps, dash
Speaker 2: for conditional ones, hover over them, double click to follow them.
Speaker 2: Makes tracing the program's path so much easier than just
Speaker 2: reading addresses.
Speaker 1: Helps visualize the flow exactly.
Speaker 2: Then right next to it often is the decompiler window.
Speaker 1: Ah, the crown jewel.
Speaker 2: Arguably yes, this is where GADRA tries its best to
Speaker 2: reconstruct high level C like source code from the assembly.
Speaker 1: How good is it?
Speaker 2: It's often remarkably good. It gives you a much much
Speaker 2: higher level understanding of what the code is trying to
Speaker 2: do the logic compared to just staring at assembly. Now,
Speaker 2: it's not perfect.
Speaker 1: Right because of that lossy compilation precisely.
Speaker 2: Sometimes it has to guess types, maybe it overuses casts,
Speaker 2: and it always generates C even if the original code
Speaker 2: was C plus plus or something else. But still it's
Speaker 2: incredibly valuable for quickly grasping function logic.
Speaker 1: Okay, listing for assembly decompiler for pseudo C. What's the
Speaker 1: third key window?
Speaker 2: The symbol tree window. This is all about program structure.
Speaker 2: It shows you information extracted from the binary symbol tables
Speaker 2: if they exist, like function names, functions, labels, global variables, classes,
Speaker 2: name spaces, and really importantly, imports and exports.
Speaker 1: Imports being stuff the program uses from outside, like libraries.
Speaker 2: YEP functions imports from shared libraries and exports are the
Speaker 2: entry points into this file. Things it provides for others,
Speaker 2: including the main program entry point often called entry.
Speaker 1: Or start, and this helps you navigate massively.
Speaker 2: It's also where you often spot C plus plus code
Speaker 2: because of name mangling. C plus plus compilers tweak function
Speaker 2: names to handle overloading adding extra characters. GIDRA shows you
Speaker 2: these mangled names and often tries to demangle them back
Speaker 2: to something readable. Super useful for understanding C plus plus binaries.
Speaker 1: So these three windows listing, Decompiler, symbol tree give you
Speaker 1: different complementary views into the binary.
Speaker 2: That's the idea assembly for the ground truth dcompiler for
Speaker 2: high level logic, Symbol tree for overall structure and external connections.
Speaker 2: GET helps you bring order to the chaos.
Speaker 1: It's like giving you different lenses to look through. Okay,
Speaker 1: so you have these views, how do you actually see
Speaker 1: the connections? How does function A relate to function B?
Speaker 1: Or where is this piece of data used?
Speaker 2: This where cross references or xrafs come in.
Speaker 1: Absolutely fundamental the glue holding the program together.
Speaker 2: Exactly what they are. Think of every address in the
Speaker 2: program as a potential node in a giant graph. Xrfs
Speaker 2: are the edges connecting those notes.
Speaker 1: How do they show up?
Speaker 2: In the listing window? Next to an instruction or a
Speaker 2: data definition, you'll often see something like XRF three function
Speaker 2: AC data location R. It tells you what other locations refer.
Speaker 1: To this spot, and the letters mean different things. Are
Speaker 1: WCB right.
Speaker 2: For data references, you'll see R for read, W for wright.
Speaker 2: If its address is taken used as a pointer for
Speaker 2: code references, C means it's being called like a function call,
Speaker 2: and J means it's being jumped to.
Speaker 1: Okay, so how would you use that in practice?
Speaker 2: Let's say you find a suspicious string in the data section,
Speaker 2: maybe something like enter password. You can look at the
Speaker 2: xrfs to that string's address, and that tells you it'll
Speaker 2: point you directly to the code locations that use that string,
Speaker 2: so you can instantly jump to the part of the
Speaker 2: code that's probably handling the password input.
Speaker 1: AH very power erful for tracking.
Speaker 2: Things down incredibly or flip it around. If you identify
Speaker 2: a function that looks vulnerable, you can look at its
Speaker 2: XRIs to see which other functions call this potentially dangerous function.
Speaker 2: GEDRA has dedicated windows just for managing and exploring these references.
Speaker 2: It lets you build that mental map of dependencies.
Speaker 1: Beyond just lists of references. Does giredra help visualize these connections?
Speaker 2: Yes, absolutely, okay. Graphs are another strong point. The main
Speaker 2: one is the function graph few what does that show?
Speaker 2: It takes a single function and displays it as a
Speaker 2: flood chart. Each node is a basic block, a sequence
Speaker 2: of instructions with no jumps in or out except at
Speaker 2: the beginning and end. The edges show the control flow
Speaker 2: that jumps and branches between blocks.
Speaker 1: So you can see loops and conditional paths visually.
Speaker 2: Precisely. You can zoom in, pan around, even collapse blocks
Speaker 2: to simplify complex functions. It makes understanding the logic flow
Speaker 2: much more intuitive than just reading linear assembly. Guedra also
Speaker 2: offers function call graphs, which show the bigger picture how
Speaker 2: different functions across the entire program call each other.
Speaker 1: So putting it together, the xrafs and graphs really let
Speaker 1: you untangle that complex web inside a binary.
Speaker 2: They make the invisible structure visible, letting you navigate and
Speaker 2: comprehend behavior that would otherwise be incredibly hard to follow.
Speaker 1: Now, Geidra sounds amazing out of the box, but you
Speaker 1: mentioned it's extensible. What if it doesn't do exactly what
Speaker 1: you need, or you want to automate something repetitive.
Speaker 2: Great question. That's where Giedra's extensibility really shines. If you
Speaker 2: need a feature Gedra doesn't have, or you want to
Speaker 2: automate a tedious analysis task, you often can the primary
Speaker 2: ways through giedras scripting.
Speaker 1: Scripting like writing small programs to control Gijra exactly.
Speaker 2: You can write scripts in Java or Python. There's a
Speaker 2: built in script manager to organize, edit and run them.
Speaker 1: What can scripts do?
Speaker 2: Lots of things? They have access to a simplified flat
Speaker 2: API that lets you interact with the program being analyzed.
Speaker 2: You can get the current address, read or write bytes,
Speaker 2: find specific byte sequences, iterate through funds, examine instructions.
Speaker 1: So you could write a script to say, find all
Speaker 1: functions that use a specific instruction.
Speaker 2: Easily, or account how many times a certain function is called,
Speaker 2: or automatically rename functions based on patterns you find, or
Speaker 2: even modify the program's memory. If you're doing emulation or patching,
Speaker 2: you can print results to the console, add comments automatically.
Speaker 2: It's very flexible for automating tasks.
Speaker 1: Beyond simple scripts, can you add bigger pieces of functionality.
Speaker 2: Yes, you can develop custom analyzers. Gadra's autoanalysis uses many
Speaker 2: built in analyzers. One example is the function id analyzer,
Speaker 2: which tries to identify common library functions by matching their
Speaker 2: code patterns against pre built databases fight dates.
Speaker 1: So it labels things like print automatically, right.
Speaker 2: If it recognizes the pattern. But you can build your
Speaker 2: own analyzers in Java using gidra's development framework in Eclipse.
Speaker 2: Maybe an analyzer that specifically looks for return oriented programming
Speaker 2: ROP gadgets those short instruction sequences useful for exploitation.
Speaker 1: Okay, and you mentioned loaders earlier.
Speaker 2: Yes, custom loadors. If Gidra doesn't recognize a specific file format,
Speaker 2: maybe some custom firmware image or packed executable, you can
Speaker 2: write a loader module to teach Gidra how to interpret it,
Speaker 2: how to map it into memory for analysis.
Speaker 1: So you could write a loader for maybe shell code
Speaker 1: embedded inside a word document.
Speaker 2: Potentially. Yes, if you can write code to extract the
Speaker 2: shell code and tell Gidra where to load it and
Speaker 2: how it's structured, then gidrick can analyze.
Speaker 1: It, and the deepest level of customization.
Speaker 2: That would be processor modules. These define how gidra actually
Speaker 2: disassembles instructions for a given CPU architecture. Gidri uses its
Speaker 2: own language called s LAAG. For this. You could potentially
Speaker 2: modify existing processor definitions or even add support for a
Speaker 2: whole new processor. Although that's quite advanced.
Speaker 1: Wow, And can you automate all this without the GI.
Speaker 2: Yep headless mode. You can run gidra from the command
Speaker 2: line using Analyze headless. You can tell it to import
Speaker 2: a file, run the AutoAnalyzers, run spasific scripts, bulkitscript, and
Speaker 2: out results all without ever opening the graphical interface.
Speaker 1: Oh.
Speaker 2: Great for batch processing lots of files.
Speaker 1: So gidra isn't just a tool, It's really a platform.
Speaker 1: You can shape it, extend it, automate it to tackle
Speaker 1: very specific problem.
Speaker 2: That's exactly right. You're not just using it, you can
Speaker 2: build upon it.
Speaker 1: Okay, let's talk about the real world, which, as you said,
Speaker 1: is messy. Reverse engineering isn't always against clean, straightforward code.
Speaker 1: What about differences between compilers or when software deliberately tries
Speaker 1: to hide what it's doing.
Speaker 2: Yeah, those are major hurdles. First, compiler variations, the exact
Speaker 2: same C plus plus code can produce wildly different assembly
Speaker 2: depending on the compiler GCC versus CLIG versus Microsoft's compiler,
Speaker 2: and even just the optimization level used like Nanniko two
Speaker 2: versus a debug build. How different, very different. A simple
Speaker 2: switch statement might become an efficient jump table or slow
Speaker 2: series of comparisons. Debug builds often have extra checks and
Speaker 2: simple information, while release builds are stripped and optimized.
Speaker 1: What about optimizations like inlining.
Speaker 2: That's a big one. Function inlining can completely remove a
Speaker 2: function call. Pasting the function's code directly where it was
Speaker 2: called makes following the logic harder because the explicit call
Speaker 2: is gone.
Speaker 1: And C plus plus adds its own wrinkles.
Speaker 2: Oh yes, things like run time type information RTTI use
Speaker 2: for features like dynamic AST. Guidra has analyzers for some
Speaker 2: RTTI formats, but often relies on that name. Mangling we
Speaker 2: talked about. If a binary is stripped, meaning simple information
Speaker 2: is removed, finding C plus plus structures gets much harder.
Speaker 2: Even finding the main entry point main function in a
Speaker 2: stripped binary requires knowing how the specific compiler sets things.
Speaker 1: Up, So just the compiler choices make a big difference.
Speaker 1: What about intentional roadblocks anti reverse engineering?
Speaker 2: That's the next level of challenge obfuscation is about making
Speaker 2: the binary intentionally confusing many ways, inserting junk code instructions
Speaker 2: that don't actually do anything but look like real code
Speaker 2: to confuse the disassembler using obscure jump targets, maybe jumping
Speaker 2: into the middle of another valid instruction. Sometimes they'll load
Speaker 2: libraries dynamically using OS functions like load library instead of
Speaker 2: standard imports, hiding dependencies. Or they might use hashes of
Speaker 2: function names instead of plane strings, making simple stream searches less.
Speaker 1: Effective, trying to break the analysis tools exactly.
Speaker 2: And then there's anti dynamic analysis detecting if the program
Speaker 2: is running inside a virtual machine or a sandbox, looking
Speaker 2: for specific files, registry keys, or artifacts left by virtualization
Speaker 2: software like VMware tools. If detected, the program might just
Speaker 2: refuse to run or behave.
Speaker 1: Differently sneaky and anti debugging yep.
Speaker 2: Actively trying to stop debuggers. Yeah, they might intentionally trigger
Speaker 2: exceptions that debuggers handled differently, or on Linux Unix they
Speaker 2: might use tricks with the sirtrace system call, which debuggers
Speaker 2: like GDB rely on to prevent a debugger from attaching
Speaker 2: in the first place.
Speaker 1: It really is an arms race. So faced with all this,
Speaker 1: can GUDRA still.
Speaker 2: Help it absolutely can. Static analysis is often key to
Speaker 2: defeating these techniques For things like packed or encrypted code
Speaker 2: where the real code is hidden initially. You could sometimes
Speaker 2: use GETRA scripting and emulation capabilities to simulate the unpacking
Speaker 2: or decryption routine.
Speaker 1: You run the deoccuscation code virtually sort of, you emulate
Speaker 1: just that small part.
Speaker 2: Let it decode the hidden section in memory, and then
Speaker 2: you can tell Guedro to reanalyze that now decoded memory.
Speaker 2: It lets use statically analyzed code that was initially hidden.
Speaker 1: Clever, and what about changing the binary? Can GEDRA help
Speaker 1: with patching?
Speaker 2: Yes? Patching binaries is another common use case. Maybe you
Speaker 2: want to change a string bypass a license check for
Speaker 2: educational purposes, of course, or fix a bug in a
Speaker 2: program where you don't have the source.
Speaker 1: How do you do it?
Speaker 2: Guedra helps you find the spot you want to change,
Speaker 2: using a search tools, searching memory for byte sequences or strings,
Speaker 2: or even searching for specific instruction patterns. Once you find it,
Speaker 2: you can use the byte viewer window, which acts like
Speaker 2: a hex editor, to directly modify the bytes, or use
Speaker 2: scripts for more complex patches, and.
Speaker 1: Then save the modified file.
Speaker 2: File export program. Unless you save your changes back to
Speaker 2: a new executable file, though you need to be careful
Speaker 2: about things like file offsets and relocations.
Speaker 1: One last area comparing files. What if you have two
Speaker 1: versions of a program or want to see what changed
Speaker 1: in an update.
Speaker 2: Guidra has excellent binary diffing tools for that. It's super
Speaker 2: useful for seeing what changed between versions, maybe porting your
Speaker 2: analysis from an old version to a new one, or
Speaker 2: merging work with colleagues.
Speaker 1: What tools does it offer.
Speaker 2: There's program diff which shows two files side by side
Speaker 2: and synchronized listing windows, highlighting differences in color. You can
Speaker 2: choose to ignore, replace, or merge changes. There's also function
Speaker 2: comparison for just comparing two specific functions and for more
Speaker 2: complex scenarios. Version tracking helps correlate functions in data between
Speaker 2: different versions, even finding functions that are similar but not
Speaker 2: identical fuzzy matches.
Speaker 1: So it's not just analysis, but also modification and comparison
Speaker 1: whole life cycle.
Speaker 2: Pretty much. Geydra provides a really comprehensive toolkit for dealing
Speaker 2: with binaries, from initial understanding right through to modification and
Speaker 2: tracking changes over time, even when facing obfuscation.
Speaker 1: It's incredible. From its somewhat shadowy origins inside the NSA
Speaker 1: to now being this vital open source tool. Geedra really
Speaker 1: does empower anyone to decode that digital core.
Speaker 2: It truly does. It goes way beyond just showing you bytes.
Speaker 2: It's an ecosystem for deep analysis, for active modification, for collaboration.
Speaker 2: That ability to pull together different kinds of information, assembly,
Speaker 2: decompiled code, cross references graphs, and look at the problem
Speaker 2: from multiple angles is just so valuable.
Speaker 1: So thinking about all this, the complexity compilers add, the
Speaker 1: deliberate tricks used to hide code, makes you wonder, doesn't it.
Speaker 1: What surprising things might Geidra reveal If you pointed it
Speaker 1: at the everyday software you use, maybe even the OS
Speaker 1: on your phone.
Speaker 2: Or computer, it's a fascinating thought. You might be surprised
Speaker 2: what's really going on under the surface.