Speaker 1: Ever wonder what happens in that split second when you
Speaker 1: click on a program.
Speaker 2: It seems so simple, doesn't it, Yeah, exactly.
Speaker 1: But apparently it kicks off this incredibly complex series of
Speaker 1: events deep inside your Windows system.
Speaker 2: It's a whole journey. And you know, as we'll find out,
Speaker 2: that complexity can sometimes well, it can open doors for vulnerabilities.
Speaker 1: Right, So today we're doing a deep dive into that
Speaker 1: hidden world Windows internals. We're using that book you shared,
Speaker 1: Windows ABT Warfare as our guide.
Speaker 2: That's the one. And yeah, this isn't your average user guide.
Speaker 2: It's really aimed at people who want to get under
Speaker 2: the hood of Windows security.
Speaker 1: Wise, like engineers, malware folks.
Speaker 2: Exactly, Windows engineers, malware researchers, ethical hackers, people like that.
Speaker 2: It gets really hands on with stuff like reverse engineering,
Speaker 2: exploit development, how attacks actually work at a low level.
Speaker 1: Okay, So our mission today then is to pull out
Speaker 1: the really crucial, maybe even the mind blowing stuff from
Speaker 1: this book.
Speaker 2: Yeah, to still it down right.
Speaker 1: We want to give you the listener those aha moments
Speaker 1: about how Windows programs get built, how they run.
Speaker 2: And critically, how that whole process can be targeted, how
Speaker 2: it can be manipulated by attackers.
Speaker 1: Exactly, trying to cut through some of the heavy technical
Speaker 1: jargon and make it, you know, engaging.
Speaker 2: Absolutely think of it as a guided tour of Windows
Speaker 2: Core using the book's insights. We'll hit the key mechanisms,
Speaker 2: the security side of things, so.
Speaker 1: You get a quick but hopefully thorough grasp of some
Speaker 1: fundamental ideas.
Speaker 2: Right, and this knowledge is honestly pretty powerful, whether you
Speaker 2: just want to stay informed, or understand software better, or
Speaker 2: maybe even prep for some technical cybersecurity chats.
Speaker 1: Okay, let's get started in time for that deep dive
Speaker 1: into Windows APT warfare, uncovering how programs come alive and
Speaker 1: why that's maybe a double edged sword sometimes.
Speaker 2: Let's do it. We should probably start right at the
Speaker 2: beginning the journey. A simple C program takes from code
Speaker 2: someone writes to well to a running process on your.
Speaker 1: Machine, even just Hello World, Right, seems basic, but there's
Speaker 1: a whole transformation happening behind.
Speaker 2: The scenes totally. First up, you've got the C compiler.
Speaker 1: Okay, what's its job? Exact?
Speaker 2: It basically translates that human readable C code into assembly
Speaker 2: language assembly.
Speaker 1: Now, for those of us maybe not deep into coding,
Speaker 1: how's that different? From C. Why does that matter here?
Speaker 2: Good question. C is relatively high level, closer to how
Speaker 2: we think. Assembly is much much closer to what the
Speaker 2: computer's processor actually understands.
Speaker 1: So like direct instructions for the chip.
Speaker 2: Pretty much each assembly line is usually one tiny instruction
Speaker 2: for the processor. And understanding that level is key because
Speaker 2: a lot of core Windows functions and definitely malware operate
Speaker 2: down there.
Speaker 1: Okay, so C to assembly, then what there's an assembler
Speaker 1: involved too?
Speaker 2: Yep. The assembler takes that assembly code and turns it
Speaker 2: into the actual machine code.
Speaker 1: The raw binary ones and zeros.
Speaker 2: That's it, the processor's native language.
Speaker 1: The book mentioned tools like TDMGCC visual Studio, those are
Speaker 1: the things doing this compiling and.
Speaker 2: A SI exactly those tools integrated development environments. They handle
Speaker 2: all these steps for you, packaging your C code into
Speaker 2: that final runnable file.
Speaker 1: But it's not just the machine code thrown into a file,
Speaker 1: is it? The Windows linker steps in here? Sounds important?
Speaker 2: Oh, absolutely crucial. The linker takes all the compiled machine code,
Speaker 2: grabs any other bits of the program needs like libraries, data,
Speaker 2: and packages it all up, packages it into the portable
Speaker 2: executable format, the PE format. That's your standard dot ex
Speaker 2: file in Windows.
Speaker 1: Okay, PE format. What key things does the linker pack
Speaker 1: in there? The book's mentioned a few.
Speaker 2: Right, Well, it sets a default image based address often
Speaker 2: zero by four hundred thousand. That's like the program's preferred
Speaker 2: home in memory referred okay, And it organizes everything into
Speaker 2: sections within that PE file, like.
Speaker 1: The dot text section. What's that for?
Speaker 2: That's where the actual executable code lives. Then you've got
Speaker 2: dot I data read only data like text string exactly
Speaker 2: like your Hello World string. And then there's dot iData
Speaker 2: that holds the import address table or IAT BIAT.
Speaker 1: Something tells me we'll be hearing more about that one.
Speaker 1: What's its job?
Speaker 2: Think of it like your program's phone book for outside help.
Speaker 2: It lists all the functions your program needs to call
Speaker 2: from other places, usually Windows own libraries.
Speaker 1: The DLLs, so it knows who to call for certain tasks, right, And.
Speaker 2: When your program runs, Windows uses the IAT to find
Speaker 2: the actual memory addresses of those functions. But crucially, if
Speaker 2: an attacker can rewrite those phone numbers.
Speaker 1: Ah, they can redirect calls to their own code exactly.
Speaker 2: It's a key vulnerability point. We'll definitely come back to
Speaker 2: that The linker also adds the optional header tons of
Speaker 2: metadata the loader needs later.
Speaker 1: Okay, so we've got this static PE file on disc
Speaker 1: How does it become a living, breathing process in memory.
Speaker 1: That's the system application loader's job. Yep.
Speaker 2: The loader takes that PE file and brings it to life.
Speaker 2: It reads those sections code data imports, and carefully places
Speaker 2: them into memory.
Speaker 1: Following the instructions in the pehaders.
Speaker 2: Precisely using that base address as a starting point. It
Speaker 2: writes the sections to memory at the right offsets and
Speaker 2: does some initial setup to get the program ready to run.
Speaker 1: So it's not just copying, it's really constructing the process
Speaker 1: and memory more dynamic than.
Speaker 2: I thought, absolutely, and getting this initial journey CCODE to
Speaker 2: running process. It's fundamental. It really sets the stage for
Speaker 2: all the security stuff the book dives into later how
Speaker 2: this very process gets targeted.
Speaker 1: Right, So building on that, how the PE file gets made.
Speaker 1: Chapter two looks at how that static file actually lays
Speaker 1: out in memory when it's running process memory.
Speaker 2: Yeah, how those PE parts, the doss header, the NT
Speaker 2: headers with the file header, and the optional header, the
Speaker 2: section headers. How they all get mapped into the process's
Speaker 2: virtual memory space.
Speaker 1: It's all structured following the rules laid out in those
Speaker 1: headers exactly.
Speaker 2: The book talks about the file mapping process, how the
Speaker 2: system copies bits of the PE file into memory addresses.
Speaker 2: It uses things like size of headers.
Speaker 1: That's how big the header part is, right, and.
Speaker 2: Then to raw data and relative virtual address RVA guide
Speaker 2: where the content of each section goes in memory.
Speaker 1: RVA relative virtual address so like an offset from the.
Speaker 2: Start pretty much an address relative to the module's base
Speaker 2: address in memory. Understanding rva's is key if you ever
Speaker 2: want to pick apart a PE file or understand how
Speaker 2: things link up internally.
Speaker 1: Okay, and knowing how this mapping works leads into some well,
Speaker 1: some shadier techniques discussed in the book, Yeah, like PE
Speaker 1: infection or PE patching.
Speaker 2: Yeah. The core idea there is adding your own malicious section,
Speaker 2: maybe with some shell code.
Speaker 1: Shell code being that small, self contained bit of malicious.
Speaker 2: Code, right, You add that to a normal program. Then
Speaker 2: you tweak the program's entry point.
Speaker 1: So when the program starts, it runs the malicious code first.
Speaker 2: Exactly, it gets redirected. It sounds really hard to spot too, would.
Speaker 1: A normal user even notice anything? What are the signs?
Speaker 2: That's the tricky part. The original program might still seem
Speaker 2: to work fine afterwards, maybe it takes a bit longer
Speaker 2: to start unusual network activity. Security software might flag it,
Speaker 2: hopefully by spotting the extra section or the modified entry point.
Speaker 2: But yeah, it can be subtle.
Speaker 1: The book used that Pikachu volleyball example. Right, infecting pickaball
Speaker 1: dot ex.
Speaker 2: Yeah, you think you're launching a game, but note something
Speaker 2: else runs first really drives the point.
Speaker 1: Huh, definitely. And then there's process hollowing That sounds even sneakier.
Speaker 2: It's a step up, for sure. An attacker starts a
Speaker 2: legitimate process, say Google Update dot ex, but pauses it
Speaker 2: immediately creates it in a suspended state.
Speaker 1: Okay, so it's loaded but not running code yet. Right.
Speaker 2: Then they basically hollow it out. They unmap its original
Speaker 2: memory and replace it entirely with their own malicious code.
Speaker 1: So the legit process is just a shell, a container
Speaker 1: for the bad stuff exactly.
Speaker 2: And the really deceptive part, the process's internal data structures
Speaker 2: like the people we'll talk about, might still point to
Speaker 2: the original Google Update dot.
Speaker 1: Ex, so it looks legitimate to the system.
Speaker 2: It can. Yeah, the book even says sometimes the original
Speaker 2: digital signature can appear valid because the systems looking at
Speaker 2: the initial process information, not the hollowed out content, makes
Speaker 2: detection way harder.
Speaker 1: Wow hiding and plain sight. The book also mentions tiny linker.
Speaker 1: What's that about?
Speaker 2: Oh yeah, tiny linker, It's about building a really stripped
Speaker 2: down minimal compiler and linker.
Speaker 1: Why would you do that?
Speaker 2: Well, partly to understand the absolute bare minimum needed for
Speaker 2: a PE file, But attackers like it because they can
Speaker 2: create incredibly small executables, tiny payloads that might slip past
Speaker 2: some security checks that look for larger, more complex files.
Speaker 1: Okay, so from legit programs loading, we're already seeing how
Speaker 1: those mechanics get twisted. Chapter three moves on to how
Speaker 1: running programs talk to Windows Dynamic API calling.
Speaker 2: Right, programs need to ask Windows to do things open files,
Speaker 2: show Windows talk to the network. They do this by
Speaker 2: calling Windows APIs application programming interfaces. Often this happens right
Speaker 2: down at the assembly code level.
Speaker 1: And there are rules for how these calls are made.
Speaker 1: Conventions like WinAPI exactly.
Speaker 2: Calling conventions are like protocols for function calls. They dictate
Speaker 2: how arguments get passed on the stack in registers. Who
Speaker 2: cleans up the memory afterwards, where does a return value go?
Speaker 1: The book used message box as an example.
Speaker 2: The pop up box yeah, a classic example of the
Speaker 2: WinAPI convention. Parameters usually pushed onto the stack right to left,
Speaker 2: and the message box a function itself, cleans up the
Speaker 2: stack when it's done.
Speaker 1: Okay. Then the book introduces these really important but apparently
Speaker 1: often undocumented structures, the TEB and the PEB.
Speaker 2: Ah Yes, the thread environment block TB and the process
Speaker 2: environment block P. They hold a gold mine of info
Speaker 2: about a running program.
Speaker 1: So TEB is for threads, individual execution.
Speaker 2: Paths, exactly thread specific data. The book highlights fields like
Speaker 2: exceptionalists for error handling, stack base and stack limit defining
Speaker 2: the threads, stack memory, client TITE holding process and thread IDs.
Speaker 1: And crucially a pointer to the P right and.
Speaker 2: A pointer to itself. So the PAY, on the other hand,
Speaker 2: holds info for the entire process.
Speaker 1: What kind of stuff is in the P.
Speaker 2: Things like the being debugged flag. Malware hates debuggers, so
Speaker 2: they check this. There's the image base address where the
Speaker 2: main program module loaded process parameters, has info like command
Speaker 2: line arguments, and a really important one a pointer to
Speaker 2: pebble door data.
Speaker 1: Pebble door data sounds like it releads to loading things.
Speaker 2: It does. It's all about the modules, the DLLs that
Speaker 2: the process is loaded into its memory.
Speaker 1: So these TIB and PEB structures give a program context
Speaker 1: self awareness, and the book says you can sometimes access
Speaker 1: this info directly without using standard Windows functions.
Speaker 2: Yeah, especially in thirty two bit Windows. The FS segment
Speaker 2: register often points to the teb letting code access feels
Speaker 2: directly GS register in sixty four bit. This is how
Speaker 2: stealthy malware can gather info about its environment without making
Speaker 2: noisy API calls that security software might be watching.
Speaker 1: Sneaky at pebble. D R data structure sounds key then
Speaker 1: for tracking loaded DLLs.
Speaker 2: It is. It contains links inload order. Modulist tracks DLLs
Speaker 2: in the order they loaded. In memory order. Modulists tracks
Speaker 2: them by memory address, an initialization order. Modulist, well, that's
Speaker 2: about initialization order.
Speaker 1: And each entry in these lists is an LDR datable
Speaker 1: entry holding details about each DLL YEP.
Speaker 2: Things like the DLL's base address in memory dll base,
Speaker 2: its entry point, its size, its full path and file name,
Speaker 2: a full down name based a law name, even a
Speaker 2: load count showing how many times it's been referenced.
Speaker 1: Wow tons of detail, and the book explains how attackers
Speaker 1: can use this.
Speaker 2: Walk through these lists exactly. They can traverse the pet
Speaker 2: LDR structure follow the pointers in those link lists to
Speaker 2: find the base address of a specific DLL they need,
Speaker 2: like kernel thirty two dot dll.
Speaker 1: Without calling load library or get module handle.
Speaker 2: Right, they find it manually internally evades detection that might
Speaker 2: be watching those specific API calls. It's like using an
Speaker 2: internal undocumented map instead of asking for directions.
Speaker 1: Very clever. It gets worse the can thisss with these entries.
Speaker 2: Yeah. The book mentions techniques to actually modify the LDR
Speaker 2: datable entry structures. You could potentially rename a loaded DLL
Speaker 2: in memory, just change the name string to confuse analysis tools,
Speaker 2: or even unlink malicious DLL entirely from these lists hide module,
Speaker 2: making it invisible to standard enumeration methods.
Speaker 1: That's serious manipulation. The chapter also mentions parameter forgery changing
Speaker 1: command line arc briefly.
Speaker 2: Yeah, create a process suspended, then go into its PEB
Speaker 2: and fiddle with the process parameter structure to change what
Speaker 2: command line arguments it thinks it was launched.
Speaker 1: With so many ways to mess with a process. Once
Speaker 1: you understand these internals. Okay. Chapter four goes back to
Speaker 1: shell code, specifically how it finds those Windows API functions
Speaker 1: it needs. Right.
Speaker 2: Because shell cut often gets injected in weird ways, it
Speaker 2: can't rely on the normal loading process setting up that
Speaker 2: import address table IAT for it. It has to find
Speaker 2: functions itself dynamically at run time.
Speaker 1: And the key is the export address table the E within.
Speaker 2: Each LL Exactly, The ET is like the dla's public directory.
Speaker 2: It lists all the functions the DLA exports for others
Speaker 2: to use what's in the ET. It has a few
Speaker 2: key arrays. Address of functions points to the actual code
Speaker 2: for each exported function, as rva's address of names points
Speaker 2: to the names of the functions, and address of name
Speaker 2: ordinals maps the names to ordinal numbers.
Speaker 1: So shell code can read this ET to find the
Speaker 1: address of, say, create filet A inside kernel three D
Speaker 1: two dot DL precisely.
Speaker 2: The book even talks about building a simple tool to
Speaker 2: purse a DL's ET and list its exports. Then it
Speaker 2: shows how shell code uses the TBNP tricks we just
Speaker 2: discussed to first find the DL's base address and memory.
Speaker 1: Like finding kernel threet two dot DLL's.
Speaker 2: Address right, and then it manually parses that DL's PE
Speaker 2: headers to find the ET, and then searches through the
Speaker 2: ET's arrays address of names, address off name ordinals, address
Speaker 2: of functions to locate the exact memory address of the
Speaker 2: specific function at once.
Speaker 1: All without calling get proke address.
Speaker 2: Exactly, totally self sufficient, like a little detective inside the
Speaker 2: process memory.
Speaker 1: That's amazing. The chapter actually walks through writing by eighty
Speaker 1: six assembly shell code to do this.
Speaker 2: That sounds intense, it is definitely low level. The thirty
Speaker 2: two B shell code dot atism example in the book
Speaker 2: is detailed shows accessing TUB, finding PAYAB, walking the LDR
Speaker 2: list for kernel thirty two dot DL, parsing its headers,
Speaker 2: finding the EET, and then crawling the ET tables to
Speaker 2: get the address for fatal exit. It's a masterclass in
Speaker 2: manual low level function resolution.
Speaker 1: Phew. Okay, But for those not quite ready for assembly,
Speaker 1: the book mentions automating shell code generation from C or
Speaker 1: C plus plus AP.
Speaker 2: Yeah. Thankfully, there are tools and techniques to compile CC
Speaker 2: plus plus code down into position independent shell code, which
Speaker 2: makes it much more accessible. Kind of bridges the gap makes.
Speaker 1: Sense, okay. Chapter five dives deeper into the application loader itself,
Speaker 1: especially that import address table, the IAT. We keep mentioning.
Speaker 2: Yeah, the IAT is just so central to recap. It's
Speaker 2: that table of function pointers and module. When the loader
Speaker 2: loads your program at, the IAT sees which functions you
Speaker 2: need from other DLLs, goes.
Speaker 1: And finds the real addresses of those functions in memory.
Speaker 2: And patches the IAT, filling in those pointers. So when
Speaker 2: your code calls say create filarea, the IAT entry now
Speaker 2: points directly to the real create filia code loaded somewhere
Speaker 2: in memory, connects the dots exactly. It wires everything up.
Speaker 2: And the book then covers a really advanced technique loading
Speaker 2: and running a whole ex inside another process's memory, no
Speaker 2: separate file on disk.
Speaker 1: Yeah, super stealthy used by APT groups.
Speaker 2: Yeah, The book mentions threat actors like Mustang, Panda, APT
Speaker 2: forty one, and even tools like metasploit using this for
Speaker 2: stage payloads. It avoids creating a new process that security
Speaker 2: tools might immediately notice.
Speaker 1: Makes sense. Then there's IAT hooking, another way to mess
Speaker 1: with these function calls. Yep.
Speaker 2: With IAT hooking, you modify the IAT after the loader
Speaker 2: has filled it in. You change a pointer that should
Speaker 2: go to a legitimate function like message box A to
Speaker 2: point to your own malicious function instead, so.
Speaker 1: The program thinks it's calling the real function but gets
Speaker 1: hijacked exactly.
Speaker 2: The book uses message box A hijacking as an example.
Speaker 2: Legitimate uses exist, like in game plugins or sandboxes, but
Speaker 2: malware uses it to intercept data, redirect control flow, things
Speaker 2: like that.
Speaker 1: And then DLL sideloading comes up again.
Speaker 2: Right exploiting that search order program needs some dot DLL.
Speaker 2: Loader checks the program's own folder first, then system thirty two,
Speaker 2: et CETERA. Attacker puts a malicious sump dot DLL in
Speaker 2: the program's folder, and the.
Speaker 1: Loader finds and loads the malicious one before it ever
Speaker 1: looks in system thirty two.
Speaker 2: That's the idea. The book uses hijacking Chrome with a
Speaker 2: phadversion dot DLL as an example. Very common attack vector.
Speaker 1: And DLL proxying. What was that?
Speaker 2: That's a variation. The malicious DLL gets loaded via sideloading,
Speaker 2: but it actually exports all the same functions as the
Speaker 2: real DLL it replaced. When the program calls a function,
Speaker 2: the malicious DLL might do something bad first, then it
Speaker 2: proxies the call, passing it along to the actual legitimate DLL,
Speaker 2: which it loads itself.
Speaker 1: So the program still works, but the attacker gets their
Speaker 1: code executed too clever. Chapter five really shows the loading
Speaker 1: process is full of potential attack surfaces. Chapter six talks
Speaker 1: about PE module relocation. This is about loading things at
Speaker 1: different addresses exactly. Remember the linker sets a preferred image
Speaker 1: based address right like zero by four hundred thousand.
Speaker 2: In a running system, that address might already be taken
Speaker 2: by something else, So the program just fails, not necessarily.
Speaker 2: That's where relocation comes in. It's a mechanism built into
Speaker 2: the PE format that allows a module to be loaded
Speaker 2: and run correctly even if it lands at a different
Speaker 2: address than its preferred one.
Speaker 1: How does that work? Does something get adjusted?
Speaker 2: Yes, there's a relocation table inside the PE file. It
Speaker 2: lists all the places in the code and data that
Speaker 2: contain absolute memory addresses addresses that assume the module is
Speaker 2: loaded at its preferred image base.
Speaker 1: Ah. So if it loads somewhere else, those addresses would
Speaker 1: be wrong exactly.
Speaker 2: So when the LOADO puts the module at a different address,
Speaker 2: it reads this relocation table and goes through and fixes
Speaker 2: up all those listed addresses, adjusting them based on the
Speaker 2: actual load address.
Speaker 1: Making sure all the internal pointers are correct.
Speaker 2: For the new location precisely. The book mentions tiny loader
Speaker 2: again here showing how a custom loader like ploader dot
Speaker 2: cpp can handle this. It parses the relocation table and
Speaker 2: applies the fix ups when loading a module, often using
Speaker 2: virtual allock to get memory wherever it can, and then
Speaker 2: carefully patching the loaded code and data.
Speaker 1: Very important for those in memory loading techniques we discuss Okay,
Speaker 1: chapter seven packers. We've probably all run into packed executables.
Speaker 1: What's the deal with them?
Speaker 2: Packers are tools that basically wrap an executable. They compress it,
Speaker 2: maybe encrypt it, definitely obfuscate it. The original program gets
Speaker 2: bundled inside a shell or stub.
Speaker 1: So it's like putting the real program inside a protective.
Speaker 2: Box kind of yeah, or maybe a confusing box. The
Speaker 2: book shows how the memory layout changes. You often get
Speaker 2: a section marked readable, writeable and executable text up x,
Speaker 2: where the un packed code will go. You get a
Speaker 2: payload section holding the packed original program, and you get
Speaker 2: the packer stub COODE.
Speaker 1: And the stub is the code that does the unpacking.
Speaker 2: YEP. When you run the packed file, the stub executes first.
Speaker 2: Its job is to decompress or decrypt the payload into
Speaker 2: that textrap x section. Often it also has to act
Speaker 2: like a mini loader itself, fixing imports, handling relocations for
Speaker 2: the unpacked code.
Speaker 1: And then it jumps to the original program starting point.
Speaker 2: Right jumps to the original entry point OEP of the
Speaker 2: now unpacked program, and the original application starts running, hopefully
Speaker 2: unaware it was ever packed.
Speaker 1: Other different kinds of packers.
Speaker 2: Broadly, Yeah, compression packers like upx or mprs mostly just
Speaker 2: aimed to make the file smaller. Protective packers like VM
Speaker 2: protect themta Enigma protector. They focus heavily on making reverse
Speaker 2: engineering and analysis really difficult.
Speaker 1: How do they do that? What are these anti reverse
Speaker 1: engineering tricks?
Speaker 2: Oh? Loads of them. Obfuscation, making the code intentionally confusing,
Speaker 2: anti VM checks, trying to detect if it's running in
Speaker 2: a sandbox, Anti debugger tricks checking that PEB being debugged,
Speaker 2: flag using weird API calls to crash debuggers.
Speaker 1: Anti tampering too, like checking file integrity.
Speaker 2: Yeah, using checksums, maybe comparing against the pe headers checksum,
Speaker 2: checking digital signatures authenticode. Some even use virtualization. They translate
Speaker 2: the original code into a custom bytecode and run it
Speaker 2: on a tiny virtual machine. Embedded in the packer stub,
Speaker 2: super complex stuff.
Speaker 1: Plus commercial features like licensing checks sometimes right.
Speaker 2: The book also touches on building a simple packer, reading
Speaker 2: the original ex compressing it, writing an assemile stub to
Speaker 2: handle unpacking, combining it all using tools like YASM and GCC.
Speaker 1: And the unpacker stub itself has key parts right.
Speaker 2: Yeah, routines like decompress image, recarnate HDR to rebuild the
Speaker 2: pehaders for the unpacked code, and look a poet to
Speaker 2: find where to jump. The book uses packing an old
Speaker 2: game and a schnaft as an example shows the size reduction,
Speaker 2: but more importantly how tools like IDPro can't easily see
Speaker 2: the original game code anymore. It's all hidden inside the
Speaker 2: packer stub and payload.
Speaker 1: Okay, moving to chapter nine. Digital signatures in Authentic Code.
Speaker 1: We see these all the time when downloading stuff. What's
Speaker 1: their main job?
Speaker 2: Authentic Code is Microsoft's tech for signing code. Two main
Speaker 2: goals verify the publisher is this really from who it
Speaker 2: says is from? And verify integrity have this file been
Speaker 2: messed with since it was signed?
Speaker 1: Relies on trust right certificate authorities.
Speaker 2: YEP, trusted CAS vouch for the publisher's identity before issuing
Speaker 2: the certificate used for signing.
Speaker 1: The book mentioned embedded versus detached signatures.
Speaker 2: Right embedded is most common for exs and DLLs. The
Speaker 2: signature data is literally tacked onto the end of the
Speaker 2: PE file itself. Detached signatures are separate, maybe in catalog files,
Speaker 2: often just containing a hash of the sign file.
Speaker 1: So Windows checks that embedded signature when we run a downloaded.
Speaker 2: Ex usually yeah, using APIs like when verify trust. Different
Speaker 2: file types actually use different backend components called subject interface
Speaker 2: packages SIPs to handle the specifics of validation.
Speaker 1: And hashing is key for the integrity check.
Speaker 2: Absolutely, a cryptographic hash is calculated over the executable's content. But,
Speaker 2: and this is crucial, certain parts are excluded from the hash,
Speaker 2: like what the p header's check, some field, the security
Speaker 2: directory entry itself which points to where the signature is stored,
Speaker 2: and the actual signature block data are all skipped during.
Speaker 1: Hashingh skipping the signature block itself that sends an exploit
Speaker 1: opportunity there. But first, mock signatures? Can you just fake one?
Speaker 2: The book tries it copies the signature block from a
Speaker 2: signed file like Google Update, dot ex and paste it
Speaker 2: onto an unsigned one like Pikachu Volleyball.
Speaker 1: Do it work?
Speaker 2: Nope. The signature data is there, but the hash embedded
Speaker 2: inside that signature block belongs to Google Update, not Pikachu.
Speaker 2: When Windows calculates Pikachu's hash and compares it, they won't match.
Speaker 2: Verification fails.
Speaker 1: Okay, so simple copying doesn't work. What about bypassing the
Speaker 1: hash check?
Speaker 2: Now you're talking. The book mentions research by Matt Graeber
Speaker 2: showing how you can potentially hook or patch the verification
Speaker 2: function in memory, specifically crypt SIP verify indirect data to
Speaker 2: just always return true, always say the signature is valid
Speaker 2: even when it's not.
Speaker 1: So you trick the system into thinking the check past
Speaker 1: even if the hash is wrong.
Speaker 2: Essentially, yes, a way to make a fake signature look
Speaker 2: legit at a certain level.
Speaker 1: Wow, and signature steganography hiding stuff in the signature.
Speaker 2: Yeah, this exploits that exclusion we mentioned. Since the signature
Speaker 2: block itself isn't hashed, you can append extra data after
Speaker 2: the actual signature data within that block. You just need
Speaker 2: to update the size field correctly.
Speaker 1: And the signature still validates it.
Speaker 2: Can Yeah, the original signed hash is still correct for
Speaker 2: the original part of the file, but now you've smuggled
Speaker 2: extra data inside the signature block, potentially hiding malware payloads
Speaker 2: where scanners might not look closely.
Speaker 1: Very sneaky. Lastly, getting signed by abusing path normalization exploiting
Speaker 1: how Windows handles paths.
Speaker 2: This is another subtle one, again based on path normalization research.
Speaker 2: If you create a file with a weird name like
Speaker 2: Google update dot ex with a trailing space, Windows might
Speaker 2: normalize that path differently during signature checks compared to other operations.
Speaker 1: So you can have a legitimate Google update dot ex
Speaker 1: with a valid signature, and maybe a malicious Pikachu volleyball
Speaker 1: file at a path that normalizes to look like the
Speaker 1: Google update path during the check.
Speaker 2: Under certain complex conditions. Yes, it's about creating collisions in
Speaker 2: how paths are interpreted, potentially tricking the system into associating
Speaker 2: a valid signature with the wrong file. Due to these
Speaker 2: normalization quirks.
Speaker 1: The man signatures are way more complex and fragile than
Speaker 1: they seem. Okay. Chapter ten User account Control UAC, and
Speaker 1: bypassing it, UAC is meant to stop malware getting admin
Speaker 1: rights easily. Right.
Speaker 2: That's the goal. Stop programs from getting elevated privileges without
Speaker 2: your permission. It runs most things as a standard user,
Speaker 2: even if you're logged in as admin, and prompts you
Speaker 2: when something needs more power. Only certain trusted system services
Speaker 2: can bypass the prompt automatically.
Speaker 1: The book mentions Ray launch admin process in a pinfo
Speaker 1: dot DLL. What's that?
Speaker 2: That's described as the core function in the UAC service
Speaker 2: that handles elevation requests. It receives the request, validates it
Speaker 2: based on rules, and if it passes, launches the process
Speaker 2: with admin rights. It takes parameters like the executable path,
Speaker 2: command line, et cetera. It's the gatekeeper and.
Speaker 1: It has checks A two level authentication Yeah.
Speaker 2: Authentication A and B.
Speaker 1: What do they check?
Speaker 2: Authentication A is mostly about the path. Is it running
Speaker 2: from a trusted system location like CU Windows? Is it
Speaker 2: on a known blacklist? Authentication B is stricter. Does it
Speaker 2: have a valid digital signature? Does the filename maybe match
Speaker 2: internal version info? If a program passes both checks, it can.
Speaker 1: Get elevated automatically.
Speaker 2: No prompt exactly. If it's configured for auto elevation, like
Speaker 2: many built in Windows tools, are has a valid signature
Speaker 2: and runs from a trusted path UAC might let it
Speaker 2: elevate silently.
Speaker 1: Which naturally leads to bypass techniques trying to meet those
Speaker 1: conditions illegitimately.
Speaker 2: You got it. The chapter covers several ways DLL sideloading
Speaker 2: again but targeting one of those auto elevating privileged processes.
Speaker 2: If you can get your malicious DLL loaded by one.
Speaker 1: Of them, your DLL runs with elevated.
Speaker 2: Rights too, bingo. Another way is using elevated comm objects
Speaker 2: CALM objects, yeah, component object model. Some COMM objects, like
Speaker 2: ifile operation for file tasks are designed to run elevated.
Speaker 2: A low privileged process might be able to create and
Speaker 2: use one of these elevated objects to perform admin level
Speaker 2: actions by passing the usual UAC flow. Wikileaksvault seven mentioned
Speaker 2: stuff like this.
Speaker 1: Then there's CMSTP Connection Manager Profile.
Speaker 2: Installer right, another legit Windows tool, CMSTP dot exc that
Speaker 2: can be abused by crafting a malicious dot inf file
Speaker 2: and tricking CMSTP into processing it. Attackers found ways to
Speaker 2: execute arbitrary code with elevated privileges. Often involves making the
Speaker 2: attacker process look like explore dot ex and messing with its.
Speaker 1: Pebe and finally trusted path collisions again using long.
Speaker 2: Paths YEP back to path normalization. An attacker puts their
Speaker 2: malicious executable maybe one vulnerable to DLL side loading itself
Speaker 2: like BitLocker wizardleve dot exc in the books, example, in
Speaker 2: a non trusted location, but they use a very long
Speaker 2: or weirdly constructed.
Speaker 1: Path, so that when UAC checks the path after normalization, it.
Speaker 2: Looks like it's coming from a trusted directory like System
Speaker 2: thirty two, even though it isn't really there. The check
Speaker 2: pass is based on the normalized path, and UAC might
Speaker 2: grant auto.
Speaker 1: Elevation, exploiting the gap between the real path and how
Speaker 1: the system interprets it for checks. Wow. Okay. Finally, the
Speaker 1: appendix NTFS paths symbols.
Speaker 2: Why is this important because so many security checks, as
Speaker 2: we've seen, rely on comparing file paths. Understanding how Windows
Speaker 2: defines paths when thirty two versus antipaths, how it converts
Speaker 2: and normalizes them is crucial for finding bugs or ways
Speaker 2: to trick those comparisons.
Speaker 1: The book mentions different path types DOS paths, UNC paths,
Speaker 1: and that prefix being special.
Speaker 2: Yeah. The prefix tells Windows don't normalize this path much
Speaker 2: and allow it to be longer than two hundred and
Speaker 2: sixty characters. It bypasses many standard steps which could be
Speaker 2: abut oh yeah. The appendix gives examples creating folders with
Speaker 2: trailing dots or spaces that confuse, explore, using path normalization
Speaker 2: differences to bypass signature checks, even how the CD command
Speaker 2: behaves weirdly sometimes. It also mentions symbolic links like shortcuts,
Speaker 2: but more powerful, and how viewing them with one object
Speaker 2: can reveal filesystem structure and device paths like NUL. Apparently,
Speaker 2: using paths doesn't restrict the parent directory sequence, which could
Speaker 2: potentially allow access to unexpected places. It really shows that
Speaker 2: path handling is full of subtle complexities.
Speaker 1: What a deep dive. That was seriously intricate stuff, all
Speaker 1: pulled from Windows APT warfare. Looking back, what's the big
Speaker 1: picture takeaway for you?
Speaker 2: For me, it's just the here hidden complexity. Clicking an
Speaker 2: icon seems simple, but the journey from code to process,
Speaker 2: the memory layout, the API calls the security layers like
Speaker 2: signatures in UAC.
Speaker 1: It's incredibly deep and every layer has potential weaknesses.
Speaker 2: Exactly every mechanism from PE loading to path handling can
Speaker 2: potentially be manipulated or subverted. If you understand it well enough.
Speaker 2: It really highlights that constant cat and mouse game between
Speaker 2: attackers finding flaws and defenders trying to patch them or
Speaker 2: detect exploitation.
Speaker 1: Right and hopefully for you listening, getting even a glimpse
Speaker 1: of these underlying mechanisms helps make sense of how software works,
Speaker 1: maybe helps you spot weird behavior, or just understand the
Speaker 1: news about security breaches a bit better.
Speaker 2: Absolutely, if any of this sparked your interest reverse engineering,
Speaker 2: malware analysis, Windows internals, generally, definitely dig deeper. The book itself,
Speaker 2: Windows APT Warfare and its githab Repo seem like great
Speaker 2: starting points for more hands on exploration.
Speaker 1: Definitely. So maybe the final thought to leave you with
Speaker 1: is this, in this world where cyber shreds are always evolving,
Speaker 1: always getting more sophisticated, isn't.
Speaker 2: Really understanding these fundamental building blocks, the very guts of
Speaker 2: the operating system like we've touched on today. Isn't that
Speaker 2: the most critical foundation for both the attackers and the defenders.
Speaker 1: It really feels like it's all about continuous learning, right Yea.
Speaker 1: The deeper we understand these internals, the better equipped we
Speaker 1: all are