Most Wi-Fi attacks rely on some kind of packet injection. This could be in the form of injecting deauth packets, arp packets, etc.

I have a question about these fake packets -- Are they constructed from scratch by the wireless network interface card? Or are they just clones of captured packets --- i.e., mere modifications of certain packet fields in already existing packets?

Looking at the TCP/IP stack, a packet typically gets built step by step at each layer; with each layer adding something to it. This makes me think that a NIC card, by virtue of operating at layer 2, would not build a full packet on its own. Any thoughts?

1 Answer 1


So, I'm going to say for this it works by understanding the protocols in place. I think that's going to be the only real answer for this question. See why below.

Basically packet injection is beacons that contain faked or generated packet details. Usually involving details from the iv or arp data you can pull in passive sniffing. Some tools allow you to try to get data such as ivs from launching other attacks, who would have guessed.

This site (or google yourself) shows an example of manually forging wireless beacons: www.4armed.com/blog/forging-wifi-beacon-frames-using-scapy/

Which is largely similar to whats done in aireplay: github.com/aircrack-ng/aircrack-ng/blob/db3e34dfb6bac7df69b6a05146ddfe57fe60a25b/src/aireplay-ng.c

In cases like this deauth attack, it builds a frame beacon that requires the generic broadcast mac. This is a known, hardcoded thing so it's easy to identify. Then sends this beacon. It's knowledge of the protocol that will help here, because (depending on implementation tbh) some cases routers will allow clients to deauth without requiring ivs. However, note the code for aireplay does provide the ability to use known ivs and replay them against the router. If you hit one system and one router, and tell them both to disconnect, you can usually just time attack it until it succeeds.


This previous example goes into details on why this beacon works, but tldr, it's a beacon you can send to your router, router says "okay, toodles" and kills its end of a session. At the same time, you kill the clients doing the opposite. Most situations you'd want to tell the client to disconnect from the router, or send the corresponding details to both.

The fakeauth tool on aireplay is a little more detailed in that it has to try a few more things. This can also be done in scapy, or really any language. The card doesn't necessarily handle this creation, the os or the program does (not to discredit the driver or the hardware, just not really relevant where it's created). Directly building these beacons in this sense is easier than rewriting an entire library just to handle the entire stack though. All you really need to worry about is your operating system's ability to handle these requests. However, as far as a layer by layer thing, I've actually come across debate to whether wireless communication is layer 1 or layer 2. either way, the idea behind the physical connection being the radio waves and the 802.11x or similar authentication stuff will be layer 2. This beacon, can contain arp packages and move the chain up to layer 3. With all that said again, protocol knowledge will help.

Other examples: github.com/cyrus-and/zizzania/tree/master/src

Some people actually drop their own handlers for ieee802*. In which they built the compatible hex codes so they can be used accordingly.

The IEEE does provide standards documentation that details how to form your requests, this also gives you the baseline for researching these functions: standards.ieee.org/getieee802/download/802.11ad-2012.pdf

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .