WO2014148864A1 - Method for analyzing protocol of sns server - Google Patents

Abstract

The message format of the protocol of an SNS server can be deduced by performing: a step in which a test application for the SNS server being analyzed is produced and installed on the portable terminal of a client; a step in which the test application is executed in a debugger environment and content is transmitted from the test application to the SNS server; a step in which content is transmitted from the SNS server in response to the content transmission by the client; a step in which data transmitted from the client and data transmitted from the SNS server are captured in real time by a packet capture unit and the captured data are transmitted to a packet analysis unit; and a step in which the format of message delivery to/from the SNS server is deduced by the packet analysis unit.

Description

Protocol analysis method of SNS server

A protocol reverse engineering method, which is a method of finding out details about an unpublished protocol.

Recently, SNS (Social Network Service) is rapidly increasing in use due to the advantages of forming, managing and communicating with people in virtual space. Facebook, the most widely used social networking service, offers mobile applications. According to the social media statistics agency Social Bakers, about 500 million of the world's 900 million Facebook users use mobile Facebook.

However, Facebook is not currently publishing protocol protocols. Therefore, it is not possible to know in what process the Facebook mobile application communicates with the Facebook server.

If the Facebook protocol is released, many researchers around the world will be able to identify the shortcomings of the protocol and suggest ways to remedy the shortcomings. In addition, various methods for improving communication performance may be introduced.

For example, caching servers can be placed in the middle to reduce response time and reduce traffic usage. Furthermore, it is possible to develop Facebook clients that run on various platforms, and various Facebook clients depending on the purpose.

Even if the Facebook protocol is not released, if you know the details of the protocol, it can be the basis for the above-mentioned technical development. Protocol Reverse Engineering (PRT) is a way to find out more about unpublished protocols.

Protocol reverse engineering is the process of finding out the details of a protocol by applying the engineering method by collecting traffic sent and received in the communication process. Research to automate this process has been the main task of protocol reverse engineering to date.

However, these findings have not yet progressed satisfactorily and have not evolved to the details of specific protocols. However, it is used for signature generation for security and traffic classification by protocol behavior analysis. In order to grasp the details of a specific protocol using reverse engineering, a method of manually analyzing using the known information of the target protocol as much as possible is mainly used.

The purpose of this paper is to propose a method for analyzing protocols of SNS servers that are not publicly disclosed by protocol reverse engineering.

Preparing a test application for the SNS server to be analyzed and installed in the portable terminal of the client; Executing the test application in a debugger environment and transmitting content from the test application to an SNS server; Transmitting content from the SNS server in response to the content transmission of the client; Capturing data transmitted from the client and data transmitted from an SNS server in real time by a packet capture unit, and transmitting the captured data to the packet analyzer; And deriving, by the packet analyzer, a message delivery form with the SNS server. The protocol of the SNS server may be analyzed.

By the proposed protocol analysis method of the SNS server according to the embodiment of the present invention, the message exchange order and message exchange form of the SNS server protocol can be inferred.

1 illustrates a network configuration environment for protocol reverse engineering in accordance with an embodiment of the present invention.

2 is a flowchart of a method for inferring a message exchange order of protocols according to an embodiment of the present invention.

3 shows a message data transfer process of a protocol according to an embodiment of the present invention.

4 is a flowchart illustrating an authentication process when a client communicates with an SNS server according to an embodiment of the present invention.

5 is a flowchart of a method for inferring a message format of a protocol according to an embodiment of the present invention.

6 shows ID information in JSON format without an Facebook access token.

7 shows ID information in JSON format including an access token of Facebook.

8 illustrates data stored in a Bundle type variable in Facebook.

9 infers the message form sent when a message request to Facebook.

10 is inferred Facebook's response message form according to the message request to Facebook.

Hereinafter, with reference to the accompanying drawings for the present embodiment will be described in detail. However, the scope of the inventive idea of the present embodiment may be determined from the matters disclosed by the present embodiment, and the inventive idea of the present embodiment may be implemented by adding, deleting, or modifying components to the proposed embodiment. It will be said to include variations.

1 illustrates a network configuration environment for protocol reverse engineering in accordance with an embodiment of the present invention.

Referring to FIG. 1, the present embodiment includes a client 300 that exchanges information with an SNS server 600, a packet capture unit 400 that captures data in a wireless communication network, and a packet analyzer that analyzes the captured packet. 500 and the SNS server 600 that exchanges information with the client 300.

A brief look at these configurations is as follows.

The client 300 may be configured as a portable terminal, and the terminal is equipped with a Facebook application and a test application for Facebook. This communicates with the SNS server 600.

Hereinafter, the SNS server 600 will be described as a facebook server 600. However, all social media that provide open application production programs such as Facebook and Twitter can be applied.

