Skip to content

Instantly share code, notes, and snippets.

@tin-z

tin-z/APK_info.md

Last active June 16, 2025 16:29
Show Gist options
  • Save tin-z/ba5195c626096cba8e8164235d683758 to your computer and use it in GitHub Desktop.
Save tin-z/ba5195c626096cba8e8164235d683758 to your computer and use it in GitHub Desktop.
Download ZIP
Android APK basic info
Raw
APK_info.md

Index


HAL

  • Hardware abstraction layer
  • Code between linux kernel drivers and native libraries

Android security

system security

  • device encryption

    • file-based for android 7+
    • full-disk for android 5+

  • trusted execution environment (TEE)

    • hardware: keystore to store for example cryptographic keys and biometrics
    • software: trusted applications and API's

  • verified boot

network security

  • tls default
  • dns over tls android 9+
  • separate network security config per app
  • certificate pinning (only trusted cert decrypt traffic for that specific app)

software isolation

  • selinux
  • manifest file permissions

anti-exploitation

  • software + kernel + hardware
    • e.g. seccomp for syscalls

Android app structure

  • APIs

    • hardware/os component layer via the NDK (native development kit) in C/C++
    • Java (or kotlin) API's via the SDK

  • Sandbox

    • VM per app, similar to java vm but is called Dalvik VM android runtime
    • directory and user per app

  • packaging

    • APK (android package kit)
    • AAB (android app bundle)
    • manifest file (app componentes: activites, services, broadcast receivers, content providers)
    • android studio and emulators (Android Open Source Project suite)

  • NDK (Hardware/OS Component Layer via the NDK in C/C++)

    • libc: Standard C library.
    • liblog: Android-specific logging library.
    • OpenGL ES: For graphics rendering, leveraging hardware acceleration.
    • libandroid: For Android-specific features like input and asset management.

  • SDK Java (or Kotlin) APIs via the SDK

    • high-level APIs for interacting with the Android framework.
    • android.location.LocationManager: For accessing location services.
    • android.view.View: For UI components.
    • android.net.ConnectivityManager: For managing network state.
    • Java APIs are executed within the Android Runtime (ART) or Dalvik VM (pre-ART era), offering memory management, garbage collection, and sandboxing

  • Sandbox

    • VM per App: Dalvik VM / Android Runtime (ART) (introduced in Android 5.0). Key distinctions:
    • Dalvik VM: Register-based VM optimized for memory usage, using .dex (Dalvik Executable) files.
    • ART: Replaced Dalvik, offering Ahead-of-Time (AOT) compilation for better runtime performance and memory efficiency.
    • The VM isolates apps from each other, ensuring that crashes or exploits in one app don’t affect others.
    • Vulns: However, this isolation can be bypassed using inter-process communication (IPC) vulnerabilities or deserialization attacks.

  • Sandbox (2)

    • Directory and User per App
    • Each app operates under its own Linux UID and has a dedicated directory under /data/data/<package_name>/ for storing private data.
    • File access is governed by SELinux policies, further restricting cross-app file access.
    • Vulns: Exploits like privilege escalation (e.g., bypassing SELinux policies) or improper file permissions could compromise the sandbox.

  • APK (Android Package Kit) The APK is a compressed archive containing:

    • classes.dex: Compiled bytecode.
    • resources.arsc: Compiled resources for the app.
    • AndroidManifest.xml: Metadata and permissions.
    • lib/<architecture>/: Native libraries (if any).
    • APK files are signed with the developer’s key, and Android enforces signature verification.
    • Vulns: Tampering with APK contents can break this signature, but repackaging attacks involve resigning with a different key.

  • AAB (Android App Bundle)

    • AAB is a distribution format that generates APKs dynamically through Google Play Dynamic Delivery.
    • It reduces app size by delivering only the resources relevant to the device (e.g., screen size, language).
    • This complicates traditional static analysis since the APK might differ on each device.

  • Manifest File, AndroidManifest.xml is critical to app structure, containing:

  • Components:

    • Activities: UI screens.
    • Services: Background operations (e.g., Firebase listeners).
    • Broadcast Receivers: Handle system-wide or app-wide broadcast messages.
    • Content Providers: Facilitate structured data sharing between apps.

  • Permissions:

    • Declares required permissions (e.g., INTERNET, ACCESS_FINE_LOCATION).
    • Misconfigured permissions can lead to overprivileged apps or permission escalation attacks.

  • Development Tools (Android Studio)

    • Lint: For static code analysis.
    • Profiler: For performance monitoring.
    • ADB (Android Debug Bridge): For debugging and communicating with devices/emulators.
    • ProGuard/R8: For obfuscation and shrinking.
    • Vulns: Security features include debugging tools to analyze permissions, logs, and memory allocations, but misused tools (e.g., enabling debug logging in production) can expose sensitive data.

  • Development Tools Emulators (Android Open Source Project Suite)

    • Emulators replicate Android environments for testing.
    • Capable of running ARM or x86 architecture images.
    • Can be configured with various API levels, hardware profiles, and system configurations.
    • Vulns: Misconfigured emulators, such as those with root access enabled, can become attack vectors during testing.

