Mobile Phone Data Encryption – Why is it necessary?

By balaji

December 30, 2011

Mobile phones are very handy devices and are widely used by people around us for day-to-day functionalities. People are becoming more and more dependent on mobile phones for performing critical functionalities like bank transactions, etc. Subsequently, when people depend more on phones, for faster processing, a lot of sensitive data are stored in the phone and a considerable amount is also transmitted to the server. Any communication or storage for that fact, if not done in a secure manner, is a loophole left behind by a developer of that application! In this article, we will discuss how sensitive data can be encoded in the requests and how any penetration tester can break this encoding logic in order to manipulate and probe the server.

The main factors that make mobile phones vulnerable are as follows:

  • Sensitive data that are transmitted to and from the server:
    Communication from the phone to the server and back contains sensitive information that can be manipulated to perform various transactions and functionalities. This transmitted content may also have decision-making powers such as performing a bulky fund transfer, etc.
  • Sensitive data that are stored in the memory:
    Data from the server are stored in the phone's memory. This data can comprise anything such as authentication information like usernames and mPINs, account details, etc. An mPIN is a numeric pin of 4–6 digits, which is used for authentication purposes in mobile applications instead of passwords. Moreover, sharing the same location among all the applications in the phone makes it more vulnerable to attacks.

A malicious application installed on the same phone as the vulnerable mobile application, can easily steal all the data by reading the entire phone memory. This activity has become easier with the help of "Jail Breaking".

Application Ciphering the Request/Response

Sensitive data can be extracted from an application if it is not encrypted properly. Let's take the example of an ABC company's mobile application.


The above screenshot shows the ABC mobile application requesting the user to enter the UserId and mPIN. The application then extracts the mobile number from the phone's memory and frames a request. The same request is intercepted using the Burp Proxy tool as shown in the screenshot below.


From the highlighted portion of the above screenshot, it is clear that data can be transmitted and stored in any mobile phone in an encoded form. Such an encoding technique not only prevents the appliance from being stolen, but also prevents the theft or discovery of sensitive data in transmission. The encoded request and response, even if captured by any adversary, will as such be rendered useless.

Breaking the Code

The irony of the above scenario is that even after a developer takes pains to encode and decode the data that is transmitted and stored in a mobile phone, there is always a way to break it. Any penetration tester will always check how strong the encoding is by trying to crack the encoding algorithm and gaining access to the data. This is illustrated using a flow chart.


Please note that it is not mandatory that every character has to be replaced by a single character only. There may be scenarios wherein a single character is replaced by an entire string. A penetration tester should always keep this in mind during the process. In the example given below, the string separator has been represented by $45 at multiple locations.

Writing an Encoder–Decoder Program

The process followed by a penetration tester has been written step-by-step in the form of a program. The program can successfully decode and encode all the requests and responses that are generated by the ABC company application. After decoding these requests and responses, their manipulation is possible.

Encoding Table:

Decoding Code Snippet:

Encoding Code Snippet:

Using the Encoder–Decoder class file?

Once the penetration tester has completed programming the class file for encoding and decoding the request and response, the same program can be used to manipulate requests in the following manner:
The request, after decoding, is then manipulated and encoded using the Encoder–Decoder class file for attacking the application as shown in the screenshot below.
The above screenshot displays how an attacker, in spite of the request being encoded, breaks the request and easily manipulates request parameters like the mobile number (or UserId or mPIN) and uses them to probe the server.


Any weak encryption/encoding logic that is used for transmission and storage of sensitive data in the mobile application is a vulnerable implementation. In spite of such ciphering techniques being implemented, an adversary will be able to break the logic using the described process and hence launch an attack.

How can we avoid this? How should an application store all the data onto the phone without it being understood by any other application or any person who tries to sniff the network traffic? The above methodology demonstrates the ease with which an adversary can break the encoding mechanism. The answer to these questions is Mobile Phone Data Encryption.

Encryption is a process whereby data is ciphered such that only authorized persons with key can decipher and read it. Data encrypted with a strong key are safe as they cannot be decoded by any unauthorized person. If transmitted or stored data are encrypted using strong algorithms then only authorized personnel having the appropriate keys will be able to decode it. This implementation is strongly recommended.

The strength of the encryption depends on securing the key. Strong key generation and storage processes should be implemented. User-input-based key derivation brings the randomness in the encryption process. This way a better encryption can be implemented.

Tags: Technical