JSON-RPC NETWORK PROTOCOL ANALYSIS USING WIRESHARK

Size: px

Start display at page:

Download "JSON-RPC NETWORK PROTOCOL ANALYSIS USING WIRESHARK"

Martha Ford
5 years ago
Views:

1 JSON-RPC NETWORK PROTOCOL ANALYSIS USING WIRESHARK Rajdeep S. Manjre Abstract JSON-RPC (JavaScript Object Notation Remote Procedure Call) is a protocol which is used for communication through internet. JSON-RPC over HTTP is a method used for calling a remote server using the HTTP header. In this paper, the aim is to analyze the JSON-RPC protocol while sending a remote request from an android Client using Kore mobile application to a Raspbian based Raspberry pi Server possessing Kodi (formerly known as XBMC) media display center using a packet analysing tool called Wireshark. Using Wireshark, various parameters can be inspected and a detailed analysis can be carried out. Index Terms GET, HTTP, JSON-RPC, KODI, Kore, POST, Wireshark. I. INTRODUCTION Since IoT (Internet of Things) has evolved, the internet is gaining more importance in our lives resulting in an explosive growth of machine information on the internet. Thus, an environment of automated and interactive systems is needed. Owing to the requirements of IoT and significant development in networking protocol technologies, internet is used by the applications and devices to communicate with each other. Such a communication is a form of client-server interaction typically implemented via a request-response message passing system. The interaction involves the client sending a request message with some parameters to the server to execute a procedure and the server sends a response with the required return values back to the client. To communicate between a remote client and server, JSON-RPC can be used. In JSON-RPC the messages are encoded in JSON (JavaScript Object Notation) which is a light-weight, text-based data interchange format for serialization of structured data. JSON is a part of JavaScript standard but still language independent. JSON is very simple, therefore easy to generate and parse and has only a small memory footprint. Advantage of JSON is that it can be carried over existing network protocols like HTTP. II. MOTIVATION The field of embedded networks is growing rapidly and the devices are becoming more and more intelligent. Thus communicating with these devices remotely with minimum human efforts is possible. JSON-RPC, due to its numerous advantages over its competitors is one of the ways to communicate with the server remotely. The structure of the JSON-RPC protocol needs to be thoroughly analyzed to boost the development of new applications for remote communication. Additionally, with the advent of smartphones, it is possible to use mobile applications as clients to communicate and operate the remote servers with ease. III. OBJECTIVE The objective of this paper is to create analytical methodology related to the internal structure of the JSON-RPC protocol. This analysis is to help in describing each parameter of the protocol, JSON structure and sequence of communication. The analysis should be easily understandable and traceable to the specifications mentioned in the standard documents (JSON-RPC Working Group) related to the protocol. A. Overview IV. JSON-RPC (JSON DATA FORMAT) JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol. Primarily, this specification defines several data structures and the rules around their processing. It is transport agnostic in that the concepts can be used within the same process, over sockets, over http, or in many various message passing environments. It uses JSON as data format. B. JSON data format: As mentioned in RFC4627 [6], JSON can represent four primitive types (Strings, Numbers, Booleans and Null) and two structured types (Objects and Arrays). 1. Objects: An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a String, Number, Boolean, Null, Object or Array. 2. Arrays: An array is an ordered sequence of zero or more values. C. JSON Syntax: Data is represented in name/value pairs. Curly braces hold objects and each name is followed by : (colon), the name/value pairs are separated by, (comma). 2889

