MCU---ESP8266Wifi SmartConfig one-click configuration (Part 2)

Chapter Highlights

According to the previous chapter, we have already used the one-click networking of ESP8266, but we don’t know the details. How are the SSID and password broadcasted?

Through Baidu's other information, it includes determining the SSID, channel, receiving data, separating the length inside, and extracting the password and SSID from the length.

Packet capture

We want to use the wireless network card to capture 802.1x WiFi messages and see what the broadcasted data looks like. Here we need to capture packets under Linux, because WiFi messages cannot be captured on Windows.

The system used here is Kali. Since the drivers of this system are all installed, you only need an external network card to capture.

But here we need to configure the network card first, we need to use the following two important commands

iw dev wlan0 interface add mon0 type monitor

ifconfig mon0 up

To understand why, you can refer to the following passage

Because of work, I need to monitor wireless network packets, especially IEEE802.11 management control frames (frames…actually I prefer to call them packets directly). My colleague opened wireshark and captured the wifi interface, but found that he heard a lot of ethernet frames but no wifi frames. Why? Let's see what the official website of wireshark says:

If you're trying to capture network traffic that's not being sent to or from the machine running Wireshark or TShark, ie traffic between two or more other machines on an Ethernet segment, or are interested in 802.11 management or control packets, or are interested in radio-layer information about packets, you will probably have to capture in "monitor mode". This is discussed below.

Without any interaction, capturing on WLAN's may capture only user data packets with "fake" Ethernet headers. In this case, you won't see any 802.11 management or control packets at all, and the 802.11 packet headers are "translated" by the network driver to "fake" Ethernet packet headers.

The answer is revealed. It turns out that this is because the wifi driver will automatically convert the wireless frame into an ethernet frame before giving it to the kernel, so that the protocol stack in the kernel will be easier to handle.

The question is, if I want to hear the wifi frame, what should I do? The answer is simple, set the wifi adapter to monitor mode. In wifi adapters, there is usually an SSID/ESSID filter, so even if the wifi adapter is set to promiscuous mode, it will be useless because it will still not be able to receive frames from SSIDs that are not joined by itself. What about monitor mode? Let's take a look at the following sentence:

In monitor mode the SSID filter mentioned above is disabled and all packets of all SSID's from the currently selected channel are captured.

This will add a network card on which you can capture WiFi messages.

Then open wireshark and you can capture packets happily.

But after capturing the process, I still didn't find anything from the data length.

Sniffing

ESP8266 has a function called sniffing mode, which allows you to continue to receive smartconfig messages in a sniffing manner to see what the content is.

The working path is reconfigured as shown below

Recompile and then burn the firmware

In this way, some frames were captured, similar to those captured by Wireshark

Analytical protocol

After two types of packet capture, we obtained the following information.

Start and stop messages

This kind of broadcast message always has a set of data sent in a loop at the beginning and end. What we see in Wireshark is

Cycle between 625 and 622,

Sniff caught the cycle between 599 and 596

The length of the middle

It should be encrypted. When sending the same password, the content is basically the same. When the password is changed, the length changes. It seems to be encrypted data.

Other valuable information cannot be guessed.

I found this article "AirKiss Technical Principles" on the Internet

There is a passage in it

To solve these two problems, before sending the link layer data (see the next section), it is necessary to send a 400ms preamble (400ms = 8*50ms, that is, if the device switches channels at a frequency of 50ms, it can cover 8 channels. Because the general user environment does not need to monitor 14 channels, it is sufficient to cover 8 channels). The preamble consists of 4 bytes, and its value is fixed to {1,2,3,4}. After receiving these preamble packets, the receiver uses the Length field in the SNAP packet to subtract it from the Length field to obtain the difference value. For example, the receiver intercepts the 802.2 SNAP format preamble data packet at the link layer through monitoring, and the values ​​of its Length field are 53, 54, 55, and 56 respectively. The difference value can be determined as 53-1=52. After that, the receiver subtracts 52 from the Length field value of the SNAP packet after receiving the data, and the actual information data can be obtained.

I don't know how to get this leading field yet. I'm afraid it's not done in the driver. Or it's a patent. Others can't get it.

In addition, the format they use cannot be seen from the message.

There is another article

"Wifi SmartConfig One-click Configuration", which introduces some TICC3000 things.

It seems that it is still very troublesome to make a similar function, and it is not a simple application. I will study it later.

Conclusion

After a day of hard work, there was no substantial breakthrough, but I did learn some techniques, such as capturing 802.1x messages, collecting smartconfig information everywhere, and found related content on the Internet, all of which were from one or two people.