Saturday, 20 December 2014

Debugging Java applications using JDB

0 comments Posted by srini0x00 on 20:18
This article walks the readers through debugging java programs using a command line tool called JDB. Though this article doesn’t touch android concepts, this is a prerequisite to understand the next article coming in the series which is “Exploiting Debuggable Android Applications”.

What is JDB?

JDB is a java debugger is a simple command line debugger for java classes. It comes preinstalled with JDK.
I am using Ubuntu machine for this article, so we can locate JDB by navigating to /usr/bin directory as shown below
cd /usr/bin
ls | grep jdb

Note: If you are using a windows machine, it will be available in bin directory of java path. This article is written in Ubuntu machine and all the techniques shown here are almost same even in windows.


In this article, rather than typing jdb commands blindly and looking at the usage, we take a sample java application to understand how to use jdb commands based on the scenario. The whole idea is to understand jdb and its usage in debugging java programs.
Below is the sample code I have taken as an example:

Name of the source code file:
Class file generated: Debug.class

The code snippet shown above has two methods which are invoked from main method of Debug class and when we execute it after compiling, it shows the output as shown in the screenshot below, which is expected. 

We have compiled our java program with “–g” option so that we get some extra debugging information in the generated class file.

Running jdb:

To debug java applications, there must be a communication channel between JDB and JVM, since our java program would run inside Java Virtual Machine.
There are multiple ways to connect JDB to JVM as shown below.

Method 1:

In this method, we can directly load our class file into jdb. JDB will automatically start JVM and a connection will be established.

Debug is the class file generated after compiling the source code.

Method 2:

In this method, we first launch the JVM using the following command so that JVM will start listening on port 54321.
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=54321 Debug 

Then start jdb using the following command to connect to the JVM on port 54321.
jdb -attach 54321

This second method can be used to do remote debugging also. We will use remote debugging in the next article to exploit debuggable android applications. In this article we will use method 1 to cover both the flavors.

Beginning with Debugging:

Let’s start debugging the sample java application using method 1 by invoking JVM directly with JDB. But, to start JVM, we need to explicitly give the command “run” as shown in the following figure.

The above figure shows that JVM has been started and the program has finished executing and the application exited. To stop the flow and manually execute each line, we need to set break points before running the application.
We can set breakpoints at the beginning of a method using “stop in” command. We can do this as shown in the following figure.

We can see that we have set up a break point in method main which is in the class Debug. Type of parameters is also specified.
Let’s now start JVM and run the program to hit the break point. We use “run” command as shown earlier.

As expected, breakpoint is hit, and jdb is also showing the next line to be executed which is
System.out.println(“We are in main method”);
To look at the source code around the current location, we can execute the command “list” as shown below.

To see all the breakpoints set, we can use the command “clear” as shown below.

As we set, it is showing the place where we set the breakpoint.
To see all the thread groups, we can run the command threadgoups.

As we can see, there are two thread groups available “system” and “main”.
We can see all the threads, by running the command “theards” as shown below.

If you observe the above figure, we have three threads in system thread group and one thread with the name “main” in main thread group in running state. This is what we are going to debug in this article.
We can see the information about all the classes loaded in JVM using “classes” command as shown below.

The above figure shows all the classes loaded in JVM currently (the output is truncated to save space).
To see more information about a particular class, we can use the following command.
class <classname>
Below screenshot shows specific details of our current class “Debug”.

Similarly, we can see the information about any class. As an example let’s inspect The output looks as shown below.

To see the list of methods loaded, we can use the command “methods <classname>” as shown below.

The above mentioned commands are few important commands that one may need. Now, let’s start looking at the flow of the program and see how jdb can help us in debugging the application.
To go execute the next line, which is System.out.println(“We are in main method”); we can type the command “next”.

As expected, the execution is completed and JDB is showing the next line to be executed, which is a call to the method “test”.
Here, if we give “next” command, it will finish executing the definition and control comes back to the next line, which is call to “passCheck” method in our case. This is shown in the figure below.

As explained, it has finished executing the definition of test method and now waiting to execute the next line passCheck(“srini0x00);
Now, if we want to get into the method definition and control the flow inside the definition, we should run the command “step” rather than “next”.
I have restarted my program and now, giving “step” command at the same line as shown in the figure.

Now, we can run “next” command to continue to the next line as shown below.

At this point, for some reason if we want to get out of the method definition, rather than executing the rest of the lines inside the definition, we can run the command “step up” as shown below.

