From zero to achieve a 12306 grab tickets software
December 10, 2023
by Shannon Contreras
No Comments
The words written in the front
Every year on holidays, readers must be familiar with hard to get a vote. In this article, we lead readers to realize a 12306 ticket brushing software from scratch. Its core principle is to send HTTP requests to simulate the process of logging in to 12306 website to purchase tickets, and finally buy tickets.
On the format of HTTP requests and how to assemble HTTP packets to send requests to the server, we wrote in our previous article “Implementing an HTTP Server from Scratch” (blog.csdn.net/analogous_l…). Has been introduced in detail, if you do not understand the friends can go to the article to see.
Solemnly declare: the technology introduced here is only for learning, not malicious attack 12306 server, do not abuse the technology introduced in this article. Any loss to 12306 server is at your own risk.
Of course, many of 12306’s urls and protocol details at various stages of the ticketing process are frequently changed to prevent scalpers and other illegal attackers due to the huge number of users on the server. Therefore, some of the specific urls described in this article may be invalid by the time you read this article. But that doesn’t matter, as long as you’ve mastered the analysis methods described in this article, you’ll have the flexibility to adapt your code to the latest 12306 server. Clipboards interfaces such as 12306, for example, the url is: kyfw. 12306. Cn/otns/leftTic… , but maybe later became kyfw. 12306. Cn/otns/leftTic… Again in a few days can become kyfw. 12306. Cn/otns/leftTic… , and then a week later may become kyfw. 12306 cn/otns/leftTic… I have seen them all. Therefore, focus on the principle of learning, master the principle, no matter what 12306 related URL becomes, can be unchanged should be ten thousand changes. Alas, 12306 is going further and further in its fight against scalpers. T_T
This paper will use the following tools to analyze the ticket purchase process of 12306, and then use C++ language to simulate the relevant process and finally purchase tickets.
Chrome (other browsers will do, too, with similar interfaces, such as Chrome, Internet Explorer with HttpWatch, etc.)
A 12306 account that can log into the 12306 website and buy tickets
Visual Studio (version optional, I’m using VS 2013 here)
Ticket check and site information interface
The reason to analyze this interface first, because ticket checking does not require user login, relatively simple. We opened more than 12306 votes in the Chrome query page, url is: kyfw. 12306. Cn/otns/leftTic… , as shown in the figure below:
Then right-click in the menu of the page and choose “Check” menu. After opening it, select the “Network” TAB. As shown below:
After opening the page into a binary window, the left is the normal webpage page, the right is the console browser, when we operate in the left page, the right side will display our browser sent various HTTP requests and responses. Let’s check a ticket at random here, such as the ticket from Shanghai to Beijing on May 20, 2018. After clicking the query, we find the right side looks like this:
Given that the type value of the list is XHR, we know that this is an Ajax request (Ajax is an asynchronous request supported by browsers natively, please search for details). We select this request and you can see the details of the request – request and response results:
In reponse, we can see the result of our HTTP response without the HTTP header:
This is a JSON format. Let’s find a JSON formatting tool and post the JSON format for you to see. In fact, you will find that the data related to ticket purchase in the HTTP request results of 12306 are basically in JSON format. Here’s the json:
The residual ticket information is in the result node, which is an array. After each node to | segmentation, we can format shown in the interface:
The interface I made here is relatively simple, readers can make a more beautiful interface if they are interested. Let’s list the HTTP packets and reply packets sent for this request:
HTTP/1.1 200 OK Date: Sat, 19 May 2018 15:23:58 GMT Content-Type: Application /json; HTTP/1.1 200 OK Date: Sat, 19 May 2018 15:23:58 GMT Content-Type: Application /json; charset=UTF-8 Transfer-Encoding: chunked ct: C1_217_85_8 Content-Encoding: gzip Age: 1 X-Via: 1.1 Houdianxin183:6 (Cdn Cache Server V2.0) Connection: keep-alive x-dscp-value: 0 x-CDn-src-port: 33963 cache-control: no-cache, no-storeCopy the code
From the previous article “Implementing an HTTP server from Scratch” (blog.csdn.net/analogous_l…) We know that this is an HTTP GET request, with the parameters attached to the request following the URL:
These four parameters are the date of ticket purchase, departure station, arrival station and ticket type (here is adult ticket (ordinary ticket)), which exactly correspond to the query information on our interface:
However, the reader may ask, here the departure and arrival stations are SHH and BJP respectively, how do I get these site codes? Because only by knowing these station codes can I buy train tickets for the specified departure and arrival stations. If you are a careful person, you must think that when we check the ticket and then enter the ticket check page, these site information has already been, so it may be the site information requested from the server when the ticket check page is loaded, so we refresh the ticket check page, and found that it is really like this:
Before entering the ticket please page, the browser from kyfw. 12306. Cn/otns/resourc… This is a javascript script with only one line of code in it. It defines the js variable station_names. The reason why the URL is followed by station_version=1.9053. You can think of it as a version number, but mostly by using a random value of 1.9053 to tell the browser not to use station_name. Js in the cache, but to reload the file from the server every time, so that if the site information is updated, you can avoid caching problems. The local cache is inconsistent with the site information on the server. Because the site information is more, we cut a picture:
See above, we can see that each site information by dividing the @ symbol, then each site by division | all kinds of information. So, according to the format of the above, if we want to query on May 30, 2018 from changchun to nanjing train tickets, can through the website kyfw. 12306. Cn/otns/leftTic… .
Of course, it needs to be noted here that because the information file of train stations across the country is relatively large, it takes a long time for our program to parse, and the code information of train stations is not always changed, so we don’t need to download station_name. Js every time, so when I write the program to simulate this request, Generally, the first to see whether the local file, if there is a local use, not to send HTTP request to 12306 server request. Here I post my request for site information program code (C++ code) :
Because our purpose here is to simulate the operation of buying a train ticket with HTTP request, not the technical aspect itself, we use curl library for quick implementation of our purpose. The library is a powerful HTTP related library, such as the 12306 server may return chunked data, this library can help us assemble; For example, curl automatically decompresses the data returned by the server using gzip. Curl curl curl curl curl curl curl curl curl curl curl curl curl curl curl curl curl curl
/** ** Send an HTTP request *@param URL request URL *@param strResponse HTTP response result *@param gettrueTo GET,falseHTTP headers sent with POST *@param headers *@param postData Data sent with POST *@param bReserveHeaders Whether to reserve header information for the RESULT of the HTTP response *@param timeout HTTP request Timeout */ bool HttpRequest(const char* URL, string& strResponse, bool get =true, const char* headers = NULL, const char* postdata = NULL, bool bReserveHeaders = false, int timeout = 10);
Copy the code
The various parameters of the function are clearly stated in the function comments, which will not be explained here. The code for this function is as follows:
bool Client12306::HttpRequest(const char* url,
string& strResponse,
bool get/* = true*/,
const char* headers/* = NULL*/,
const char* postdata/* = NULL*/,
bool bReserveHeaders/* = false*/,
int timeout/* = 10*/)
{
CURLcode res;
CURL* curl = curl_easy_init();
if (NULL == curl)
{
LogError("curl lib init error");
returnfalse; } curl_easy_setopt(curl, CURLOPT_URL, url); // Keep the header information in the response resultif (bReserveHeaders)
curl_easy_setopt(curl, CURLOPT_HEADER, 1);
curl_easy_setopt(curl, CURLOPT_COOKIEFILE, ""); curl_easy_setopt(curl, CURLOPT_READFUNCTION, NULL); curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, OnWriteData); curl_easy_setopt(curl, CURLOPT_WRITEDATA, (void *)&strResponse); curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1); Curl_easy_setopt (curl, CURLOPT_SSL_VERIFYPEER,false);
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, false); Curl_easy_setopt (curl, CURLOPT_CONNECTTIMEOUT, timeout); curl_easy_setopt(curl, CURLOPT_TIMEOUT, timeout); curl_easy_setopt(curl, CURLOPT_REFERER, URL_REFERER); // The USERAGENT field was not required in earlier versions of 12306, but is now required to avoid third-party snooping. / / if there is no this field, will return/HTTP / 1.0 * 302 version Temporarily Location: http://www.12306.cn/mormhweb/logHTML Server: Cdn Cache Server V2.0 MIME-Version: 1.0 Date: Fri, 18 May 2018 02:52:05 GMT Content-Type: Cdn Cache Server V2.0 MIME-version: 1.0 Date: Fri, 18 May 2018 02:52:05 GMT text/html Content-Length: 0 Expires: Fri, 18 May 2018 02:52:05 GMT X-Via: 1.0 psSHgqDXXx63:10 (Cdn Cache Server V2.0) Connection: keep-alive x-dscp-value: 0 */ curl_easy_setopt(curl, CURLOPT_USERAGENT,"Mozilla / 5.0 (Windows NT 6.1; Win64; X64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.146 Safari/537.36"); // Curl_easy_setopt (curl, CURLOPT_ACCEPT_ENCODING, CURLOPT_ACCEPT_ENCODING,"gzip, deflate, br"); // Add custom header informationif(headers ! = NULL) { //LogInfo("http custom header: %s", headers);
struct curl_slist *chunk = NULL;
chunk = curl_slist_append(chunk, headers);
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, chunk);
}
if(! get && postdata ! = NULL) { //LogInfo("http post data: %s", postdata);
curl_easy_setopt(curl, CURLOPT_POSTFIELDS, postdata);
}
LogInfo("http %s: url=%s, headers=%s, postdata=%s", get ? "get" : "post", url, headers ! = NULL ? headers :"", postdata! =NULL? postdata :"");
res = curl_easy_perform(curl);
bool bError = false;
if (res == CURLE_OK)
{
int code;
res = curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &code);
if(code ! = 200 && code ! = 302) { bError =true;
LogError("http response code is not 200 or 302, code=%d", code); }}else
{
LogError("http request error, error code = %d", res);
bError = true;
}
curl_easy_cleanup(curl);
LogInfo("http response: %s", strResponse.c_str());
return! bError; }Copy the code
As noted in the comments above, there are some fields that browsers carry when sending HTTP requests that we do not need, such as the check interface browser which may send the following HTTP packets:
Fields like Connection, cache-Control, Accept, and if-Modified-since are not required, so we can add these fields when simulating our own HTTP requests. As far as I can see, The 12306 server is becoming more and more stringent about the HTTP packets it sends. For example, last year, user-agent was not required. Now, if you do not wear this field, 12306 May not return the correct result. Of course, there will be no clear error message in the incorrect results, at best may tell you that the page does not exist or the system is busy please try again later, this is an important measure of server self-protection, imagine you do server program, will tell illegal users clear error message? That would give whoever attacked the server an opportunity to try again and again.
In particular, the header of the HTTP protocol sent by the check interface also has a field called Cookie, whose value is a very strange string of things:
There is a JSESSIONID in this string, which we can pass or not pass on non-log-in checking interfaces. But in the ticket and query contact these need to be in commonly used has the login can only be carried out under the condition of operation, we must take the data, this is the server for your token (authentication token), and this token is at first in the 12306 site, with many of the server, log operations must take the token behind you, Otherwise, the server will consider your request an illegal request. That’s why, when I first looked into 12306’s ticketing process, I couldn’t log in even with the correct username, password and photo verification code. This is a security measure used by 12306 to prevent illegal logins.
Login and pull image verification code interface
My login page looks like this:
12306 pictures of captcha generally consists of eight pictures, like the “dragon boat” text, and pictures, the two images (text images and authentication code) is on the server after assembling, sent to the client, server 12306 small images have a certain amount of this type, although the quantity is large, but is limited. If you want to automate captcha, try downloading most of the images and doing statistical patterns. So, I didn’t do automatic image recognition here. Interested readers can try it on their own.
First, the interface to pull the captcha. We open the Chrome 12306 login interface: kyfw. 12306. Cn/otns/login/I…
The interface that can pull the verification code:
We can see that the HTTP request packet is sent in the following format:
The Cookie field must carry the JSESSIONID as described above. The download image verification code and the following steps must also carry the JSESSIONID value in the Cookie field. Otherwise, you cannot get a correct response from the 12306 server. We’ll show you how to get this later. The HTTP GET request to pull the image captcha requires three parameters, login_site, module, rand, and a random value like 0.7520968747611347, as shown in the above code fragment. The values of the first three fields are fixed. The module field indicates the current module. The current value is login, and the value for obtaining the latest contact is passenger. Another point to note here is that if you fail to validate the image captcha and re-request the image, you must also re-request the JSESSIONID. The url is https://kyfw.12306.cn/otn/login/init. The HTTP request and reply packets are as follows:
This is a POST request, where the input image captcha on the POST data strip selects coordinates X and Y values:
Answer: 175,58,30,51 login_site: E rand: sjrandCopy the code
Here I have selected two images, so there are two sets of coordinates, (175,58) is one set, (30,51) is the other set, the coordinate system is as follows:
Since each image has the same size, I can set a range of coordinates for each image. When I select an image, I can give a coordinate within it, not necessarily the exact position of the mouse click:
Similarly, here is the interface implementation code for authenticating the user name and password:
int Client12306::loginAysnSuggest(const char* user, const char* pass, const char* vcode)
{
string param = "loginUserDTO.user_name=";
param += user;
param += "&userDTO.password=";
param += pass;
param += "&randCode=";
param += vcode;
string strResponse;
string strCookie = "Cookie: ";
strCookie += m_strCookies;
if(! HttpRequest(URL_LOGINAYSNSUGGEST, strResponse,false, strCookie.c_str(), param.c_str(), false, 10))
{
LogError("loginAysnSuggest failed");
return2; } ///** Successfully return //HTTP/1.1 200 OK //Date: Thu, 05 Jan 2017 07:49:53 GMT //Server: apache-coyote /1.1 // X-powered-by: The Servlet 2.5; Jboss-5.0 / jbossweb-2.1 //ct: c1_103 //Content-Type: Application /json; Charset =UTF-8 //Content-Length: 146 // X-via: 1.1 F186:10 (Cdn Cache Server V2.0) //Connection: Keep-alive // x-cdn-src-port: 48361 // The mailbox does not exist //{"validateMessagesShowId":"_validatorMessage"."status":true."httpstatus": 200,"data": {},"messages": ["The mailbox does not exist."]."validateMessages"// Password error //{"validateMessagesShowId":"_validatorMessage"."status":true."httpstatus": 200,"data": {},"messages": ["Incorrect password. If you make more than four wrong entries, you will be locked out."]."validateMessages"// Login succeeded //{"validateMessagesShowId":"_validatorMessage"."status":true."httpstatus": 200,"data": {"otherMsg":"",loginCheck:"Y"},"messages": []."validateMessages":{}}
//WCHAR* psz1 = Utf8ToAnsi(strResponse.c_str());
//wstring str = psz1;
//delete[] psz1;
Json::Reader JsonReader;
Json::Value JsonRoot;
if(! JsonReader.parse(strResponse, JsonRoot))return2; / / {"validateMessagesShowId":"_validatorMessage"."status" : true, / /"httpstatus" : 200, "data" : {"otherMsg":"", loginCheck : "Y"}, "messages": []."validateMessages" : {}}
if (JsonRoot["status"].isNull())
return- 1; bool bStatus = JsonRoot["status"].asBool();
if(! bStatus)return- 1;if (JsonRoot["httpstatus"].isNull() || JsonRoot["httpstatus"].asInt() ! = 200).return 2;
if (JsonRoot["data"].isNull() || ! JsonRoot["data"].isObject())
return 2;
if (JsonRoot["data"] ["otherMsg"].isNull() || JsonRoot["data"] ["otherMsg"].asString() ! ="")
return 2;
if (JsonRoot["data"] ["loginCheck"].isNull() || JsonRoot["data"] ["loginCheck"].asString() ! ="Y")
return 1;
return 0;
}
Copy the code
There is also a detail to pay attention to, that is, the data sent by POST request needs to do URL Encode for some symbols, which I did in the last article “From zero to an HTTP server” (blog.csdn.net/analogous_l…). It is also introduced in detail. If it is not clear, please refer to the previous article. Therefore, the comma information contained in the coordinate information of the image verification code should be URL encoded from
answer=114%2C54%2C44%2C46&login_site=E&rand=sjrand
Copy the code
Therefore, the content-Length field specified in the HTTP header should be the encoded string Length, not the original Length, which is particularly error-prone.
If the verification is successful, the next step is to check and buy tickets. Here is not an introduction, all the principles are the same, the author can explore. Of course, I have explored all the interfaces and implemented them, so LET me post here:
The specific implementation code is not posted in the article, you can download my code. Download address in wechat public number “easyServerDev” in reply to “12306 source” can get the download address, of course, because 12306 interface often change, when you get the code, 12306 server interface may have slightly changed, you can do the corresponding modification according to the principle introduced above.
Finally, once you have implemented the basic login and ticketing functions, you can constantly simulate certain requests to swipe tickets.
All rights reserved.
Welcome to the public account “easyServerDev”. If there is any technical or professional problems need my help, can contact me by the public, the public, not only share stories, high-performance server development experience, and at the same time also free for the general technology to answer friends to provide technical and professional solutions, do you have any question can leave a message on WeChat public directly, I will reply you as soon as possible.
