Installing Google Play on the Android Emulator (API 21 – “Lollipop”)

With the recent release of Android 5.x, I decided that it was time to release an update on how to install the Google Play Store on the Android Emulator.  This document outlines the steps required using the latest version of the Android SDK (Revision 24.0.2) and is focused on Android 5.0.1 (API 21).


Install the Android 5.0.1 Image

With that, let’s begin by launching the SDK manager. We’ll first need to ensure that Android 5.0.1 (API 21) is installed.

[pyoor@localhost]$ cd ~/android-sdk/tools/
[pyoor@localhost tools]$ ./android sdk

Select the Android 5.0.1 Packages

If it’s not, check the top level element, “Android 5.0.1 (API 21),” and click “Install 15 Packages.”  Then, when prompted, accept the license agreement and continue.


Create the AVD

Once installed, close the SDK manager and launch the AVD manager.

[pyoor@localhost tools]$ ./android avd

Here we’ll need to create a new AVD which utilizes the Android 5.0.1 platform and has snapshots enabled so that any changes we make are persistent.  Also, due to the increased size of the 5.0.1 image, we’ll need to allocate at least 2048MB of RAM for our AVD.

Create the AVD


Download the GAPPS Package

Next we need to pull down the appropriate Google Apps package that matches our Android AVD version.  In this case we’ll be using the package.  You can download that file from BasketBuild here.

[pyoor@localhost]$ md5sum

In order to install Google Play, we’ll need to push the following 4 APKs to our AVD (located in ./system/priv-app/):

  • GmsCore.apk
  • GoogleServicesFramework.apk
  • GoogleLoginService.apk
  • Phonesky.apk
[pyoor@localhost]$ unzip -j \
  system/priv-app/GoogleServicesFramework/GoogleServicesFramework.apk \
  system/priv-app/GoogleLoginService/GoogleLoginService.apk \
  system/priv-app/Phonesky/Phonesky.apk \
  system/priv-app/GmsCore/GmsCore.apk -d ./


Push APKs to the Emulator

With our APKs extracted, let’s launch our AVD using the following command.

[pyoor@localhost tools]$ ./emulator @Flinkd -no-boot-anim

This may take several minutes the first time as the AVD is created. Once started, we need to remount the AVDs system partition as read/write so that we can push our packages onto the device.

[pyoor@localhost]$ cd ~/android-sdk/platform-tools/
[pyoor@localhost platform-tools]$ ./adb remount

Next, push the APKs to our AVD:

[pyoor@localhost platform-tools]$ ./adb push GoogleServicesFramework.apk /system/priv-app/
[pyoor@localhost platform-tools]$ ./adb push GoogleServicesFramework.apk /system/priv-app/
[pyoor@localhost platform-tools]$ ./adb push GoogleLoginService.apk /system/priv-app/
[pyoor@localhost platform-tools]$ ./adb push Phonesky.apk /system/priv-app/



And finally, reboot the emualator using the following commands:

[pyoor@localhost platform-tools]$ ./adb shell stop && ./adb shell start

Once the emulator restarts, we should see the Google Play package appear within the menu launcher. After associating a Google account with this AVD we now have a fully working version of Google Play running under our emulator:

Working Google Play!

1 Comment more...

Decrypting AES With Burp Intruder

Recently, I’ve noticed a significant rise in the number of mobile applications making use of local encryption in order to encrypt request parameters prior to passing them over the wire. Not only does this make casual observation of the traffic more difficult, any type of parameter tampering/manipulation will likely fail unless the supplied payload can be successfully decrypted by the backend.

With that in mind, I developed a simple Burp Extender plugin that utilizes the IIntruderPayloadProcess interface in order to automatically encrypt payloads managed by Intruder. This way you can select an application request, identify the parameters that are encrypted, and select your payload listing as normal.

The only downside of this approach is that Intruder will show the fully encrypted payload within the results tab. In order to determine which payload was actually sent you’ll need to decrypt the payload by hand.

