commSync

That said, I acknowledge that the rules are effective against the default public build, and realistically most users of this tool would compile it as-is without modifying the constants. For that threat model; script kiddies and unsophisticated actors, the detection logic is valid and useful. The original evasion claims hold specifically against a hardened, operationally configured deployment, not the out-of-the-box version.

Hi M., Thank you for the detailed response. One correction regarding your Type 7 detection: "istream starts with a reply packet > malicious". Looking at the source directly, the agent's very first action is to send an Echo Request (not a Reply): asm ; --- First Beacon hello packet --- mov r12, 0 ; Empty payload call [rbp + 0x3010] ; VTable → _icmp_send (Echo REQUEST) _sniff: call [rbp + 0x3008] ; Now enters recv loop The istream begins with a Request from the agent. Type 7 would not trigger on a legitimate ICMP-Ghost session; it either produces a false negative here, or your test PCAP was replayed in a way that altered the packet ordering. Regarding VESQER: this is not a known third-party library. It is a custom DPCM+RLE hybrid compression algorithm I wrote from scratch in pure x86-64 Assembly, with zero external dependencies. The compression format has no public specification or magic bytes. Even if an analyst XOR-decrypts the payload (the key is public — 0x42, +0x07 per byte), they get compressed data in an undocumented custom format with no standard tooling to decompress it. Two layers of obscurity, not one. Finally, on scalability: PacketSmith operates on offline PCAPs. In enterprise environments processing tens of thousands of ICMP packets per second, per-stream behavioural correlation becomes computationally impractical for live traffic. The detection works well for forensic post-mortem analysis, but not as a real-time prevention mechanism, which is where the original evasion claim stands. Best regards, JM00NJ

Hi, I'm the author of ICMP-Ghost. Good analysis overall; you correctly identified the RDTSC high-bits constraint and the asymmetric ID+SEQ authentication. These are real structural fingerprints. However, I'd push back on the conclusion that these rules defeat the evasion claims: All rules target the default public build constants. Changing three values; the auth sum (45000/55000), the mimicry padding sequence, and the DNS fake domain breaks every rule you've written. That's a 5-minute recompile for any operator. More importantly, the VTable protocol pivot (!D/!I) is completely invisible here. An operator who pivots to DNS mid-session and changes the default chunk size produces traffic none of these rules match. The XOR key (0x42, +0x07) is also hardcoded and public — but your rules don't decrypt the payload to inspect plaintext commands. That would be the harder, more robust detection approach. These rules detect the toy/demo build, not a hardened operational variant. The evasion claims hold against production deployments. JM00NJ