Tag: Reverse Engineering

Getting Started

This article walks through the process of extracting Android applications from an un-rooted device, reverse engineering those applications, and using auxiliary tools such as automation frameworks and malware analysis tools to identify if the application’s configuration is identified as malware. During this article the following tools are showcased and used:

DROID DETECTIVE 

DroidDetective is a Python tool for analysing Android applications (APKs) for potential malware related behaviour and configurations. When provided with a path to an application (APK file) Droid Detective will make a prediction (using it’s ML model) of if the application is malicious.

 

AUTO DROID 

AutoDroid is a Python tool for programmatically scripting bulk interactions with one or more Android devices. Useful for downloading and extracting all APKs from all connected devices, testing a developed application on multiple devices at once, and more.

 

ADB 

Android Debug Bridge (adb) is a command-line interface tool for communicating with Android devices. The adb command allows for a plethora of device interaction types – including acquiring a shell, installing / uninstalling apps, and interacting with the screen and other hardware accessories. 

Structure of an Application (APK)

To get things started it’s first important to understand the structure of Android applications. 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 APK files also include a file detailing the application configuration, called 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

Retrieving an Application From A Device

Being able to retrieve applications from a device is key in identifying if one of those applications is potentially malware. Before continuing ensure that ADB is enabled on the device being tested – This can be done by going to Settings, About phone, and by tapping Build number seven times. After this go to developer settings and enable USB debugging. Now connect the device and accept any prompts that are displayed. 

Android application’s are not encrypted at rest and so if an APK’s location on a device can be identified it can be retrieved. There are two shell commands that can be used when using ADB on a device (via adb shell) to help with this. These being the pm list packages command which will list all packages on the target device, and pm path <package name> which will return the path to that package’s apk file on device. Once the path has been located the adb pull <path to apk> command can be used to retrieve the APK from a device.

Automating Retrieving and reverse engineering apks

AutoDroid wraps the ability to retrieve Android applications from a device, along with other functionality, to allow for the configurable bulk interaction with an Android device. AutoDroid is configurable with a JSON file, using the below configuration all applications from all connected devices will be extracted from the device, and their manifest files extracted and saved locally to an XML format. 

{
  "devices": ["*"],
    "apps": ["*"],
    "commands": {
      "get_app": ["!adb_connect !app_path !app_id.apk"],
      "reverse_app":["reverse: !app_id.apk;manifest"]
    }
}

Ensure all AutoDroid dependencies are installed by running the below installation command:

pip install -r REQUIREMENTS.txt

After creating a JSON config file, AutoDroid can be run by providing the path to the config file as a command line parameter:

python AutoDroid.py <JSON config path>

It would now be possible to iterate through these manifest files one by one to identify trends and malicious configurations commonly seen in malware. As, on average, most users have upwards of 80 applications on a single device this would, however, take a considerable amount of time. In the next section machine learning is used to combat this issue and automate the analysis of these APKs.  

Using machine learning to identify malware

As mentioned previously, the manual process of reviewing every single APK on an Android device can be tedious. This article pitches using machine learning to serve as a first pass to help save some of this analysis time. DroidDetective is a Python tool for analysing Android applications (APKs) for potential malicious configurations in the AndroidManifest.xml file.

Dependencies for DroidDetective are installed in the same fashion to AutoDroid. DroidDetective also requires an apk_malware.model (the pre-trained ML model) at the execution root.

pip install -r REQUIREMENTS.txt

After this DroidDetective can be run as follows

python AutoDroid.py <path to APK> <optional JSON output file>

DroidDetective works by training a Random Forest binary classifier on information derived from both known malware APKs and legitimate APKs. This tooling comes pre-trained, however, the model can be re-trained on a new dataset at any time. This model currently uses permissions from an APKs AndroidManifest.xml file as a feature set. This works by creating a dictionary of each standard Android permission and setting the feature to 1 if the permission is present in the APK. Similarly, a feature is added for the amount of permissions in use in the manifest and for the amount of unidentified permissions found in the manifest.

Putting it all together 

Using what we’ve implemented so far in this article, DroidDetective can be used alongside AutoDroid to automatically retrieve applications from a device and identify if they contain malicious configurations in their manifest file. 

For this, ensure that all requirements and required files are present, and run AutoDroid with the following configuration:

{
  "devices": ["*"],
    "apps": ["*"],
    "commands": ["!adb_connect pull !app_path !app_id.apk",
    "python DroidDetective.py !app_id.apk output.json"]
}

This will result in all APKs on the target device(s) being analysed by DroidDetective. As an optional json output file is provided all of these results are appended to output.json. An example of this ca be seen below:

{
    "com.google.android.uvexposurereporter": false,
    "com.google.android.networkstack.tethering": false,
    "com.amazon.mShop.android.shopping": false,
    "com.google.omadm.trigger": false,
...
    "com.google.android.apps.cultural": false,
    "com.android.companiondevicemanager": false,
    "com.verizon.obdm_permissions": false,
    "com.android.mms.service": false,
    "com.google.android.apps.docs.editors.sheets": false
}

 

 

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

TypeDescription
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. 

 

Dendroid

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.

APKLab

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” →

 

Let’s start things off with a question; what does the TV show Black Mirror, the series Person of Interest, and Android Google Play devices all have in common? Well it’s not the fact that they all involve technology, nor is it the fact that they all include mobile devices, instead it’s the fact that they all include elements of using machine learning and AI to detect malicious activity. In the case of Android Google Play devices this is via the Safety Net APIs  – and it’s this we’ll be talking about today. By the end of this article we’ll have answered the bellow, by reverse engineering the Android SafetyNet Attestation API and framework.

How do app developers identify if a device an application is running on is legitimate?

Google Play Safety Net Attestation API

What is SafetyNet?

Google SafetyNet (also known as SNet) is a suite and umbrella of functionality available on Android devices that have Google Play Services available. Google Play Services comes with most Android devices and allows devices to have applications such as the Google Play Store installed on them. Some devices, such as a selection of Huawei devices, do not have Google Play Services available, and so SNet is not available on these devices. 

The SNet umbrella is broken down into the following:

SNet Safe Browsing API

The SNet Browsing API provides services to application developers, running application’s on device’s with Google Play Services, the ability to check a given URL for if it has been identified as a known threat by Google. For example a web browsing application could use this API to identify if the URL a user was visiting was malicious and in turn the URL could be blocked.

SNet Verify Apps API

The SNet Browsing API provides services to application developers, running application’s on device’s with Google Play Services, the ability to check if there are any malicious or harmful applications running on the same devices as the application. For example a banking application could use this API to ensure it is not used on the same device as malware.

SNet reCAPTCHA API

This API extends the Google reCAPTCHA framework and allows application developers to use reCAPTCHA checks inside of their application. For example these reCAPTCHA checks could be used to validate user requests or form submissions.

SNet Attestation API

The SNet attestation API is one of the most interesting of these APIs and the one that we’ll be focusing on moving forward. The Attestation API is an anti-abuse API that allows application developers to assess the Android device their application is running  on – in turn being able to identify if the application the device is running on is rooted or compromised in some way. As an example, banking applications can use this API to ensure they’re not running on a rooted device.

Rooting and Root Detection

Both Android and other mobile operating systems have a concept of privileged control on a device. Here, when talking about privileged control, it refers to providing a user with extensive controls over the device, which the manufacturer did not intend for the end-user to have and can normally allow for actions such as breaking application sandboxing, accessing and modifying system actions, and accessing the underlying kernel. For Android this is commonly referred to as rooting. From the above it can been seen why some applications would not want to run on rooted devices, including user security, intellectual property controls, and it leading to future exploitation or control of an application. Below can be seen a sample of application’s on Android that implement root detection – this comes in many forms; from instructing the user the device is rooted, closing the application completely, or silently logging that the device is rooted.

One of the most common root detection mechanisms in place in Android applications is the Google Play SNet API. Later on this article will dive into the internals on how the SNet API operates, however, for now the below demonstrates a sample wrapper application (an application that’s sole purpose is to call the API and display the results to the screen) using the API on both a standard and rooted Android device. 

How Developers get Attestation data from SNet

Now that we can see that applications using the SNet API are magically able to identify if a device is rooted or not, the next question is, how? The process for a developer is a fairly simple one. At first Google Play Services periodically runs on the device and downloads a jar file (Java archive), this code is then dynamically run and aggregates an assortment of data (Described later) on the device. This information is then sent to an unknown Google server for analysis. After this point third party applications running on the device can then call the API and will receive several variables in response.

The variables received by the application from the API include:

  • ctsProfileMatch: The strictest identifier on the device’s integrity.  If false then the device has failed Android compatibility testing and is not a Google-certified Android device.
  • basicIntegrity: The more lenient identifier of device integrity. If false then it is likely that the device has been tampered with in some way.

There are also several optional variables that can be returned:

  • error: Error information relating to the current API request.
  • advice: Recommendations for fixing the device state.
  • evaluationType: How the device evaluation was performed, i.e. is it backed by hardware?

Taking apart the mystery Jar file

As previously mentioned, Google Play Services periodically aggregates data from an Android device and sends it to a server for analysis. While the decision making, on if a device is tampered with or not, is performed on the server the data aggregation occurs on the device. This means that by reverse engineering the Jar file that is downloaded by SNet a picture can be put together of what data goes into identifying the integrity of a device. 

Timeframe of SNet Attestation versions

There have been many versions of SNet over the years, and with each new version comes new forms of data aggregation that occur on the device. Below shows an incomplete timeframe of SNet versions (put together in part by the research from Collin Mulliner & John Kozyrakis) up to 2019, however, there have been many more versions both between these dates and after. 

SNet Attestation Modules

The data aggregation performed by the SNet Jar file is broken down into several categories based on their functionality. From this point I’ll walk through a handful of the modules available in SNet version 10000700. 

Device State Checker

DeviceStateChecker.java | SNet Version: 10000700

Including variables: the verify boot state, verifying mode, security patch level, and if OEM unlock is supported on the device.

Settings Finder

SettingsFinder.java | SNet Version: 10000700

Including variables: if ADB is enabled, the device fingerprint status, the lock screen timeout, lock screen type, if non-market apps are enabled, notification visibility at lock screen, Android smart lock, and the storage encryption status.

SD Card Analyzer

SdCardAnalyzer.java | SNet Version: 10000700

Process: this module saves a JPG file to the external storage of the device and periodically checks in on it. If the image has been altered, removed, or changed in any way it’s reported as a indicator or compromise. 

Rooting File Finder 

RootingFileFinder.java | SNet Version: 10000700

Process: this module looks for the presence of several files and file paths on the device, including: “/system/bin”, “/dev/block/loop”, “/system/xbin”, “/bin”, “/xbin”, “/proc/self/mountinfo”, and more. 

Preferred Package Finder

PreferredPackageFinder.java | SNet Version: 10000700

Process:  this module aggregates the set default installer and web browser on the device (i.e. Google Play Store and Chrome).

Captive Portal Detector

CaptivePortalDetector.java | SNet Version: 10000700

Process: this module sends a request to a hardcoded Google server and saved the IP address, response body, and response code. Presumably this is compared with the known response by the integrity check on the server to identify if a captive portal or man-in-the-middle was present on the device.

Wrap-Up

In addition to the above sampled aggregated variables, there are many more that SNet aggregates and sends to the Google server for integrity reviews. In late 2019 the version of SNet I reviewed included approximately 55 variables that it was aggregating. 

In past research I’ve previously developed a tool called Tamper, which seeks to replicate some of the key functionality of SNet. I may write a follow on article on this process, however, for now you can see it’s development over on GitHub.

 

 

Develop Your Reverse Engineering Skills

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.

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! 

 

 

 

ANDROID CHEAT SHEETS AND STUDY GUIDES

Free and premium resources, available on everything from Android and iOS security fundamentals, reverse engineering basics, and study guides for my Udemy courses.

 

During this article we’re going to take a whistle stop tour of Android reverse engineering to get you to the stage of being able to take apart and review a simple Android game, as soon as possible. 

What  you’ll need to get started

For this walkthrough the only tooling you’ll need is an APK (Android PacKage) decompiler, called Jadx. Jadx can be installed onto Windows, Linux, and MacOS by following the instructions on their website. Using Jadx is as simple as running:

jadx-gui <path to the APK file>

How to reverse engineer an application

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.

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 or game 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. 

Decompiling and Disassembling An APK

Reverse Engineering Android Games

There are several reasons why you might want to start taking apart Android games and applications – the obvious being curiosity and the ability to alter key traits in games such as health, score, and more. For the purpose of today we’re going to download and reverse engineer an MIT licensed game, ‘Original 2048’. You can download the APK of this game from APKPure or APKMirror (However, please be warned that these are external websites and I do not control the content on them – ensure to download the APK safely). 

Now that we’ve downloaded the 2048 game APK we can open it in Jadx, with the command above. In the panel on the left hand side of Jadx-gui you will be able to see all of the resources bundled into the APK, including decompiled source code, assets, images, and more. The source code is most probably obfuscated, this means that at compile time the name of the classes, functions, variables, and so on were all altered and modified to obscure the program if a malicious actor was to reverse engineer it (i.e. the class called ‘update’ could be renamed to ‘ca’). While this is the case we can find look at the entry point for the decompiled source code – this can be seen in the source code drop down at the below path:

com.androbaby.original2048

The next steps are up to you, look at what images are used in the game, review the configuration via the AndroidManifest.xml file, or take it a step further and reverse engineer the .dex file located in the applications assets folder. 

 

Learn More

This article is inspired by my Udemy course on reverse engineering Android games. If you’re interested in Android, gaming, and learning more about reverse engineering then consider checking it out!

Adverts