You can download the Netbeans project and JAR here.

(continue reading…)

Installing Google Play on the Android Emulator (API 18)

Updated (2-11-15): I’ve written a new post which describes installing Google Play on Android 5.x.  You can find that post, here.


Before I begin, I just want to mention that what I’m about to describe is by no means new. There are several other posts out there which describe how to install the Google Play packages under the Android Emulator. However, today I needed to create a new AVD for a project I’m working on and after searching for a few minutes, I realized that most of these posts are outdated and contain broken links to the appropriate Google apps. As such, I’ve decided to wikify it here.

This document outlines the steps required using the latest version of the Android SDK (Revision 22.3) and is focused on Android 4.3 (API 18). Although Android 4.4 (Kit Kat) is out at the time of writing, the appropriate Google Apps package is not yet publicly available.

With that, let’s begin by launching the SDK manager. We’ll first need to ensure that Android 4.3 (API 18) is installed.

[pyoor@localhost tools]$ ./android sdk


If not, check the top level element, “Android 4.3 (API 18)”, click “Install 6 Packages”, and accept the license agreement.

Once installed, close the SDK manager and launch the AVD manager. Here we’ll need to create a new AVD which utilizes the Android 4.3 platform and has snapshots enabled so that any changes we make are persistent.

[pyoor@localhost tools]$ ./android avd


Next we need to pull down the appropriate Google Apps package. Using Android 4.3 (API 18) we must use the “20130813” package. You can find that package at the page.

Please note that this package will only work for Android 4.3. For earlier versions of Android, please see the RootzWiki here. A full listing of packages can be found here.

Once downloaded, extract the archive. In order to install Google Play, we’ll need to push the following 3 APKs to our AVD (located in ./system/app/):

  • GoogleServicesFramework.apk
  • GoogleLoginService.apk
  • Phonesky.apk

However, before we do, we need to make some minor modifications to our AVD. Let’s launch the newly created AVD using the following command. Note that we’ve specified a partition size of 512MB. This is to ensure that our AVD has enough capacity to install the Google Play Store and its dependencies.

[pyoor@localhost tools]$ ./emulator -avd Test -partition-size 512 -no-boot-anim

This may take several minutes the first time as the AVD is created. Once started we need to remount the AVD’s partition and modify the permissions of “/system/app/” as this is where our packages will be installed to.

[pyoor@localhost platform-tools]$ ./adb remount
[pyoor@localhost platform-tools]$ ./adb shell chmod 777 /system/app/

And finally, we can push these APKs to our AVD:

[pyoor@localhost platform-tools]$ ./adb push ~/system/app/GoogleServicesFramework.apk /system/app/
[pyoor@localhost platform-tools]$ ./adb push ~/system/app/GoogleLoginService.apk /system/app/
[pyoor@localhost platform-tools]$ ./adb push ~/system/app/Phonesky.apk /system/app/

Now if your emulator is as slow as mine it may take a few minutes for the package to be installed. You’ll know if the installation hasn’t yet completed if the launcher process repeatedly crashes on you ;)

After a few minutes, we should see the Google Play package appear within the menu launcher. After associating a Google account with this AVD we now have a fully working version of Google Play running under our emulator:


New Peach Fuzzer Template Added For QT MOV/MP4

I’ve added a new Peach Pit for the Quicktime MOV/MP4 file format. This template covers the majority of the specification, complete with size and count relations with the exception of a few corner cases where certain size elements are not included.

You may also notice from the comments that there are some instances where certain relations, though included, have been disabled. This is due to the overwhelmingly long amount of time required to parse these elements. As such, they’ve been replaced with simple blob elements.

You can download the new Peach Pit here.

Also, as with all of my previous Peach Pits, this template is currently written for Peach v2.3.9 or less. Updating it to Peach v3.0 shouldn’t be much of an issue. For more information, take a look at documentation for the new Peach Pit format, here.

Proxying Non-Proxy-Aware Applications with Burp and PPTP

