• No results found

JSON-RPC NETWORK PROTOCOL ANALYSIS USING WIRESHARK

N/A
N/A
Protected

Academic year: 2020

Share "JSON-RPC NETWORK PROTOCOL ANALYSIS USING WIRESHARK"

Copied!
9
0
0

Loading.... (view fulltext now)

Full text

(1)

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.

IV. JSON-RPC(JSON DATA FORMAT) A. Overview

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).

JSON-RPC NETWORK PROTOCOL ANALYSIS USING WIRESHARK

Rajdeep S. Manjre

(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 (ClientServer)

Response (ServerClient)

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.

‘http://<your-ip>:<your-port>/jsonrpc’

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.

‘http://<your-ip>:<your-port>/jsonrpc?request=<url-enco ded-request>’

Following comparison between POST and GET method (Table1) mentioned [7] concludes that POST request method should be the preferred one.

(3)

Table 1 : Comparison between POST and GET Request methods [7]

Paramet ers

POST GET

Encodin g type

application/x -www-form-urlen

coded or

multipart/form-da ta. Use multipart encoding for binary data

application/x -www-form -urlencoded

Restrict ions on data length

No restrictions. 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.

Restrict ions on data type

No

restrictions.

Binary data is also allowed.

Only ASCII characters allowed.

Security POST is a little safer than GET because the parameters are not stored in browser history or in web server logs

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!

Visibilit

y Data is not

displayed in the URL

Data is visible to everyone in the URL

Bookm arked

Cannot be

bookmarked

Can

be bookmarked Cached Cannot be cached Can be cached History Parameters are not

saved in browser history.

Parameters

remain in

browser history.

BACK button/

Reload

Data will be re-submitted (the browser should alert the user that the data are about

to be

re-submitted)

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.

(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

32700 Parse error

Invalid JSON was received by the server.

An error occurred on the server while parsing the JSON text.

-32600 Invalid

Request The JSON sent is not a valid Request object.

-32601 Method not found

The method does not exist / is not available.

-32602 Invalid

params Invalid method

parameter(s).

-32603 Internal

error Internal JSON-RPC

error.

-32000 to

-32099 Server error

Reserved for

implementation-defined 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 802.11, 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.

(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 2 : Full frame (Request frame)

The first line in Packet Details Panel (Figure 3:

Frame Details) shows the summary of the frame.

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 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(192.168.1.2) and destination(192.168.1.8) 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

(6)

flags, Header checksum and Time to live (TTL) (64) is also mentioned.

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 6 : TCP layer (Request frame)

5. HTTP protocol layer (Figure 7):

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 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.

(7)

Figure 8 : JSON protocol layer 1 (Request 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.

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. 376.

B. Response frame

1. Full frame (Figure 10):

First we are selecting frame no. 377. The frame is basically a Response frame to Request frame no.

376 and is a collective composition of all the

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

Figure 10 : Full frame (Response frame)

The first line in Packet Details Panel (Figure 11:

Frame Details) shows the summary of the frame.

Figure 11 : Frame Details (Response frame)

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.

(8)

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 (192.168.1.8) and destination (192.168.1.2) 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.

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 51350 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 14 TCP layer (Response frame)

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 15 : HTTP protocol layer (Response frame) 6. JSON protocol layer (Figure 16):

(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.

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.

REFERENCES [1] http://kodi.wiki/view/JSON-RPC_API.

[2] http://www.jsonrpc.org/

[3] https://kodi.tv/kore-the-new-official-android-remote/

[4] https://kodi.tv/about/

[5] http://www.jsonrpc.org/historical/json-rpc-over-http.ht ml

[6] https://tools.ietf.org/html/rfc4627

[7] http://www.diffen.com/difference/GET-vs-POST-HTTP -Requests

[8] https://www.wireshark.org/

[9] https://www.cs.cf.ac.uk/Dave/C/node33.html

[10] Dr. Mahesh Kumar and Rakhi Yadav, “TCP & UDP PACKETS ANALYSIS USING WIRESHARK”, IJSETR, Volume 4, Issue 7, July 2015.

[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 2012.

Rajdeep S. Manjre

Embedded Systems Engineer, Unify Netstruments Pvt. Ltd., Pune, Maharashtra, India.

Figure

Table 1 : Comparison between POST and GET Request methods [7] Paramet ers POST GET Encodin g type application/x -www-form-urlen coded or multipart/form-da ta
Table 2 : Error codes
Figure 3 : Frame Details (Request frame)
Figure 5 : IP layer (Request frame)
+4

References

Related documents

Does the Grantee have an implementation plan and/or schedule to monitor at least 5% of the completed SERC units in state or territory per year. Is the Grantee implementing

Joshua Pruyn (former Admissions Representative, Alta College, Inc., Denver CO), Testimony before the Senate Committee on Health, Education, Labor, and Pensions, For-Profit Schools:

Json with php curl post method variables are checking to check whether to return an http?. Filtering by HTTP Method in Wireshark

Wireshark is a GUI network protocol analyzer It lets you interactively browse packet data process a stream network or resurrect a previously saved capture file Wireshark's

[Argentina] New Data on Exploited Pleistocene Fauna at Piedra Museo (Central Plateau of Santa Cruz Province, Argentina).. Laura Marchionni and

[r]

File and you for body request using rest assured post to add rest http post request using json objects and the server code using http protocol communication in path?. Relating to

Asst Finance Executive Consultant-SKP Cross Consultant Head Finance CFO Director - Finance Technical Head Accounts Executive VP-Finance MD Finance Executive Manager