As expected, it has exited from the definition and control is now in main method waiting to execute the next line.
The next couple of lines are going to be interesting as we are going to see the commands to view the secret messages stored in variables. Before going there, I would like to explain one more interesting command called “where”.
“where” command shows the current call stack. So, let’s run it inside main method and see the current call stack. Later let’s ruin the same command inside a method definition to understand its functionality.

As we could see, we are currently inside the method Debug.main.
Let’s now, give a “step” command and get into the method definition and check the current call stack inside the method. This is shown in the following figures.

The above figure shows the current location as “Debug.passCheck” and it is called from “Debug.main”.
Now, we are inside passCheck method. So, let’s see if there are any interesting local variables holding some sensitive information. We can see all the local variables using the command “locals”. (This doesn’t work if the code is not compiled using “-g” option).

As we can see, the call has sent a password to the method definition as an argument and it is displayed. The above figure is showing, only method arguments since they are not yet assigned to the local variable declared inside the definition yet. We can execute the next line and see the value of local variable “password”.
We can use print command to print the value of a specific variable as shown below.


This article has explained the basics of JDB, various JDB commands and how to apply them for debugging java applications. It has also provided the necessary information to understand the next article in the series.


Note: This article is originally written by me for Infosec Institute

Friday, 19 December 2014

Unintended Data Leakage (Side Channel Data Leakage)

0 comments Posted by srini0x00 on 20:29
In this Article, we will discuss "Unintended Data Leakage" which was formerly known as “Side Channel Data Leakage”.

What is Unintended Data Leakage?

When an application processes sensitive information taken as input from the User or any other source, it may result in placing that data in an insecure location in the device. This insecure location could be accessible to other malicious apps running on the same device thus leaving the device in a serious risk.

Security Risks:

Code becomes vulnerable to serious attacks since exploiting these side channel data leakage vulnerabilities is very easy. An attacker can simply write a small piece of code to access the location where the sensitive information is stored. We can even use tools like adb to access these locations.

Example scenarios for unintended data leakage:

Below is the list of example scenarios where unintended data leakage flaws may exist.

  • Leaking Content Providers
  • Copy/Paste buffer Caching
  • Logging
  • URL Caching
  • Browser cookie objects
  • Analytics data sent to 3rd parties
In the next section, I will demonstrate how some of the above scenarios can be exploited by attackers.

      1.    Leaking Content Providers:

Though, this is vulnerability doesn’t place its contents anywhere on the device, data can be easily extracted from leaking content providers using a malicious app.
A detailed writing of how this can be accomplished can be read here.

      2.    Copy/Paste buffer Caching:

Copy/paste buffer caching is one more dangerous problem in android devices. Users generally tend to copy and paste a lot of things due to the space limitations on the mobile screen. If a user copies any sensitive information such as credit card number to the clip board, an attacker can easily read it with a small piece of code running on the same device as shown below. This may lead to a serious damage since the attacker can access this information remotely sitting anywhere in the world using the app running on the victim’s device.

I have developed a simple app using the same piece of code given above to demonstrate how a malicious app can read the clipboard to access sensitive information copied by the user.
The scenario is, the user has copied a secret message to the clipboard when he is using a legitimate app. Now, we are reading that message from the clipboard using our malicious app. below is the screenshot.

Though we are just reading and printing the message on the screen for demo purposes, an attacker can remotely access this by sending it to remote server controlled by him.

      3.    Logging:

Android “Logs” is a great place to look for Information Leakage. Logging Techniques are generally used by developers for debugging purposes during their application development. In this section, we will see how an attacker can exploit this information leakage via logs. During a pentest, we can test for information leaks via logcat in multiple ways as described in the next section.

     3.1 Using Eclipse:

If you are running eclipse IDE, connect your device/emulator to the machine. We can see all the logs under “logcat” option when your app is running and observe if any sensitive information is logged. Below is the screenshot of a test application logging its user passwords in logs. 

     3.2 Using ADB:

We can also look at the logs using adb.
First connect your device or emulator to your machine using adb and type the following command:
adb logcat
It will display all the logs in the terminal as shown in the figure below. We can inspect those logs for sensitive information. The figure below is showing the dump of all the system events along with the application logs we are interested to inspect. We can filter the output using the options available in logcat.

  • -v verbose
  • -d debug
  • -i information
  • -e error
  • -w warning

We can even write this output into a file using the following command
adb logcat > output.txt
Now we can save this output.txt file somewhere on the local machine and inspect it further.

     3.3 Using a malicious Application:

We can even develop a malicious application which can read logs from the device using the following code.

Note:  READ_LOGS permission is disabled for third party apps on the regular devices right from Jellybean (Android 4.1 API level 16). We can still run the code on rooted devices/emulators with elevated privileges.