The Problem

Often times when testing iOS applications, getting access to compilable source code is not possible and I’m forced to test the application using a physical device. In order to observe and manipulate the application’s traffic, I’ll typically connect the device to my wireless network, and then configure the iOS client’s wireless network settings to utilize a proxy of my choosing. However, during a recent mobile application assessment, I noticed that a significant portion of the application’s traffic was not being passed through my proxy, but rather, directly to the web service.

As this usually works quite well, I was unsure why iOS was unable to enforce my proxy settings.

After looking a bit deeper, I noticed that the application communicated with two web services; one of which utilized a non standard port (i.e. not 80 or 443). Because of that, the iOS proxy settings would be ignored and traffic would be issued directly to the web service.

The Solution

To work around this issue, I realized that I could simply set up a VPN server, and configure the iOS client to tunnel all traffic (not just HTTP), to a host of my choosing. From there it would be simple to intercept and manipulate the target traffic.

In order to simplify setup, I put together a short bash script to install and configure a PPTP server. I tested it primarily on Kali Linux, however it should work on most Debian based distros.

You can download that script, here.

And yes, as I imagine you’re thinking, I likely did go a bit overboard with the coloring.

Execution of the script will produce the following output:

pptp - 1

Next, you’ll need to configure your iOS device to use the PPTP VPN. You can find instructions on how to do so, here.

Once you have your client connected to the VPN, you’ll need to decide what proxy to use. In this particular case, as my traffic was still HTTP, albeit using a non-HTTP port, I chose to use Burp.  In order to tunnel the application’s traffic to Burp’s interface, we need to add the following iptables rule.

Please note that in the example below, we’re assuming that the application is using TCP port 5555 and that Burp is configured with the default port of 8080.

iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 5555 -j REDIRECT --to-ports 8080

And finally, we’ll need to make a few changes to our Burp proxy settings. First, we’ll need to instruct Burp to listen on all interfaces (or atleast our PPTP interface). Additionally, as our client isn’t aware that it’s traffic is being proxied, we’ll need to configure Burp to perform invisible proxying. This means that Burp will look to the HTTP Host header in order to determine where it should forward the incoming requests.

Burp - 1

You can find further information on Burp’s invisible proxy support here.


In the event that your application is using something other than HTTP, one alternative is Mallory, a transparent TCP and UDP proxy developed by the Intrepidus Group. Using Mallory, it’s possible to intercept and manipulate any binary protocol.

Apple Quicktime 7 Invalid Atom Length Buffer Overflow

Earlier this year I reported a stack overflow vulnerability affecting QuickTime versions < 7.7.3 (CVE-2013-1017) via the iDefense Vulnerability Contributor program. Unfortunately, this bug had already been reported via by Tom Gallagher (Microsoft) & Paul Bates (Microsoft) working with HP’s Zero Day Initiative.

The Apple Advisory regarding this vulnerability can be found here.

As this bug was patched in version 7.7.4, I forwarded the details and a proof of concept over to Metasploit Exploit Developer, Wei Chen (@_sinn3r) who was kind enough to convert my proof of concept into a Metasploit exploit module. This module is now included as part of the Metasploit Framework. The individual module and source code can be found here.

Huge thanks to sinn3r for kindly helping me with my Ruby “handicap” and implementing this for me!

Still Alive

As it has been well over a year since my last post here, I’d like to let those of you that still follow this blog that I am in fact, still active and actually quite busy to say the least. Recently I had the privilege to publish two articles for Team Corelan which documented the process I use when attempting to identify the root cause of a crash and determine its exploitability. Links to those two articles can be found below:

Furthermore, with the help of iDefense Vulnerability Contributor Program, I’m awaiting the public disclosure of a number of bugs I’ve identified ofter the past few months. Once public, I hope to provide some additional details and proof of concept code here.

And finally, I have a number of home brew projects that I’ve been using in my private fuzz farm over the past few months that I hope to make available to the general public. Please check back here soon for updates.

