How LLMs Feed Your RE Habit: Following the Use-After-Free Trail in CLFS Contents How LLMs Feed Your RE Habit: Following the Use-After-Free Trail in CLFS TL;DR This post demonstrates how LLMs and pyghidra-mcp accelerate reverse engineering by tracing a use-after-free vulnerability in Windows’ Common Log File System (CLFS) through a patch diff, showing how AI maintains momentum in complex analysis. LLMs don’t replace the work—they feed the habit by making the work feel lighter, faster, and well… fun. Reverse engineering has always been a mix of instinct, curiosity, and stubbornness. You follow threads, you chase weird behavior, you stare at code flows until they start to make sense. But something interesting happens when you add LLMs into the loop. Not as oracles. Not as replacements. As momentum — the thing that keeps you moving when the system gets complicated. They help you move faster in systems you already know, and they help you build foundational structure in systems you’ve never touched. They can turn “Where do I start?” into “Show me the shape of this thing.” How LLMs Feed Your RE Habit Series This two‑part mini‑series explores both sides of that experience: First, by following a UAF path in CLFS — a subsystem I know well enough to be dangerous. Then, by mapping macOS XPC services — a subsystem I just started studying. Same tools, totally different terrain. Let’s find out how LLMs feed your RE habit . Understanding CLFS Context for CVE-2025-29824 Before diving into the vulnerability, let’s quickly understand what CLFS (Common Log File System) does in Windows. It’s the kernel-level logging system that provides high-performance, reliable, structured persistent logging for Windows components and applications. CLFS is just another Windows kernel driver that quietly does its job… until it doesn’t. And when it doesn’t, the consequences surface directly in the kernel. User-mode applications interact with it through Win32 APIs like CreateLogFile and ReserveAndAppendLog (from clfsw32.dll), which open special log handles — by sending IOCTL requests straight to the clfs.sys driver in the kernel. The vulnerabality can be triggered by creating a subtle race condition by sending these IOCTLs. Eventually, through the help of a patch diff, a blog post, and an LLM, we will see exactly how the vulnerability can be triggered. Patch Diffing Found the Bug, What Was the Bug Again? Patch diffs are where the story starts, not where it ends. When you’re patch diffing , finding the code changes is usually the easy part. The harder part — and the part that actually matters — is understanding why the change was needed. That’s where the reverse engineering begins. You start tracing control flow, start to understand the code, and ask the classic question: “Okay… but how does this actually become a bug?” Try it. You can run the patch diff for CVE-2025-29824 yourself with these commands: 1 2 3 wget https://msdl.microsoft.com/download/symbols/Clfs.Sys/B199B0AF86000/Clfs.Sys -O clfs.sys.x64.10.0.26100.3624 wget https://msdl.microsoft.com/download/symbols/Clfs.Sys/931DCBBD86000/Clfs.Sys -O clfs.sys.x64.10.0.26100.3775 uvx ghidriff clfs.sys.x64.10.0.26100.3624 clfs.sys.x64.10.0.26100.3775 Check out the ghidriff result . Ghidriff diff output showing CLFS patch changes From the diff we can see a couple functions have been modified and we can actually go and see the details of how the code was changed. We know that CVE-2025-29824 is a use-after-free (UAF), so that gives us quite a bit of a head start and the perfect context for an LLM. In addition to the diff, sometimes you get lucky and someone has already done the heavy lifting. For this example we can leverage an excellent StarLabs write‑up on CVE‑2025‑29824. With this detailed post, the diff and vulnerability have context, shape, and stakes. Turns out, it’s a use-after-free vulnerability in the Windows Common Log File System (CLFS) driver. When a log file handle is closed, the FsContext2 structure is incorrectly freed in CClfsRequest::Cleanup(), while another IRP request can still be in progress. My Blind Date with CVE-2025-29824 When reading another write-up, I like to go and see for myself if it’s true. A good write‑up shouldn’t replace your own investigation — it gives you a direction. Maybe this is true for you? You want to see the path, the conditions, the lifetime transitions, the exact moment where CLFS lets a UAF slip through. You can do this investigation on your own with Ghidra, Binja, or Ida, but what if you could automate some of the analysis with a LLM? Let’s try it. Environment Setup and Tech Stack To follow along, you’ll need a setup that combines the knowledge of LLMs with Ghidra’s analysis power. If you have the compute that can run local LLMs, even better! Local LLM Tech Stack Open WebUI and LM Studio : For running and chatting with local LLMs. Open WebUI provides a clean interface, while LM Studio handles model management and inference. Local LLMs for privacy (optio...