4.URL Caching and Browser Cookie Objects:

There have been plenty of issues with web view based applications which leak URLs, Cookies and Cached information on the device which allows an attacker to take over the session of the user. This caching could be in any form including logs, web history, web cache etc.
We can filter the logcat output using grep and inspect the logs for sensitive information such as cookies with the command shown below.
adb logcat | grep “cookie”
Many applications do not disable caching of the applications. This can be easily avoided using HTTP’s caching headers such as “no-cache”, “no-store”. 
There are numerous vulnerabilities reported on this. Please look at the references at the end of the article for more information on this.

5. Analytics data sent to 3rd parties:

There could be scenarios where apps use third party APIs. Using this app, the third party APIs may read sensitive information such as Device ID, Location from the device.


As per OWASP Mobile TOP 10 list released in 2014, unintended data leakage is in 4th place. Though, it looks like a simple vulnerability it creates serious risk depending upon the criticality of the information being leaked. So it is highly recommended for developer to look into this during the development of an application as it is super easy for an attacker to detect data leakage by inspecting all mobile device locations that are accessible to all apps.


Note: This article is originally written by me for Infosec Institute.

Friday, 30 May 2014

Launching - Android Application Pentesting Video Course

0 comments Posted by srini0x00 on 03:53
I am delighted to announce our Video Course on Android Application Penetration Testing.

 After starting my blog, I got several requests from readers asking me to make a simple video series beginning from basics. I always wished I had time to do a complete video series. But when John of approached me with an idea to start JSInfosec and release the video series on Android Security, I got some moral boost to start the things. As a result of that conversation we are launching a complete course which can surely help you in becoming an Android Application Penetration Tester. I am sure you would love the series since it is designed in such a way that even a beginner in the field of mobile security can learn the techniques.

Release Date: 31st May 2014
Course Price: $99

For more details, 
write us

Friday, 25 April 2014

Exploiting Content Provider Leakage

1 comments Posted by srini0x00 on 06:13


In the previous article, we discussed how an attacker exploits vulnerable Activity Components and ways to secure them. In this Article, we will discuss "Content Provider Leakage". 

What are content Providers?

As per Google’s inbuilt security model, Application data is private to an application and hence it is not possible for an application to access other application’s data by default. When applications want to share their data with other applications, Content Provider is a way which acts as an interface for sharing data between applications. Content providers use standard insert(), query(), update(), delete() methods to access application data. A special form of URI which starts with “content://” is assigned to each content provider. Any app which knows this URI can insert, update, delete and query data from database of the provider app. 
There may be some cases where content providers might not be implemented for sharing data with other apps, or developer may want to give access only to those apps which have proper permissions. In such cases, if proper security controls are not enforced in the app, that leads to leakage of information.
Inbuilt SMS application in Android devices is a classic example of content providers. Any app can query the inbox from the device using it’s URI content://sms/inbox.   But, READ_SMS permission must be declared in the app’s AndroidManifest.xml file in order to access SMS app’s data.

Prerequisites to follow the steps:

Computer with Android SDK Installed
A Non Rooted mobile device to install the app.

Test Application’s functionality:

Once after downloading the test application, install it in the non rooted android device in order to test and exploit it. 
It can be installed with adb using the following command
adb install <name of the apk>.apk
It has a feature to store data inside the application. When we launch it, it appears as shown in the figure. 
The Goal is to find out if there are any content providers implemented in this app and if YES, We need to check and exploit if they are vulnerable to data leakage.

Topics Involved:

Information gathering
Attacking Vulnerable Content Providers
Securing the applications

Information gathering

Like any other pentest, let’s start with information gathering. We assume that we have the APK file with us. So, decompile the downloaded apk file as shown in the previous article and check AndroidManifest.xml file for any registered content providers. We should also check the smali files for all the URIs used in the app.
Content Providers are generally registered in AndroidManifest.xml file in the following format.
So let’s go ahead and examine the manifest file.
We got one content provider registered in the AndroidManifest.xml file and good news is, it is exported to be accessed by all other apps. 

Attacking Vulnerable Content Providers

This is the most interesting part. Let’s now try to query the content provider we found. If it returns any data, then it is vulnerable. This can be done in multiple ways.
1. Using adb shell
2. Using a Malicious app to query
3. Using Mercury Framework
Using adb:
To query the content provider from adb, the app should be installed on the device. 
Get an adb shell on the device and type the following command to query the content provider. In my case, I am going to query the URI I found in MyProvider.smali file which is extracted by APK tool.

