Some people might remember the video chat application Houseparty. Similar to others like Zoom, Skype, and What’s App, it provided light-hearted group video chat functionality alongside games and entertainment activities. In early 2020 Houseparty, developed by Epic, was at it’s peak and was hit by an unproven social media rumour that claimed the app caused users’ other online accounts (including Netflix, eBay, Instagram and Spotify) to be hacked. Epic later offered a $1m reward to anyone who could prove it was targeted by a smear campaign (however, the bounty went unclaimed). Later in 2020 Epic withdrew Houseparty from the app store and later discontinued it completely

Back when these allegations first erupted in 2020, I took a few hours out of my “busy lockdown schedule” to take apart the application and see how it was ticking behind the scenes. This article will take us through a whistle stop tour of this analysis, breaking down some of the key functions of the app, and finally conclude with my personal opinion on if I think these allegations were true and if at all possible.


The Android manifest is a central configuration file used on an app-by-app basis. Manifests are consistently structured across all Android applications and hold information such as the application entry points, permissions, and the services that the application uses. Android as a whole is a fairly robust operating system, meaning that if an application is acting alone and inside the confines of the Android sandbox (i.e. not using any exploits or vulnerabilities) then if something isn’t in it’s manifest file, then it won’t be able to perform that action. For example, if you want your application to take a photo and tag the location, if the camera and location permissions are not set, then the application will error when it attempts to take the picture. It it possible to dynamically declare some of these permissions in the code base, but for the most part the manifest file is used.


So to start with, lets have a look at permissions. When it comes to permissions (and especially when looking at if an application is malicious) the goal is normally to identify elements that are out of the ordinary for the type of application being reviewed. For example, having a camera application that has the premium SMS permission would be seem a bit odd. When it comes to Houseparty, there are quite a few permissions listed, below is an excerpt of some of the most interesting:

<uses-permission android:name="android.permission.READ_PHONE_STATE"/>
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.CAMERA"/>
<uses-permission android:name="android.permission.RECORD_AUDIO"/>
<uses-permission android:name="android.permission.READ_CONTACTS"/>
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
<uses-permission android:name="android.permission.FOREGROUND_SERVICE"/>
<uses-permission android:name="android.permission.WAKE_LOCK"/>
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
<uses-feature android:name="android.hardware.microphone"/>
<uses-permission android:name=""/>
<uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES"/>
<uses-permission android:name="android.permission.BLUETOOTH"/>
<uses-permission android:name="android.permission.CHANGE_NETWORK_STATE"/>

Some of these permissions are self explanatory, however, lets take a closer look at a few.

  • READ_PHONE_STATE  – An application with this permission can access a device’s phone number, information about ongoing calls, and cellular network information.
  • FOREGROUND_SERVICE – A fairly harmless permission, this permission allows for an application to run in the background while the application is not actively running or in the Android task stack. However, to do this, it must show a constant notification to the user. This means that unless a  notification for Houseparty is in the device notification drop-down then it isn’t running on a device (outside of one or two edge cases).
  • RECEIVE_BOOT_COMPLETED – Boot Complete is one of these edge cases. This permission means that when the device restarts, the application can be ‘woken up’ and begin running. Without this, an application would need to be restarted by either another application or by the user manually each time the device restarted.
  • WAKE_LOCK – Another fairly simple permission. This permission allows the application to stop the screen from dimming. Such functionality is usually used for call applications to force the screen to stay active while on video calls.
  • REQUEST_INSTALL_PACKAGES – This permission allows Houseparty to request to install third party applications on the device. This is, however, not as scary as it sounds as there are several safeguards in place to stop the abuse of this permission. Unless you have the  Unknown Sources option ticked in your Android settings this will fail, and even if you do, you will receive a yes/no prompt before an application is installed through this method.
  • BILLING – Another scary sounding permission, however, not as bad as it sounds. Here we can see the difference between (for this permission) and android.permission (for the others). This means that this permission doesn’t reside in core Android and instead in vending, which is the internal name for the Google Play Store. Instead of what it may sound like, this permission doesn’t give the application the ability to access any of your financial information, instead it allows the application to request transactions through the Play Store. This will also display a yes/no prompt when it occurs.


