Reviewing Application Security

Application security has been a hot-button topic since even before Android existed. During the onset of the web application craze, developers fl ocked to quickly develop applications, overlooking basic security practices or using frameworks without adequate security controls. With the advent of mobile applications, that very same cycle is repeating. This chapter begins by discussing some common security issues in Android applications. It concludes with two case studies demonstrating discovery and exploitation of application fl aws using common tools.

Common Issues

With traditional application security, there are numerous issues that crop up repeatedly in security assessment and vulnerability reports. Types of issues range from sensitive information leaks to critical code or command execution vulnerabilities. Android applications aren’t immune to these fl aws, although the vectors to reach those fl aws may differ from traditional applications.
This section covers some of the security issues typically found during Android app security testing engagements and public research. This is certainly not an exhaustive list. As secure app development practices become more commonplace, and Android’s own application programming interfaces (APIs) evolve, it is likely that other fl aws—perhaps even new classes of issues—will come to the forefront.

App Permission Issues

Given the granularity of the Android permission model, there is an opportunity for developers to request more permissions for their app than may be required. This behavior may be due in part to inconsistencies in permission enforcement and documentation. Although the developer reference docs describe most of the permission requirements for given classes and methods, they’re not 100 percent complete or 100 percent accurate. Research teams have attempted to identify some of these inconsistencies in various ways. For example, in 2012, researchers Andrew Reiter and Zach Lanier attempted to map out the permission requirements for the Android API available in Android Open Source Project (AOSP). This led to some interesting conclusions about these gaps.
Among some of the fi ndings in this mapping effort, they discovered inconsistencies between documentation and implementation for some methods in the WiFiManager class. For example, the developer documentation does not mention permission requirements for the startScan method. Figure 4-1 shows a screenshot of the Android development documentation of this method.

