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!