Hacker circles circulate in places fragmented and carelessly set out information about the technology of "super-weapons" (so to speak) to fight against NAT s of all kinds and even standing in cascade in any quantity; as well as with any kind of other obstacles for the peer-to-peer communication - except one, which I will say at the end.

The technology is simple in understanding: let's say X and Y can learn from STUN each of their own external address, but this is not enough for them to communicate, because both sit for two - in the sum of four - NAT , besides symmetrical (they do not make their way with the help of the STUN hint) .. What should I do? Drive traffic through TURN - it will be either slow and thin stream, or not free, and in all cases it is not safe, plus often you need complex authentication, account creation, linking mail, sometimes phone, filling out forms, etc. - admire this all, for example, at numb.viagenie.ca .. Tunneling over IPv6 rarely rarely possible. his support is scanty, as you can see if you have access to honest statistics.

So, how to be? This is the technology itself: client X sends a request to any non-suspecting system administrator's public resource — google.com, mail.ru, fb.com, etc. — and replaces (spoof) IP and TTL in the package sent:

  1. instead of the client’s IP X, the client’s IP fits when sending it,
  2. the lifetime of the packet, TTL , is set up microscopically so that the packet is guaranteed to die without reaching any of the servers at all ,
  3. when the package dies two steps away from the starting point, an ICMP package will appear with a mournful cry about its death - and it will be sent to ... - no, not where you think - and it will be sent to the address that was entered when sending - that is, on client IP ,
  4. arriving at client Y, the burying packet does not just tell the address and port of the person who sent it (these IP:порт client X IP:порт will write the kamikaze request to the 16 bytes of the payload, and the ICMP obliged to repeat these bytes in RFC in the body), and in addition to the hint, it also “walks the way” for the subsequent connection of X and Y, will bring keep-alive , so to speak.

And, as you understand, if it is done infrequently, but only for “building bridges” at the beginning of X and Y communication, then the system administrators of the provider will have no reason to cut off the ICMP traffic for you. Actually only the complete chopping off of ICMP personal to you and can break off this technology. Everything else is not able to resist it.

SO, NOW LET HOW TO POSITION YOUR QUESTION:

I am writing a C ++ Qt5.7 (QtCreator, MinGW, Windows 10 x64) application that implements the functionality that I described above. Since in Windows, after XP SP3, the substitution of the sender's address by another IP is impossible without installing WinPcap , then the actual question is - show me how to do two things:

  • create an installer for a Qt application and in this installer register the WinPcap installation along with the Qt application itself - of course, with elevated privileges, i.e. from the Administrator,
  • how, having connected WinPcap in the project headers, to assemble (craft) UDP/IP kamikaze packet, as I described above, with a spoofed IP .

    1 answer 1

    Where you just read it. Do not read such resources anymore ... Better get a competent book on the structure of networks.

    1. NAT is not a network filter, but an address spoofing system. If the provider is a NAT, then there are not enough real people. And if so, then for whatever technology you send the package to such an ip provider stupidly will not know which of the clients to transfer it. After all, the basis of any NAT is memorization of established sessions. Here you send a packet to google port 443 from your internal ip (we are silent about the substitution) from port 12345. The provider changes your IP to a certain one from its pool and changes the port of the sender to 32000 and at the same time remembers that any packets received on port 32000 from google (from where ip was sent) you have to send client X to port 12345. If a packet comes from outside to any other port for which this state was not remembered, then this packet will be destroyed, since it will not be clear who will send it.

    2. Any little bit competent provider on the network filter first of all blocks any packets coming from subscribers with any outgoing IP that were not issued to the subscriber. So a packet with a spoofed IP will be killed on the first router on the way (and in some cases directly on the switch where the subscriber is on). Yes, in addition to this killed silently, without the formation of ICMP. There are no such locks only on inter-operator channels (and even then not always).

    3. The concept of keep-alive exists only for protocols with a settable connection. There is no such thing for ICMP packets. An ICMP packet is not physically able to "pave the way." Except if this ICMP is say a ping request and falls under the general NAT scheme.

    • Comments are not intended for extended discussion; conversation moved to chat . - Nick Volynkin ♦