2 Square brackets hold arrays and values are separated by, (comma). D. JSON supports the following two data structures: A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array. An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence. E. Attributes A number of JSON attributes make JSON-RPC suitable for many applications. Completely programmed technique for de-serializing and serializing JavaScript objects, with very little coding. Most of the browsers have enough support of JSON. The format is very concise due to having name/value pair based approach. De-serialization is very speedy in JavaScript. Most of JavaScript libraries have good support of JSON. Having simple API for JS and other languages like native.net support. V. JSON-RPC FOR KODI JSON-RPC is a HTTP- and/or raw TCP socket-based interface for communicating with Kodi. Kodi (formerly known as XBMC) is a free and open source media display center for playing videos, music, pictures, games etc. Kodi runs on Linux, OS X, Windows, ios, and Android, featuring a user interfaces for use with televisions and remote controls. Kore, an official android remote can be used to remotely operate and control the media center. In Kodi, JSON-RPC can be accessed over a variety of transports and has been designed from the ground up to be flexible to allow control over new transports easily. Some of the transports have different limitations which will be enforced upon the interaction over that transport. As an example HTTP transports allow response and downloading of files while the raw TCP transport allows response and notifications (events and information Kodi sends to its clients). Depending on the client's needs one can choose one (or many) of the available transports. A. Transports: The interface is available on three transports with the following settings: Python: Always enabled. HTTP : In System/Settings/Network/Services activate Allow control of Kodi via HTTP. TCP : In System/Settings/Network/Services activate Allow programs on this system to control Kodi for localhost access only and Allow programs on other systems to control Kodi for access from other computers as well. Here, we will only be discussing on transports carried out via HTTP. The HTTP transport can be used by third-party applications running on the same machine as Kodi or on a different machine which can access the machine running Kodi using the HTTP protocol. Because this transport allows applications outside Kodi to control Kodi, it has to be manually enabled by the user. The JSON-RPC API for KODI supports JSON-RPC 2.0 specifications. B. HTTP Header Considerations: Regardless of whether a remote procedure call is made using HTTP GET or POST, the HTTP request message must specify the following headers: Content-Type should be 'application/json-rpc' but may be 'application/json' or 'application/jsonrequest'. The Content-Length must be specified and correct. The Accept must be specified and should read 'application/json-rpc' but may be 'application/json' or 'application/jsonrequest'. C. JSON-RPC via HTTP JSON-RPC via HTTP is generally divided into two parts. Request (Client Server) Response (Server Client) 1. Request: There are basically two types of HTTP requests that a client can make to the server while requesting the needed information. POST request: Third-party application can access Kodi's JSON-RPC API by sending JSON-RPC requests embedded in a HTTP POST request using the following URL. GET request: Third-party application can access Kodi's JSON-RPC API by sending JSON-RPC requests embedded in a HTTP GET request using the following URL. ded-request> Following comparison between POST and GET method (Table1) mentioned [7] concludes that POST request method should be the preferred one. 2890

3 Table 1 : Comparison between POST and GET Request methods [7] Paramet ers Encodin g type Restrict ions on data length Restrict ions on data type Security Visibilit y POST application/x -www-form-urlen coded or multipart/form-da ta. Use multipart encoding for binary data No restrictions. No restrictions. Binary data is also allowed. POST is a little safer than GET because the parameters are not stored in browser history or in web server logs Data is not displayed in the URL Cannot be bookmarked ISSN: GET application/x -www-form -urlencoded Since form data is in the URL and URL length is restricted. A safe URL length limit is often 2048 characters but varies by browser and web server. Only characters allowed. ASCII GET is less secure compared to POST because data sent is part of the URL. Never use GET when sending passwords or other sensitive information! Data is visible to everyone in the URL Bookm Can arked be bookmarked Cached Cannot be cached Can be cached History BACK button/ Reload Parameters are not saved in browser history. Data will be re-submitted (the browser should alert the user that the data are about to be re-submitted) Parameters remain in browser history. GET requests are re-executed but may not be re-submitted to server if the HTML is stored in the browser cache. A. Request Object Format [2]: JSON-RPC protocol includes a Request Object which the Client sends to a Server. The Request Object contains the following members. jsonrpc: A String specifying the version of the JSON-RPC protocol. It must be exactly "2.0". method: A String containing the name of the method to be invoked. params: A Structured value that holds the parameter values to be used during the invocation of the method. This member may be omitted. id: An identifier established by the Client that must contain a String, Number, or NULL value if included. If it is not included it is assumed to be a NOTIFICATION (It is a Request Object without an id number. The Server is not expected to give a Response Object back to the Client.). The value should normally not be Null and Numbers should not contain fractional parts. The Server should reply with same return value. This is used to correlate between the Objects. B. Parameter Structure: If present, parameters for the rpc call must be provided as a structured value. Either by-position through an Array or by-name through an Object. by-position: params must be an Array, containing the values in the Server expected order. by-name: params must be an Object, with member names that match the Server expected parameter names. The absence of expected names may result in an error being generated. The names must match exactly, including case, to the method's expected parameters. 2. Response: The Response functionality is the only functionality that should be present in every transport available as it describes the functionality to respond to a JSON-RPC request with a valid JSON-RPC response (be it an error message or an actual response). For non-notification requests including system procedures using POST or GET indicate a success response using HTTP status code: 200. However, for notification requests, a success response indicates a HTTP status code: 204. A. Response Object Format [2]: When the rpc call is made, the Server replies with a Response except in case of Notification Request Object. The Response JSON Object contains following members: jsonrpc: A String specifying the version of the JSON-RPC protocol. It must be exactly "2.0". result: If no error occurred, this member contains the response from the Server, typically values determined by the method invoked on the Server. If an error occurred, this member is not included in the response. 2891