The experimental application was developed using the Facebook Software Development Kit (SDK), which is a development platform provided by Facebook. The reason why the experimental application was created and installed is to infer the detailed form of the protocol by analyzing the changes of the variables identified at each execution stage of the program while executing them on a debugging tool and controlling the execution order.

In addition, the Facebook server 600 communicates with the client 300 through a Facebook application or a protocol unique to the Facebook server through the Facebook application or the experimental application.

In addition, the packet capture unit 400 collects packets exchanged between the Facebook client 300 and the server in order to infer the message exchange order of the Facebook protocol, and the packet analyzer 500 at the packet capture unit The collected data are classified according to the type, and arranged in time series for analysis.

In more detail, packet capture and analysis will be described according to an embodiment of the present invention.

First, use the official Android Facebook application and experiment in two different environments, 3G and Wi-Fi. You can use the SHW-M180S device (OS 2.3.4 Gingerbread) as a mobile terminal and use the Wire Shark For Root application to capture packets in the mobile environment.

In order to see direct network communication in Android environment, Android's root authority is required.

When capturing a packet in a Wi-Fi environment, the packet analyzer 500 may create a Wi-FI network and use a packet capture program such as tcpdump and WireShark to view and analyze the packet in real time.

However, in order to experiment in the same environment as the 3G environment, a packet capture unit 400 for capturing a packet in a mobile terminal and a packet analyzer 500 for moving a captured file and analyzing it using WireShark are separately provided.

2 is a flowchart of a method for inferring a message exchange order of protocols according to an embodiment of the present invention.

A method for inferring the message exchange order of the Facebook protocol will be described with reference to FIGS. 1 and 2.

First, the content request is made to the Facebook server 600 through the Facebook application installed in the portable terminal of the client 300. For example, using Facebook application in 3G and Wi-Fi state, it transmits 5 letters (Hello) in English to the wall (S101).

The packet capture unit 400 captures the data transmitted through the wireless communication network in real time and transmits the data to the packet analyzer 500 in the order of time (S102).

The packet analyzer 500 classifies the data passing in real time according to the type of data, and analyzes the data by arranging them in order of time (S103).

The message exchange order of the Facebook protocol is inferred from the analyzed information (S104).

3 is a diagram illustrating a data transmission process of a protocol message according to the experimental result of FIG. 2.

Referring to FIG. 3, the inference result of the message exchange procedure of FIG. 2 is as follows.

A session is established between the server and the client 300 using the TCP 3-way handshake and a TLS handshake using TLSv1 is established to establish a secure communication foundation of Facebook. In the data transmission process, encrypted data is exchanged and session is terminated through FIN and ACK. However, you can see the order of the transmitted packets, but the details of the transmitted data are not known because they are encrypted through the TLSv1 handshake.

In another embodiment of the present invention was analyzed by sending a 99KB photo to the Facebook wall in the same experimental environment. The same process occurred in both 3G and Wi-Fi environments. When transmitting a photograph, the data transmission process of FIG.

In other words, as in the previous experiment, the session is established, the data is transmitted after the TLSv1 handshake, and the session is terminated. Like the writing process, the packets in the photo transmission process did not know the details of the data transmitted due to encryption.

4 illustrates an authentication process sequence when the client 300 communicates with an SNS server in an embodiment of the present invention.

The authentication process is not included in the message exchange sequence above. The authentication process is performed before the above process and is the same as FIG. 4, and the authentication method uses the Oauth method.

Currently, representative SNS, Twitter and Facebook both use Oauth authentication method.

This authentication method defines each data set such as user data, wall post data, comment data, friend data, etc. as an object, and receives an object token from the authentication server for each object. This is the method of authentication.

In the above, the reasoning method of the message exchange procedure is demonstrated.

However, the message exchange order was able to know the order of the communication process between the client 300 and the server, and what protocol was used to encrypt and transmit the data, but the information of the options of the encrypted packet could not be known.

Therefore, in order to check the message format of the protocol, the application is directly written using the Facebook SDK, and the protocol is analyzed using the results generated during the transmission of the text and photos.

5 is a flowchart of a method for inferring a message format of a protocol according to an embodiment of the present invention.

6 shows ID information in JSON format without an Facebook access token.

7 shows ID information in JSON format including an access token of Facebook.

8 illustrates data stored in a Bundle type variable in Facebook.

Referring to Figures 1, 5, 6, 7, and 8, a method for inferring the message format of the Facebook protocol is described as follows.

First, a Facebook experiment application is produced and then installed in a portable terminal of the client 300 to build an environment for communicating with Facebook. (S201).

Facebook supports Facebook SDKs in several languages, including IOS, Android, and PHP, and provides a unified application program interface (API) for work requests such as posting posts and receiving posted posts.

This API is called the Graph API and is provided to make writing Facebook applications easier. The program interface provided by the Graph API is intended to be programmed using the concept of objects. All information units that the server and the client 300 exchange, such as user information, wall posts, comments, and friend information, are objects. For example, the client 300 application updates the object information through the API provided by the Graph API, and transmits the object information to the server to send new information to the server.

