AndroidManifest.xml#

The manifest file describes the app structure, its components (activities, services, content providers, and intent receivers), and requested permissions. It also contains general app metadata, such as the app’s icon, version number, and theme.

Here is an example of a manifest file, including the package name (the convention is a reversed URL, but any string is acceptable). It also lists the app version, relevant SDKs, required permissions, exposed content providers, broadcast receivers used with intent filters and a description of the app and its activities:

1
<manifest
2
    package="com.owasp.myapplication"
3
    android:versionCode="0.1" >
4

5
    <uses-sdk android:minSdkVersion="12"
6
        android:targetSdkVersion="22"
7
        android:maxSdkVersion="25" />
8

9
    <uses-permission android:name="android.permission.INTERNET" />
10

11
    <provider
12
        android:name="com.owasp.myapplication.MyProvider"
13
        android:exported="false" />
14

15
    <receiver android:name=".MyReceiver" >
16
        <intent-filter>
17
            <action android:name="com.owasp.myapplication.myaction" />
18
        </intent-filter>
19
    </receiver>
20

21
    <application
22
        android:icon="@drawable/ic_launcher"
23
        android:label="@string/app_name"
24
        android:theme="@style/Theme.Material.Light" >
25
        <activity
26
            android:name="com.owasp.myapplication.MainActivity" >
27
            <intent-filter>
28
                <action android:name="android.intent.action.MAIN" />
29
            </intent-filter>
30
        </activity>
31
    </application>
32
</manifest>

Note that the package attribute shown above is deprecated in current builds — the application ID is declared as namespace in build.gradle and is no longer written into the manifest at build time.

Classes.dex#

This is the actual code of the app. “dex” is short for Dalvik Executable. Source is written in .java or .kt, which compiles to .class, and those class files are then packed into a dex file to run on the Android runtime.

Past the 64K method-reference limit the build splits the code across several files — classes.dex, classes2.dex, classes3.dex and so on (multidex). When reversing, make sure you are not reading only classes.dex.

lib/#

Native libraries for the application live here, under CPU-specific directories. The ABIs you will actually meet are arm64-v8a, armeabi-v7a, x86_64 and x86 — armeabi and mips were deprecated in NDK r16 and removed in r17, so they are rare now.

This is where precompiled Linux shared objects (.so) live, built by the developer or pulled in from third-party libraries. If an attacker can modify or replace one and get it loaded, that is arbitrary code execution.

assets/#

Any other files that may be needed by the app. Additional native libraries or DEX files may be included here. This can happen especially when malware authors want to try and “hide” additional code, native or Dalvik, by not including it in the default locations.

META-INF/#

Contains files relating to the integrity and authenticity of the app.

This folder is where v1 (JAR) signing keeps its three files

MANIFEST.MF : Information used by the Java runtime when loading the jar — the main class, package version, build number, creator, security policies, and the list of file names in the jar with their SHA-1 digests, etc.

CERT.SF : The list of all files with their SHA-1 digest.

CERT.RSA : The signed contents of CERT.SF, plus the certificate chain of the public key used to sign.

Note this is the v1 scheme only. Most modern apps are also signed with APK Signature Scheme v2 (Android 7+) and v3 (Android 9+), which sign the APK as a whole and keep the signature in an APK Signing Block rather than in META-INF — so a Play-distributed APK may contain no CERT.RSA at all. Run apksigner verify --print-certs -v app.apk to see which schemes an APK carries.

res/#

res/ holds the app’s resources — the ones not compiled into resources.arsc. There are many subfolders inside it, each for a different resource type.

The values folder is worth a look during an assessment: strings.xml holds the app’s constants, and hardcoded secrets — API keys, AWS Cognito pool IDs, endpoints — turn up there more often than they should. In a compiled APK these are not plain XML on disk; they are packed into resources.arsc, so decode with apktool d app.apk (or read them through jadx) rather than expecting to open the file directly.

Activities#

An activity is the entry point for interacting with the user. in-short Activity performs actions on the screen.
Each activity needs to be declared in the Android Manifest with the following syntax:

1
<activity android:name="ActivityName">
2
</activity>

Fragments : represents a behavior or a portion of the user interface within the activity. Fragments don’t need to be declared in manifest files because they depend on activities.

Example in Java:

1
public class MyFragment extends Fragment {
2
    ...
3
}

Services#

A service is a component that runs in the background to perform long-running operations. For example, a service might play music in the background while the user is in a different application

1
<service android:name=".ExampleService" />

Broadcast receivers#

They handle communication between Android OS and applications.

Content providers#

content provider component supplies data from one application to others on request. The data may be stored in the file system, the database or somewhere else entirely.

every component will be in another part in future so here just intro .

Source code obfuscation#

Android Runtime (ART) executes .dex files, which are part of the APK package. Dalvik bytecode (.dex) can be translated to equivalent Java bytecode. Conversion is not perfect and cannot be reversed, but Java code can be easily read and analyzed. Understanding the code, specifically implemented security mechanisms gives the attacker great advantage and significantly increases the chance of exploiting the application.

To mitigate that risk, developers can obfuscate the source code. Obfuscation is a process of making a code difficult to understand by humans, but without changing its semantics and functionality. The most typical techniques used by obfuscators are changing methods/parameters names, modifying the flow of the code and encrypting string and assets.

The obfuscator you will meet most often is R8, the default shrinker in the Android Gradle Plugin since 3.4 — it is what “ProGuard rules” now actually run through, and since AGP 7 ProGuard can no longer be selected at all. DexGuard (Guardsquare) is the commercial upgrade, adding string encryption, control-flow obfuscation and root/tamper checks.

Code Signing#

Every APK must be signed by its developer — but once you decompile and modify one, you are the developer, so you have to sign it yourself.

Rebuild the modified APK, then sign it with apksigner (shipped with the Android SDK build-tools):

1
# 1. rebuild the decoded sources
2
apktool b <path-to-decompiled> -o unsigned.apk
3

4
# 2. generate a throwaway keystore (once)
5
keytool -genkey -v -keystore my.keystore -alias mykey -keyalg RSA -keysize 2048 -validity 10000
6

7
# 3. sign, then verify
8
apksigner sign --ks my.keystore --out signed.apk unsigned.apk
9
apksigner verify --print-certs -v signed.apk

Repackaging changes the app’s signature, so any integrity or signature check the app performs will now fail at runtime — that is a finding in itself, and often the point at which you switch to a Frida hook instead. Note also that you cannot install a re-signed build over the original: uninstall the original first (which wipes its data) or change the package name.

Dalvik & Smali?#

Most android applications are written in java , kotlin is also supported and interoperable with java

Instead of the Java code being run in Java Virtual Machine (JVM) like desktop applications, in Android, the Java is compiled to the Dalvik Executable (DEX) bytecode format.
For earlier versions of Android, the bytecode was translated by the Dalvik virtual machine. For more recent versions of Android, the Android Runtime (ART) is used.
If developers, write in Java and the code is compiled to DEX bytecode

to reverse engineer, do the opposite direction

Smali is the human readable version of Dalvik bytecode. Technically, Smali and baksmali are the name of the tools (assembler and disassembler, respectively), but in Android, we often use the term “Smali” to refer to instructions.
SMALI is like the assembly language: between the higher level source code and the bytecode.