4 error: If an error occurred, this member contains a service-specific error Object with details about the error. If no error occurred, this member is not included in the response. id: The identifier specified in the Request. If there was an error in detecting the id in the Request object (e.g. Parse error/invalid Request), it must be Null. B. Error Object Format: code: A numeric error code [Table 2] that identifies the error type. message: A string containing an error message suitable for printing in a log file. data: A Structured value that contains additional information about the error. This can be omitted. Table 2 : Error codes code message meaning Invalid JSON was Parse error received by the server. An error occurred on the server while parsing the JSON text Invalid The JSON sent is not a Request valid Request object Method The method does not not found exist / is not available Invalid Invalid method params parameter(s) Internal Internal JSON-RPC error error. Reserved for to Server implementation-defined error server-errors. VI. WIRESHARK Wireshark is a GUI based free and open source network packet capture and analyser tool. Wireshark was formerly known as Ethereal. There is a command line utility to capture packet known as TShark. It can be used where only console-based environment is available. Owing to some of the attributes mentioned below Wireshark is one of the foremost network packet analyser tool used in industries and research areas. Multi-platform: Runs on Windows, Linux, macos, Solaris, FreeBSD, NetBSD, and many others. Live data can be read from Ethernet, IEEE , PPP/HDLC, ATM, Bluetooth, USB, Token Ring, Frame Relay, FDDI, and others (depending on your platform). Live capture and offline analysis. Deep inspection of hundreds of protocols, with more being added all the time. A. Panels of Wireshark: 1. Start the Wireshark application. When Wireshark is first run, a default, or blank window is shown. To list the available network interfaces, select the Capture Interfaces menu option traffic click the Start button for the network interface you want to capture traffic on. Windows can have a long list of virtual interfaces, before the Ethernet Network Interface Card (NIC). 2. To stop the capture, select the Capture Stop menu option, Ctrl+E, or the Stop toolbar button. What you have created is a Packet Capture or pcapng file, which you can now view and analyse using the Wireshark, interface, or save to disk to analyse later. The capture is split into 3 parts: Packet List Panel this is a list of packets in the current capture. It colours the packets based on the protocol type. When a packet is selected, the details are shown in the two panels below. Packet Details Panel this shows the details of the selected packet. It shows the different protocols making up the layers of data for this packet. Layers include Frame, Ethernet, IP, TCP/UDP/ICMP, and application protocols such as HTTP. Packet Bytes Panel shows the packet bytes in Hex and ASCII encodings. VII. EXPERIMENTAL SETUP Here, Raspbian based Raspberry Pi model 1 is used as a Server. Wireshark is installed on the Server so as to capture the network packets on the wire for analysis. Kodi a media display center is also installed on the Server. On the Client side Android mobile is used. Kore mobile application, an official remote for controlling the Kodi is installed on the Client. Now Client is enabled to communicate with the Server and Request is sent by the Client to display a picture image on the screen which is connected to the server via HDMI cable. Meanwhile, the Wireshark is enabled to capture the packets on the network. As the communication between the Client and Server is done, Wireshark is stopped and a file (json-rpc.pcapng) containing Request and Response frames is saved and then used for the analysis of JSON-RPC protocol. VIII. ANALYSIS AND RESULTS Firstly, a display filter needs to be set so that we can focus only on the required network packets. Here, http display filter is set so that we can concentrate on the JSON-RPC over HTTP protocol. Following diagram [Figure 1] shows the Time sequence communication between Client and Server for JSON-RPC over HTTP. 2892