The Graph API is also used to retrieve, delete, publish, and update objects. Each object has its own unique object ID, and if you query for the information of the object through https://graph.facebook.com/<Facebook ID>, the object of Facebook ID in JSON format as shown in FIG. Receive information. In other words, information about each object exchanged by the Facebook protocol is expressed in JSON format inside the Facebook SDK and the data is exchanged. The JSON format is a lightweight data format that is easy to read and easy to use. JSON consists of name / value pairs and supports several development languages.

In order to know the limited information of the user of Facebook or the limited entity information related to the user, the Facebook ACCESS_TOKEN should be issued. After obtaining the corresponding permission through the Oauth authentication process, more detailed information as shown in FIG. 7 can be obtained.

Thereafter, the experimental application is registered in a Facebook server and an ID is obtained. If you register this application on Facebook Developer and receive and use your own APP_ID, the created application can operate normally. (S202)

Then, run the experiment Facebook application in the debugger environment on the portable terminal of the client 300, using the experimental Facebook application to log in to the Facebook server 600, write on the wall, upload photos to the wall, logout function In step S203, the content is transmitted.

At the same time, the packet capture unit 400 captures the data transmitted through the wireless communication network in real time and transmits the data to the packet analyzer 500 in chronological order. The packet analyzer 500 classifies the data passing in real time according to the type of data, and infers the message format by analyzing the data in the order of time.

9 infers the message form sent when a message request to Facebook.

Hereinafter, referring to FIG. 9, a method of analyzing a message and an inference result of a message transmitted when writing on a wall will be described.

First, the user specifies the method and URI of the HTTP Request line (800) as POST and me / feed and requests the creation of the object. In this case, me / feed is a URL indicating a wall post and means an assembly of each entity.

As described above, the message that is actually transmitted uses the JSON form as the object information, and the JSON form information is stored and transmitted later (Android uses a variable type of Bundle type). First, the message to be sent with the key corresponding to the key is stored in the object that created the message to be sent. If the key is message "then the corresponding value is the data itself to be passed.

Again, add information to the object as a [format, json] pair, save the login permission ([access_token, ACCESS TOKEN]) during the login process, and add [method, post]. After this process, data as shown in FIG. 8 is stored in the newly created object. The message, "method", "access_token", and "format" values are mandatory to send a post. The actual data to be passed is the value stored in the "message" key. . "access_token" is the result obtained in the authentication process described above, and "format" is fixed to "json". There are other values of name and link.

When this data is stored, a Facebook message is generated and delivered to the HTTP message body 900 after the Content-Disposition representing the boundary and the attributes is added as shown in FIG. 8.

HTTP headers sent at the same time determine other options. For the first time, user-agent information of the system where the current application is running is stored in the user-agent option. Set the Content-Type to multipart / form-data and set the Connection to Keep-Alive.

Other header options are set when connecting an httpconnection. You can check the completed Request headers (850) by setting up Eclipse breakpoints during the write process, debugging, and looking at the value of httpsEngine-RequestHeader-props. When the information found in the request headers 850 and the message body 900 described above are applied to the HTTP request message format, the format as shown in FIG. 9 is completed.

Meanwhile, when a request is made to the Facebook server 600 using the openUrl of the Facebook SDK, a result value for the requested operation may be received. At this time, the response of the result value is also captured and analyzed as if the packet of the transmission message is captured and analyzed (S205).

10 is inferred Facebook's response message form according to the message request to Facebook.

If the transmission fails, the response of the status line is 400, and the message body 900 contains the reason or information about the failure. If the request is successful, the message body 900 contains the ID of the object that is the result of the request, and the response is returned. The object ID may be an ID of a wall post, a picture, a comment, and the like. If the data coming in response is checked using the getresponseheader method, the header option shown in FIG. 10 is included.

In another experimental example of the present invention, when sending a picture, unlike when leaving the wall of the request to transmit the request URI me / photos rather than me / feed. But there are no differences in the overall options.

In addition, the message format may be analyzed and inferred using the experimental application client 300 according to the above method.

Claims (2)

1. Preparing a test application for the SNS server to be analyzed and installed in the portable terminal of the client;

   Executing the test application in a debugger environment and transmitting content from the test application to an SNS server;

   Transmitting content from the SNS server in response to the content transmission of the client;

   Capturing data transmitted from the client and data transmitted from an SNS server in real time by a packet capture unit, and transmitting the captured data to the packet analyzer; And

   And inferring, by the packet analyzer, a message delivery form with the SNS server.
2. The method of claim 1,

   Inferring the message delivery form by the packet analyzer,

   And the data transmitted from the packet capture unit is classified, and the data is in chronological order so that the message format is inferred.

Images