What happens when captured packet data is garbled?

Why does this happen? Careful children may find that the request connection data we sent to the server is different:

The information in the first picture is {"roomid":98284,"uid":271298361556770}

The information in the second picture is {"uid":276194535568357,"protover":2,"roomid":98284}

roomid is the real room number, and uid is a randomly generated string of numbers. You can copy and log in directly.

In comparison, the second one has an extra "protover":2 parameter. In fact, the first picture is to capture the data packet of the mobile client, and the second picture is to capture the data packet of the computer web page. So whether there is this "protover":2 parameter, you can connect to the barrage server.

So we can infer that the easiest data to capture when capturing packets is the mobile phone, followed by the wap side, and finally the computer side.

But many times the packet data we capture is a string of garbled characters as shown in Figure 2, whether you use utf8 or Even using gbk encoding cannot achieve the effect shown in Figure 1.

This kind of data is actually a kind of compressed data gzip. Currently, wireshark does not support the decompression mode of this compressed data.

Nowadays, websites are basically transmitted in compression mode during transmission, so the data you capture is compressed data. In your opinion, it is completely garbled and there is no way to start.

As shown in the figure, when visiting my blog homepage, the web page data sent back by the crawling server is in gzip mode, and the web pages we usually visit are decompressed and rendered by the browser and then presented to us.

Since the Bilibili server transmits gzip data, the solution is very simple. Installing a third-party zlib package or gzip package can solve this problem.

The above is the detailed content of What happens when captured packet data is garbled?. For more information, please follow other related articles on the PHP Chinese website!