DEV Community: JM00NJ

VESQER: A DPCM+RLE Hybrid Compressor in Pure x64 Assembly

JM00NJ — Wed, 01 Jul 2026 11:55:06 +0000

The Origin Story

At 5 AM, while brainstorming ways to minimize the wire footprint of a custom ICMP-based C2 agent, an idea hit me: "What if I just store the first byte, calculate the difference to the next one, and count how many times that same difference repeats?"

The logic was dead simple. No dictionaries, no Huffman trees, no frequency tables — just subtraction and counting. Two primitive operations that could fit in a handful of x64 instructions.

I felt like a genius... until I realized I had just accidentally reinvented Differential Pulse-Code Modulation (DPCM) combined with Run-Length Encoding (RLE) — techniques formalized by telecom engineers in the 1950s-1970s.

But here's the thing: writing it completely from scratch in pure x86-64 Assembly, with zero libc, zero dependencies, and under 200 instructions — that part was entirely new. And it works beautifully for its intended purpose.

The Problem: Why Compress C2 Traffic?

In a covert channel scenario, every byte matters. Consider a typical ls -la /root output: ~450 bytes. Over ICMP with 56-byte chunk fragmentation, that's 9 packets on the wire. Each packet is a detection opportunity — a chance for an IDS to correlate, flag, and alert.

Now compress that 450 bytes down to ~250 bytes. You just dropped to 5 packets. Fewer packets means less traffic, smaller timing windows, and a reduced statistical footprint. The math is simple: less wire time = less detection surface.

But the compressor itself must be tiny. In a PIC (Position Independent Code) shellcode context, you can't afford to drag in zlib or LZ4. You need something that compiles to a few dozen instructions and requires zero heap allocation.

The Algorithm: DPCM + RLE Hybrid

The VESQER algorithm operates in two conceptual layers that execute in a single pass:

Layer 1 — Delta Encoding (DPCM): Instead of storing raw byte values, we store the difference (delta) between consecutive bytes. If the input is A B C D (ASCII 65, 66, 67, 68), the deltas are all +1. This transforms sequential patterns into repetitive values.

Layer 2 — Run-Length Encoding (RLE): Once the deltas are calculated, identical consecutive deltas are collapsed into a single (count, delta) pair. Those four bytes A B C D become: Anchor: A + (3, +1) — just 3 bytes instead of 4.

The real power appears with longer sequences. ABCDEFGHIJ (10 bytes) becomes A + (9, +1) — only 3 bytes. That's a 70% reduction from two simple operations.

The Compression Format

The output binary format is minimal and signature-free:

[Anchor Byte] [Count₁] [Delta₁] [Count₂] [Delta₂] ... [CountN] [DeltaN]

