Virtual interfaces aren't necessary, and would be overkill. All he needs on his server is to listen on a raw network socket, read the incoming packet's IP TTL value, then forge and send an ICMP "time exceeded" response with the source IP address set to a value that depends on the TTL. The entire thing could be done in 20-30 lines of Python.

Next to that he set up a DNS server configured with PTR records that map these forged IP addresses to arbitrary hostnames of his choices.

For maximum 'performance' you can do it in-kernel with eBPF :^) https://github.com/simmsb/traceroute-spoof

Sure, another way to do it, though the python would have to get the peer address, extract 64 bits of the incoming msg, table lookups of hop count -> forged address, decrement hop counts, etc. A shell script creating virtual interfaces and routing wouldn't likely be much longer than 20-30 lines either.

There is no need to do "table lookups of hop count" or to "decrement hop counts". The IP TTL value is just a field that can be read from the IP header, which is trivial since the Python would get the entire IP header from the raw socket. If you see a TTL=1 you send back the forged response as coming from $IP_1, if you see a TTL=2 you forge the response as coming from $IP_2, etc. The forged response can always contain the same default TTL.

> table lookups of hop count -> forged address

>> There is no need to do "table lookups of hop count"

>> If you see a TTL=1 you send back the forged response as coming from $IP_1, if you see a TTL=2 you forge the response as coming from $IP_2

You're describing a table lookup of the forged address using the hop count.

Right, I understand you now.

traceroute(1) uses the IP Time-To-Live (TTL) field, not network latency. So just a bunch of virtual interfaces on a suitable *nix should be enough.

Ah, right, hop count ceiling and decrement from each hop.

Specifically timed latency might be fun to delineate sections for the viewer though.