Figure 1 : Sequence diagram for JSON-RPC over HTTP Following steps are included in analysis of JSON-RPC packets over HTTP protocol.

The frame is basically a collective composition of all the network layers described by the TCP/IP protocol network model. Figure 3 : Frame Details (Request frame) The summary consists of Frame no.

Also the network protocols present in total frame is present according to the TCP/IP network model. 2.

5 Figure 1 : Sequence diagram for JSON-RPC over HTTP Following steps are included in analysis of JSON-RPC packets over HTTP protocol. Here, we will dissect and go through each layer and the internal structure of a single Request frame. A. Request frame: 1. Full frame (Figure 2): First we are selecting a required JSON frame. The frame is basically a collective composition of all the network layers described by the TCP/IP protocol network model. Figure 3 : Frame Details (Request frame) The summary consists of Frame no. 376, bytes on wire 663(5304 bits), bytes captured 663(5304 bits) and the Interface id: 0(eth0). Detailed information about the capture time is also mentioned. Also the network protocols present in total frame is present according to the TCP/IP network model. 2. Ethernet layer (Figure 4): Moving to the next layer, Ethernet layer, It describes the mac address of both Source (00:12:40:57:4a:18) and Destination (b8:27:eb:66:20:50). Also the Type of internet protocol is mentioned, IPv4 (0x0800). Additionally, you can see the manufacturers name i.e. Source is AmoiElectronics while Destination is Raspberry pi. Figure 2 : Full frame (Request frame) The first line in Packet Details Panel (Figure 3: Frame Details) shows the summary of the frame. Figure 4 : Ethernet layer (Request frame) 3. IP layer (Figure 5): The IP layer is concerned with moving between networks, hence the original meaning of the term internetwork, from whence Internet was derived. Highlighting the network layer shows more details. We can see the source( ) and destination( ) IP addresses as well as the IP header length. Here IP version is 4 And Header length 20 bytes. Also other information related to set 2893

$1. Content-Type: application/json; charset=utf-8\r\n Content-Length: 411 Above parameters are mentioned according to the HTTP requirements stated above.$

6 flags, Header checksum and Time to live (TTL) (64) is also mentioned. HTTP (Hypertext Transfer Protocol) protocol is an application layer protocol. We can see the Request method used by the Client is POST Request Method. Request URI: /jsonrpc and the Request Version: HTTP/1.1. Content-Type: application/json; charset=utf-8\r\n Content-Length: 411 Above parameters are mentioned according to the HTTP requirements stated above. It is also mentioned that the response to this frame is in Frame 377. Figure 5 : IP layer (Request frame) 4. TCP layer (Figure 6): The transport layer is where applications communicate via the use of ports. We can see that the source port is 51350, while the destination port is 80 and Seq. No. 2894, Ack. No. 2943, TCP Segment Length 597, Header length 32 bytes,widow size value: 876. Figure 7 : HTTP protocol layer (Request frame) 6. JSON protocol layer (Figure 8 and Figure 9): JSON: application/json is the required dissection content. According to the Request Object Format mentioned above we can see there are 4 member keys mentioned. jsonrpc String Value : 2.0 method String Value : Player.GetItem id Number Value : 110 (so we can conclude that this is not a notification) params Structured Object which holds the parameter properties. Figure 6 : TCP layer (Request frame) 5. HTTP protocol layer (Figure 7): 2894

network layers described by the TCP/IP protocol network model.

Client requests. It is described as a String value. The first line in Packet Details Panel (Figure 11: Frame Details) shows the summary of the frame.

This frame is a Response to the above described Request frame. Frame no. 377 is a Response frame to the above Request Frame (376) as described in the HTTP protocol of Request frame no. 376. B.

