CodeInspect: An Analysis Tool For Android Apps

A detailed analysis, that an Android app is really safe and the user data are protected, is possible only with expert knowledge and time-consuming. In the Fraunhofer SIT CodeInspect was developed, which should facilitate the work of app analysts. How it works is explained using an example.

Smartphone security experts, forensics, penetration testers, developers of Android apps, but also app – students want to know: one contains app security holes? Are data in an app safely stored? The (Safety) standards of our company meets an app? Why does an app crash? Often the required expertise or the time is missing however, such – part – very complex questions.

However, the need for complex app analysis is not limited to the security area. App developers often require a detailed understanding of an application to identify, for example, programming errors in your own app and mend. Such patches are sometimes very time-consuming, in particular through necessary as a preliminary detailed analysis of the application.

Find cheap phone and data rates in the comparison

for example all-net & surf Flex L for only €9.99 per month

The identification of programming errors in externally-linked libraries that have not even been implemented is particularly problematic. Because the app developer has the source code of the external library nor the library developers have the source code of the app, the exact identification of the cause of the crash for both parties is very time-consuming.

I would like to introduce now a framework called CodeInspect, which you in detail and without special expertise to analyze Android apps, even if there is no source code.

To answer questions such as “My data will be stored in this app safe?” or “Where is the programming error that leads to the crash?”, the framework provides different functionality.

Imagining the basic functions of this framework on the basis of an analysis of a defective application of the so-called BadAccents malware family, as an example. The examples include original code snippets that have not been modified by me.

Apps can be loaded from the hard disk as well as directly from the Smartphone in CodeInspect. Figure 1 displays CodeInspect after an application is imported. CodeInspect is built on the Eclipse environment, the surface very much recalls the Eclipse IDE. So programmers or analysts who once worked with Eclipse or an other IDE should navigate quickly with CodeInspect.

Standard functions

CodeInspect first translates the binary code of the app in a human-readable intermediate language called “Jimple”. Figure 2 shows an example of a method in the Jimple intermediate representation.

A complete reversion of binary Android applications in the source code representation (Java code) is possible in many cases as a result of Obfuskierungstechnikennicht. In the cases where the reversion is possible, however, the class can be represented as Java code (fig. 3).

Common development environments such as Eclipse and Android Studio offer the developer of an app a variety of functions, for example, renaming variables, fields, and methods, uncomment or change of lines of code, adding new code, displaying methods call hierarchies and type hierarchies, etc.

These features are relevant, but also very helpful in analyzing Android applications not only for developers, to find out details about the specific behavior of an app.

CodeInspect provides all of these features also the analysts, without requiring access to the source code of the app. So he can find out very quickly, for example, with the help of the methods call hierarchy about which methods the program flow to a specific line of code.

Example, Figure 4 shows that the method is called sendSMS only when a SMS is received (com.a.a.AR), a call arrives (CallService) or the user clicks a certain button (red points).

In the following I will describe the additional analysis functions now, the CodeInspect of the features already known from a normal development environment offers to assist the analysts even better in his work.

Values view

The values view lists all constant values are located in the application. In addition, the view provides the ability to set your own or predefined filters. Picture 5 shows, for example, all of the constants in the code, refer to the additional APK files (extension to .apk). In this example, the defective application loads after additional code or even more malicious apps from the SD card. Further, also HTTP connections are listed including the application connects. These are very important information during a security analysis of an application.

Permission view

The permission view provides additional important information about the use of sensitive methods. If an Android developer wants to implement a sensitive method, such as the sending of SMS messages, it must for its app a specific permission (android.permission. SEND_SMS in this case) set. The permission view shows in CodeInspect to each permission, where the corresponding methods that use this permission, be invoked in the app. Figure 6 shows that the app has two methods for sending SMS messages. If the analyst clicks on a method, he jumps directly to the respective line of program code. This allows him to understand under what conditions the message will be shipped, for example, to find out whether sensitive data at this point are sent unprotected.

Byte-code debugging

CodeInspect offers also the possibility to debug applications on the human-readable Jimple intermediate language step by step. This provides a detailed insights analysts about the functionality of the application at run time. Using the debugger, he can see, for example, whether a password in the app is stored really sure because the handling of password can be traced step by step.

An analyst can do so very quickly locate the cause program errors. Picture 7 shows an example at the breakpoint at line 163, as incoming SMS messages are examined in a particular format. This breakpoint is reached, unless sent an SMS message to the device. The app responds and verifies the sender’s number, whether it starts with + 86 or + 82 (line 166). These two area codes correspond to China and South Korea.

The sending of an SMS message can be in CodeInspect with the help of an additional plug-in the met (fig. 8). Once sent the SMS to the device, stop the application on line 163.

Figure 9 shows that the variable “$String” has the value “12345678” (telephone number, which is specified in Figure 8). If the analyst in the code step by step continues, he reached a point (line 66 in Figure 9), on which the app will send the contents of the incoming SMS message by E-mail to the attacker. You can see that the method “MailSend” with different arguments is called, where the contents of the mail (contents of $String) is our received text message that has a time stamp. In this example CodeInspect has helps analysts identify a data theft of incoming SMS messages by E-mail.

Data flow

In many cases, it is necessary to find out what data in an app where to be sent. For example, it may violate guidelines in the company or regulatory requirements, to send some sensitive data to servers in other countries. To edit such issues, CodeInspect has a feature called “Data flow”.

In Figure 10 (upper part red marked) is a UI to see, that processes credit cards relevant data. The data flow view (lower part of the image) shows that the data entered in the text box (left side) directly via SMS to the attacker is sent (right side row 15)–so send the app credit card information via SMS to the attacker. CodeInspect displays the source (the TextBox in this case), the sink (SMS), and any lines of code that process sensitive data on the path from the source to the sink, for each such data flows. The CodeInspect function is specially useful for privacy and compliance issues.

The presented features of CodeInspect and more, which in this article were not described you can see in the video. You can download a fully functional demo of the site.

What’s next with CodeInspect?

CodeInspect is very actively being developed. The moment is working mainly on automatic vulnerability detection and dynamic analyses, so that in the future even more precise information is available will be the app analysts.