mirror of
https://github.com/vanhoefm/fragattacks.git
synced 2024-11-25 00:38:24 -05:00
fragattack: updated README
This commit is contained in:
parent
78f9833e0f
commit
25066d096d
@ -22,13 +22,22 @@ the paper also briefly discusses the applicability of the attacks against WEP.
|
|||||||
|
|
||||||
**Version 1.2 (? November 2020)**:
|
**Version 1.2 (? November 2020)**:
|
||||||
|
|
||||||
- Clarified that all commands can test both clients and APs unless noted otherwise.
|
- Tool will automatically quit after a test completed or timed out.
|
||||||
|
|
||||||
- Clarified the description of cache attacks, Broadcast fragment, and A-MSDU EAPOL attack tests in this README.
|
- Tool detects if the 4-way handshake is looping or if there is not replly to a rekey request (`--rekey-req`).
|
||||||
|
|
||||||
|
- When using an external DHCP server, the tool will now send rekey EAPOL frames with as destination address
|
||||||
|
the AP (instead of the DHCP server).
|
||||||
|
|
||||||
|
- When acting as a client, the tool will send EAPOL Rekey Request with a Replay Counter of one instead of zero.
|
||||||
|
|
||||||
- Debug output now shows the correct (group) key when encrypting broadcast/multicast frames. This does not
|
- Debug output now shows the correct (group) key when encrypting broadcast/multicast frames. This does not
|
||||||
influence any test results, it only changes the output of the test tool.
|
influence any test results, it only changes the output of the test tool.
|
||||||
|
|
||||||
|
- Clarified that all commands can test both clients and APs unless noted otherwise.
|
||||||
|
|
||||||
|
- Clarified the description of cache attacks, Broadcast fragment, and A-MSDU EAPOL attack tests in this README.
|
||||||
|
|
||||||
**Version 1.1 (20 October 2020)**:
|
**Version 1.1 (20 October 2020)**:
|
||||||
|
|
||||||
- Fixed a bug where the command `ping I,E,D` would send a normal encrypted ping request. It now sends an
|
- Fixed a bug where the command `ping I,E,D` would send a normal encrypted ping request. It now sends an
|
||||||
@ -157,7 +166,7 @@ to manually copy `htc_7010.fw` and `htc_9271.fw` to the appropriate directory.
|
|||||||
|
|
||||||
After installing the patched drivers and firmware you must unplug your Wi-Fi dongles
|
After installing the patched drivers and firmware you must unplug your Wi-Fi dongles
|
||||||
and **reboot your system**. The above instructions have to be executed again if your
|
and **reboot your system**. The above instructions have to be executed again if your
|
||||||
Linux kernel gets updated or if the driver patches get updated.
|
Linux kernel gets updated or if the patched drivers get updated.
|
||||||
|
|
||||||
Note that even when your device works out of the box, I still recommend to install the modified
|
Note that even when your device works out of the box, I still recommend to install the modified
|
||||||
drivers, as this assures there are no unexpected regressions in kernel and driver code.
|
drivers, as this assures there are no unexpected regressions in kernel and driver code.
|
||||||
@ -524,7 +533,7 @@ All commands work against both clients and APs unless noted otherwise.
|
|||||||
| `ping I,E,F,AE` | Variant if no data frames are accepted during the rekey handshake.
|
| `ping I,E,F,AE` | Variant if no data frames are accepted during the rekey handshake.
|
||||||
| `ping I,E,F,AE --rekey-plain` | If the device performs the rekey handshake in plaintext.
|
| `ping I,E,F,AE --rekey-plain` | If the device performs the rekey handshake in plaintext.
|
||||||
| `ping I,E,F,AE --rekey-plain --rekey-req` | Same as above, and actively request a rekey as client.
|
| `ping I,E,F,AE --rekey-plain --rekey-req` | Same as above, and actively request a rekey as client.
|
||||||
| `ping I,E,F,AE --rekey-early-install` | Install the new key before receiving/sending message 4.
|
| `ping I,E,F,AE --rekey-early-install` | Install the new key after sending message 3 of the 4-way handshake.
|
||||||
| `ping I,F,BE,AE --freebsd` | Mixed key attack against FreeBSD or similar implementations.
|
| `ping I,F,BE,AE --freebsd` | Mixed key attack against FreeBSD or similar implementations.
|
||||||
| <div align="center">*[Cache attacks (§5)](#id-extended-cache)*</div>
|
| <div align="center">*[Cache attacks (§5)](#id-extended-cache)*</div>
|
||||||
| `ping I,E,R,AE --freebsd [--full-reconnect]` | Cache attack specific to FreeBSD implementations.
|
| `ping I,E,R,AE --freebsd [--full-reconnect]` | Cache attack specific to FreeBSD implementations.
|
||||||
@ -582,8 +591,8 @@ these alternative mixed key attack tests. Some remarks:
|
|||||||
- `ping I,E,F,AE --rekey-plain --rekey-req`: This particular combination is useful to test routers that use a MediaTek
|
- `ping I,E,F,AE --rekey-plain --rekey-req`: This particular combination is useful to test routers that use a MediaTek
|
||||||
driver. These routers perform the rekey handshake in plaintext, and the client can actively request a rekey handshake.
|
driver. These routers perform the rekey handshake in plaintext, and the client can actively request a rekey handshake.
|
||||||
|
|
||||||
- `ping I,E,F,AE --rekey-early-install`: A low number of clients and APs (incorrectly) install the key too early during
|
- `ping I,E,F,AE --rekey-early-install`: A low number of clients (incorrectly) install the key too early during
|
||||||
a pairwise session rekey. To reliably test these devices, add the `--rekey-early-install` parameter.
|
a pairwise session rekey. To reliably test these clients, add the `--rekey-early-install` parameter.
|
||||||
|
|
||||||
Finally, in case the test `ping-frag-sep` doesn't succeed, you should try the following mixed key attack test:
|
Finally, in case the test `ping-frag-sep` doesn't succeed, you should try the following mixed key attack test:
|
||||||
|
|
||||||
@ -813,10 +822,9 @@ Frequencies for channels that are _not_ marked as disabled, no IR, or radar dete
|
|||||||
conditions may depend on your network card, the current configured country, and the AP you are
|
conditions may depend on your network card, the current configured country, and the AP you are
|
||||||
connected to. For more information see, for example, the [Arch Linux documentation](https://wiki.archlinux.org/index.php/Network_configuration/Wireless#Respecting_the_regulatory_domain).
|
connected to. For more information see, for example, the [Arch Linux documentation](https://wiki.archlinux.org/index.php/Network_configuration/Wireless#Respecting_the_regulatory_domain).
|
||||||
|
|
||||||
Although I have not yet encountered a device that behaved differently in the 2.4 GHz band compared
|
Note that a device may use different drivers to handle the 2.4 and 5 GHz band. As a result, it is
|
||||||
to the 5 GHz band, this may occur in practice if different drivers are used to handle both bands.
|
important to test devices in both these bands, since a device may behave differently depending on
|
||||||
If you encounter such a case please let us know. Since I have not yet observed such differences
|
which frequency band is being used.
|
||||||
between the 2.4 and 5 GHz band I believe that it is sufficient to only test one of these bands.
|
|
||||||
|
|
||||||
Note that in mixed mode the Linux kernel may not allow the injection of frames even though it is
|
Note that in mixed mode the Linux kernel may not allow the injection of frames even though it is
|
||||||
allowed to send normal frames. This is because in the function `ieee80211_monitor_start_xmit` the kernel refuses
|
allowed to send normal frames. This is because in the function `ieee80211_monitor_start_xmit` the kernel refuses
|
||||||
|
Loading…
Reference in New Issue
Block a user