Before we begin, you will need the following:

Before beginning with this recipe, you should have already downloaded and updated your Android SDK. You should have either set up your PATH variables appropriately, or you should be in the working directory that contains the appropriate tools/binaries.

To start off, let's enable debugging via the ADB. On either Windows or Linux execute the following command:

adb logcat

This will only work if you are in the correct working directory, which is [path-to-sdk]/sdk/platform-tools/ for Linux users or [path-to-sdk]sdkplatformtools for Windows users.

This will output the logging information of some of the software- and hardware-level events. Naturally, we would like to focus this on the events and applications we are inspecting for security vulnerabilities. Luckily, logcat is capable of filtering through the log information. Here's a breakdown of all the options:

adb logcat [options] [filter]

Where [options] can be any one of the following—I've omitted some of them to keep things short and to the point:

And [filter] is a list of the tag:priority command, which is discussed as follows:

For instance, if you want to monitor the logs for Error level priority log components and higher, you would use the following command:

adb logcat *:E

The * indicates that we want the Error level priority for all log component tags.

Another way you could filter through the log quite effectively is to dump the logcat output to a text file and search through it using either grep, which comes with most Linux/Unix distributions, or a text editor like Notepad++ for Windows users. A link to the download page of Notepad++ and grep are available in the See also section of this recipe. For Windows users, there's a Microsoft version of grep called WinGrep if you really want to do some powerful regular expression-based matching. A link to the WinGrep download page has also been made available in the See also section of this recipe.

Once you've decided how you want to search the text, it really doesn't matter how you do this as long as you know how to find what you're looking for in the logs. You can dump the output of the logfile by executing the following command:

adb logcat > output.txt

This works the same way via the Linux terminal or Windows command prompt. You can also "pipe"—which means feeding the output of one program into the input of another—this directly into another program like this. This works in either the Windows command prompt or the Linux terminal.

adb logcat | [other program]

If your using grep, you would do it by executing the following command:

adb logcat | grep [pattern]

Where [pattern] would be the text pattern you're searching, for example:

adb logcat | grep ApplicationManager

I really don't want to write a full tutorial on how to use grep here. If you want to make use of some of the more powerful features of either grep or WinGrep, please see the See also section of this recipe.

Here are some examples you may find useful; monitor the logfile for web-related information:

adb logcat | grep [Cc]ookie
adb logcat | grep "http[s]*"
adb logcat | grep "ftp[s]*"

I know these are not very strict examples, but they are just strict enough to match web addresses.

The previous logs were generated by the Google Play Store app on a Samsung Galaxy S3 mobile phone.

You could also try to catch some sign-on or authentication-type token strings being leaked through the logfile:

adb logcat | grep –i "[ws_-]*token[ws_-]*"

When looking for valuable information in the logfile, it's generally a good idea to look for information that you would otherwise need permissions to get hold of or directly cause you to gain knowledge of information protected by other apps. For instance, if an app logs the cookie values returned after a user logs into his/her LinkedIn profile, would this be dangerous?

Yes! Effectively you have just bypassed the need to know his/her LinkedIn password, or the need to have your app be granted rights to some of the authentication functions in the LinkedIn application. During the hours you will probably spend reading the logfile, you should try to focus on finding this kind of information.

Case and point! The cookies being logged here are being disclosed harmfully by the Android LinkedIn app on a Galaxy S3 mobile phone. Another real-world example of this vulnerability can be found at Discovering a Major Security Hole in Facebook's Android SDK. The link for the same is provided in the See also section.

Of course applications are often developed to respond to hardware or software events, either via broadcast receivers or intents from other applications or system services. And naturally, you would like to know how applications respond to these events, or whether their behavior becomes potentially harmful in response to these kind of events. Then the question is, how do you create/send these events to the application you're testing without pressing your volume up button, locking and unlocking your screen, and pressing buttons yourself? The answer is the Android Monkey testing framework. It's designed to send system- and hardware-level events to an application, so that developers can gauge how well their application handles these events. It operates somewhat as a device event "fuzzing" framework for applications.

Before explaining how to use it, it's important to mention that it's probably not a good idea to run the Monkey tester against applications installed on either your or someone else's personal Android device. This is because the way these applications respond to the Monkey tester may cause some damage to the applications being "monkey'd", cause loss of application data, or even crash your phone. Unless you have the proper permission or acceptance that you may lose or corrupt some data stored by the application(s) you are testing, you should only do this on an emulated or security testing-dedicated device.

One way to use this framework is to have a device connected via the ADB, and executing the following command via your command prompt or terminal:

adb shell monkey –p [package] –v [event count]

Where [package] is the name of the package/application to which you want to send these events, and [event count] is the number of random events you want to send. Here's an example of how to use it against the Flipboard app:

adb shell monkey –p Flipboard.app –v 10

This will send 10 randomly-selected events to the Flipboard app, and report back on the application's behavior.