Android Emulator Tricks

When performing security (or regular) tests on Android applications, we sometimes need to emulate or fake mobile data or actions; making/receiving calls, sending SMS or setting the exact geo-location are some commands that can be done, using the Emulator Console.  Here are a few tricks that will help you through Android application testing using the emulator:

· First, connect to the emu, using telnet:

telnet localhost 5554

· To change geo-locations:

geo fix <longtitude value> <latitude value>

· To make a phone call to the emulator:

gsm call <callerPhoneNumber>

· To send an sms to the emulator:

sms send <senderePhoneNumber> <textMessage>

· To scale the emulator window:

window scale <value from 0 to 1>

· To take a screenshot:

screencap -p  </path/to/filename.png>

· To create input events (event codes list):

input keyevent  <event_code>


The Monkey is a command-line tool that runs on the emulator instance or on a device. When the Monkey runs, it generates pseudo-random events and sends them to the system.

Read more

ADB – Common commands

What is ADB (Android Debug Bridge)

The ADB shell is a bridge between your computer and the Android device, which may be a physical device or an emulator.


How to install ADB

ADB comes with Android SDK, but you can also find it alone. Inside the AppUse VM we have installed and prepared it for you.

Read more

Erez Metula is presenting at the International 2014 Cyber Security Summit in Tel Aviv, Israel

On January 16th, 2014, Erez will be giving an important presentation on Android Hacking in Mobile Application Security.

Full logistical details can be found here:


We’d love to see everyone there and we’re looking forward to the exchange of ideas. For now, take a look at the  Synopsis so you have an idea of what’s ahead!

 Synopsis of his upcoming speech:

The mobile apps revolution has completely changed the way we use our mobile devices, that up until  recently were used just to make phone calls. Mobile applications nowadays handle our most sensitive data –  phone calls, SMS text messages, geographic location, financial information, internet browsing, etc., but the  question is “How can we really tell how secure are those applications? Who can assure us they are not spying on  us? Or, can it be abused by other applications taking advantage of security vulnerabilities in those apps?”

During this presentation we will answer such questions, while focusing on Android mobile applications. We will  start by describing the threat model of mobile apps vs. traditional apps, then we’ll demonstrate a couple of  common application level vulnerabilities, and the tools/techniques used to expose them.

Participants of this presentation will also witness the usage of the AppUse Android Penetration Testing VM – an open source virtual machine created by AppSec Labs for the sole purpose of pentesting Android applications.


Wardriving? Apple? Really ??

EvilQR – When QRCode goes bad

Security assessment of mobile QR readers – Updated (30-Nov-2011)

Quick Response code, also known as QRCode has been around for several years, but in the last months there has been an incline in adoption of QRcodes as a marketing channel. A QRcode can encode a variety of information into a 2-dimentional barcode that is presented to the costumer. Customers are often referred by vendors into scanning QRCodes in order to receive coupons, discounts or other marketing media such as website, flash movie etc. The QRCode is parsed by QR-reader software on a mobile phone equipped with a camera. The true nature of QRcode content is an enigma until it is scanned; there is no possibility for the customer to authenticate the content of a QRcode without scanning it first. Because of the latter fact, an attacker with evil intent could craft a malicious QRCode (or evilQR) and lure an innocent customer to scan it. Once scanned the evilQR would be parsed by the customer mobile phone software and would initiate its’ attack. Attack vectors could vary from browser-based such as Cross-Site-Scripting (XSS) to specific buffer-overflow and command injection. The key for a successful attack lays in the default behavior of the mobile QRCode reader software. If as an example, a QRCode reader parses a link from a evilQR and preforms a URL redirection without proper confirmation of the customer – the attack would succeed. In this assessment we have compared the default behavior of several QR-readers for and noted their behavior upon the parsing of two evilQRs. Best practices for mobile users are also discussed.

The problem:

 An innocent customer can be easily tricked into scanning a malicious-crafted QRCode (evilQR) by an attacker, upon scanning the customer mobile would be attacked by the encoded payload.


The motive for executing such attack is very clear – the mobile phone is a gold mine for an attacker, because today’s phone contains very sensitive information such that can be abused by an attacker in several ways:

Read more