7 network layers described by the TCP/IP protocol network model. Figure 8 : JSON protocol layer 1 (Request frame) Figure 10 : Full frame (Response frame) The Member Key properties contains an array which holds all the required properties of the image that the Client requests. It is described as a String value. The first line in Packet Details Panel (Figure 11: Frame Details) shows the summary of the frame. Figure 11 : Frame Details (Response frame) Figure 9 : JSON protocol layer 2 (Request frame) Now we will go through the response frame captured by Wireshark. This frame is a Response to the above described Request frame. Frame no. 377 is a Response frame to the above Request Frame (376) as described in the HTTP protocol of Request frame no B. Response frame 1. Full frame (Figure 10): First we are selecting frame no The frame is basically a Response frame to Request frame no. 376 and is a collective composition of all the The summary consists of Frame no. 377, bytes on wire 628(5024 bits), bytes captured 628(5024 bits) and the Interface id: 0(eth0). Detailed information about the capture time is also mentioned. Also the network protocols present in total frame is present according to the TCP/IP network model. 2. Ethernet layer (Figure 12): Moving to the next layer, Ethernet layer, It describes the mac address of both Source (b8:27:eb:66:20:50) and Destination (00:12:40:57:4a:18). Also the Type of internet protocol is mentioned, IPv4 (0x0800). Additionally, you can see the manufacturers name i.e. Source is Raspberry pi while Destination is Amoi Electronics. 2895

8 Figure 14 TCP layer (Response frame) Figure 12 : Ethernet layer (Response frame) 3. IP layer (Figure 13): The IP layer is concerned with moving between networks, hence the original meaning of the term internetwork, from whence Internet was derived. Highlighting the network layer shows more details. We can see the source ( ) and destination ( ) IP addresses as well as the IP header length. Here IP version is 4 And Header length 20 bytes. Also other information related to set Flags, Header checksum and Time to live (TTL) (64) is also mentioned. 5. HTTP protocol layer (Figure 15): As mentioned earlier, the Request is non-notification type we can see that the success Status Code is 200 with Response Phrase OK. Content-Type : application/json Content-Length : 363. Above parameters are mentioned according to the HTTP requirements stated above. It is also mentioned that the request to this frame is in Frame 376. Figure 13 : IP layer (Response frame) 4. TCP layer (Figure 14): The transport layer is where applications communicate via the use of ports. We can see that the source port is 80, while the destination port is and Seq. No. 2943(This number was Ack. No. in the Request frame), Ack. No. 3491, TCP Segment Length 562, Header length 32 bytes,widow size value: 656. Figure 15 : HTTP protocol layer (Response frame) 6. JSON protocol layer (Figure 16): 2896

JSON: application/json is the required dissection content. According to the Request Object Format mentioned above we can see there are 3 member keys mentioned.

9 JSON: application/json is the required dissection content. According to the Request Object Format mentioned above we can see there are 3 member keys mentioned. id Number Value : 110 (so we can conclude that this is not a notification) jsonrpc String Value : 2.0 result The result gives the total description of the information provided by the Sever to the Client. Here, the information is regarding the picture which is requested by the Client. Properties like file, label, thumbnail, type are mentioned. URL is a part of the body and cannot be seen directly unless dissected. REFERENCES [1] [2] [3] [4] [5] ml [6] [7] -Requests [8] [9] [10] Dr. Mahesh Kumar and Rakhi Yadav, TCP & UDP PACKETS ANALYSIS USING WIRESHARK, IJSETR, Volume 4, Issue 7, July [11] Zia Ul Haq, Gul Faraz Khan and Tazar Hussain, A Comprehensive analysis of XML and JSON web technologies, CSSCC-14. [12] WachyuHari Haji, Web Based Service Optimization with JSON-RPC Platform in Java and PHP, ICETD Rajdeep S. Manjre Embedded Systems Engineer, Unify Netstruments Pvt. Ltd., Pune, Maharashtra, India. Figure 16 : JSON protocol layer (Response frame) IX. CONCLUSION In this paper we discussed about the JSON-RPC protocol over HTTP in detail. We also analyzed the flow of network packets from Source to Destination and vice-versa. The Request and Response Object Format mentioned in JSON-RPC 2.0 Specifications was analyzed using Wireshark, similarities were found between the standard mentioned format and the format described in Wireshark dissection panel. Also, the requirements mentioned in HTTP headers were also exactly seen in the frames specified in the results. Advantages of using POST Request method over GET Request method were also discussed. As we discuss the analysis of JSON-RPC, in future more remote handling protocols like this will be analyzed and the growth in network technologies will be boosted. 2897

Lab 4: Network Packet Capture and Analysis using Wireshark

Lab 4: Network Packet Capture and Analysis using Wireshark 4.1 Details Aim: To provide a foundation in network packet capture and analysis. You may be faced with network traffic analysis, from traffic