The idea to make a pocket tool for analyzing WiFi networks prompted me .
Thanks to them for the idea. I just had nothing to do.
All work was done as a hobby for the purpose of having fun and expanding my knowledge in the field of network technologies. Slowly, 1..4 hours a week, since the beginning of this year.
Application use was not planned. Those. it is NOT a hacker's tool.
At the moment, all the intended functionality works. All sources, completely ready for assembly, . There are also assembly instructions, etc. In this note, I will not duplicate the information posted on github. I will tell you only what I consider necessary to describe separately.
My opinion on the "universal tool" and the reason for choosing the ESP32
I don't claim the truth. Everyone has her own. I will try to justify my choice of "iron".
the option of using a combination of Linux (originally Raspberry Pi) + "peripherals" in the form of a controller (STM32) + CC1110 (8051 core) and a plan to cram everything that is possible (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) into it did not seem suitable for me. However, it looks like it will remain private and closed (flipper-zero github "This organization has no public repositories.") and went towards not too common hardware.
Maybe I'm wrong, and in the future, the authors will lay out the source code of the software in the public domain. But if not, then I would not buy such a piece of iron without source codes.
My tool requirements
The box should be small (the smaller the better).
Therefore:
- Built-in battery is not needed. With a current > 100 mA when working with Wifi, the built-in battery will either be large, or it will not last long. Therefore, let the "box" be powered by a standard power bank. All the same, I always have a power bank in my pocket / car.
- Keep inside the "box" Linux with tools, written over many years in all languages in the presence of a small screen and a meager set of control buttons, it makes no sense. The results can be viewed/processed on a normal laptop with a full keyboard and screen.
- Components should be readily available and widely known (available SDK, lots of examples and documentation).
As a result, for me, the choice was obvious - ESP32.
For all the tasks stated in the article, which prompted me to take action, the ESP32 capabilities are enough. Although the most I want to do is this:
- Play around with Bluetooth.
- Play around with the 433mHz range with the simplest hardware (only amplitude modulation, which is enough for practical needs).
Fly in the ointment in ESP32
- SDK (IDF) ESP32 is somewhat clumsy.
- Part of the functionality (the WiFi stack, for example) comes without source codes in the form of assembled static libraries.
- The 5GHz band is not supported and there are some limitations and clumsiness in working with WiFi.
But the price / size fully compensate for these shortcomings.
The main functionality of the software
I will briefly describe the functionality and my opinion about ...
Manage settings and upload files from SD
All external control is done through a simple Web page launched in a separate menu item. ESP32 starts in WiFi AP mode and displays a page at a fixed IP address.
Although the ESP32 cores are quite fast, but, as experiments have shown, the simultaneous operation of the built-in Web service and, for example, the router mode do not mix well. Therefore, there is no dynamic control and in all other modes the page is not available.
Moreover, dynamic control is not needed for research purposes.
Working with Beacon Packages
Modes are banal and not very interesting. Made "because you can". For check.
There are examples in the official Espressif examples.
AP list scanning mode.
Actually, any smartphone can do it.
Well, in this mode, the list of APs will be saved.
Beacon spammer.
ESP32 starts as an AP with a hidden SSID and a random MAC and starts sending [beacon frame] on a pre-created SSID list (created manually or obtained earlier by scanning the AP list)
WiFi sniffing mode
Espressif developers have added the ability for application software to receive all WiFi packets βflying in the airβ through a callback function. In fact, not all, since you can set the mode for only one fixed channel.
Very strict time limits are imposed on the processing of a callback function call. If for the mode of simple statistics collection this does not cause problems, then for the mode of writing a PCAP file to an SD card, I had to tinker, organizing the recording through a queue in memory and semaphores. Taking into account the peculiarity that the process that calls the callback spins on one core, and the process that writes to SD in another.
With a "noisy air" some packets are lost (there is no space in the queue and they are discarded), but with a typical "air" of an apartment in the evening (5..7 APs within sight), writing to PCAP has time to complete without packet loss.
Additionally, for PCAP monitoring and recording, there is a filtering mode based on the MAC list in the packet headers.
For example, you can track the appearance of a person in a club / cafe, before he even entered or appeared in the field of view. Few people turn off WiFi and automatic connections to known APs. (I'm turning it off now..)
Viewing recorded traffic in Wireshark is informative and interesting to understand the maps, it all works.
Mode of operation with deauth packets
By default, sending these packages is prohibited in the libnet80211.a library, which comes without sources. But this is easy to stop by correcting a couple of baits. At first, I doubted whether it was worth uploading patch. But after walking around different places with the [deauthentication frame] scanning mode enabled, I thought: βwhat the hell.β Moreover, in esp8266 the sending of these packages is not closed and there are assemblies on github under esp8266.
In many places (I won't say where) unwanted AP suppression is used through this method. And it's not "hooligans" ...
And I was still surprised that it was my distribution of the Internet from my phone that didnβt work in places ...
The tracking mode of the number and RSSI of such packets is very useful to understand "where the left APs do not like."
router mode
This feature is probably the most interesting of all to explore.
ESP32 supports simultaneous operation in STA + SoftAP mode. Therefore, it is possible to implement a classic NAT router on it.
To support the networking stack, Espressif uses a (virtually unchanged) fork of the lwip library.
But, by default, in the standard assembly, in the esp-lwip library, there is no forwarding between the netif interfaces 'ap' (SoftAP) and 'st' (STA).
Of course, you can do it without NAT, but there is a problem with the simultaneous connection of two or more STAs to the 'ap' interface and synchronization of IP addresses from the network interface 'st' to 'ap'. So the complexity is not worth it and it's easier through NAT.
Moreover, there is a fork esp-lwip from marting-ger which adds a simple implementation of NAT for IP4.
Although my hands itched to redo it purely cosmetically (in my opinion, it was easier without a fork project, but through LWIPHOOK build-defined functions), but laziness won out and the marting-ger version is used as is.
In router mode, incoming and outgoing IP4 traffic is viewed.
In particular, it is extracted from it to display on the screen and collect statistics in a file:
- Device name that connected to SoftAP ESP32 (DHCP packets)
- URL from DNS queries (UDP port 53) from a device connected to SoftAP ESP32.
Additionally, you can enable the recording of traffic in a PCAP file.
This mode is very useful, for example, in order to understand, for example, what your phone sends to the network and where it goes.
You can think of other ways to use this mode, taking into account the ability to completely programmatically control SoftAP ESP32 incoming and outgoing traffic at the network interface level: Ehernet header (destMAC[6]+srcMAC[6]+type[2]) + payload (IP4, IP6, DCHP, etc. type).
In principle, the ESP32 copes quite well with the WiFi->WiFi router function, passing regular traffic through itself without much delay. Subjectively, delays in a phone connected via a router to the ESP32 are not noticeable.
Unfortunately, in the Espressif API there is no way to set a filter by MAC connected to SoftAP EPS32. Instead, it is suggested to say "goodbye" (esp_wifi_deauth_sta) to already connected STAs that are "not wanted".
Filtering by MAC for connected STAs had to be done through a call to esp_wifi_deauth_sta()
In conclusion
Although I didnβt come up with anything new within the framework of working with ESP32, maybe someone will be interested in the result (sources).
I would like to note that the code was written solely for educational purposes. For "hacking", etc., it was specially made not very convenient.
I did not make a printed circuit board, because it took 1.5-2 hours to solder the finished scarves with a wire.
And if you do, then you need to assemble it not from ready-made boards, but from individual components. Then the dimensions will be even smaller.
Source: habr.com