Learn Android Hacking the Right Way: APK Structure Explained for Beginners — Inside Telegram’s APK, File by File (Chapter-03) | xProtagonist
(A quick note before we sail: I used AI as a writing partner to help structure and polish this chapter. The research, commands and outputs are mine. I ran every one of them myself)
Ahoy, Digital Corsairs! ⚓
Welcome back to our Android hacking voyage! 🏴☠️
In Chapter-02, we went down into the engine room: core libraries, native libraries, and those mysterious .so files. Today we stop talking about Android in general and climb aboard a single ship. One real APK. We’ll open every hatch, read every crate, and find out what each file reveals to someone who knows where to look.
First, Let me ask you something.
Suppose you download an Android application. You install it, open it, and everything looks normal. There is a login screen, a profile page, a payment feature, and a dozen other things working quietly in the background.
Everything looks simple from the outside.
But behind that beautiful interface, the application contains code, configuration files, images, layouts, libraries, and other resources working together to make everything happen.
Now imagine the developer gives you no source code.
No GitHub repository. No Kotlin files. No project documentation. Nothing.
All you have is one apk file.
Can you still investigate how the application is built? Can you discover which components it declares, what code it contains, which APIs it references, and what additional files the developer packaged inside it?
Absolutely. And the first step doesn’t require an exploit, a fancy tool, or even a running Android device.
It starts with understanding the APK itself.
Most “APK structure” articles give you a boring list: this folder is for images, that file is for code. That won’t help you on a real assessment. There, you need three answers for every file:
- What does Android actually do with it?
- What can I learn from it before I run anything?
- Where do developers make mistakes in it?
That’s what this chapter is about. To an ordinary user, these are implementation details.
To an Android security tester, they are the beginning of an investigation.
First Things First: What Exactly Is an APK?
APK stands for Android Package Kit. It is the package format used to distribute and install Android applications.
Think of an APK as a delivery box containing most of the ingredients an application needs to be installed and run.
Inside this box, you may find:
- The application’s compiled code.
- Its manifest and configuration.
- Images, icons, layouts, and other resources.
- Additional files such as fonts, HTML, and JSON data.
- Native libraries written in languages such as C and C++.
- Package metadata and, depending on the signing scheme, signature-related information.
An APK is based on the ZIP file format. That means we can use familiar archive tools to list its contents and extract its files.
However, there is an important detail:
An APK is not just a collection of readable source files. Much of its code is compiled, and Android-specific files such as the manifest and resource XML files may be stored in binary formats.
That is why we use tools such as unzip, Apktool, and JADX for different parts of the investigation.
We will use Telegram apk. and we will download it from :
https://telegram.org/android
Now, you have downloaded the APK . First, we will check the file type:
file Telegram.apk
Now, Let’s list its contents without extracting anything:
unzip -l Telegram.apk
This command shows the files and directories packaged inside the APK. To see the actual files, extract them:
mkdir apk_extracted
unzip Telegram.apk -d apk_extracted
Now explore the extracted directory:
cd apk_extracted
ls -la
Congratulations ! You’ve just cracked open your first APK and taken a peek inside an Android application.
But here’s where the real adventure begins and we will go through one by one.
Understanding the Most Important Files Inside an APK
Let’s examine the major files and directories one by one.
The exact contents of an APK vary depending on the application, its build process, and the libraries it uses. You will not necessarily find every item listed below in every APK.
01. AndroidManifest.xml: The First Place I’d Look
If I had to choose one file to inspect before diving into the rest of an unfamiliar APK, I’d start with the manifest.
Not because it contains every secret. It doesn’t.
I start here because it helps me understand how Android is supposed to interact with the application.The manifest declares information about the app, including its components, permissions, intent filters, and other configuration.
In other words, before investigating what a component does, I want to know which components the app declares. (we will go through all of these in the upcoming chapters)
Simply, What is it?
It is a configuration file that describes the application and declares information Android needs to install and run it.
What’s inside?
Depending on the app, it can include:
- The application’s package name.
- Permissions the app requests.
- Activities, services, broadcast receivers, and content providers.
- Application settings and metadata.
- Intent filters that describe which types of actions or requests a component can handle.
- Component properties such as android:exported.
lets open the file from the extracted folder.
we don’t understand anything what is written here , right ! Because
The AndroidManifest.xml in is compiled into Android’s binary XML format. That’s why running cat AndroidManifest.xml displays strange symbols instead of readable XML.
for this we will use jadx or apktool . jadx Analyzes DEX bytecode and reconstructs a readable, Java-like representation. we can use this command to download jadx -
sudo apt update
sudo apt install jadx
jadx --version
now lets open a terminal and open jadx
jadx-guiand we will see the interface of jadx . then we will directly open the Telegram apk file . not the unzipped files.
now we can , see all the files of telgram more structurily .
here is our AndroidMenifest.xml file under resource folder .
and now we can see everything in a readable format.
if we see then we can know :
- Package name: org.telegram.messenger.web — Identifies the Android application package.
- Application version: 13.0.3 (versionCode: 71839) — Specifies the app’s version information.
- SDK compatibility: Minimum SDK 23, targeting SDK 36 — Indicates the minimum Android API level and the target API level declared by the app.
- Location access: Requests coarse and fine location permissions, supporting location-related functionality.
- Network access: Requests INTERNET, enabling network communication with Telegram’s services.
- Media and clipboard access: Requests ACCESS_MEDIA_LOCATION and READ_CLIPBOARD, indicating potential access to media-location metadata and clipboard content.
- Telephony permissions: Requests permissions including CALL_PHONE, READ_CALL_LOG, READ_PHONE_STATE, READ_PHONE_NUMBERS, and SEND_SMS.
- Microphone and camera: Declares camera and microphone hardware features and requests foreground-service permissions associated with camera and microphone use.
- Foreground services: Declares permissions for several service types, including data synchronization, media playback, location, and remote messaging.
- Push notifications: Requests com.google.android.c2dm.permission.RECEIVE, associated with receiving Firebase Cloud Messaging (FCM) messages.
- Hardware compatibility: Declares support for features such as GPS, Wi-Fi, Bluetooth, telephony, and cameras, with many marked optional.
- Screen compatibility: Supports multiple screen sizes, densities, and resizable layouts.
- Custom permission: Defines org.telegram.messenger.web.permission.MAPS_RECEIVE with signature protection, restricting access to apps signed with the same signing certificate.
Hacker perspective: Why should you care?
The manifest is one of the best places to begin your investigation because it helps you map the application’s structure before diving into its code.
Ask yourself:
- Which components does the app declare?
- Which permissions does it request, and why?
- Are any components exported?
- Do intent filters reveal deep links or custom URL schemes?
- Are there configuration settings worth investigating further?
An exported component can potentially be reached by another application, subject to Android’s rules and any applicable permissions or other checks. That makes it interesting to investigate — but it does not automatically mean a vulnerability exists.
02. classes.dex — Where Much of the Application Logic Lives
Now imagine that the manifest gives you a map of a building. The next question is: what actually happens inside the rooms?
That is where the application’s compiled code becomes important.
What is it?
A DEX file is a compiled code file used by the Android runtime. DEX stands for Dalvik Executable.
Java and Kotlin source code is typically compiled and transformed into DEX bytecode as part of the Android build process. Think of classes.dex as a book written in a format designed for a machine to process, rather than a person to read comfortably. It contains compiled instructions, class definitions, methods, fields, and other information needed to represent the app’s code.
For example, when you open an APK in JADX-GUI, you may see classes.dex in the project tree. That’s because JADX recognizes the DEX file as the compiled code it needs to analyze.
What’s inside?
You may find code responsible for:
- Login and registration workflows.
- API requests and response processing.
- Input validation.
- Session handling.
- Business rules.
- Data storage.
- Communication with other application components.
The main file is commonly named:
classes.dex
Larger applications may contain additional files:
classes.dex
classes2.dex
classes3.dex
These additional DEX files are normal in applications whose compiled code is split across multiple files.
Get Protagonist | Offensive Security’s stories in your inbox
Join Medium for free to get updates from this writer.
lets check the dex file of the telegram.apk
JADX doesn’t show code when you click classes.dex. The decompiled classes appear under Source code, sorted by package. Expand org.telegram and you’re reading Telegram’s logic. but we will go with a different approach to understand another file type .Smali file . Because a decompiler guesses what the source looked like, and sometimes it guesses wrong. Smali shows exactly what’s in the DEX, with no guessing. JADX examines the DEX instructions and attempts to reconstruct readable Java-like source code.
we will use apktool . Apktool takes a different approach. It can disassemble DEX bytecode into Smali files.
now the question is what is smali files or smali code !!
03. what is a .smali file?
Smali is a human-readable representation of the instructions stored in a DEX file.
Imagine you have a song saved as an audio file. You can’t easily read the audio file’s contents as words. But if someone gives you a written transcription, you can inspect the words.
Similarly:
- classes.dex is the compiled binary representation.
- .smali is a text representation of the instructions inside that DEX file.
Smali lets you read lower-level details about what the compiled app’s methods do.
lets take a small example so that we can understand the difference between the dex bytecode and the smali code :
Suppose the developer writes this Java code:
public int add(int a, int b) {
return a + b;
}The Android build process compiles the code into DEX bytecode, which is packaged inside the APK. Now imagine you don’t have the original source code. You only have the APK.
then how can you know what has written on the code .
Decompiler: JADX
Takes compiled DEX bytecode and attempts to reconstruct Java-like source code.
return a + b;
Its goal is to make the program’s logic easier for humans to understand.
Decoder / disassembler: Apktool
Decodes Android resources and disassembles DEX bytecode into Smali instructions.
add-int v0, p1, p2
return v0Its goal is to expose the lower-level instructions and decode the APK’s resources into inspectable files.
now lets decode with the apktool :
apktool d Telegram.apk -o telegram_decoded
The folder names you see are not necessarily features of Telegram. They often represent Java/Kotlin package names, Android framework-related code, libraries, and compiled classes.
folder structure:
Each folder represents a part of a package namespace, while each .smali file represents a class or interface.
For example:
java/util/function/Function.smali
corresponds to the Java package java.util.function and its Function interface.
Don’t try to understand every folder. Start by finding the app’s package and entry points.
from manifest file we can find the package name:
org.telegram.messenger.web
That is a useful search starting point, although the package name alone won’t tell you where every feature is implemented.
Look for Telegram-related classes
Now let’s move to a file that beginners often overlook.
04. res, assets, and resources.arsc
Imagine you're building an Android application. Your app needs:
- Images and icons
- Text, such as "Login" or "Settings"
- Layouts that define how screens look
- Colors and dimensions
- Other files, such as fonts or JSON configuration files
Android provides different ways to store these things.
res/ — Resources folder: Contains Android-recognized resources, such as images, layouts, strings, colors, and dimensions.
Example: res/drawable/logo.png, res/layout/activity_main.xml
assets/ — Raw files folder: Contains files that the developer wants to package and access as files, often using their paths.
Example: assets/config.json, assets/fonts/custom.ttf
resources.arsc — Compiled resource table: Contains information Android uses to identify and look up compiled resources, including their IDs and values.
Think of it as an index or directory for the app's Android resources.
- res/ contains the resource files.
- resources.arsc is the catalog that tells Android how to identify and look up resources.
- assets/ contains files that the application can access directly by path.
At this point, you have inspected the manifest, followed some DEX code, and explored resources.
Then you notice another directory:
05. lib/
What is that?
The .so extension usually identifies a native shared library. Android applications can include native code written in C or C++, often through the Android Native Development Kit (NDK) or third-party dependencies.
The directory may contain architecture-specific versions of the same library:
lib/
├── arm64-v8a/
├── armeabi-v7a/
├── x86/
└── x86_64/
These names identify different Android ABI variants. A package doesn’t have to include every architecture.
Next, let’s talk about a directory that is easy to misunderstand.
06. META-INF/
The META-INF/ directory may contain files related to the APK’s signature.
Think of it like a package containing documents that help verify who signed the app and whether its contents have changed.
You may see:
META-INF/
├── MANIFEST.MF
├── CERT.SF
└── CERT.RSA
Let’s understand these three files.
MANIFEST.MF: Contains entries with information, including digests (hashes) of files in the package.
CERT.SF: Contains signature-related data, including digests of manifest information.
CERT.RSA: In the traditional JAR-signing arrangement, contains the digital signature and the signer’s certificate.
What is an APK signature?
Imagine a developer creates an app called ShopMate.
Before distributing it, the developer signs it using a private cryptographic key.Think of this as putting a tamper-evident seal on a package.
When Android verifies the signature, it checks whether the package satisfies the relevant signing and integrity requirements.
For example, if someone modifies a signed APK and then tries to install it without producing a valid replacement signature, signature verification will generally fail.
But there’s an important distinction: a signature proves that the package was signed by the holder of a particular key, not automatically that the signer is the legitimate developer. To establish that it’s the official app, you need to compare its signing identity with a trusted reference.
You don’t need to memorize these file names yet. Just remember that they are associated with the older APK signing mechanism, called v1 signing
Not every APK has these files, and their absence does not prove that the APK is unsigned.
Android supports newer signing schemes, including v2 and v3, which store their signature data in a signing block outside the normal ZIP entries.
So, if you don’t find CERT.RSA, don’t conclude that the APK is unsigned.
No CERT.RSA does not mean no signature
now lets check the signature of the telegram.apk
apksigner verify --verbose --print-certs Telegram.apk
To interpret the result, ask three questions:
- Does signature verification succeed? This indicates whether the signature is valid under the checks performed by the tool.
- Which signing schemes are supported? The output can show whether v1, v2, v3, or other supported schemes verify.
- Does the certificate match a trusted reference? Compare its fingerprint with the fingerprint of a known-good release.
The Most Common Mistakes Beginners Make
Before we finish, let’s clear up a few misunderstandings.
Mistake 1: “If I find a suspicious filename, I have found a vulnerability.”
No. A filename is a clue, not proof. You must investigate how the file is used and demonstrate a security impact.
Mistake 2: “If an activity is exported, the app is vulnerable.”
Not necessarily. Exported components can be intentional. You must examine the component’s permissions, input handling, authentication requirements, and authorization logic.
Mistake 3: “Everything inside an APK is readable as normal text.”
No. DEX files contain compiled bytecode, Android XML may be stored in binary form, and native .so libraries contain compiled machine code. Different file types require different tools.
Mistake 4: “META-INF/ is the only place to check APK signatures.”
Incorrect. Modern APK signature schemes store signature data differently. Use appropriate verification tools rather than relying on a directory listing.
Mistake 5: “Finding an API endpoint means I found an API vulnerability.”
No. An endpoint is a place to investigate. You still need to test the relevant security controls, such as authentication, authorization, and server-side validation, within your authorized scope
Final Thoughts
Let’s return to the original question.
What can you learn from an APK when you don’t have its source code?
Quite a lot.
The manifest helps you understand declared components and configuration. DEX files let you investigate compiled application logic. Resources reveal interface and configuration clues. Assets may contain additional packaged data. Native libraries introduce another layer of code to analyze. Signature verification helps establish information about the package’s integrity and signing identity.
But the individual files are not the most important part.
The important part is how you connect them.
You find a component in the manifest. You locate its implementation in JADX. You follow the inputs it accepts. You discover which API it calls. You investigate whether the server enforces the correct authorization checks.
One observation leads to the next.
That is how an APK stops looking like a random collection of files and starts becoming an understandable system.
But remember the most important lesson:
A good hacker doesn’t just ask, “What file is this?” A good hacker asks, “What does this file tell me, what assumptions can I make, and how can I safely verify them?
In the next chapter, we’ll dive into AndroidManifest.xml file .
Until then, keep exploring, keep questioning, and keep learning the right way.
Ruddra ~ xprotagonist-New Here ? Start with
#AndroidHacking #AndroidSecurity #MobileApplicationSecurity #AndroidPentesting #APKAnalysis #ReverseEngineering #JADX #Apktool #CyberSecurity #EthicalHacking