Anchor (1 byte): The literal first byte of the input. This is the reference point for the entire stream.
Count (1 byte, unsigned): How many times to apply the associated delta. Range: 0–255.
Delta (1 byte, signed via two's complement): The difference to add for each step. Range: -128 to +127.

No magic bytes. No headers. No metadata. Just raw compressed data — exactly what you want when avoiding static signatures.

Walk-Through: How It Actually Works

Let's trace the algorithm with a concrete example. Given the input string:

"AABCDFFF333A"  (12 bytes)

Step 1 — Anchor Setup:
Read the first byte A (0x41) and write it directly to the output. This is our anchor — the starting reference point. The compressor now peeks at the second byte A and calculates the initial delta: 0x41 - 0x41 = 0. Active Delta is set to 0.

Step 2 — Main Compression Loop:
The compressor walks through the remaining bytes. For each byte, it calculates current - previous and compares it to the Active Delta:

Position	Char	Value	Previous	Delta	Active Delta	Match?	Action
1	A	0x41	A (0x41)	0	0	✅	Count++ → 1
2	B	0x42	A (0x41)	+1	0	❌	FLUSH (1, 0) → New delta: +1
3	C	0x43	B (0x42)	+1	+1	✅	Count++ → 2
4	D	0x44	C (0x43)	+1	+1	✅	Count++ → 3
5	F	0x46	D (0x44)	+2	+1	❌	FLUSH (3, +1) → New delta: +2
6	F	0x46	F (0x46)	0	+2	❌	FLUSH (1, +2) → New delta: 0
7	F	0x46	F (0x46)	0	0	✅	Count++ → 2
8	3	0x33	F (0x46)	-19	0	❌	FLUSH (2, 0) → New delta: -19
9	3	0x33	3 (0x33)	0	-19	❌	FLUSH (1, -19) → New delta: 0
10	3	0x33	3 (0x33)	0	0	✅	Count++ → 2
11	A	0x41	3 (0x33)	+14	0	❌	FLUSH (2, 0) → New delta: +14
—	EOF	—	—	—	—	—	FINAL FLUSH (1, +14)

Compressed Output:

[0x41] [01,00] [03,01] [01,02] [02,00] [01,ED] [02,00] [01,0E]
  A     1×(0)  3×(+1)  1×(+2)  2×(0)  1×(-19) 2×(0)   1×(+14)

Result: 15 bytes from 12. In this particular short example, the overhead of frequent delta changes actually expands the data. This is expected — the algorithm's strength is with longer, more predictable sequences.

Where It Dominates

Consider a typical log line repeated across thousands of entries:

"192.168.1.96  - - [10/Apr/2026:05:38:27 +0000] "GET /index.html..."

The spaces, repeated digits, sequential timestamps, and identical structural characters create long delta runs. A 1KB log block can easily compress to 400-500 bytes — a 50-60% reduction with zero dictionary overhead.

The x64 Assembly Implementation

Register Architecture

The compressor is designed for maximum register economy — critical for shellcode deployments where every byte of machine code counts:

RSI  →  Source pointer (raw input data)
RDI  →  Destination pointer (compressed output)
RCX  →  Remaining bytes counter (loop control)
R8B  →  RLE Count (0–255, single-byte register)
R9B  →  Active Delta (current difference being tracked)
AL   →  Working register (current byte / delta calculation)
BL   →  Previous byte value (the "anchor" for delta math)
DL   →  Temporary save register (preserves current byte)

No heap. No stack frames. No memory allocation. Everything lives in registers during the hot loop.

The Compressor Core

The heart of the algorithm — the main loop — is remarkably compact:

_compress_loop:
    test rcx, rcx
    jz _end
    mov al, byte[rsi]       ; Read current byte
    mov dl, al              ; Save it (we'll need the original)
    sub al, bl              ; Calculate delta: current - previous
    cmp al, r9b             ; Does it match our Active Delta?
    jne _flush              ; No → flush the current run

_inc_r8b:
    inc r8b                 ; Yes → extend the run
    inc rsi                 ; Advance source pointer
    dec rcx                 ; Decrement remaining counter
    jz _end                 ; If zero → final flush and exit
    mov bl, dl              ; Update "previous" byte
    cmp r8b, 255            ; Overflow guard (max 1-byte count)
    jne _compress_loop      ; Continue scanning

The hot path — when deltas match — executes in just 8 instructions per byte. No branches taken, no memory writes, pure register operations. Branch prediction loves this because jne _flush is "not taken" for the majority of iterations in sequential data.

The Flush Mechanism

When a delta mismatch occurs, the current run is written to the output and a new sequence begins:

_flush:
    mov byte [rdi], r8b     ; Write RLE count to output
    inc rdi
    mov byte [rdi], r9b     ; Write Active Delta to output
    inc rdi

    ; Start tracking the new sequence
    mov r9b, al             ; New Active Delta = the mismatched delta
    mov r8b, 1              ; Reset count to 1 (this byte starts a new run)
    mov bl, dl              ; Update previous byte

    inc rsi
    dec rcx
    jz _end
    jmp _compress_loop

The 255 Overflow Guard

A single byte can only represent counts up to 255. When a run exceeds this limit, a "mini-flush" writes the current state and resets the counter — without changing the Active Delta:

_flush_255:
    mov byte [rdi], r8b     ; Write 255 to output
    inc rdi
    mov byte [rdi], r9b     ; Write current delta
    inc rdi
    mov r8b, 0              ; Reset counter, KEEP the same delta
    jmp _compress_loop      ; Continue — same series, new count

This ensures seamless handling of runs longer than 255 bytes — they simply produce multiple (255, delta) pairs followed by the remainder.

The Decompressor

Decompression is the inverse operation and is intentionally simpler — this is critical because in a C2 context, the decompressor runs on the client side where code complexity is less constrained, but in the agent-side PIC context, simplicity means fewer instructions and smaller shellcode.

_decompress_loop:
    test rcx, rcx
    jz _print_and_exit

    mov dl, byte [rsi]      ; Read Count
    inc rsi
    dec rcx

    test rcx, rcx
    jz _print_and_exit

    mov al, byte [rsi]      ; Read Delta
    inc rsi
    dec rcx

    test dl, dl             ; Count == 0? Skip (edge case)
    jz _decompress_loop

_write_loop:
    add bl, al              ; Apply delta: previous + delta = current
    mov byte [rdi], bl      ; Write reconstructed byte
    inc rdi
    dec dl
    jnz _write_loop         ; Repeat for the full count

    jmp _decompress_loop

The key detail is in _write_loop: the delta is applied cumulatively. Each iteration adds the delta to the running byte value. This is what reconstructs sequences like A → B → C → D from a single (3, +1) pair — not by writing B three times, but by computing A+1=B, B+1=C, C+1=D.

Performance: Compression Scenarios

Here's what to expect with real-world data on a 1GB file scale:

Scenario 1: Server Log Files (access.log)

Repeated IP addresses, timestamps with sequential seconds, identical HTTP status codes, recurring URL paths.

Expected Compression: ~40-55% reduction → ~450-600 MB output

Delta encoding crushes timestamp sequences (incrementing seconds produce delta=1 runs). Repeated structural elements (spaces, brackets, quotes) create long zero-delta runs.

Scenario 2: Random / Encrypted Binary Data

Uniform byte distribution, no patterns, no sequential relationships.

Expected Compression: 0% — data EXPANDS by ~50-80% → ~1.5-1.8 GB output

Every delta change triggers a flush, producing 2 bytes (count + delta) for almost every input byte, plus the anchor overhead. This is mathematically unavoidable — Shannon's entropy theorem guarantees no lossless algorithm can compress truly random data.

Scenario 3: Database Exports (CSV / SQL Dumps)

Sequential IDs (1, 2, 3...), repeated column names, consistent delimiters, similar numeric values.

Expected Compression: ~30-45% reduction → ~550-700 MB output

Auto-incrementing IDs produce perfect delta=1 runs. Repeated commas, quotes, and fixed-width fields compress well. Variable-length string fields (names, addresses) reduce overall effectiveness.

Versus Traditional Algorithms

Algorithm	Log File	Random	DB Dump	Dictionary?	Decode Complexity
VESQER (DPCM+RLE)	~50%	Expands	~40%	❌ No	Trivial (~15 instructions)
gzip (LZ77+Huffman)	~80%	~0%	~70%	✅ Yes	Heavy (sliding window + tree)
LZ4	~65%	~0%	~55%	✅ Yes	Medium (hash table lookups)
zstd	~85%	~0%	~75%	✅ Yes	Heavy (FSE + match finder)

VESQER doesn't compete with dictionary-based algorithms on raw compression ratio. It was never designed to. Its advantages are elsewhere:

Zero memory overhead: No hash tables, no sliding windows, no frequency tables.
Tiny code footprint: The entire compressor fits in ~100 instructions. Critical for PIC shellcode.
Trivial decompression: ~15 instructions to decompress. The client-side decoder is negligible.
No signatures: No magic bytes, no headers, no identifiable structure. The output is indistinguishable from random noise.

C2 Integration: The Real Purpose

In the Ghost-C2 project, VESQER sits in the data pipeline between command execution and network transmission:

Command Output (RAM) → VESQER Compress → Rolling XOR → ICMP Chunking → Wire

The compression step achieves two things simultaneously:

1. Reduced Wire Footprint: A ls -la output that would normally require 9 ICMP packets now fits in 5. Fewer packets = fewer detection opportunities = lower IDS correlation probability.

2. Double-Layer Obfuscation: Compressed data already has high entropy — it looks like random noise. When Rolling XOR is applied on top, the result is indistinguishable from encrypted random data. A DPI engine analyzing the payload sees no ASCII patterns, no structural markers, nothing to fingerprint.

The PIC-integrated version of the compressor is called via a simple function convention:

; RSI = Source buffer (raw command output)
; RDI = Destination buffer (compressed output)
; RCX = Input length
call _vesqer_compress
; RAX = Compressed length (new size for chunking)

All registers are preserved via push/pop, making it a clean drop-in function within the agent's execution pipeline.

The "Accidental Reinvention" Reflection

The irony isn't lost on me. DPCM was formalized in the 1950s for voice digitization. RLE dates back to the 1960s. Combining predictive coding with run-length encoding has been done in countless forms — JPEG uses a variant, video codecs use it, even fax machines used it.

But none of those implementations were written in pure x86-64 Assembly, with zero dependencies, optimized for shellcode deployment inside a fileless C2 agent running inside a hijacked cron process.

Sometimes reinventing the wheel is the whole point — when you need that wheel to be invisible.

📖 Source Code & Implementation

The complete standalone compressor and decompressor are available as open-source tools:

VESQER Compressor Repository: dpcm-rle-hybrid-x64-compressor on GitHub

Ghost-C2 (Integrated Version): Ghost-C2 on GitHub

⚠️ Legal Disclaimer

This project is created for educational purposes and security research only. The compression algorithm itself is a general-purpose tool, but its integration with C2 frameworks is discussed purely in the context of authorized penetration testing and red team operations. Unauthorized access to computer systems is illegal. The author is not responsible for any misuse of this tool.

MITRE ATT&CK: T1048 · T1027

memfd_create: Anonymous RAM Files and Volatile Storage in x64 Assembly

JM00NJ — Wed, 01 Jul 2026 11:47:48 +0000

Research Context

"In high-performance computing and modern system auditing, reducing disk I/O overhead is critical for operational efficiency. This article examines the memfd_create system call—a mechanism designed to create anonymous, volatile files that reside exclusively in RAM, providing a secure and fast alternative to traditional disk-based temporary storage."

1. The Problem with Physical Storage

Traditional temporary files (usually stored in /tmp) require disk interaction, which introduces latency and leaves a physical footprint on the storage medium. In scenarios requiring high volatility and data privacy, physical disk traces are undesirable. memfd_create solves this by providing a file descriptor that points to an anonymous file in the RAM-backed tmpfs.

2. Technical Anatomy of memfd_create

Introduced in Linux Kernel 3.17, memfd_create (Syscall 319 on x64) behaves like a regular file but lacks a permanent location on the global file system. It is invisible to standard directory listing commands like ls.

Key Characteristics:

Volatility: The data is lost immediately when the last file descriptor is closed or the process terminates.

Sealing: Using fcntl, the file can be "sealed" (MFD_ALLOW_SEALING), making it immutable and preventing further modifications—a vital feature for integrity-sensitive operations.

3. Implementation in x64 Assembly

Implementing memfd_create at the assembly level allows for a microscopic footprint and direct control over memory allocation. Below is the technical implementation of creating an anonymous file:


section .rodata

    mem_name db "system_audit_log", 0  ; Null-terminated internal label

; memfd_create(const char *name, unsigned int flags)

; RAX: 319, RDI: name_ptr, RSI: flags



    mov rax, 319            ; sys_memfd_create

   lea rdi, [rel mem_name] ; Pointer to a string label (visible only in /proc/pid/fd/)

    mov rsi, 1              ; MFD_CLOEXEC (Close-on-exec flag)

    syscall                 ; Execute

    ; Result: RAX contains the file descriptor

4. Advanced Use Cases: Observability and Logic Isolation

From a system research perspective, memfd_create is an essential tool for System Integrity Analysis:

Dynamic Payload Analysis: Safely executing and analyzing code blocks in a memory-resident environment without altering the host's disk state.

Inter-Process Communication (IPC): Sharing large data structures between processes via file descriptors without the overhead of disk synchronization.

Forensic Resilience: Evaluating how modern forensic tools detect memory-only artifacts, a crucial part of Runtime Security Research.

5. Defense and Monitoring Perspective

While memfd_create offers significant performance benefits, its "invisible" nature requires specific auditing strategies. Blue Team researchers should monitor:

File Descriptor Auditing: Inspecting /proc/[pid]/fd/ for links starting with memfd:.

Syscall Hooking: Utilizing eBPF or Auditd to track sys_memfd_create calls, especially those originating from unauthorized or non-service processes.

Conclusion

memfd_create represents a significant evolution in Linux memory management. By enabling memory-resident storage and execution, it provides researchers with a powerful tool for building high-performance, low-impact system utilities. Understanding these low-level volatile mechanisms is key to mastering both System Architecture and Modern Security Auditing.

⚠️ Legal Disclaimer

This project is created for educational purposes and security research only. Unauthorized access to computer systems is illegal. The author is not responsible for any misuse of this tool. Operating this tool on networks you do not own is strictly prohibited.

MITRE ATT&CK: T1055.009 · T1027 · T1564

Linux x64 Assembly: Syscalls, Registers, and the .bss Segment

JM00NJ — Wed, 01 Jul 2026 11:43:48 +0000

Research Context

If you are messing around with Assembly, the most direct way to talk to the processor is through the Syscall (System Call) mechanism. Opening a file, reading from a keyboard, or printing text to a terminal... it all starts with a formal request to the Kernel. Today, we are going behind the scenes to examine the open, read, and exit calls, how registers manage data flow, and why the .bss segment is your best friend for memory management.

1. The Register Dance: Who Goes Where?

In the Linux x64 architecture, before making a syscall, you must tell the Kernel exactly what you want. There is a strict protocol for this:

RAX: Holds the Syscall ID. (e.g., 0 for read, 2 for open, 60 for exit).

RDI: The 1st Parameter (Usually the File Descriptor).

RSI: The 2nd Parameter (Usually the memory address for a buffer).

RDX: The 3rd Parameter (Usually the size of the data in bytes).

Understanding File Descriptors (FD)

To the Kernel, there is no difference between a keyboard, a terminal, or a .txt file; they are all just numbers:

0 (stdin): Standard Input (Keyboard).

1 (stdout): Standard Output (Terminal screen).

2 (stderr): Standard Error.

2. Essential Syscalls: Open, Read, and Exit

To read data from a file and then shut down the program, we follow this logical sequence:

A. sys_open (RAX = 2)

Before you can touch a file, you must "open" it.

RDI: The address of the filename string (e.g., filename db "data.txt", 0).

RSI: Flags. 0 = Read-only, 1 = Write-only.

RDX: Mode (File permissions, usually used when creating a file).

B. sys_read (RAX = 0)

Once the file is opened, the Kernel returns a File Descriptor (FD) inside the RAX register. Now we can read:

RDI: The FD number returned by the previous open call.

RSI: The address of where the data should be written (Buffer address).

RDX: How many bytes to read.

C. sys_write (RAX = 1)

Now that the data is safely parked in our .bss buffer, we want to actually see it. We ask the Kernel to take that data and push it to the terminal screen.

RDI: 1 (The File Descriptor for Standard Output / Terminal).

RSI: The address of the data we want to print (our .bss buffer).

RDX: How many bytes to print.

D. sys_close (RAX = 3)

A true systems programmer always cleans up after themselves. Leaving File Descriptors open causes memory/resource leaks. Since we overwrote our RDI register during the sys_write step, we need to make sure we saved our original file FD somewhere safe (like R8) so we can close it properly.
RDI: The File Descriptor of the file we want to close (saved earlier).

E. sys_exit (RAX = 60)

When the task is done, you must tell the OS "I'm leaving."

RDI: The status code (0 usually means "everything is fine").

3. The .bss Segment: The Data "Parking Lot"

If your program receives external data (like a keyboard entry or file content), you need a place to store it. This is where the .bss (Block Started by Symbol) segment comes in.

Why use .bss instead of .data?

The .data section is for pre-defined (initialized) data (e.g., msg db "Hello"). This increases the actual size of your binary file.

The .bss section simply "reserves" space. It doesn't increase the file size on disk; it only ensures that when the program runs, the RAM reserves that much space for you.

How Data is Written to .bss

When you execute a sys_read syscall, you provide the address of a label defined in .bss to the RSI register. The Kernel then takes the bytes it reads from the file/keyboard and lays them out in memory starting from that specific address.

4. Implementation: A Minimalist File Reader

The following code opens a file, reads its content into a .bss buffer, and exits gracefully.

section .data
    filename db "test.txt", 0   ; Null-terminated string for the filename

section .bss
    buffer resb 64              ; Reserve 64 bytes for our incoming data

section .text
    global _start

_start:
    ; 1. OPEN the file (sys_open)
    mov rax, 2                  ; syscall: sys_open
    mov rdi, filename           ; 1st param: address of the filename
    mov rsi, 0                  ; 2nd param: O_RDONLY flag (read only)
    xor rdx, rdx                ; 3rd param: mode (0, clear garbage data)
    syscall                     ; Execute. RAX now contains the FD

    push rax                    ; PRO TIP: Save the FD to the stack instead of a register!

    ; 2. READ the data (sys_read)
    mov rdi, rax                ; 1st param: Move FD from RAX to RDI
    mov rax, 0                  ; syscall: sys_read
    mov rsi, buffer             ; 2nd param: destination buffer in .bss
    mov rdx, 64                 ; 3rd param: number of bytes to read
    syscall                     ; Execute. The data is now in the buffer

    ; 3. WRITE the data to terminal (sys_write)
    mov rax, 1                  ; syscall: sys_write
    mov rdi, 1                  ; 1st param: File Descriptor 1 (stdout)
    mov rsi, buffer             ; 2nd param: source buffer in .bss
    mov rdx, 64                 ; 3rd param: number of bytes to write
    syscall                     ; Execute. Data prints to the screen

    ; 4. CLOSE the file (sys_close)
    pop rdi                     ; 1st param: Pop the saved FD directly into RDI!
    mov rax, 3                  ; syscall: sys_close
    syscall                     ; Execute. File is successfully closed!

    ; 5. EXIT the program (sys_exit)
    mov rax, 60                 ; syscall: sys_exit
    xor rdi, rdi                ; 1st param: exit code 0 (success)
    syscall                     ; Execute. Program terminates cleanly

Conclusion

In Assembly, everything is about addressing and register management. Whether data comes from the terminal (FD 0) or a file is just a parameter change for the Kernel. By mastering the .bss section and syscall registers, you gain total control over how your program interacts with the system memory and hardware.

In the low-level world, every byte is under your command. Keep coding!

RFC 1071 Checksum Explained: x64 Assembly Implementation

JM00NJ — Sun, 28 Jun 2026 16:59:48 +0000

Research Context

As the development of my ICMP-based Network Communication Project continues at full throttle, today I want to talk about the most "diplomatic" part of the operation: the Checksum. If you don't stamp this seal correctly on the packet you're sending, the Target host's operating system treats your packet as a "Malformed data" and dumps it in the trash before it even gets through the door.

So, how exactly is this "seal" calculated in a low-level language? Let's examine it step-by-step through the very algorithm I wrote and currently use in my project.

🛠️ The Heart of the Algorithm: perform_checksum

The ICMP protocol uses a 16-bit One's Complement sum to ensure data integrity. This means you have to add up the entire packet in 16-bit (2-byte) chunks.

Here is what this mathematical operation looks like in the x64 Assembly realm:

Note: In this context, rdi represents the starting address of our data buffer, r14 is the starting offset, and r15 is the ending offset.


perform_checksum:

    ; RFC 1071 standard 16-bit one's complement sum algorithm

    xor eax, eax                ; Clear eax (Accumulator for the sum)

    mov r10, r14               ; r10 = Current offset

.loop:

    mov r11, r15               ; r11 = End offset

    sub r11, r10                ; Remaining bytes to process

    cmp r11, 1                  ; Check if only 1 byte is left (odd length)

    jle .last                       ; If <= 1 byte left, jump to final block



    movzx r12d, word [rdi + r10]; Read 2 bytes (1 word) zero-extended

    add eax, r12d              ; Add to accumulator

    add r10, 2                   ; Move offset forward by 2 bytes

    jmp .loop                   ; Repeat

🧩 Part 1: Gathering the Pieces

We are essentially telling the CPU: "Fetch me a 16-bit (word) chunk from memory, add it to the eax register, and move to the next 2 bytes." This loop runs smoothly until we hit the end of the packet.

⚖️ Part 2: The "Odd Byte" Paradox

If the total length of the packet is an odd number (e.g., 11 bytes), the very last byte won't have a pair to form a 16-bit word. In this scenario, our algorithm elegantly dives into the .final block:

.last:
    je .final                   ; If exactly 1 byte left, handle it
    jmp .wrap                   ; If 0 bytes left, finalize calculation
.final:
    movzx r12d, byte [rdi + r10]; Read the last remaining single byte
    add eax, r12d               ; Add it to the accumulator

🔄 Part 3: The Wrap and Carry

Mathematically, this continuous addition might exceed a 16-bit boundary. This is where the most critical aspect of RFC 1071 comes into play: Adding the overflowing bits (the carry) back into the main sum.

.wrap:
    mov r11d, eax               ; Copy sum to r11d
    shr r11d, 16                ; Shift right to isolate the carry bits
    and eax, 0xFFFF             ; Mask eax to keep only the lower 16 bits
    add ax, r11w                ; Add the carry bits back to the sum
    adc ax, 0                   ; Add any final carry (add with carry)
    not ax                      ; One's complement (invert bits) for final checksum
    ret

🎯 Why not ax?

The not instruction at the very end is the final requirement of the One's Complement logic. By inverting the bits (0 -> 1, 1 -> 0), we ensure that when the receiving end takes our packet and performs the exact same addition, the result will be 0xFFFF. If it is, the data is clean, and our seal is valid!

Conclusion

Writing this algorithm in Assembly is a fantastic exercise to truly understand how data is laid out in memory and how the CPU crunches bytes. Thanks to this algorithm, our custom ICMP packets can bypass kernel-level drops and roam the network like "official documents".

When I integrate dynamic targeting and fileless execution (memfd_create) into my Distributed management architecture, this checksum engine will remain the most reliable gear in the machine.

Stay Coded!

Building a Low-Level ICMP Sniffer in x64 Assembly (Raw Sockets)

JM00NJ — Sun, 28 Jun 2026 16:53:51 +0000

Research Context

In the realm of network security and packet analysis, tools like Python (Scapy) or C are the usual go-tos. However, when we want to strip away all abstraction layers from the OS network stack and talk directly to the processor, resources become incredibly scarce. Finding modern, zero-dependency networking tools written in x64 Assembly on the internet is almost impossible today.

In this post, we will explore the architecture and design decisions behind my x64 Assembly-based ICMP Sniffer project, completely rejecting standard C libraries (libc) and relying purely on direct Linux system calls (syscalls).

The Concept: Why Assembly?

Our goal isn't just to catch ICMP (ping) packets on the network. We want to manually manage memory, register allocations, and data type conversions (integer-to-string) at the CPU cycle level. This approach provides a flawless foundation for understanding how hardware behaves during System security auditing and low-level software analysis.

How Does It Work? (Technical Deep Dive)

The architecture of the tool is divided into three main phases:

The Raw Socket Foundation To capture raw, unprocessed packets passing through the network interface card (NIC), the application uses sys_socket (syscall 41) with AF_INET and SOCK_RAW parameters. Our target here is strictly the IPPROTO_ICMP protocol. This tells the operating system to filter out all TCP/UDP traffic and hand us only the ICMP packets.
Packet Observation and Header Stripping Incoming packets are read into a memory buffer using sys_recvfrom. Since we are using Raw Sockets, the data arrives in its absolute raw form. To reach the actual payload, we must manually bypass the protocol headers:

IPv4 Header: 20 Bytes

ICMP Header: 8 Bytes

Therefore, by utilizing the lea rsi, [sniffed_data + 28] instruction in our Assembly code, we strip away this 28-byte "noise" and dive straight into the heart of the data.

The Custom Integer-to-ASCII Engine This is the most complex and educational part of the project. The captured IP address (e.g., 192.168.1.29) resides in memory as raw binary (hexadecimal). To print this to the terminal, we must convert it into a human-readable ASCII string.

Since we aren't using any external printf or itoa functions, I designed the engine as follows:

Each octet (8-bit IP segment) fetched from the network address is divided by 10 using the div instruction.

We mathematically add 48 (0x30) to the remainders to convert them into ASCII characters.

These converted characters are written into a 16-byte memory buffer in reverse order (from end to start).

Using logical brakes via conditional jumps (je, jg), dot (.) characters are strategically inserted only between the octets to prevent malformed strings.

Conclusion and Source Code

This tool proves how we can filter not just the "existence" of ICMP packets, but the actual payloads hidden inside them (like Non-standard data structures or remote management signals) at the kernel level. Writing our own string conversion engine using nothing but Linux Syscalls, without relying on any external libraries, has been a fantastic exercise in pushing the limits of low-level system programming.

For security researchers, Blue Team members, and exploit development enthusiasts who want to test the tool or review the code, the full source is available on my GitHub profile:

🔗 GitHub Repo: JM00NJ/asm-icmp-sniffer

⚠️ Legal Disclaimer

Linux Process Evasion: ptrace & prctl

JM00NJ — Sun, 28 Jun 2026 16:49:03 +0000

Research Context

In cybersecurity research and Red Team simulations, developing custom tools requires a deep understanding of host-based evasion. When an agent lands on a target system, modern Blue Teams and Endpoint Detection and Response (EDR) solutions will attempt to attach a disassembler or a debugger to analyze the suspicious process.

How do these processes defend themselves against analysis? In this article, we will explore the technical details of how the Linux kernel's own mechanisms—ptrace and prctl—can be utilized for process self-defense, strictly using pure x64 Assembly.

1. Preventing Debuggers with ptrace

In Linux environments, tools like gdb or strace rely on the ptrace (Process Trace) system call to inspect the internal state and system calls of a process. However, the Linux kernel enforces a golden rule: A process can only be traced by one tracer at a time.

This architectural constraint can be leveraged for defensive research. If an application sends a PTRACE_TRACEME command to itself the moment it starts, it effectively blocks any external analyst or tool from attaching to it. If an attempt is made, the operating system simply returns an EPERM (Operation not permitted) error.

Here is how this logic is implemented in pure x64 Assembly:

_anti_debug:

    ; Dynamically calculating Syscall 101 to evade static analysis

    mov rax, 91         

    add rax, 10         ; rax = 101 (sys_ptrace)



    xor rdi, rdi        ; arg1 = 0 (PTRACE_TRACEME)

    xor rsi, rsi        ; arg2 = 0

    xor rdx, rdx        ; arg3 = 0

    xor r10, r10        ; arg4 = 0

    syscall



    ; Result check (If already being traced, rax returns negative)

    test rax, rax       

    js _exit            ; If negative, debugger detected! Terminate the process.

    ret



_exit:

    mov rax, 60         ; sys_exit

    mov rdi, 1          ; Exit with error code

    syscall

A key detail in the code above is that we avoid writing the sys_ptrace syscall number (101) directly into the code. Instead, we calculate it dynamically at runtime (91 + 10). This simple operation, known as Syscall Obfuscation, is a highly effective technique for bypassing static signature scans, such as YARA rules.

2. Preventing Memory Dumps with prctl

We successfully blocked the debugger, but what if an incident responder takes a core dump of the process memory? When a RAM image is captured, all dynamically resolved strings, IP addresses, or command outputs become completely visible to the investigator.

To mitigate this, we can turn to prctl (syscall 157), the process control mechanism of the Linux kernel. By passing the PR_SET_DUMPABLE argument with a value of 0 to the prctl function, we give the kernel a strict directive: "Forbid the creation of core dumps for this process at the OS level."

The implementation is quite minimal:


_disable_memory_dump:

    mov rax, 157        ; sys_prctl

    mov rdi, 4          ; arg1 = 4 (PR_SET_DUMPABLE)

    mov rsi, 0          ; arg2 = 0 (SUID_DUMP_DISABLE)

    syscall

    ret

Once this function is executed, even users without root privileges are restricted from accessing the memory of your process. When combined with a process that runs in the background (daemonized via fork) and masquerades as a legitimate system service (like systemd-resolved), this technique creates a significant blind spot for analysts.

Operational Security (OPSEC) and Conclusion

Developing a tool that secures itself by communicating directly with the kernel, without even relying on the standard libc library, elevates the code from a standard script to a work of low-level engineering.

Naturally, modern and advanced EDR solutions operating at the Kernel level (via eBPF) have the capability to intercept system calls. However, understanding and utilizing the ptrace and prctl combination is an excellent baseline technique for evading manual analysis by Incident Response teams and traditional antivirus software.

⚠️ Legal Disclaimer

Linux sends ICMP Echo with 56-byte payload + 8-byte header = 64 bytes total. Windows uses 32 bytes. NDR systems fingerprint hosts by these defaults — before any exploit lands. This post shows how to mimic any OS at the raw socket level.

JM00NJ — Sat, 27 Jun 2026 12:58:28 +0000

JM00NJ

Jun 27

Network Fingerprinting: Analyzing Default ICMP Structures and Payload Mimicry

#cybersecurity #assembly #linux #network

4 min read

Network Fingerprinting: Analyzing Default ICMP Structures and Payload Mimicry

JM00NJ — Sat, 27 Jun 2026 12:46:31 +0000

Research Context

"In advanced network observability, understanding the default behavior of various operating systems is vital for traffic profiling. This article explores the structural differences in ICMP Echo Requests across different OS environments and analyzes how 'Traffic Mimicry' can be used to evaluate the accuracy of Network Intrusion Detection Systems (NIDS)."

1. The Anatomy of an ICMP Signature

A standard ICMP Echo Request is not just a simple signal; it carries a specific "fingerprint" based on the operating system that generated it. These fingerprints consist of:

Total Packet Size

TTL (Time to Live) values

Default Payload Content

2. Cross-Platform Discrepancies (Linux vs. Windows)

When a system sends a "ping," the default data size ($D$) and the total packet length ($L$) vary significantly between architectures.

Feature	Linux (Typical)	Windows (Typical)
Data Size ($D$)	56 Bytes	32 Bytes
ICMP Header ($H$)	8 Bytes	8 Bytes
Total ICMP Length ($L$)	64 Bytes	40 Bytes
Default Payload	Timestamp + Data	abcdefg...

The Linux Signature
In most Linux distributions, the ping utility sends 56 bytes of data. When combined with the 8-byte ICMP header, it totals 64 bytes. A key characteristic of Linux ICMP traffic is that the first few bytes of the payload are often occupied by a high-resolution timestamp, used to calculate RTT (Round Trip Time) with microsecond precision.

The Windows Signature
Windows systems default to a 32-byte data payload. The payload content is static and follows a predictable alphabetical sequence: abcdefghijklmnopqrstuvwabcdefghi. This static nature makes Windows ICMP traffic easily identifiable during deep packet inspection (DPI).

3. The Concept of Traffic Mimicry

Traffic Mimicry is a research method used to test the resilience of network filters. By aligning custom communication protocols with the default signatures of a specific OS, researchers can evaluate whether a security appliance is biased toward certain traffic patterns.

For example, when developing a Remote Management Interface in x64 Assembly, ensuring the payload size ($D$) is exactly 32 bytes or 56 bytes allows the traffic to blend into the "Ambient Noise" of a corporate network.

4. Implementation: Engineering a Mimicry-Aligned Packet Structure

To evaluate the resilience of network monitoring tools, we must construct a packet architecture that adheres strictly to the structural expectations of a standard Linux environment. Below is the assembly-level definition of an ICMP Echo Reply, designed with Structural Alignment in mind.


; --- [MIMICRY UPDATE] UPDATED PACKET ARCHITECTURE ---

; This structure strictly aligns with the 64-byte Linux ICMP Echo signature

icmp_packet:

    type db 0                ; ICMP Type 0 (Echo Reply)

    code db 0                

    checksum dw 0            ; Checksum placeholder

    identifier dw 0          ; Process Identifier

    sequence dw 0            ; Internal signaling sequence



    ; --- MIMICRY PADDING (24 BYTES) ---

    ; Emulates the default timestamp behavior of modern network stacks

    mimicry_ts dq 0          ; 8-byte Dynamic Timestamp (Cycle-accurate timing)



    ; 16-byte Sequential Padding: Replicates standard OS data patterns

    mimicry_seq db 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17

                db 0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F



    ; --- DATA TRANSMISSION AREA ---

    payload times 32 db 0    ; 32-byte payload chunk to hit the 64-byte total

    payload_len equ $ - icmp_packet

Analysis of the Structural Logic
Timestamp Emulation (mimicry_ts): Standard Linux ping requests embed an 8-byte timestamp to calculate RTT. By reserving this space and populating it with high-precision timing data (via RDTSC), our custom communication layer avoids the "Empty Payload" signature that often triggers NIDS anomalies.

Sequential Byte Padding (mimicry_seq): Many network filters look for entropy in the payload. By utilizing a fixed, sequential padding (0x10 to 0x1F), we replicate the predictable data structures of kernel-level protocol implementations.

The 64-Byte Structural Boundary: By dedicating 24 bytes to structural emulation and allocating exactly 32 bytes for the data payload, the internal data segment equals the 56-byte Linux standard. When combined with the 8-byte ICMP header, the total packet size is precisely 64 bytes (8 + 24 + 32 = 64). This ensures that the traffic volume remains strictly within the expected "Ambient Noise" threshold.

5. Defensive Implications: Anomaly Detection

From a Blue Team perspective, identifying "Mimicry" requires looking beyond packet size. Advanced detection strategies include:

Entropy Analysis: Monitoring the randomness of the payload.

TTL Consistency: Checking if the TTL value matches the expected OS signature.

Frequency Analysis: Analyzing if the ICMP requests follow the standard interval pattern of a human-initiated ping.

Conclusion

Understanding the "Default State" of network protocols is the first step in advanced system auditing. Mimicry is not just about blending in; it is a critical tool for identifying the limitations of signature-based detection. By mastering the low-level construction of ICMP packets, researchers can develop more robust and observable communication frameworks.

⚠️ Legal Disclaimer

Solving IP Endianness in x64 Assembly: A Single-Pass Algorithm

JM00NJ — Sat, 27 Jun 2026 12:34:20 +0000

Research Context

When doing low-level network programming in Assembly, you experience firsthand the immense chaos running behind the scenes of operations we solve with a single line in high-level languages (Python, C, etc.). While developing the Nested-ICMP-Communication Analysis project, specifically an Encapsulated ICMP framework, I hit exactly this kind of wall: extracting an IP address from a packet header and printing it to the screen in the correct format.

Sounds simple, right? However, when x86 architecture and network protocols are involved, seeing 5.1.168.192 instead of 192.168.1.5 on your terminal is extremely common.

So why does this happen, and what kind of algorithm did I develop to overcome this issue during the debugging process? Let's dive into the background.

The Endianness Problem in Network Headers

When you capture a packet coming over the network and read the source/destination IP address inside the sockaddr_in structure, the data arrives in Network Byte Order (Big-Endian) format. This means the most significant byte is stored at the lowest memory address.

However, the x86/x64 processor architectures we use rely on Little-Endian (Host Byte Order). When the processor pulls this 4-byte IP data into a register, the reading direction is effectively reversed for our purposes.

The result? A packet that arrives as 192.168.1.5 appears scrambled if we try to naively print it from memory. The inet_ntoa() function in high-level languages handles this conversion in the background. But if you are writing a custom sniffer in pure Assembly, you must do this conversion byte by byte yourself.

Debugging Hell: The Problems Encountered

While writing this conversion, I encountered a few critical issues that cost me hours in GDB (GNU Debugger):

Register Clashes: While separating each octet (byte) of the IP address and converting it to an ASCII character (string), you must use the AX register for division operations (DIV). If you don't carefully manage your remainders (AH) and quotients (AL), the numbers of the IP address get completely corrupted.

The Dot (.) Separator: It's not enough to just convert the numbers; a . (0x2E / 46 in decimal) character must be inserted exactly between each octet, but not at the very end.

Performance Loss (The Reversing Trap): In standard logic, you parse the IP, convert it to a string, and realize the string is backwards. Then, you write a second loop to reverse that string. This creates unnecessary memory read/write cycles and bloats the code.

The Solution: A Single-Pass Backward Build Algorithm

To solve the problem, instead of creating the string and then reversing it, I designed a more optimized algorithm.

The logic is simple but highly effective: Read the IP bytes backwards, and write the ASCII string backwards. By starting at the end of the IP address within the sockaddr_in structure (offset 7 down to 4) and writing from the end of a 15-byte output buffer (addr_ip) down to index 0, the string naturally formats itself correctly from left to right.

Here is the exact critical loop from my engine:

ASSEMBLY CODE:


; IP ADDRESS TO STRING ALGORITHM (EXTRACT REVERSE BYTE-BY-BYTE AND CONVERT TO ASCII)

    xor rdx, rdx                ; Clear rdx
    xor rbx, rbx                ; Clear rbx
    mov rcx, 7                  ; Start index for reading IP from sockaddr_in (sin_addr offset)
    mov rdi, 15                 ; Start index for writing to the addr_ip buffer (backwards)
_loopforip:
    mov bl, 10                  ; Divisor for base-10 conversion
    movzx ax, [incoming_addr+rcx] ; Fetch one octet from IP address
_divloop:
    div bl                      ; Divide AX by 10; AL = quotient, AH = remainder
    add ah, 48                  ; Convert remainder to ASCII character
    mov [addr_ip+rdi], ah       ; Store ASCII character in the output buffer
    dec rdi                     ; Move buffer pointer backward
    xor ah, ah                  ; Clear AH for the next division cycle
    cmp al, 0                   ; Check if quotient is zero
    jg _divloop                 ; If not zero, continue extracting digits

    cmp rcx, 4                  ; Check if this is the last octet (first IP block)
    je _contiune                ; If last octet, skip adding the dot separator
    mov byte [addr_ip+rdi], 46  ; Insert '.' (dot) character
_contiune:
    dec rdi                     ; Move buffer pointer backward for the next octet
    dec rcx                     ; Move to the next IP octet in sockaddr_in
    cmp rcx, 3                  ; Check if all 4 octets have been processed
    jg _loopforip

This single-pass method successfully converts the raw network bytes into a human-readable ASCII string using minimal CPU cycles, entirely avoiding an extra "string reversing" loop.

Conclusion and Open Source

Network programming in Assembly might seem tedious at first, but it is a unique experience for understanding the true mechanics underlying these systems. Especially when working on tunneling architectures aimed at Evaluating IDS detection resilience, having this level of byte-control is absolutely vital.

You can find this algorithm in action, along with the complete source code of the asm-icmp-sniffer, on my GitHub profile:

JM00NJ/asm-icmp-sniffer

Disclaimer: This article and the associated source code are intended for educational purposes and authorized security research only. Understanding low-level network protocols is essential for building better defense mechanisms.

DEV Community: JM00NJ

VESQER: A DPCM+RLE Hybrid Compressor in Pure x64 Assembly

The Origin Story

The Problem: Why Compress C2 Traffic?

The Algorithm: DPCM + RLE Hybrid

The Compression Format

Walk-Through: How It Actually Works

Where It Dominates

The x64 Assembly Implementation

Register Architecture

The Compressor Core

The Flush Mechanism

The 255 Overflow Guard

The Decompressor

Performance: Compression Scenarios

Scenario 1: Server Log Files (access.log)

Scenario 2: Random / Encrypted Binary Data

Scenario 3: Database Exports (CSV / SQL Dumps)

Versus Traditional Algorithms

C2 Integration: The Real Purpose

The "Accidental Reinvention" Reflection

📖 Source Code & Implementation

⚠️ Legal Disclaimer

memfd_create: Anonymous RAM Files and Volatile Storage in x64 Assembly

Research Context

1. The Problem with Physical Storage

2. Technical Anatomy of memfd_create

3. Implementation in x64 Assembly

4. Advanced Use Cases: Observability and Logic Isolation

5. Defense and Monitoring Perspective

Conclusion

⚠️ Legal Disclaimer

Linux x64 Assembly: Syscalls, Registers, and the .bss Segment

Research Context

1. The Register Dance: Who Goes Where?

Understanding File Descriptors (FD)

2. Essential Syscalls: Open, Read, and Exit

A. sys_open (RAX = 2)

B. sys_read (RAX = 0)

C. sys_write (RAX = 1)

D. sys_close (RAX = 3)

E. sys_exit (RAX = 60)

3. The .bss Segment: The Data "Parking Lot"

4. Implementation: A Minimalist File Reader

Conclusion

RFC 1071 Checksum Explained: x64 Assembly Implementation

Research Context

🛠️ The Heart of the Algorithm: perform_checksum

🧩 Part 1: Gathering the Pieces

⚖️ Part 2: The "Odd Byte" Paradox

🔄 Part 3: The Wrap and Carry

🎯 Why not ax?

Conclusion

Related

Building a Low-Level ICMP Sniffer in x64 Assembly (Raw Sockets)

Research Context

The Concept: Why Assembly?

How Does It Work? (Technical Deep Dive)

The architecture of the tool is divided into three main phases:

Conclusion and Source Code

⚠️ Legal Disclaimer

Related

Linux Process Evasion: ptrace & prctl

Research Context

1. Preventing Debuggers with ptrace

2. Preventing Memory Dumps with prctl

Operational Security (OPSEC) and Conclusion

⚠️ Legal Disclaimer

Related

Linux sends ICMP Echo with 56-byte payload + 8-byte header = 64 bytes total. Windows uses 32 bytes. NDR systems fingerprint hosts by these defaults — before any exploit lands. This post shows how to mimic any OS at the raw socket level.

Network Fingerprinting: Analyzing Default ICMP Structures and Payload Mimicry

Network Fingerprinting: Analyzing Default ICMP Structures and Payload Mimicry

Research Context

1. The Anatomy of an ICMP Signature

2. Cross-Platform Discrepancies (Linux vs. Windows)

3. The Concept of Traffic Mimicry

4. Implementation: Engineering a Mimicry-Aligned Packet Structure

5. Defensive Implications: Anomaly Detection

Conclusion

⚠️ Legal Disclaimer