Say you set --auto-ttl to 4.
If the TTL distance to the destination host is too short, say 6, auto-ttl
would decrease it by 4 and send a fake packet with TTL 2, which is too low
for the packet to travel via DPI system.
But if you set --auto-ttl to a lower value such as 2, that may introduce
issues over long lines where outgoing-path TTL and incoming-path TTL may have
difference more than 2 hops due to higher chance of assymetric routing along
the path.
To solve this issue, this commit introduce auto-ttl range of two values.
If the incoming TTL distance is more than autottl2, it is subtracted by
autottl2 value.
If the distance is less than autottl2, the distance value is used as a
normalized weigth of [autottl1; autottl2] scale.
The simplified formula is as follows:
128 > extracted_ttl > 98: // Server is running Windows
nhops = 128 - extracted_ttl
64 > extracted_ttl > 34: // Server is running Linux/FreeBSD/other
nhops = 64 - extracted_ttl
if (nhops - autottl2 < autottl2)
ttl_of_fake_packet = nhops - autottl1 - trunc((autottl2 - autottl1) * ((float)nhops/10));
else
ttl_of_fake_packet = nhops - autottl2
This is a per-connection (per-destination) automatic TTL adjusting feature.
Basically a --set-ttl mode where you don't need to set specific TTL value.
It works as follows:
1. All incoming SYN/ACKs (the response to client's SYN) are intercepted
2. TTL value is extracted from SYN/ACK
3. New TTL is calculated with the simple formula:
128 > extracted_ttl > 64: // Server is running Windows
fakepacket_ttl = 128 - extracted_ttl - decrement
64 > extracted_ttl > 34: // Server is running Linux/FreeBSD/other
fakepacket_ttl = 64 - extracted_ttl - decrement
4. Fake packet is sent
To comply with the multi-path multi-hop server connections
where 1 hop dispersion is not rare, decrement should be at least of
value "2", which is the default.
The patch does not process "too strange" TTL values (bigger than 128,
less than 34).
