OK, I'm new to this, so bear with me

Question 1: Wouldn't lines 4 and 6 of the manipulated traceroute put up a red flag?

4 core3-g2-0.snfc21.pbi.net (206.171.134.130) 9.467 ms 8.700 ms 9.152 ms
5 rback23-fe2-0.snfc21.pbi.net (216.102.187.149) 14.432 ms 20.435 ms 16.546 ms
6 core4-g3-0.snfc21.pbi.net (216.102.187.130) 0.883 ms 0.594 ms 0.427 ms

Correct me if I'm wrong, but I can only see two reasons to have the same IP twice in a traceroute.

1) Misconfigured router sending traffic back though a place it's already been (most likely resulting in a fun looping situation)

2) A manipulated response that shows traffic going back through the same router to find the fake destination. Granted, this wouldn't ALWAYS be the case, but it would most of the time (unless the target happened to pick a fake destination inside his same ISP, for example).


Question 2: Do the traceroute results show the IP the request went to, or the IP sent back when the TTL=0? I am assuming it is the IP sent back with the timeout (otherwise hop 6 would show the target ip).


So it looks to me like everything past hop 5 would be the same results as a separate tracert from the taget computer to the fake destination IP. The target computer simply stops the ICMP packet and adds the next hop of the latter (fake) tracert one at a time.


Question 3: Is there a way that the program can tell what hops happened before the request got to the target so it can remove any duplicate hops? It looks like the program removed one duplicate (line 5 should be there twice since that IP is both the last hop before the target and is ALSO the first hop from the true target on the way to the fake target). Without doing it's own tracert to the source IP, can you know the entire path of the trace (all IPs), or can you only determine the IP source of the tracert and the IP from the 1 previous hop (since that's the immediate IP that forwarded the packet to you)?

4 core3-g2-0.snfc21.pbi.net (206.171.134.130) 9.467 ms 8.700 ms 9.152 ms
5 rback23-fe2-0.snfc21.pbi.net (216.102.187.149) 14.432 ms 20.435 ms 16.546 ms
6 core4-g3-0.snfc21.pbi.net (216.102.187.130) 0.883 ms 0.594 ms 0.427 ms

If you can only know the source IP and the IP of the 1 previous hop, I can see how one wouldn't be able to remove the duplicate line 6. However, wouldn't it be a smart idea if the program resolved the hostname of the one previous IP (hop 5 in this case - "rback23-fe2-0.snfc21.pbi.net)", determined the TLD as pbi.net, and then removed all pbi.net hops in the secondary tracert that it appends to the first request? That would avoid a great deal of duplicate routers.

Anyway, I'm rambling. Just found this topic interesting!