Content –query –uri content://com.isi.contentprovider.MyProvider/udetails
We should now see all the details stored into the app’s db as show in the figure below.

Using a Malicious app to query:
We can even write a malicious app to query the data from its content provider. Following is the code snippet to query the inbox from a mobile device. 

Using Mercury Framework:
The entire process can be carried out using Mercury framework in even more efficient and simple way.
Securing the Applications:
1. Setting android:exported attribute’s value to false:
In the AndroidManifest.xml file of our application, we should add the following attribute to the content provider to be secured. In our case com.isi.contentprovider.MyProvider is the content provider.
If we try to query the content provider whose android:exported value is set to false, it will throw an exception as shown below.
Note: The Default value of android:exported is true for all the applications using API Level lower than 17.
2. Limiting access with custom permissions

We can also impose permission-based restrictions by defining custom permissions for an activity. This is helpful if the developer wants to limit the access to his app’s components to those apps which have permissions.

Other issues with Content Providers:

SQL Injection: If security controls are not properly implemented, content providers can lead to Client Side attacks like SQL Injection. This works similar to traditional SQL Injection attacks.
Path Traversal: This is one more attack which can be carried out, if a content provider is not properly implemented. This is similar to the path traversal attacks on Web Applications. It allows an attacker to traverse and view the local file system. Sensitive files can be transferred from the device to the local machine using an app vulnerable to Path Traversal attack.

Note: You can download the sample application used in this article and follow the steps along with us.
 Download Link: Click Here

Feel free to post your suggestions and Questions.

Exploiting and Securing Application Components

0 comments Posted by srini0x00 on 05:14


Mobile Application Security is one of the hottest segments in the security world as security is really a big concern with growing mobile applications. In this Article, we will go through the attacks associated with Android Application Components.

What are Android Application Components?

App components are essential building blocks of an Android App. Every app is built as a combination of some or all of those components which can be invoked individually. There are 4 main components in Android which are explained below.

 Activity: An Activity provides a screen with which users can interact in order to do something. Users can perform operations such as making a call, Sending an SMS etc.
Example: Login screen of your facebook app.

Service: A Service can perform long-running operations in the background and does not provide a user interface.
Example: Playing Music

Content Providers: A content provider presents data to external applications as one or more tables. In other words, content providers can be treated as interfaces that connect data in one process with code running in another process.
Example: Using content providers, any app can read SMS from inbuilt SMS App’s repository in our device.
*READ_SMS permission must be declared in the app’s AndroidManifest.xml file in order to access SMS app’s data.

Broadcast Receivers: A broadcast receiver is a component that responds to system-wide broadcast announcements such as Battery Low, boot completed, headset plug etc. Though most of the broadcast receivers are originated by the system, applications can also announce broadcasts.
This article focuses on demonstrating the methodology to attack and secure vulnerable Activity components of Applications.  


As shown in the figure below, it has two activities. The first activity takes a password as input. If the user enters the correct password he will be landed in a page which says “Private Area”, else he will get a message “Wrong password”. For test purposes, the password to login is set as “password”. Ideally, the first screen should use an intent and invoke the second screen if a valid password is entered. We need to perform black box testing on this app to see if we can bypass the authentication by directly invoking the welcome screen.

Prerequisites to follow the steps

Computer with Android SDK Installed
A Non Rooted mobile device to install the app.

Topics Involved:

Information gathering
Attacking Vulnerable Activity Components
Securing the applications

Information gathering

1.       Decompile the app with APK tool
2.       Analyze AndroidManifest.xml file for exported Activity components.

Every Android App has a package name and every Activity has its own Class name inside the package. The initial steps are to find out the name of the package and names of the available sensitive activities. Though, there are other methods to get this information, looking at the AndroidManifest.xml is a good approach. We can get the AndroidManifest.xml file by decompiling the application using APKTOOL.
1.       Download APKTOOL from here
2.       Place the test application in the same folder as in APKTOOL
3.       Now, decompile the apk file using the following command as shown in figure.
apktool d testapp.apk
As shown in the figure below, we should now be able to see a new folder named “testapp” with AndroidManifest.xml file inside it.
Now, we need to search for the package name and its activities.
All the activities will be registered in AndroidManifest.xml file using <activity></activity> tags. So, anything inside these tags will be an activity. Looking at the AndroidManifest.xml file, we are able to see two Activity Components and the package name as shown in the figure below.

By examining the above figure, it is clear that we got the following information about the app.
com.isi.testapp is the name of the package.
com.isi.testapp.Welcome could be the activity we are getting after providing the correct password.

Attacking Vulnerable Activity Components

