---

The Basics

Forgive me if this post sounds too basic or detailed. My tutor job gave me this style. Hopefully it helps beginners.

What is a Call Stack?

Assuming you understand the basic concepts such as process and thread, you should know that a thread is essentially a code flow; and a code flow, from a computer's perspective, either processes data for a function call, or processes data returned by a function call, which brings us the need for state management, which we call stack. So, yes, a thread has a stack, and a process has one or more threads.

The stack, when used for function call tracking, we call it a call stack.

In the following screenshot, there are 5 call stacks.

Each row has some information about a function call, it's called a stack frame. Comment describes where the function is. In most cases, functions are from some executable images (exe, dll). Ntdll is a user space gateway to Windows system calls, that's why some of its functions are marked as system.

However, for obvious reasons, we sometimes have to run code from somewhere other than executable images, to make it less detectable. But guess what? Your code has to run as a thread, which creates a call stack; and a call stack looks like the screenshot. If you haven't found it yet, look again. Yes, it's the one I marked with blue circle (obviously). What makes it special is that it doesn't have any image (file) backing it, it's from some memory address (well, they all are, but this one is anonymous) that's on the heap, instead of legitimate .text section.

Why not write to .text then?

Well, short answer: you can't. It's read-only.

Obviously, you can allocate heap memory and write code to it, then flip its permission to be executable, you get the following, which give you away by having no legitimate name in the call stack when it runs.

Crystal Palace

I wrote this article when I was adding crystal palace to emp3r0r C2. Crystal palace is a linker that allows you to decouple your C2 payload from evasion code, and link them together as PICO (shellcode). PICO, as shellcode, doesn't have a place in images, it has to be on the heap, which gives you the "unbacked code in call stack" issue.

Anyway, what I did is integrate SilentMoonWalk stack spoofing into a PICO payload. This article is mainly about how stack proofing works.

First, we have to find PICO in memory. As we know that the memory pages have to be flipped to executable, VirtualProtect has to be called. We set a breakpoint there and we get the address in RCX (google calling convention if you don’t understand why).

To be continued...