The term ‘Services’ in Android is a general catch all term. In this context services will refer to anything that allows the application to run in the background or foreground when the application isn’t being manually and directly run, and is visible, to the user. Services, such as this, can be declared in the manifest file as well as dynamically in the codebase. Some examples of services being declared in the Houseparty manifest can be seen below:

<service android:name="" android:permission="android.permission.BIND_JOB_SERVICE"/>
<service android:name="" android:enabled="true" android:exported="false"/>
<service android:name=""/>

There are a considerable amount of services in the manifest, to many to list here, however many of these belonged to a package named InstaBug, which on their website describe themselves as:

Instabug empowers mobile teams to release with confidence through comprehensive bug and crash reports, in-app surveys, and real-time user feedback

As for the other services listed here, the BackgroundVideoService seems to be the main service used by the application. Earlier I mentioned that Foreground services must show a notification to the user when the activity is running. This restriction is only in place from Android 8.0 Oreo (API Level 26). In the Houseparty decompiled codebase we can see this notification being created, for this service, here:

public static void a(Context context, Notification notification) {
  hxw.a(4, "Start service to keep alive and show active party notification", (Throwable) null);
  Intent intent = new Intent(context, BackgroundVideoService.class);
  intent.putExtra("ACTIVE_PARTY_NOTIFICATION", notification);
  b = true;
  if (Build.VERSION.SDK_INT >= 26) {
  } else {

The next service, ScreenRecordingService, is for recording the screen of the device. This uses an Android system service named media_projection. Below we can see Houseparty retrieve the Media Projection system service and start an activity with it. However, as this service declaration in the manifest is part of the Instabug class, my gut instinct is that this is part of some bug reporting functionality.

if (bundle == null) {
  boolean z = true;
  this.a = getIntent().getBooleanExtra("isVideo", true);
  this.b = getIntent().getBooleanExtra("isInitial", true);
  Intent createScreenCaptureIntent = ((MediaProjectionManager) getSystemService("media_projection")).createScreenCaptureIntent();
  if (!this.a) {
    startActivityForResult(createScreenCaptureIntent, 101);
  } else if (SettingsManager.getInstance().getAutoScreenRecordingAudioCapturingState() == Feature.State.ENABLED) {
    if (ContextCompat.checkSelfPermission(this, "android.permission.RECORD_AUDIO") != 0) {
      z = false;
    if (!z) {
      ActivityCompat.requestPermissions(this, new String[]{"android.permission.RECORD_AUDIO"}, 2022);
    } else {
  } else {


Before we stop talking about the Manifest there are one or two honourable mentions that are worth discussing. These being the use of the Facebook marketing and the HockeyApp providers, where on their website HockeyApp describe themselves as:

HockeyApp is the best way to collect live crash reports, get feedback from your users, distribute your betas, and analyze your test coverage.

<provider android:name="" android:exported="false" android:authorities="com.herzick.houseparty.MarketingInitProvider"/>
<activity android:name=""/>

As with Instabug above, there are a considerable number of third-party libraries being used inside of the Houseparty application. This is not out of the ordinary for applications of this size, however, does pose an additional attack surface where if a vulnerable or malicious third party service is used it can provide an additional risk to the end user.

Side Loading / Hot Swapping

Earlier it was briefly mentioned how the REQUEST_INSTALL_PACKAGES permission could be used, if user consent was provided, to install third-party applications on some devices. Here we’ll be diving into other methods that the application uses for dynamically running code/ content. 

Here the term side loading is used to refer to the process of programmatically running third party code, or data, without going via the Google Play Store. Loading code in this form would mean that it typically wouldn’t be visible as part of a static code review such as this – meaning that potentially malicious code **could** be installed when then application is running.

After an initial look into the Houseparty decompiled codebase there isn’t an immediate indication that the application is doing this. However, Houseparty does have several dynamic elements, primarily it’s ability to dynamically update what games can be played in the application. While the specific games are hard coded into the app (e.g. Trivia, Heads Up, etc) the packs used in these games aren’t hard coded. Instead they are downloaded and stored in a Realm Database. I’ve only taken a look at the Heads Up game however, it seems likely that the same logic is applicable across all of their game offerings. 

It’s important to stress here that while these games are dynamically downloaded there doesn’t appear to be any code downloaded, and instead just elements that can be plugged into the game engine. As below we can see the elements for one of these ‘Heads Up Card Packs’ being updated with this data.

public static HeadsUpDeckModel buildFromParcel(Parcel parcel) {
  Builder builder = new Builder();
  String unused = = parcel.readString();
  List unused2 = builder.skus = parcel.createStringArrayList();
  String unused3 = = parcel.readString();
  String unused4 = builder.description = parcel.readString();
  String unused5 = builder.imageUrl = parcel.readString();
  boolean z = true;
  if (parcel.readInt() != 1) {
    z = false;
  boolean unused6 = = z;
  List unused7 = = parcel.createStringArrayList();


Some questions on if Houseparty was truly malicious may still stand: “well, what if they were to implement the side loading code in the future?” or “what if another one of the game packs side loads code?“. As a whole Google has very stringent rules on the side loading of code, with them stating that:

Apps or SDKs that download executable code, such as dex files or native code, from a source other than Google Play… are explicitly prohibited.

In general, Google also have fairly good automated systems for picking up these types of applications before they enter the Play Store, known as Google Play Protect, and scans over 50 billion applications, on user devices, per day.

To conclude, in my personal opinion I don’t believe Houseparty was doing anything malicious behind the scenes, however, I do recommend the advice noted by the team at NakedSecurity, across the board for all users/ applications, it’s a good read.


Reverse Engineering Android Malware Course

I’m in the process of developing a Udemy course on reverse engineering Android malware. Enter your email address below to receive an update and early-bird discount code once the course is live, along with updates on other resources I make available.


Learn More On Android Internals

In 2021 I released my first book with Apress publishing, Android Software Internals Quick Reference. If you work with or find programming and Android interesting please consider picking the book up for yourself! 




10% off Android Malware Reverse Engineering Cheat Sheets

Free and premium resources, available on everything from Android and iOS security fundamentals, reverse engineering basics, and study guides for my Udemy courses. Use code ‘MALWARE-ARTICLE’ for 10% off on the Android Malware Reverse Engineering Cheat Sheet.


This article covers the building blocks of Android malware analysis, getting you ready to go, with everything needed when it comes to reverse engineering malware on Android! 

Types of Android Malware

For Android devices running Google Play Services, and in turn using the Google Play Store, one of the biggest application security defences is the Google Play Protect utility. Google Play Protect identifies malware in two forms; on device, and off device (also known as Cloud). On device protection works by daily scanning all applications installed on Android devices, while cloud protection works by vetting and reviewing applications that are uploaded to the Google Play Store. 

As an authority on Android Malware, we’ll be using the definitions provided by Google Play Protect for Android Malware (also referred to as Potentially Harmful Applications). In addition to device malware, some antivirus providers also class personally unwanted software (POS) or Mobile Unwanted Software (MUwS) as harmful to a device. These won’t be included here as, while they pose a danger to the device ecosystem,  they do not strictly fall into the category of malware. These can include:

  • Ad fraud
  • Unauthorized Use or Imitation of System Functionality
  • Disruptive ads
  • Social Engineering
  • Data collection and restricted permissions abuse

TrojanUsed in combination with other malware categories, a Trojan will usually appear as something it is not. For example a legitimate game, application, or useful piece of software. While it may appear to be benign it will then perform undesirable actions against the user.
SpywareSpyware is any form of application or software that transmits personal or personally identifiable information to a third party without adequate control, notice, or consent - this can include contact information, photos or other files, messages from email, call logs or sms, web history and bookmarks and information from the device '/data/' directory. This can also include actions such as recording video, audio, calls, and acquiring application data.
StalkerwareA subset of this type of malware and is often seen used as a commercial/ spyware-as-a-service, where the data is often sent to a third party that is not the PHD provider. Legitimate versions of such software can be used by parents to track their children, however, a persistent notification should be displayed at all times.
SpamApplications that send unsolicited messages to the user's contacts, the user themselves, or others without adequate consent from the user.
Rooting - An application or code that roots the target device without consent from the user and in turn executes some form of further malicious code onto the device.
RansomwareDefined as an application or code that gains partial or full control over a device and in turn offers to relinquish that control for a performed action such as payment. This can include encrypting device data or enabling device admin controls to lock the user out of the device.
Elevated privilege abuseSimilar to rooting, this is where an application or code compromises system integrity by breaking the app sandbox, gaining elevated privileges, or changing or disabling access to core security-related functions. This can include everything from disabling SELinux, abusing features so that the application cannot be uninstalled, abusing permission or authentication models.
PhishingSimilar to a Trojan, this is where an application or code masquerades as a legitimate piece of software and requests user authentication credentials or other personal and private information. This data is then sent to a malicious third party.
Non-Android threatThis malware category applies to Android applications and code that do not provide a direct threat to the device ecosystem or user, and instead leverage the device to target other platforms - such as connected devices or devices on the same network.
Hostile downloadersThis category covers applications and code that are utilised to download other malware. Google Play Protect has a collection of rules it uses for identifying if a given piece of downloader software if classed as hostile, these being:
There is reason to believe it was created to spread PHAs and it has downloaded PHAs or contains code that could download and install apps; or
At least 5% of apps downloaded by it are PHAs with a minimum threshold of 500 observed app downloads (25 observed PHA downloads).
They don't drive downloads without user interaction
All PHA downloads are initiated by consenting users.
Denial of service (DoS)An application or code that performs a denial of service (DoS) / distributed DoS attack against a third party system or resource.
Billing fraudBilling fraud summarises several types of an application or code that leads to the user being charged for a service in an intentionally deceptive way. This is commonly broken down into: SMS, Call, and Toll fraud.
BackdoorA backdoor will often allow for a malicious actor to gain unwanted, unauthorised, and potentially harmful remote control of the target device.

Android Applications 101

Android application’s are commonly written in either Java or Kotlin. When a software engineer wants to create an APK (the Android pacKage), that contains the code and materials that are run on an Android device, they will need to compile that Java or Kotlin source code to a Dalvik executable/ bytecode. This Dalvik executable is a binary that is run on the Android device. This works where each process on the device uses its own virtual machine (VM) which segregates applications. Prior to Android API level 21 (Android 5), this would have been a Dalvik Virtual Machine, and in later versions will instead use the Android Runtime (ART). Both operate in similar fashions, where they simulate a device’s CPUs, registers, and other features while running an application’s compiled Dalvik bytecode.

Decompiling and Disassembling An APK

While it is the Dalvik bytecode that needs to be run on a device, this is not human readable and so if we are to reverse engineer an application we’ll need to decompile it back into a human readable form. This is where Jadx comes in. Using Jadx we can decompile the Dalvik bytecode back into Java. This is often called pseudo Java, as it is not a one for one representation of what the original source code would have been, and instead is the decompiler’s best guess.  

Android application architecture

An Android application (APK) is an archive-like file format, that contains several other files and folders. This including:

  • assets— A directory for application assets. This is for arbitrary storage; anything provided by the application creator can be stored here.
  • res— A directory with all resources that are not compiled into arsc (icons, images, etc.).
  • lib— A directory for native libraries used by the application. Contains multiple directories for each supported CPU architecture that the application has been compiled for.
  • META-INF— A directory for APK metadata – including signatures.
  • xml— The application manifest in a binary XML formatted file that contains application metadata — for example, its name, version, permissions, etc.
  • dex— The classes.dex file contains the compiled application code in the Dex file format. There can be additional .dex files (named classes2.dex, etc.) when the application uses multidex.
  • arsc— This file contains precompiled resources—such as strings, colours, or styles.

Android Manifest File

Android APK files also include a file detailing the application configuration – AndroidManifest.xml. The Android manifest includes information such as:

  • Package name and application ID
  • Application components
  • Intent filters
  • Icons and labels information
  • Permissions
  • Device compatibility information

Building and Reverse Engineering an ordinary application

First things first, especially if you’re new to Android as a whole, my recommendation would be to build a simple Android application. As an example open up Android Studio and create one of the following simple applications. This will give you a better understanding of Java, how Android applications are written, and some experience using a device/ emulator when running an application.

  • A simple note-taking application
  • A quote of the day application
  • A simple password manager
  • An Android file explorer

After compiling the created application to an APK, your next step will be to decompile that application to pseudo-Java, using Jadx. This will provide you with an understanding of how code goes from source code, to Dalvik assembly, then back to decompiled pseudo Java.

Reverse Engineering Android Malware

Kicking things off, it’s important to bear in mind that any malware analysis should be performed on a segregated system, such as a VM, with minimal connection to the outside world. 

All of the malware samples used today can be found on the Android Malware GiHub repository by Ashishb.

Malicious Skype Application

In the rouge_skype folder you can find a file named skype.apk. If loaded onto a device this application would present itself as a regular, if old, Skype application.  That being the case, we can use some tools to identify a more nefarious purpose. 

Virus Total

Before this, however, we can upload the APK onto Virus Total (a tool for analysing and sharing suspicious files, domains, IPs and URLs). With an immediate look, we can see that we’re not the first people to be looking at this APK, with the first submission of the file to Virus Total (VT) being back in 2015. Straight off the bat, VT gives us a clear indication that this APK is potentially (and probably)malicious

Reverse Engineering

The next step is to disassemble this APK and begin diving into it’s contents. Using APKTool, the contents of the APK archive can be identified (for information on these files see the Android Application Architecture section above).

Entering the assets folder of the application we can see several obfuscated file names. Using the file command it can be identified that one of these files, a , is actually a jar file. As an APK is simply an instance of a Jar (Java Archive) file, with some additional Android files dotted in there, this can be reverse engineered with ease.

Using APKTool a second time, this time on the Jar file, it can be seen that the jar file is successfully de-bundled into it’s core components, and the internals of a second APK can be seen. This is a good indication that the original Skype application was patched in some way and is dynamically loading the jar file inside of the assets directory at runtime. 

Further analysis could be performed on both this APK and the jar file, including reviewing the manifest file, reviewing interesting functions, and identifying the link between the two files. 



The next malware sample we’ll be reviewing can be found in the dendroid folder in the GitHub repository. Dendroid malware was quite sophisticated in it’s time, being first identified in 2014 by Symantec. Falling into several of the above categories, Dendroid was capable of deleting call logs, opening web pages, dialling numbers, recording calls, SMS interception, uploading files, opening applications, and performing denial of service attacks.


Instead of manually reviewing the file structure and disassembled SMALI of this application, we’ll be using APKLab (A Mobile Threat Intelligence Platform by Avast), as an example of automated reverse engineering tooling (if you do not have access to APKLab, you can use other automated tooling such as Quark).

Using APKLab, this APK can be uploaded and an analysis performed on it. Some key information that APKLab provides, includes:

  • Suspicious permissions
  • URL strings
  • Generated files
  • Emulator check for known build properties
  • A network dump
  • Entrypoints
  • More…


By now, you have an entry level understanding into the internals of Android applications, Android malware types, and several areas and variables to look out for during Android malware analysis. See below for additional resources on the topic!


Reverse Engineering Android Malware Course

I’m in the process of developing a Udemy course on reverse engineering Android malware. Enter your email address below to receive an update and early-bird discount code once the course is live, along with subscribing to my mailing list.



Introduction To Reverse Engineering Course

I’ve released an Android reverse engineering course inspired by my interest in game design. This course walks through the fundamentals of reverse engineering and uses Android games as a fun and practical starting point.


10% off Android Malware Reverse Engineering Cheat Sheets

Free and premium resources, available on everything from Android and iOS security fundamentals, reverse engineering basics, and study guides for my Udemy courses. Use code ‘MALWARE-ARTICLE’ for 10% off on the Android Malware Reverse Engineering Cheat Sheet.

Continue reading “Android Malware Reverse Engineering”