The idea to create a pocket tool for WiFi network analysis came to me .
Thanks to them for the idea. I had just the right amount of free time.
All the work was done as a hobby to enjoy and expand my knowledge in network technologies. Slowly, for 1 to 4 hours a week, since the beginning of this year.
I wasn’t planning on applying it practically. That is, this is NOT a tool for hackers.
At the moment, all the intended functionality works. All source files, fully ready for compilation, . There is also an assembly guide and more. In this note, I won't duplicate the information posted on GitHub. I’ll only mention what I think is necessary to describe separately.
My opinion on the "universal tool" and the reason for choosing ESP32
I do not claim to hold the truth. Everyone has their own. I will try to justify my choice of hardware.
combines Linux (originally Raspberry Pi) + peripherals like a controller (STM32) + CC1110 (8051 core) and plans to fit everything possible (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) seemed unsuitable for me. However, seems to remain private and closed (flipper-zero github "This organization has no public repositories.") and I decided to go for less common hardware.
Perhaps I am wrong, and in the future, the authors will release the software source code to the public. But if they don't, I wouldn’t want to buy such hardware without the source code.
My requirements for the "tool"
The box should be small (the smaller, the better).
Therefore:
- A built-in battery is not needed. With currents > 100 mA while working with WiFi, a built-in battery will either be large or won’t last long. So let the "box" be powered by a standard power bank. I always have a power bank in my pocket/car.
- Keeping Linux with tools inside the "box", written over many years in all languages with a small screen and a limited set of controls makes no sense. Results can be viewed/processed on a normal laptop with a full keyboard and screen.
- The components must be readily available and well-known (accessible SDK, plenty of examples and documentation).
As a result, for me, the choice was obvious — ESP32.
The capabilities of the ESP32 are quite sufficient for all the tasks mentioned in the article that prompted me to take action. Although the maximum I want to do is:
- Play around with Bluetooth.
- Experiment with the 433mHz range using the simplest hardware (just amplitude modulation, which is enough for practical needs).
A downside of the ESP32
- The ESP32 SDK (IDF) is somewhat awkward.
- Some features (like the WiFi stack, for example) come without source code in the form of compiled static libraries.
- The 5GHz range is not supported, and there are some limitations and quirks with WiFi connectivity.
But the price/size compensates for these drawbacks quite well.
Main software functionality
I will briefly describe the functionality and my opinion on...
Managing settings and uploading files from the SD card
All external management is done through a simple web page, launched from a separate menu item. The ESP32 operates in WiFi AP mode and serves a page at a fixed IP address.
Although the cores of the ESP32 are quite fast, experiments have shown that running the built-in web service simultaneously with, for example, router mode does not work well together. Therefore, dynamic management is not available, and in all other modes, the page is inaccessible.
Moreover, dynamic management is not needed for research purposes.
Beacon packet operation mode
The modes are mundane and not very interesting. They are implemented 'just because they can be done'. For the sake of formality.
Examples are available in the official Espressif examples.
AP scanning mode.
In fact, any smartphone can do this.
Well, in this mode, it will also save the AP list.
Beacon spammer.
The ESP32 starts as an AP with a hidden SSID and random MAC address, and begins sending [beacon frame] from a pre-created list of SSIDs (created manually or obtained earlier during the AP scanning).
WiFi packet sniffing mode
Espressif developers added the ability for application software to receive all WiFi packets 'flying in the air' through a callback function. In reality, not all packets are captured, as it is possible to set the mode for only one fixed channel.
The processing of callback function calls is subject to very strict time constraints. While this poses no problems for the simple statistics gathering mode, significant effort was required to organize the writing of PCAP files to the SD card using in-memory queues and semaphores. Given the particularity that the process invoking the callback runs on one core while the process writing to the SD operates on another.
In a 'noisy environment', some packets are lost (there's no space in the queue and they're discarded), but under typical evening 'environment' conditions in an apartment (5 to 7 APs in sight), writing to the PCAP succeeds without packet loss.
Additionally, for monitoring and recording PCAP, there is a filtering mode based on a MAC address list in the packet headers.
For example, you can track the appearance of a person in a club/café before they even entered or became visible. Few people turn off WiFi and automatic connections to known APs. (I do now...)
Viewing recorded traffic in Wireshark is enlightening and interesting for understanding how all this works.
Operation mode with deauth packets
By default, the sending of these packets is prohibited in the libnet80211.a library, which is provided without source code. However, it is not difficult to tweak a couple of bytes. Initially, I doubted whether to publish the patch. But after visiting various places with the source sending [deauthentication frame] scan mode enabled, I thought: 'why not'. Especially since the sending of these packets is not locked in esp8266, and there are builds available on GitHub for esp8266.
In many places (I won't say where), unwanted AP suppression is implemented using this method. And these are not just 'vandalism'…
I was still surprised that my internet sharing from the phone occasionally doesn't work…
The mode of tracking the count and RSSI of such packets is very useful to understand 'where they don't like foreign APs'.
Router mode
This feature is probably the most interesting of all for research.
ESP32 supports simultaneous operation in STA + SoftAP mode. Therefore, it can be implemented as a classic NAT router.
To support the network stack, Espressif uses a fork (virtually unchanged) of the lwip library.
However, by default, in the standard build, the esp-lwip library does not provide forwarding between the 'ap' (SoftAP) and 'st' (STA) netif interfaces.
It is certainly possible to do without NAT, but a problem arises when trying to connect two or more STAs to the ‘ap’ interface and synchronize the IP addresses from the ‘st’ network interface to the ‘ap’. So the difficulties are not worth it and it's easier through NAT.
Moreover, there is a fork of esp-lwip by martin-ger that adds a simple implementation of NAT for IPv4.
Although I was tempted to redo it purely cosmetically (in my opinion, it would have been easier without forking the project, but through LWIP),HOOK functions defined at build time), but laziness won and the version from martin-ger is used as is.
In router mode, incoming and outgoing IPv4 traffic can be viewed.
In particular, it extracts for display on the screen and collecting statistics in a file:
- The name of the device that connected to the ESP32 SoftAP (DHCP packets)
- URLs from DNS queries (UDP port 53) from the device connected to the ESP32 SoftAP.
Additionally, you can enable traffic recording to a PCAP file.
This mode is very useful, for example, to understand what your phone is sending to the network and where it is going.
Other ways to use this mode can be thought of, considering the ability to fully programmatically control incoming and outgoing traffic of the ESP32 SoftAP at the network interface level: Ethernet header (destMAC[6]+srcMAC[6]+type[2]) + payload (IPv4, IPv6, DHCP, etc. type).
In principle, the ESP32 manages the function of a WiFi->WiFi router well, passing ordinary traffic through without significant delays. Subjectively, delays on the phone connected through the router on ESP32 are not noticeable.
Unfortunately, the Espressif API does not allow setting a filter by MAC for devices connecting to the ESP32 SoftAP. Instead, it offers to say "goodbye" (esp_wifi_deauth_sta) to already connected STAs that are "undesirable."
MAC filtering for connecting STAs had to be done by calling esp_wifi_deauth_sta()
In conclusion
Although I haven't come up with anything new in working with the ESP32, perhaps someone will find the result (source code) interesting.
I would like to note that I wrote the code exclusively for educational purposes. It was intentionally made not very user-friendly for use in "hacking" and so on.
I did not create a printed circuit board, as it took about 1.5-2 hours to solder ready-made boards with wire.
And if I were to make one, it should not be assembled from ready-made boards, but from individual components. This way the dimensions would be even smaller.
Source: habr.com