Our job now is to launch Welcome activity without providing any password in the first screen.
We can perform attacks on vulnerable activity components in several ways as mentioned below.
1.       Launching sensitive Activities with Activity Manager Tool.
2.       Using a Malicious App to invoke Activities of other apps.
3.       We can also use Mercury framework for performing these attacks which will be covered in later articles.

Launching sensitive activities with Activity manager tool:

Activity Manager is a tool that comes preinstalled with Android SDK and can be used along with “adb shell”. This tool can be used to launch activities and Services of an application. We can even pass intents using it.
So, let’s begin.
1.       Connect the device to the computer and get a shell on the device using the following command

adb shell

2.       Type in the following command to launch Welcome activity.

am start –n com.isi.testapp/.Welcome

We should now see the welcome screen fired up by am tool without providing the password.

Using a Malicious App to invoke Activities of other apps:

Another way of invoking other application’s activities is to write a malicious app and feed it with the name of the package and activity to be launched. The figure below is a code snippet to launch an activity where in com.isi.testapp.Welcome is the activity to be launched. In our case, malicious app doesn’t require any permission to launch “Welcome” activity of vulnerable app.

Using Mercury framework:

The same attack can be reproduced with mercury framework. We will discuss mercury framework later in this series.

Securing the application components

1.       Setting up android:exported attribute’s value to false

In the AndroidManifest.xml file of our application, we should add the following attribute to the application component to be secured. In our case com.isi.testapp.Welcome is the activity to be secured.
The above code restricts other applications or any system component other than the current app from accessing this Activity.  Only applications that have the same user id as the current app will be able to access this Activity.

1.       Limiting access with custom permissions

android:exported attribute is not the only way to limit an activity's exposure to other applications. We can also impose permission based restrictions by defining custom permissions for an activity. This is helpful if the developer wants to limit the access to his app’s components to those apps which have permissions.
Note: The above security controls are applicable to any other Application component which we discussed in the beginning of the article.


Note: You can download the sample application used in this article and follow the steps along with us.
 Download Link: Click Here

Feel free to post your suggestions and Questions.

Friday, 24 January 2014

ARM Assembly Part 3 - "Hello world" in ARM assembly

0 comments Posted by srini0x00 on 02:00


This article gives you the taste of writing your first program in ARM assembly. The series eventually takes you towards advanced ARM assembly concepts, writing shell code and ARM Exploitation. To follow this series, you need to have the lab setup which is explained here.

We are going to write a very simple program which prints the string "Hello World\n". In order to simplify our task, we will take advantage of system calls to print the string on the output screen and exit the program.

What is System Call?

Operating Systems contain routines to perform various low level operations. If we want to invoke these operating system routines from our program, we need to make system calls.

From Wikipedia, "A system call is how a program requests a service from an operating system's kernel. This may include hardware related services (e.g. accessing the hard disk), creating and executing new processes, and communicating with integral kernel services (like scheduling). System calls provide an essential interface between a process and the operating system."

How do I check the list of systemcalls?

Type in the following command in terminal.

cat /usr/include/asm/unistd.h

In this program, we will use write and exit syscalls as shown in figure 1.1 and figure 1.2. As we can clearly see in the figures, write has the system call number 4 and exit has the system call number 1.
Figure 1.1
Figure 1.2

We can check the man files to know the usage of these syscalls which looks as shown in figure 1.3 and figure 1.4.

Figure 1.3
Figure 1.4

Your First Program

Now open any editor of your choice and type in the following program, then save it as "filename.s". In my case, I am using Vim editor. Every line in the program is self explanatory as i have given explanation in the comments.
Figure 1.5

The registers r0, r1, r2 are being used for data operations. When we work with syscalls, register r7 should be used to store syscall number.

Note: In the next article, we will have a detailed explanation of ARM registers and how we use them.

SVC in the above program is an instruction that generates a supervisor call. Supervisor calls are normally used to request privileged operations or access to system resources from an operating system. In simple words, SVC is used to generate an interrupt(in our case, write and exit).

Once, we are done with writing the program, we have to assemble and link it to the final executable.

Assembling and Linking

Now, we need to assemble and link the program. "as" is the assembler and "ld" is the linker we use.
To assemble the program type in the following commands as shown in figure 1.6

Assembling: as -o filename.o filename.s 
(filename.s is the input to the assembler, filename.o is the output)

Linking:       ld -o filename filename.o 
(filename.o is the input to the linker, filename is the final executable)

(Executing the binary to see the output)

Figure 1.6
Please post your comments if you have any queries or suggestions.


Recent posts

Recent Comments

Bookmark & Share