SniffJoke actually implements three scramble techniques.

These technique is required to desynchronise the sniffer flow from the real one. They would act in two ways: bring the sniffer to accept an invalid packet, or bring a sniffer to discard a valid packet.

Also the way this objective is achieved is quite the same in all the threee methods: create a packet accepted into the tcp session that would be easily dropped by the destination or that will never come to.
This is the basic principle that permits sniffjoke to work, leading the sniffer to believe in fake session close, packets with fake data and so on (attack details explained in plugin and attack type.
 

Ordered by the actually tested strongness we could have:

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.

2) 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.

3) 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.