This differs from the actual source code for this method (in Android 4.2), which indicates a call to enforceCallingOrSelfPermission, which checks to see if the caller bears the ACCESS_WIFI_STATE permission by way of enforceChangePermission:
public void startScan(boolean forceActive) {
private void enforceChangePermission() {
mContext.enforceCallingOrSelfPermission(android.Manifest. permission.CHANGE_WIFI_STATE,
Another example is the getNeighboringCellInfo method in the TelephonyManager class, whose documentation specifi es a required permission of ACCESS_COARSEUPDATES. Figure 4-2 shows a screenshot of the Android development documentation for this method.

However, if you look through the source code of the PhoneInterfaceManager class (in Android 4.2), which implements the Telephony interface, you see the getNeighboringCellInfo method actually checks for the presence of the ACCESS
FINE_LOCATION or ACCESS_COARSE_LOCATION permissions—neither of which are the nonexistent, invalid permission specifi ed in the documentation:

public List< NeighboringCellInfo > getNeighboringCellInfo() {
try {
} catch (SecurityException e) {
// If we have ACCESS_FINE_LOCATION permission, skip the check


// A failure should throw the SecurityException from

// ACCESS_COARSE_LOCATION since this is the weaker precondition mApp.enforceCallingOrSelfPermission(
android.Manifest.permission.ACCESS_COARSE_LOCATION, null);

These kinds of oversights, while perhaps seemingly innocuous, often lead to bad practices on the part of developers, namely undergranting or, worse, overgranting of permissions. In the case of undergranting, it’s often a reliability or functionality issue, as an unhandled SecurityException leads to the app crashing. As for overgranting, it’s more a security issue; imagine a buggy, overprivileged app exploited by a malicious app, effectively leading to privilege escalation.
For more information on the permission mapping research, see
When analyzing Android applications for excessive permissions, it’s important to compare what permissions are requested to what the application’s purpose really is. Certain permissions, such as CAMERA and SEND_SMS, might be excessive for a third-party app. For these, the desired functionality can be achieved by deferring to the Camera or Messaging applications, and letting them handle the task (with the added safety of user intervention). The “Mobile Security App” case study later in the chapter demonstrates how to identify where in the application’s components those permissions are actually exercised.

Insecure Transmission of Sensitive Data

Because it receives constant scrutiny, the overall idea of transport security (for example, SSL, TLS, and so on) is generally well understood. Unfortunately, this doesn’t always apply in the mobile application world. Perhaps due to a lack of understanding about how to properly implement SSL or TLS, or just the incorrect notion that “if it’s over the carrier’s network, it’s safe,” mobile app developers sometimes fail to protect sensitive data in transit.
This issue tends to manifest in one or more of the following ways:
■ Weak encryption or lack of encryption
■ Strong encryption, but lack of regard for security warnings or certifi cate validation errors
■ Use of plain text after failures
■ Inconsistent use of transport security per network type (for example, cell versus Wi-Fi)
Discovering insecure transmission issues can be as simple as capturing traffi c sent from the target device. Details on building a man-in-the-middle rig are outside the scope of this book, but numerous tools and tutorials exist for facilitating this task. In a pinch, the Android emulator supports both proxying of traffi c as well as dumping traffi c to a PCAP-format packet trace. You can achieve this by passing the -http-proxy or -tcpdump options, respectively.
A prominent public example of insecure data transmission was in the implementation of Google ClientLogin authentication protocol in certain components of Android 2.1 through 2.3.4. This protocol allows for applications to request an authentication token for the user’s Google account, which can then be reused for subsequent transactions against a given service’s API.
In 2011, University of Ulm researchers found that the Calendar and Contacts apps on Android 2.1 through 2.3.3 and the Picasa Sync service on Android 2.3.4 sent the Google ClientLogin authentication token over plaintext HTTP. After an attacker obtained this token, it could be reused to impersonate the user. As numerous tools and techniques exist for conducting man-in-the-middle attacks on Wi-Fi networks, interception of this token would be easy—and would spell bad news for a user on a hostile or untrusted Wi-Fi network.
For more information on the University of Ulm’s Google ClientLogin fi ndings, see

Insecure Data Storage

Android offers multiple standard facilities for data storage—namely Shared Preferences, SQLite databases, and plain old fi les. Furthermore, each of these storage types can be created and accessed in various ways, including managed and native code, or through structured interfaces like Content Providers. The most common mistakes include plaintext storage of sensitive data, unprotected Content Providers (discussed later), and insecure fi le permissions.
One cohesive example of both plaintext storage and insecure fi le permissions is the Skype client for Android, which was found to have these problems in April 2011. Reported by Justin Case (jcase) via, the Skype app created numerous fi les, such as SQLite databases and XML fi les, with world-readable and world-writable permissions. Furthermore, the content was unencrypted and included confi guration data and IM logs. The following output shows jcase’s own Skype app data directory, as well as partial fi le contents:
ls -l /data/data/
-rw-rw-rw- app_152 app_152 331776 2011-04-13 00:08 main.db
-rw-rw-rw- app_152 app_152 119528 2011-04-13 00:08 main.db-journal
-rw-rw-rw- app_152 app_152 40960 2011-04-11 14:05 keyval.db
-rw-rw-rw- app_152 app_152 3522 2011-04-12 23:39 config.xml
drwxrwxrwx app_152 app_152 2011-04-11 14:05 voicemail
-rw-rw-rw- app_152 app_152 0 2011-04-11 14:05 config.lck
-rw-rw-rw- app_152 app_152 61440 2011-04-13 00:08 bistats.db
drwxrwxrwx app_152 app_152 2011-04-12 21:49 chatsync
-rw-rw-rw- app_152 app_152 12824 2011-04-11 14:05 keyval.db-journal
-rw-rw-rw- app_152 app_152 33344 2011-04-13 00:08 bistats.db-journal

grep Default/data/data/

< Default>jcaseap< /Default>

The plaintext storage aspect aside, the insecure fi le permissions were the result of a previously less-well publicized issue with native fi le creation on Android. SQLite databases, Shared Preferences fi les, and plain fi les created through Java interfaces all used a fi le mode of 0660. This rendered the fi le permissions read/ write for the owning user ID and group ID. However, when any fi les were created through native code or external commands, the app process inherited the umask of its parent process, Zygote—a umask of 000, which means world read/ write. The Skype client used native code for much of its functionality, including creating and interacting with these fi les.
(NOTE) As of Android 4.1, the umask for Zygote has been set to a more secure value of 077. More information about this change is presented in Chapter 12.
For more information on jcase’s discovery in Skype, see www.androidpolice .com/2011/04/14/exclusive-vulnerability-in-skype-for-android-is -exposing-your-name-phone-number-chat-logs-and-a-lot-more/.

Information Leakage Through Logs

Android’s log facility is a great source of information leaks. Through developers’ gratuitous use of log methods, often for debugging purposes, applications may log anything from general diagnostic messages to login credentials or other sensitive data. Even system processes, such as the ActivityManager, log fairly verbose messages about Activity invocation. Applications bearing the READ_LOGS permission can obtain access to these log messages (by way of the logcat command).
(NOTE) The READ_LOGS permission is no longer available to third-party applications as of Android 4.1. However, for older versions, and rooted devices, third-party access to this permission and to the logcat command is still possible.

As an example of ActivityManager’s logging verbosity, consider the following log snippet:
I/ActivityManager(13738): START {act=android.intent.action.VIEW dat= (has extras) u=0} from pid 11352
I/ActivityManager(13738): Start proc for activity pid=11433 uid=10017 gids={3003, 1015, 1028}
You see the stock browser being invoked, perhaps by way of the user tapping a link in an e-mail or SMS message. The details of the Intent being passed are clearly visible, and include the URL ( the user is visiting. Although this trivial example may not seem like a major issue, under these circumstances it presents an opportunity to garner some information about a user’s web-browsing activity.
A more cogent example of excessive logging was found in the Firefox browser for Android. Neil Bergman reported this issue on the Mozilla bug tracker in December 2012. Firefox on Android logged browsing activity, including URLs that were visited. In some cases, this included session identifi ers, as Neil pointed out in his bug entry and associated output from the logcat command:
I/GeckoBrowserApp(17773): Favicon successfully loaded for URL =;jsessionid=83CB330691854B071CD172D41DC2C3 AB
I/GeckoBrowserApp(17773): Favicon is for current URL =;jsessionid=83CB330691854B071CD172D41DC2C3 AB
E/GeckoConsole(17773): [JavaScript Warning: "Error in parsing value for 'background'. Declaration dropped." {file: ";jsessionid=83CB330691854B071CD172D41DC2C 3AB?" line: 0}]
In this case, a malicious application (with log access) could potentially harvest these session identifi ers and hijack the victim’s session on the remote web application. For more details on this issue, see the Mozilla bug tracker at https://

Unsecured IPC Endpoints

The common interprocess communication (IPC) endpoints—Services, Activities, BroadcastReceivers, and Content Providers—are often overlooked as potential attack vectors. As both data sources and sinks, interacting with them is highly dependent on their implementation; and their abuse case dependent on their purpose. At its most basic level, protection of these interfaces is typically achieved by way of app permissions (either standard or custom). For example, an application may defi ne an IPC endpoint that should be accessible only by other components in that application or that should be accessible by other applications that request the required permission.
In the event that an IPC endpoint is not properly secured, or a malicious app requests—and is granted—the required permission, there are specifi c considerations for each type of endpoint. Content Providers expose access to structured data by design and therefore are vulnerable to a range of attacks, such as injection or directory traversal. Activities, as a user-facing component, could potentially be used by a malicious app in a user interface (UI)–redressing attack.
Broadcast Receivers are often used to handle implicit Intent messages, or those with loose criteria, such as a system-wide event. For instance, the arrival of a new SMS message causes the Telephony subsystem to broadcast an implicit Intent with the SMS_RECEIVED action. Registered Broadcast Receivers with an intent-fi lter matching this action receive this message. However, the priority attribute of intent-fi lters (not unique just to Broadcast Receivers) can determine the order in which an implicit Intent is delivered, leading to potential hijacking or interception of these messages.
(NOTE) Implicit Intents are those without a specifi c destination component, whereas explicit Intents target a particular application and application component (such as “com.wiley.exampleapp.SomeActivity”).
Services, as discussed in Chapter 2, facilitate background processing for an app. Similar to Broadcast Receivers and Activities, interaction with Services is accomplished using Intents. This includes actions such as starting the service, stopping the service, or binding to the service. A bound service may also expose an additional layer of application-specifi c functionality to other applications. Since this functionality is custom, a developer may be so bold as to expose a method that executes arbitrary commands.
A good example of the potential effect of exploiting an unprotected IPC interface is Andre “sh4ka” Moulu’s discovery in the Samsung Kies application on the Galaxy S3. sh4ka found that Kies, a highly privileged system application (including having the INSTALL_PACKAGES permission) had a BroadcastReceiver that restored application packages (APKs) from the /sdcard/restore directory. The following snippet is from sh4ka’s decompilation of Kies:
public void onReceive(Context paramContext, Intent paramIntent)
if (paramIntent.getAction().toString().equals( "com.intent.action.KIES_START_RESTORE_APK"))
kies_start.m_nKiesActionEvent = 15;

byte[] arrayOfByte11 = new byte[6];

byte[] arrayOfByte12 = paramIntent.getByteArrayExtra("head");

byte[] arrayOfByte13 = paramIntent.getByteArrayExtra("body");

byte[] arrayOfByte14 = new byte[arrayOfByte13.length];
int i4 = arrayOfByte13.length;

System.arraycopy(arrayOfByte13, 0, arrayOfByte14, 0, i4);

StartKiesService(paramContext, arrayOfByte12, arrayOfByte14);


In the code you see the onReceive method accepting an Intent, paramIntent. The call to getAction checks that the value of the action fi eld of paramIntent is KIES_START_RESTORE_APK. If this is true, the method extracts a few extra values, head and body, from paramIntent and then invokes StartKiesService. The call chain ultimately results in Kies iterating through /sdcard/restore, installing each APK therein.
In order to place his own APK in /sdcard/restore with no permissions, sh4ka exploited another issue that yielded the WRITE_EXTERNAL_STORAGE privilege. In his write-up “From 0 perm app to INSTALL_PACKAGES,” sh4ka targeted the ClipboardSaveService on the Samsung GS3. The following code snippet demonstrates this:
Intent intentCreateTemp = new Intent(" CLIPBOARD_SAVE_SERVICE");
intentCreateTemp.putExtra("copyPath", "/data/data/"+getPackageName()+ "/files/avast.apk");
intentCreateTemp.putExtra("pastePath", "/data/data/");
Here, sh4ka’s code creates an Intent destined for, passing in extras containing the source path of his package (in the files directory of his proof-of-concept app’s datastore) and the destination path of /sdcard/restore. Finally, the call to startService sends this Intent off, and ClipboardService effectively copies the APK to /sdcard. All of this happens without the proof-of-concept app holding the WRITE_EXTERNAL_STORAGE permission.

In the coup de grâce, the appropriate Intent is sent to Kies to gain arbitrary package installation:
Intent intentStartRestore = new Intent("com.intent.action.KIES_START_RESTORE_APK");
intentStartRestore.putExtra("head", new String("cocacola").getBytes());
intentStartRestore.putExtra("head", new String("cocacola").getBytes());
intentStartRestore.putExtra("body", new String("cocacola").getBytes());
For more information on sh4ka’s work, check his blog post at

Case Study: Mobile Security App

This section walks through assessing a mobile security/anti-theft Android application. It introduces tools and techniques for static and dynamic analysis techniques, and you see how to perform some basic reverse engineering. The goal is for you to better understand how to attack particular components in this application, as well as uncover any interesting fl aws that may assist in that endeavor.

Profi ling

In the Profi ling phase, you gather some superfi cial information about the target application and get an idea of what you’re up against. Assuming you have little to no information about the application to begin with (sometimes called the “zero-knowledge” or the “black box” approach), it’s important to learn a bit about the developer, the application’s dependencies, and any other notable properties it may have. This will help in determining what techniques to employ in other phases, and it may even reveal some issues on its own, such as utilizing a known-vulnerable library or web service.
First, get an idea of the purpose of the application, its developer, and the development history or reviews. Suffi ce it to say that apps with poor security track records that are published by the same developer may share some issues. Figure 4-3 shows some basic information for a mobile device recovery/antitheft application on the Google Play web interface.

When you examine this entry a bit more, you gather that it requests quite a few permissions. This application, if installed, would be rather privileged as far as third-party apps go. By clicking the Permissions tab in the Play interface, you can observe what permissions are being requested, as shown in Figure 4-4.
Based on the description and some of the listed permissions, you can draw a few conclusions. For example, the description mentions remote locking, wiping, and audio alerting, which, when combined with the READ_SMS permission, could lead you to believe that SMS is used for out-of-band communications, which is common among mobile antivirus apps. Make a note that for later, because it means you might have some SMS receiver code to examine.

Static Analysis

The static analysis phase involves analyzing code and data in the application (and supporting components) without directly executing the application. At the outset, this involves identifying interesting strings, such as hard-coded URIs, credentials, or keys. Following that, you perform additional analyses to construct call graphs, ascertain application logic and fl ow, and discover potential security issues.
Although the Android SDK provides useful tools such as dexdump to disassemble classes.dex, you can fi nd other bits of useful information in other fi les in the APK. Most of these fi les are in various formats, such as binary XML, and might be diffi cult to read with common tools like grep. Using apktool, which can be found at, you can convert these resources into plaintext and also disassemble the Dalvik executable bytecode into an intermediate format known as smali (a format which you’ll see more of later).
Run apktool d with the APK fi le as a parameter to decode the APK’s contents and place the fi les in a directory named after the APK:
~$ apktool d ygib-1.apk
I: Baksmaling...
I: Loading resource table...
I: Decoding values / XMLs...
I: Done.
I: Copying assets and libs...
Now you can grep for interesting strings like URLs in this application, which could help in understanding communications between this application and a web service. You also use grep to ignore any references to .com, a common XML namespace string:
~$ grep -Eir "https?://" ygib-1 | grep -v ""
ygib-1/smali/com/yougetitback/androidapplication/settings/xml/ XmlOperator.smali:
const-string v2, "" ygib-1/res/layout/main.xml: xmlns:ygib="">
ygib-1/res/values/strings.xml: < string >Please enter a previous email address if you already have an account on or a new email address if you wish to have a new account to control this device.< /string > ygib-1/res/values/strings.xml: < string ></ string > ygib-1/res/values/strings.xml:Please create an account on before activating this device"</ string > ygib-1/res/values/strings.xml: < string >
ygib-1/res/values/strings.xml: < string ></ string > ygib-1/res/values/strings.xml: < string >< /string > ygib-1/res/values/strings.xml: < string >< /string > ygib-1/res/values/strings.xml: < string > Account Registration Successful, you can now use the email address and password entered to log in to your personal vault on< /string > ygib-1/res/values/strings.xml: < string >ERROR:creating user account. Please go to where you can reset your password, alternatively enter a new email and password on this screen and we will create a new account for you. Thank You.< /string > ygib-1/res/values/strings.xml: < string > Congratulations you have sucessfully registered. You can now use this email and password provided to login to your personalised vault on </ string > ygib-1/res/values/strings.xml: < string >< /string > ygib-1/res/values/strings.xml: < string > Access your online vault, or change your password at <a></a>< /string >
Although apktool and common UNIX utilities help in a pinch, you need something a bit more powerful. In this case, call on the Python-based reverse engineering and analysis framework Androguard. Although Androguard includes utilities suited to specifi c tasks, this chapter focuses on the androlyze tool in interactive mode, which gives an IPython shell. For starters, just use the AnalyzeAPK method to create appropriate objects representing the APK and its resources; the Dex code itself; and also add an option to use the dad decompiler, so you can convert back to Java pseudo-source:
~$ –s
In [1]: a,d,dx = AnalyzeAPK("/home/ahh/ygib-1.apk",decompiler="dad")
Next, gather some additional cursory information about the application, namely to confi rm what you saw while profi ling. This would include things such as which permissions the application uses, activities the user will most likely interact with, Services that the app runs, and other Intent receivers. Check out permissions fi rst, by calling permissions:
In [23]: a.permissions
These permissions are in line with what you saw when viewing this app in Google Play. You can go a step further with Androguard and fi nd out which classes and methods in the application actually use these permissions, which might help you narrow your analysis to interesting components:
In [28]: show_Permissions(dx) ACCESS_NETWORK_STATE : 1 Lcom/yougetitback/androidapplication/PingService;->deviceOnline()Z (0x22) ---> Landroid/net/ConnectivityManager;>getAllNetworkInfo()[Landroid/net/NetworkInfo; 1 Lcom/yougetitback/androidapplication/PingService;->wifiAvailable()Z (0x12) ---> Landroid/net/ConnectivityManager;>getActiveNetworkInfo()Landroid/net/NetworkInfo;
SEND_SMS : 1 Lcom/yougetitback/androidapplication/ActivateScreen;>sendActivationRequestMessage(Landroid/content/Context; Ljava/lang/String;)V (0x2) ---> Landroid/telephony/SmsManager;>getDefault()Landroid/telephony/SmsManager;
1 Lcom/yougetitback/androidapplication/ActivateScreen; ->sendActivationRequestMessage(Landroid/content/Context;
1 Lcom/yougetitback/androidapplication/ActivationAcknowledgeService;

doPost(Ljava/lang/String; Ljava/lang/String;)Z (0xe) ---> Ljava/net/URL;
1 Lcom/yougetitback/androidapplication/ConfirmPinScreen;->doPost( Ljava/lang/String; Ljava/lang/String;)Z (0xe) ---> Ljava/net/URL;

Although the output was verbose, this trimmed-down snippet shows a few interesting methods, such as the doPost method in the ConfirmPinScreen class, which must open a socket at some point as it exercises android.permission .INTERNET. You can go ahead and disassemble this method to get a handle on what’s happening by calling show on the target method in androlyze:
In [38]: d.CLASS_Lcom_yougetitback_androidapplication_ConfirmPinScreen.
########## Method Information
Ljava/lang/String;)Z [access_flags=private]
########## Params

  • local registers: v0...v10
  • v11:java.lang.String
  • v12:java.lang.String
  • return:boolean

    doPost-BB@0x0 :
    0 (00000000) const/4 v6, 0
    1 (00000002) const/4 v5, 1 [ doPost-BB@0x4 ]

doPost-BB@0x4 :
2 (00000004) new-instance v3, Ljava/net/URL;
3 (00000008) invoke-direct v3, v11, Ljava/net/URL;->< init >

4 (0000000e) invoke-virtual v3, Ljava/net/URL;>openConnection()
5 (00000014) move-result-object v4

6 (00000016) check-cast v4, Ljava/net/HttpURLConnection;

7 (0000001a) iput-object v4, v10, Lcom/yougetitback/ androidapplication/ConfirmPinScreen;->con Ljava/net/HttpURLConnection;

8 (0000001e) iget-object v4, v10, Lcom/yougetitback/ androidapplication/ConfirmPinScreen;->con Ljava/net/HttpURLConnection;

9 (00000022) const-string v7, 'POST'

10 (00000026) invoke-virtual v4, v7, Ljava/net/HttpURLConnection; ->setRequestMethod(Ljava/lang/String;)V

11 (0000002c) iget-object v4, v10, Lcom/yougetitback/ androidapplication/ConfirmPinScreen;->con Ljava/net/HttpURLConnection; 12 (00000030) const-string v7, 'Content-type' 13 (00000034) const-string v8, 'application/ x-www-form-urlencoded'

14 (00000038) invoke-virtual v4, v7, v8, Ljava/net/ HttpURLConnection;->setRequestProperty(Ljava/lang/String; Ljava/lang/String;) V 15 (0000003e) iget-object v4, v10, Lcom/yougetitback/ androidapplication/ConfirmPinScreen;->con Ljava/net/HttpURLConnection; ... 31 (00000084) const-string v7, 'User-Agent'

32 (00000088) const-string v8, 'Android Client' ... 49 (000000d4) iget-object v4, v10, Lcom/yougetitback/ androidapplication/ConfirmPinScreen;->con Ljava/net/HttpURLConnection;

50 (000000d8) const/4 v7, 1

51 (000000da) invoke-virtual v4, v7, Ljava/net/ HttpURLConnection; ->setDoInput(Z)V

52 (000000e0) iget-object v4, v10, Lcom/yougetitback/ androidapplication/ConfirmPinScreen;->con Ljava/net/HttpURLConnection; 53 (000000e4) invoke-virtual v4, Ljava/net/HttpURLConnection; ->connect()V
First you see some basic information about how the Dalvik VM should handle allocation of objects for this method, along with some identifi ers for the method itself. In the actual disassembly that follows, instantiation of objects such as and invocation of that object’s connect method confi rm the use of the INTERNET permission.
You can get a more readable version of this method by decompiling it, which returns output that effectively resembles Java source, by calling source on that same target method:
In [39]: d.CLASS_Lcom_yougetitback_androidapplication_ConfirmPinScreen. METHOD_doPost.source()
private boolean doPost(String p11, String p12)

this.con = new;


this.con.setRequestProperty("Content-type", "application/x-www-form-urlencoded");
this.con.setRequestProperty("Content-Length", new StringBuilder().append(p12.length()).toString());
this.con.setRequestProperty("Connection", "keep-alive"); this.con.setRequestProperty("User-Agent", "Android Client");
this.con.setRequestProperty("accept", "/"); this.con.setRequestProperty("Http-version", "HTTP/1.1");
this.con.setRequestProperty("Content-languages", "en-EN");




v2 = this.con.getOutputStream();


android.util.Log.d("YGIB Test", new StringBuilder("con.getResponseCode()— >").append(this.con.getResponseCode()).toString());
android.util.Log.d("YGIB Test", new StringBuilder( "urlString-->").append(p11).toString());

android.util.Log.d("YGIB Test", new StringBuilder("content-->"). append(p12).toString());
(NOTE) Note that decompilation isn’t perfect, partly due to diff erences between the Dalvik Virtual Machine and the Java Virtual Machine. Representation of control and data fl ow in each aff ect the conversion from Dalvik bytecode to Java pseudo-source.
You see calls to android.util.Log.d, a method which writes a message to the logger with the debug priority. In this case, the application appears to be logging details of the HTTP request, which could be an interesting information leak. You’ll take a look at the log details in action a bit later. For now, see what IPC endpoints may exist in this application, starting with activities. For this, call get_activities:
In [87]: a.get_activities()
In [88]: a.get_main_activity()
Out[88]: u'com.yougetitback.androidapplication.ActivateSplashScreen'
Unsurprisingly, this app has numerous activities, including the ConfirmPinScreen you just analyzed. Next, check Services by calling get_services:
In [113]: a.get_services()
Based on the naming convention of some of these Services (for example, UnlockService and wipe), they will most likely receive and process commands from other application components when certain events are trigged. Next, look at BroadcastReceivers in the app, using get_receivers:
In [115]: a.get_receivers()
Sure enough, you fi nd a Broadcast Receiver that appears to be related to processing SMS messages, likely for out-of-band communications such as locking and wiping the device. Because the application requests the READ_SMS permission, and you see a curiously named Broadcast Receiver, SmsIntentReceiver, chances are good that the application’s manifest contains an Intent fi lter for the SMS_RECEIVED broadcast. You can view the contents of AndroidManifest.xml in androlyze with just a couple of lines of Python:

In [77]: for e in x.getElementsByTagName("receiver"):
print e.toxml()

action >

Comments 0