Key Components of manifest file

  • AndroidManifest.xml
  1. Activities

  • represent the app’s UI screens. Each activity corresponds to a single task or user interaction.

  • Example: A login screen, a settings screen, or a product detail page.

  • Key Properties:

 android:name: Specifies the fully qualified name of the activity class.

 android:launchMode: Defines how an activity instance is managed in the activity stack. Modes include:
    standard: Default; a new instance is created each time.
    singleTop: Reuses the activity if it's already at the top of the stack.
    singleTask: Reuses the activity if it exists anywhere in the stack and clears other activities on top.

android:exported: Determines whether other apps can launch this activity. Misconfigurations here can lead to component hijacking attacks.

android:theme: Specifies the theme (e.g., light, dark, or custom).

Lifecycle Methods:
    onCreate: Called when the activity is created. Used to initialize UI components.
    onStart, onResume, onPause, onStop, onDestroy: Manage the activity's lifecycle (e.g., starting/stopping animations or saving app state).
  • Example:
<activity android:name=".MainActivity"
          android:exported="true"
          android:launchMode="singleTop">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

  1. Services

  • Services handle background tasks without direct user interaction, such as playing music, syncing data, or receiving push notifications.

  • Types:

    • Foreground services: Used for tasks that the user is actively aware of (e.g., music playback).
    • Background services: Perform tasks without user awareness (e.g., data syncing). Starting from Android 8.0 (Oreo), these are heavily restricted for battery optimization.
    • Bound services: Provide interfaces for other components or apps to interact with them.

  • Key Properties:

android:name: Specifies the fully qualified service class name.

android:exported: Determines whether other apps can bind/start the service. 
    (Misconfigurations may allow unauthorized apps to interact with the service.)

android:foregroundServiceType: Specifies the type of foreground service (e.g., location, mediaPlayback).

Lifecycle Methods:
    onCreate: Called when the service is first created.
    onStartCommand: Handles service start requests.
    onDestroy: Cleans up resources when the service is stopped.
  • Example:
<service android:name=".SyncService"
         android:exported="false"
         android:foregroundServiceType="dataSync">
</service>

  1. Permissions

  • Permissions control access to sensitive system features, user data, or device resources.

    • Permissions must be declared in the manifest for the app to request them.

  • Categories:

    • Normal permissions: Granted automatically (e.g., INTERNET).
    • Dangerous permissions: Require explicit user consent (e.g., ACCESS_FINE_LOCATION).
    • Signature permissions: Granted only if the requesting app shares the same signature as the app defining the permission.

  • Common Issues:

    • Over-requesting permissions can lead to privacy concerns or rejected app submissions.
    • Failing to declare a required permission results in a SecurityException at runtime.
    • Improper use of android:permission in exported components can allow unauthorized access.

  • Example:

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

  1. Broadcast Receivers

  • Components that respond to system-wide broadcast messages or custom app-defined broadcasts.

  • Examples:

    • System broadcasts: BOOT_COMPLETED, BATTERY_LOW.
    • Custom broadcasts: Sent by your app to notify other components or apps.

  • Key Properties:

android:name: Specifies the receiver class.

android:exported: Determines whether the receiver can receive broadcasts from other apps.

intent-filter: Specifies the types of broadcasts the receiver listens to.

Lifecycle: Broadcast receivers do not remain active. They are triggered when a broadcast is received and stop immediately after handling it.
  • Example:
<receiver android:name=".MyBroadcastReceiver" android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED" />
    </intent-filter>
</receiver>

  1. Content Providers

  • Facilitate data sharing between apps and manage structured data (e.g., databases, files).

  • Example: Sharing contacts between apps.

  • Key Properties:

android:name: Specifies the provider class.

android:exported: Determines whether other apps can interact with the provider.

android:authorities: Specifies the unique URI identifier for the provider.

Vulnerabilities: Improperly configured android:exported="true" or missing URI permissions can allow unauthorized data access.
  • Example:
<provider android:name=".MyContentProvider"
          android:authorities="com.example.myapp.provider"
          android:exported="false">
</provider>
  • Lifecycle Methods
    • Key lifecycle methods mentioned (like onCreate) are part of app components (Activities, Services, etc.)
    • and define behavior during the component's lifecycle.
onCreate: Initializes the component. Common tasks:
    Setting up UI (for Activities).
    Initializing resources like databases or listeners (for Services or Content Providers).

onDestroy: Cleans up resources when the component is stopped or destroyed.

IPC

  • binder

android-signing

  • 4 versions supported
    • check signing in the following order v4,v3,v2,v1
    • if one of the signing is supported by the apk then it is checked with that version, if fails apk is rejected

etc

proguard

  • ProGuard is an open-sourced Java class file shrinker, optimizer, obfuscator, and preverifier.
  • As a result, ProGuard processed applications and libraries are smaller and faster.
    • The shrinking step detects and removes unused classes, fields, methods, and attributes.
    • The optimizer step optimizes bytecode and removes unused instructions.
    • The name obfuscation step renames the remaining classes, fields, and methods using short meaningless names.
    • The final preverification step adds preverification information to the classes, which is required for Java Micro Edition and for Java 6 and higher.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment