The fact that a request with a TTL smaller than 12 does not trigger a response does not mean the responder is the host after 12 hops. Assuming none of the previous hosts misbehaves (they could be increasing or at least not decreasing the TTL) you can only conclude that it is none of the later hosts, but it can still be any of the previous ones.
That leaves you with Comcast AND China Unicom hosts and, considering that the replies you see in the traceroute results can easily be spoofed, it can be any third party as well.
Possible scenarios include (I don't say they are more likely):
1. Comcast is producing the responses, but only does so if the request TTL is large enough to make you blame China Unicom.
2. China Unicom hands the packets over to a third party after just a few hops in their backbone. The third-party sends ICMP Time exceeded messages looking like they are from other China Unicom hosts to make you blame China Unicom.
Conclusion: This is either an obvious attack from within the China Unicom backbone OR a more sophisticated attack where the attacker wants to a) hide his identity and b) blame China Unicom for it (I can't think of a scenario where b) would be a by-product and not on purpose).
Just saying. The sentences in the post that include the words "prove" and "proven" are simply wrong.
The fact that a request with a TTL smaller than 12 does not trigger a response does not mean the responder is the host after 12 hops. Assuming none of the previous hosts misbehaves (they could be increasing or at least not decreasing the TTL) you can only conclude that it is none of the later hosts, but it can still be any of the previous ones.
That leaves you with Comcast AND China Unicom hosts and, considering that the replies you see in the traceroute results can easily be spoofed, it can be any third party as well.
Possible scenarios include (I don't say they are more likely):
1. Comcast is producing the responses, but only does so if the request TTL is large enough to make you blame China Unicom.
2. China Unicom hands the packets over to a third party after just a few hops in their backbone. The third-party sends ICMP Time exceeded messages looking like they are from other China Unicom hosts to make you blame China Unicom.
Conclusion: This is either an obvious attack from within the China Unicom backbone OR a more sophisticated attack where the attacker wants to a) hide his identity and b) blame China Unicom for it (I can't think of a scenario where b) would be a by-product and not on purpose).
Just saying. The sentences in the post that include the words "prove" and "proven" are simply wrong.