DEV Community: JM00NJ

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

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.

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

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

Related

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

Research Context

The Endianness Problem in Network Headers

Debugging Hell: The Problems Encountered

The Solution: A Single-Pass Backward Build Algorithm

ASSEMBLY CODE:

Conclusion and Open Source

Related