Introduction to BOTs
Recently, I’ve been researching BOTs, and today I had a sudden inspiration to integrate OfferShow’s features into a BOT, thus beginning this bumpy journey;
“Stream: Including BOTs”
Since OfferShow is a WeChat Mini Program, initially I used Stream for packet capturing. I was actually quite close to the result back then, but didn’t pay much attention…
Below is the packet directly captured for the request interface, simply:
I successfully obtained the return value, which should have been a happy ending, but about ten minutes later, I made another request:
Therefore, the current task is to find the return interface, which I realized only after analyzing it using Wireshark; I had already captured this interface myself:
But at the time, I didn’t look closer because it wasn’t focused on traffic analysis, so I wasn’t sensitive to these terms, and after taking a quick look, I saw that the request body carried some data, so I overlooked it…
Directly [Painful face.jpg] …
Fiddler
Initially, I mistakenly thought Stream didn’t capture the desired packet, so I tried Fiddler next, but the results were even worse;
After preparing, I started capturing packets within the same local network, using Fiddler to proxy access OfferShow, but got stuck at the entry interface, and Fiddler didn’t capture the relevant packets either;
I googled and found out that the current version of WeChat only trusts its own certificates, so Fiddler’s certificate wasn’t trusted, causing the connection failure and inability to access;
I also read that WeChat running on a PC can be captured, so I followed online tutorials to set up HTTPS packet capturing, but the returned data was all garbled. Even after trying other people’s solutions, it didn’t work, so I switched to Wireshark instead;
Wireshark
In the end, I had no choice but to use the traffic analysis tool Wireshark. I’ll go straight to the images, where I’ve filtered out all traffic packets for OfferShow:
Classic HTTPS handshake process:
After establishing the connection, data transmission begins:
The server responds to the data packet received via TCP, sending it back to the requester:
Then, it’s time to request with this data,
After which you will receive the response data, but it needs to be Unicode decoded;
You can simply copy it to an online decoding website, which is still quite common, for instance:
You can actually directly follow Stream -> HTTP Stream
This makes it quicker and easier to view;
In conclusion, if we can obtain the data, we can access the information;
However, the data is one-time-use and seems to require APPID and APPKEY, making it difficult for users to access independently…
Afterword
Due to the special nature of the data, the interface calls for OfferShow will be paused for now. Let’s see if we can find another way later. Overall, there were still some gains. Not bad!