Fuzzing with Peach – Part 2 (Fixups)


In this tutorial I’ll be detailing the process used to develop a Peach Pit for the RAR file format. I’ll also be discussing the use of Fixups and the steps required to implement your own custom Fixup. This article is intended to build upon the skills described in my first article so if you haven’t read it, I highly recommend doing so before continuing. You can find that article here. With that said, the following will assume that you have working level knowledge of the Peach Pit format.

Again, I’d like to thank Mike Eddington and the rest of the Peach community for such a great product. Make sure you check out the Peach project page and the Peach Google Group.

A quick update, after posting this article I realized that Mike also has a very informative section on extending peach with custom fixups. You can find that article here.

Getting Started

To begin, let’s grab a copy of the most recent RAR tech note available here. Please note that since the tech note does not fully describe the specification, some of the information contained in this Pit has been enumerated from the UnRAR source, 010 RAR Binary Template, and other sources.

Moving right along we see that the specification is defined as a series of block-like structures, each of which contains several recurring elements. As we are unable to tell which order some of these blocks will occur, we will wrap all blocks in a choice element. Let’s first begin by creating the block structure for the “Marker Block”.

(continue reading…)

Fuzzing with Peach – Part 1


For the past several months I’ve been doing a fair amount of work with the Peach fuzzing framework. At times (many in fact), I’ve struggled with performing somewhat basic tasks with Peach but with a little perseverance and a lot of help (thanks Mike and Mikhail), I’ve been able to develop some fairly complete Peach templates. In an attempt to save those of you just beginning with Peach, I thought I’d put together a few short tutorials to help expose some of the more advanced features within the framework.

If this is your first time hearing of the Peach fuzzing framework, I invite you to take a look at the Peach project page.

I would also like to mention that this tutorial will be very similar to the one provided by Mike Eddington, on creating a Peach template for parsing WAV files. That document can be found here, at the Peach project page.

Getting Started

For this tutorial, we’ll be looking at the Zip file format. We’ll try and define a Peach template that covers as much functionality defined in the specification as possible. The latest Zip file format specification can be found here.

Before we begin, there are a few tools you’ll need to follow along with this tutorial.

  • Peach Fuzzing Framework
    • You must have the latest version of Peach to use the Pit included in this tutorial (rev. 2468 at the time of release). Several of the functions included in this tutorial will not work with the Peach installer. You can find the SVN information here.
  • 010 Binary Editor
    • The 010 Binary Editor utilizes binary templates for parsing a variety of file formats. Included in the base install is a template for the Zip file format. This will help us to debug our Pit as we progress. You can find this software here.

In order to instruct Peach on what we’d like to fuzz, we’ll begin by creating a Peach Pit, an XML based file that provides Peach with the structure of our data, how we’d like it fuzzed, and what application we’d like to target. A Peach Pit is comprised of 5 main sections:

Peach Structure

  • DataModel
    • The DataModel is the element within our pit that we’ll use to define the structure of our data. In this case, we’ll use the DataModel to provide Peach with the structure, layout, and functionality of the Zip file format. We also have the ability within the DataModel to inform Peach which elements we do and do not want to fuzz (fuzzable elements can also be defined in the Test block).
  • StateModel
    • The StateModel is responsible for managing the flow of data during the fuzz process.
  • Agents
    • The Agents are used for monitoring the behavior of an application during the fuzz process. This includes capturing data related to application state and any crashes that may be triggered during the fuzz process.
  • Test Block
    • The Test Block is responsible for correlating the configuration of the StateModel, Agents, and Publishers (responsible for managing the data generated by the DataModel) into a single test case.
  • Run Block
    • The Run Block is used for defining which tests will be executed during the fuzz process.. This block also manages logging of any data generated by the Agents during the fuzz process.

(continue reading…)

Copyright © 1996-2010 Flinkd!. All rights reserved.
iDream theme by Templates Next | Powered by WordPress