There was a project on GitHub that (was going to, if it hadn't been abandoned) modify TCP fields in order to evade packet sniffing. It explains in specifics how this would work here. In particular, this is what's specified:

  1. packets with a short time to live (TTL).

this technique obtains the objective manipolating the ttl of the packet the ttl chosen is a random one shorter than the one requested to get to the destination.

the real ttl value is calculated at regular intervals using an optimized algoritm based on the traceroute.

  1. packets with bad ip options.

this technique obtains the objective manipoulating the IP and TCP header options of the packet;

here, following some RFC guidelines and exploiting the differences between various operative systems we use some particular invalid ip option leading the destination to drop the packet.

every ISP treat the IP options in different ways. as explained in the location autodetect, and the configuration file iptcp-options.conf describe which kind of IP/TCP options will be accepted in our ISP, and which possibility you have to use them to scramble the packets.

Some IP options is rejected with an ICMP parameter problem (and this is a problem!), some other are discarded by the remote host (and this is an useful scramble, because the sniffer will not know if the IP option has been accepted or not), some options are not accepted in proposed twice in the same header, and some options is not accepted on a specific status of the session. This combos are automatically tested and used in the best combinations during the obfuscation.

  1. packet with bad tcp checksum.

this technique obtains the objective altering the tcp checksum of the packet;

this is probably one of the oldest technique conceived and it's mantained only for this reason because it has also some drawbacks.

in fact, while working with quite all destinations, this tecnique altering the checksum leads quite all tcp implementation to a windows resize causing performance degradation.

I guess my question is, do these concepts work? I don't know why this project died all those years ago, but do the concepts behind it's fruition stand today?

  • ... yes, by making your own network protocol, you can "fool" sniffers that expect TCP. That's not a surprise. However, a VPN or Tor would be a better and more robust method.
    – schroeder
    Oct 25, 2023 at 19:13
  • This is true, but I'm talking about using TCP, but scrambling it so that third-parties are confused by the packets.
    – R-Rothrock
    Oct 25, 2023 at 19:17
  • But this project modifies TCP, thereby creating a new protocol. You need a client and server to make this work. This wouldn't work well as a robust solution. Obfuscation and custom network protocols require a lot of testing. People would more likely to use tested and robust solutions instead.
    – schroeder
    Oct 25, 2023 at 20:30
  • @schroeder I didn't paste all the website archive, since there's a lot of text, but it states that Alice can talk to Bob, but packet sniffing can't. This is all done explicitly within the laws of TCP, or at least it is in theory, or it was back then. My question is whether this, in any case, is plausible. I encourage you to peruse what remains of the website, since I can't post it all here.
    – R-Rothrock
    Oct 25, 2023 at 23:19
  • I did read the site. It actually violates TCP rules, which is why sniffers fail to interpret the stream. So, by violating TCP rules, it creates a new protocol based on TCP. And so all my other comments apply. The answer is "of course it can work". As to why we don't do this, I've covered that above, too.
    – schroeder
    Oct 26, 2023 at 8:26

1 Answer 1


... do these concepts work?

It depends.

DPI solutions are usually designed for speed, so they often check only few things about the traffic and ignore the rest. This means they might not check if the packet in question will reach the final target application at all, or if it might be discarded earlier due to a short TTL or discarded at the targets network stack due to a wrong checksum.

But, with a fairly simple traffic normalization with a stateful packet filter these "defects" might be removed by discarding packets with wrong checksum and enforcing a minimal TTL value before doing the DPI analysis and forwarding the traffic.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .