Relocate and Emulate: Re-Hosting Android’s Application Layer 1st Thomas Sutter
2nd Timo Kehrer
3rd Bernhard Tellenbach
4th Marc Rennhard
arXiv:2606.09528v1 [cs.SE] 8 Jun 2026
University of Bern Armasuisse Science and Technology Zurich University of Applied Sciences University of Bern Winterthur, Switzerland Cyber-Defense Campus Bern, Switzerland Bern, Switzerland [email protected] Thun, Switzerland [email protected] [email protected] [email protected]
Abstract—Dynamic analysis of Android’s application layer typically relies on physical devices, limiting scalability and reproducibility. To compensate, we introduce a systematic re-hosting method that relocates the Android framework and pre-installed software from real device firmware into a fully emulated environment. Our approach integrates vendor-specific components into the Android Open Source Project (AOSP) build system using tailored extraction and injection strategies, producing vendorflavoured emulator images that preserve system integrity and runtime compatibility. This enables dynamic execution of realworld framework and application-layer components, including proprietary binaries and pre-installed apps, across multiple SDK versions. We evaluate our method on 184 firmware samples from SDK 31–33. It achieves high build and boot success rates, with residual failures primarily occurring during core-service initialization due to baseline strategy limitations, missing dependencies, device-protection checks, or emulator constraints. However, the modular design allows injection strategies to be extended for specific firmware, supporting broader compatibility and future research on automated, adaptive re-hosting. Though we identified potential for optimization through engineering vendor-specific solutions, our research demonstrates the feasibility of vendorflavoured emulators for scalable, reproducible dynamic analysis. Index Terms—Android, Mobile, Smartphone, Rehosting, Emulator, Firmware, ROM, Android Framework, Preinstalled, Dynamic-Analysis, AOSP, Native Libraries, Pre-installed Apps, Security, Software Engineering
I. I NTRODUCTION The Android Open Source Project (AOSP) provides a flexible foundation that allows device manufacturers to tailor the operating system to their hardware and market needs. These customizations often involve modifying core components, such as the application framework—including the core system process Zygote [1]—and integrating proprietary or region-specific applications [2]. While this adaptability enables innovation, it also introduces additional complexity and leads to a fragmented Android ecosystem [3]. Fragmentation poses several risks [4], [5], including the introduction of software bugs [6], [2], reduced maintainability [7], and security vulnerabilities in vendor-specific system components [2], [8], [9], [10]. Despite Android’s open-source foundation, vendor modifications to the application framework make dynamic analysis challenging and often unreproducible [11]. Pre-installed apps (PIAs) on Android devices illustrate this problem: studies
show that they are often outdated, privacy-invasive, or insecure [9], [12], [13], [14]. Most existing analyses, however, rely on static-analysis techniques [3], [13] or are conducted on a limited set of devices [15], which cannot fully capture runtime behaviour. To perform comprehensive dynamic analysis, researchers often need to root or jailbreak devices [11], [16], granting privileged access to system resources and enabling monitoring of otherwise restricted processes. While dynamic analysis provides deeper insight, it is impractical at scale because it requires physical devices that are costly, heterogeneous, and difficult to reproduce due to hardware variability and regional firmware differences [11]. To compensate, we propose a re-hosting approach that enables dynamic, device-independent analysis of the Android application framework. To our knowledge, this is the first approach that re-hosts the Android application framework from real-world ARM firmware into the Android emulator, enabling vendor-specific dynamic analysis without physical devices. While previous approaches primarily target Linuxbased IoT devices [17], [18], [19] or RTOS [20], our work focuses on Android firmware, specifically the re-hosting of application-layer components. Prior systems such as Firmadyne [18], FirmAE [19], and HALucinator [21] automate rehosting for embedded Linux or HAL-level code but do not support Android’s multi-layered framework, binder IPC, or AOSP integration. Our virtualized testing framework supports a wide range of use cases, including security evaluation, software testing, and performance benchmarking. Our re-hosting method addresses three key challenges. (i) Identifying and extracting vendor-specific framework components: We analyse firmware from 184 smartphones to identify common modification patterns. Our findings show that most vendors extend or modify existing AOSP components while largely preserving the original file structure. Based on these insights, we design extraction, and injections routines to reliably retrieve the relevant binaries and resources. (ii) Executing vendor binaries and dependencies in the Android emulator: We design configurable injection strategies to integrate vendor binaries and their native-library dependencies into an emulator compatible image. Depending on the modification pattern, we apply dynamic injection strategies to ensure correct linking and execution. We demonstrate this by re-hosting the Zygote
binary (app_process64) and other core services, and we measure successful process execution. (iii) Re-hosting custom vendor services: By integrating into the AOSP build process, we create a configurable method for re-hosting vendor-specific services that is applicable across a diverse set of Android devices and OS versions. We leverage Android Pony EXpresss (APEXs) to dynamically link vendor binaries and their nativelibrary dependencies into an isolated namespace environment. We evaluated our re-hosting approach on firmware images from multiple vendors, including Google, Xiaomi, and Qualcomm. For each vendor, we generated functional emulator images based on a unified baseline injection strategy applied across all tested SDK versions. This setup provides a consistent experimental baseline that facilitates reproducible and comparable re-hosting results across vendors. The evaluation confirms that our method is capable to re-host key components of Android’s application layer—including the Zygote process, Java framework, and vendor-specific binaries—while preserving build integrity and system functionality. In sum, we present and demonstrate the feasibility of a novel re-hosting method that integrates vendor-specific code into the AOSP build process, producing vendor-flavoured emulator images compatible with the Android emulator. These images enable scalable, dynamic testing of application-layer components in a fully emulated environment. While we adopted a baseline configuration that is intentionally conservative for reproducibility in terms of our experiments, vendor-tailored optimizations create a clear path towards further improving rehosting coverage and runtime success in future work. Through systematic evaluation of file coverage ratios and success rates, we establish a foundation for targeted enhancements and adaptive re-hosting strategies. We summarize our main contributions as follows: 1) A systematic, build-integrated method for re-hosting Android’s application layer from vendor firmware into the emulator. 2) Automated extraction, signing, and a base set of configurable injection techniques for integrating applicationlayer components. 3) Empirical validation showing functional vendor-flavoured emulator images across SDK 31–33 with a generic baseline injection strategy. 4) An open, reproducible infrastructure enabling scalable dynamic analysis of real-world Android firmware with study artefacts publicly available at: https://sites.google.com/view/relocate-and-emulate II. BACKGROUND The Android software architecture is organized into several distinct layers, as illustrated in Figure 1. At its foundation lies the Linux kernel, which provides essential system functionality such as process and memory management, device driver support, and security enforcement. Above the kernel resides the Hardware Abstraction Layer (HAL), a collection of standardized interfaces that enables the Android framework to communicate with hardware components—such as GPS, radio,
and sensors—without requiring knowledge of their devicespecific implementations. Built upon this foundation is the user space, which comprises the Android application layer. This layer includes the software components responsible for managing and executing user-facing applications and system services, forming the visible interface between the Android system and the end user. While this layered design promotes portability and modularity, it also creates dependency chains between components that can complicate re-hosting efforts. Vendor-specific modifications can occur across all layers—from kernel patches and custom HAL modules to modified framework services and proprietary applications—introducing additional complexity when attempting to reproduce system behaviour in a re-hosted environment. In our work, we focus solely on the application layer, as it encapsulates the Android framework and preinstalled applications. Focussing on the application layer, Android uses multiple disk partitions (e.g., system, vendor, system ext, and product) to organize the operating system and its components. These partitions serve to separate privileges and responsibilities between system and vendor code, allowing device manufacturers to customize the OS without compromising compatibility with the Android framework. In practice, the application layer spans over several disk partitions and in theory, remains isolated from the kernel and hardware via the HAL. The application layer consists primarily of framework bytecode files (.dex, .jar), system services (.elf , .apex), native libraries (.so), static resources (.xml, .json, .ogg, etc.), and pre-installed apps (.apk, .odex, .vdex). While this list is not exhaustive and may vary across products and device classes (e.g,. smartphones, cars, etc.), our re-hosting approach focuses on extracting and integrating these key components into a working emulator image to enable dynamic analysis. To do so, we implemented custom routines to handle Android specific file formats, such as the APEX file format. III. C HALLENGES Android applications are primarily developed in Java or Kotlin and compiled into Dalvik Executable (DEX) bytecode—a CPU architecture-independent format used by the Android Runtime (ART). In addition to DEX code, many apps include native C/C++ libraries that must be compiled for the target architecture (typically ARM). Most Android devices today use ARM-based processors, making native components incompatible with x86/x86 64-based emulators commonly used in previous research [22], [23], [24]. To address this, we developed our approach specifically for ARMv8a and use an ARM-compatible emulator to ensure compatibility with native code. Dynamic analysis of PIAs is constrained by Android’s security architecture, which enforces system integrity and app isolation across multiple layers: • SELinux Policies: Mandatory access control (MAC) rules restrict process privileges. Customizations by the Original Equipment Manufacturers (OEMs) often diverge from
Hardware Bootloader: - Init RAM - Set HW to initial state - Verify Kernel integrity - Load Kernel and RAM disk - Start Kernel Loads
HAL
Kernel Space Kernel: - Init environment - Init kernel subsystems - Init Drivers - Mount root partitions - Start "init" process
Binder calls
User Space Native Deamons - servicemanager - netd - apexd - app_process64 ...
Application Layer Framework Core Starts
Framework Services - System Server - Media Server - Package Manager ...
main()
Starts
Starts
Pre-Installed Apps
Android Runtime - Starts Dalvik VM - JIT Compilation
Init - Setup global env variables - Parsing Config Files - Start native deamons - Monitors Service Lifecycles - Setting up Security Contexts
Zygote64: - Register Sockets - Preloading Ressources - Preloading Java Code - Start System Server - Start Media
k() for
fork()
Binder calls
Manufacturer Apps - Google Home - Google Playstore - Google Play Protect ...
Framework Apps - Settings - PermissionController - PackageInstaller ...
Third-Party Apps - Social Media - Weather - News ...
Vendor Apps - Browser - Debug Info - Camera ...
Fig. 1. Android architecture with logical layers.
AOSP defaults, causing vendor apps to fail under stricter policies. • Read-Only Partitions: Privileged apps must reside on partitions such as /system or /product, which are protected by Android verified boot (AVB) and cannot be modified without breaking the verified boot chain. • App Signing: System apps require valid platform or media certificates; signature mismatches lead to installation rejection or secure-boot failures. • Permission Whitelisting: Privileged permissions are statically defined in XML configuration files on read-only partitions, preventing dynamic modification at runtime. Beyond these protections, several technical challenges further complicate re-hosting of application layer components: • Singleton Apps: Certain core services (e.g., the permission controller) exist only once in the system; duplicates cause conflicts or boot failures. • Inter-App Dependencies (Collusion): Many PIAs rely on shared system services or Binder IPC; missing dependencies lead to crashes. • File and Library Dependencies: Vendor apps depend on firmware-specific native libraries and configuration files that must be correctly restored. • APEX Dual Signing: APEX modules encapsulate signed mini-filesystems verified with both vendor and platform keys. Re-hosting requires extracting, validating, and resigning both layers to maintain integrity. Taken together, these challenges demonstrate that simply transferring a core binary, or PIAs to a generic emulator is insufficient for meaningful re-hosting. A careful reconstruction of its runtime context—including security policy alignment, filesystem layout, and dependency resolution—is essential. IV. A PPROACH Our goal is to re-host Android’s framework to enable the dynamic analysis of core services and PIAs created by Android device vendors (e.g., Google, Xiaomi, etc.). Figure 2 illustrates the core idea of our re-hosting approach. Leveraging Android’s build process, we create an emulator image that includes key components of the vendor firmware—framework files, native libraries, services, and PIAs—while preserving system
integrity and compatibility with the Android emulator. To achieve this, we propose a multi-stage process comprising six steps. Step 1: Firmware Extraction: In this step, the Firmware Extractor unpacks vendor-provided Android firmware images and systematically identifies all components belonging to the application-layer, including framework files, native libraries, binaries, static assets, and PIAs. Step 2: AOSP Module Generation: The AOSP Module Generator takes the extracted files as input and creates AOSPcompatible build descriptors. Android supports two formats for build module definitions: ”Android.mk” and ”Android.bp”. The generator dynamically creates these files using metadata extracted from the firmware (e.g., file location, signing key, permissions). Listing 1 shows an example of an ”Android.mk” file that integrates a prebuilt APK. Key build variables such as LOCAL_MODULE_PATH, LOCAL_CERTIFICATE, and LOCAL_PRIVILEGED_MODULE must be set correctly to ensure proper signing, placement, and privilege assignment. Otherwise, integrity checks would stop the boot process of the device. Step 3: Pre-Build Injection: The generated modules are placed into the AOSP source tree without disrupting the build process. This involves placing the modules in the appropriate directories, updating build configuration files to include the new modules, and ensuring that no build rule conflicts with existing emulator targets. Step 4: AOSP Build Process Wrapper: Invoking the AOSP build system produces a system image that includes the extracted vendor packages, ensuring that all extracted components are correctly signed (e.g., platform, network stack, media keys), prebuilt components are preserved without unnecessary recompilation, files are mounted in the expected filesystem paths (e.g., /system/priv-app/), and dependencies to native libraries are correctly resolved. Step 5: Post-Build Injection: Not all components can be injected via the standard build system. For instance, precompiled ‘.jar‘ or binary ‘.elf‘ to replace core components are not supported by the build system. Thus, such files are injected after the base AOSP build into the file system. The post-processing step adds or replaces existing files within the
2
... .SO
3
AOSP Module Generator
.APK
Select Extract
Generate
AOSP Makefiles
1
.BP
... .JAR .SO
Select
3
Emulator Firmware
AOSP Build Process
Inject
Post-Build Injector
4 5 6 7
Converts
6
.SO
Extract
5
2
Output
AOSP Blueprints
Firmware Extractor
Android Firmware
1
Inject
4
.MK .APK
Pre-Build Injector
8 9
AOSP Emulator Packer
Build Artefacts
10 11 12 13 14 15
V. I MPLEMENTATION In this section, we describe how we realize our Android rehosting approach within a research prototype for the sake of experimentation. In Section V-A, we detail the extraction and integration of vendor-specific components into the AOSP build system to produce functional emulator images. Our implementation prioritizes automation, reproducibility, and minimal AOSP modifications, while using flexible injection strategies to handle diverse vendor firmware. In Section V-B, we address cross-cutting key considerations such as signing, dependency resolution, and build stability to ensure correct execution of re-hosted components. A. Implementation of the Major Steps Step 1: Firmware Extraction: Our system supports the extraction of application-layer files from key partitions found in vendor firmware images: super, system, system_ext, vendor, and product. For this task, we leverage FirmwareDroid [13], a firmware analysis framework that supports unpacking major Android versions across a wide range of vendors and extend its extraction capabilities for our purposes. We extract all relevant files and retrieve static metadata including signing certificates, file paths, permissions, and user/group identifiers. This metadata is essential for the accurate generation of AOSP-compatible build modules. Step 2: AOSP Module Generator: Since the emulator’s filesystem layout does not always align with that of the target firmware, we map vendor file paths to the closest semantically equivalent location in the emulator image (e.g.,
include $(BUILD_PREBUILT)
Listing 1. Android make file example.
Fig. 2. Overview of the re-hosting workflow, leveraging the AOSP build process and vendor firmware to create a vendor-flavoured emulator image.
image, ensures that AVB integrity is preserved, and updates file permissions and ownerships to match runtime expectations. Step 6: AOSP Emulator Packer: Finally, we produce a vendor-flavoured emulator image, manually configuring the build to disable unnecessary emulator-specific features (e.g., telephony mocks or stub modules), ensure a minimal bootable system with the required runtime services, and validate that re-hosted applications and system services function correctly at runtime.
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE_TAGS := optional LOCAL_MODULE := Example LOCAL_MODULE_PATH := $(TARGET_OUT)/system/app/ LOCAL_CERTIFICATE := platform LOCAL_SRC_FILES := Example.apk LOCAL_MODULE_CLASS := APPS LOCAL_MODULE_SUFFIX := $(COMMON_ANDROID_PACKAGE_SUFFIX) LOCAL_OPTIONAL_USES_LIBRARIES := LOCAL_ENFORCE_USES_LIBRARIES := false LOCAL_DEX_PREOPT := false LOCAL_PRIVILEGED_MODULE := false
/system/system/app to /system/app). This ensures structural compatibility and preserves logical organization. Additionally, based on the android:sharedUserId value declared in each app’s AndroidManifest.xml, we select and reference the appropriate AOSP signing key (e.g., platform, media) in the generated module configuration. The output of the build module generator is a collection of prebuilt AOSP modules either Makefiles (.mk) or Blueprint files (.bp)—one for each app or native library. All remaining file types (e.g., binaries, static assets, or firmware blobs) are handled during the post-build injection phase. Step 3: Pre-Build Injection: The Pre-Build Injector is responsible for integrating the generated build modules into the AOSP source tree. It places modules into the appropriate partition source directory and links them into the build dynamically by adjusting core build files (e.g., base system.mk). Each module is assigned to a target partition (e.g., system, vendor) based on its original location in the vendor firmware. A key limitation of this approach lies in the inability to overwrite certain core AOSP components with pre-built modules. For instance, attempting to inject a prebuilt framework-res.apk will typically result in a duplicate module conflict and trigger build errors. Patching the AOSP source code to resolve such conflicts is technically possible, but would compromise the portability and generality of our method. To handle such cases without modifying AOSP source files, we implement a set of fallback strategies: Overwrite Directive: Use the AOSP LOCAL_OVERRIDE_BUILT_MODULES directive to prioritize our prebuilt version. • Post-Build Injection: Defer integration to the post-build injection phase, bypassing the AOSP build system entirely. • Module Removal or Patching: Remove the conflicting AOSP module or patch its definition to avoid duplication only in cases where the module is not system relevant. •
Step 4: AOSP Build Process Wrapper: To support our method, certain modifications to the AOSP source code are necessary. Overall, the total amount of AOSP code changes required is less than 300 lines. These modifications primarily
disable specific AOSP features or adjust build configurations to make the build process more stable and efficient. Re-hosting framework binaries, such as Zygote’s app_process64, presents significant challenges due to their direct dependencies on numerous native libraries and the enforcement of security checks, as discussed in Section II. Native libraries often have transitive dependencies on other libraries, which further complicates integration. Consequently, when re-hosting a core binary, it is essential to include both its direct and indirect dependencies to ensure all necessary symbols are available for correct execution. To address this, we implement configurable injection strategies that allow for custom rules tailored to different binaries and firmware. Step 5: Post-Build Injection: After the AOSP build completes, each partition (e.g., system, vendor) is represented by a dedicated directory containing its corresponding output artifacts. This structure allows us to inspect, modify, and extend the build output before the image-packing phase. In this stage, we selectively add pre-compiled .jar or native .so files extracted from the vendor firmware, or replace existing ones where appropriate. To determine which artifacts should be injected or overwritten, we iterate through all files extracted from the vendor firmware and apply the matching Algorithm 1. The algorithm compares each vendor file against intermediate AOSP build artifacts using attributes such as Application Binary Interface (ABI), file type, source and target location, file extension, module name, and privilege level. This matching process is essential, as many intermediate build files have generic names (e.g., package.apk, javalib.jar) and are dispersed across multiple directories in the AOSP build tree. By identifying the correct intermediate targets, we ensure that vendor components are accurately integrated into the final emulator image without disrupting the build process. Algorithm 1 Matching vendor firmware files to AOSP intermediate files Require: List of vendor files V , List of AOSP intermediate files A 1: Initialize empty list of matches M 2: for each v ∈ V do 3: Initialize best match to None, best match abest ← None 4: for each a ∈ A do 5: Compute match based on ABI, file type, path similarity, module name, privileges, file name, module type, keywords 6: if match then 7: Update match abest ← a 8: end if 9: end for 10: if abest ̸= None then 11: Add (v, abest ) to match list M 12: end if 13: end for 14: return M
The result of Algorithm 1 is a list with files in the vendor firmware image that have a counterpart in the AOSP intermediate files. With this information, we can then decide on the injection strategy for each file in the vendor firmware image.
Injection Strategies: We define four types of injection strategies depending on the characteristics and compatibility of the vendor file: • Indirect Injection: If a corresponding file already exists in the build output (e.g., an APEX or JAR file), we apply a matching algorithm to locate its intermediate source and overwrite it with the vendor version. • Direct Injection: If no equivalent file exists in the output directories, we copy the vendor file into the corresponding partition directory. We replicate the original path from the vendor firmware to preserve directory structure and compatibility. • Isolated Namespace Injection: Binaries that must run in an isolated namespace are encapsulated within an APEX containing all necessary dependencies. The binary is replaced with a symbolic link pointing to the APEX version, ensuring that the dynamic linker resolves dependencies only from the packaged libraries. Inclusion of binaries is performed manually by the user via an explicit list. • No Injection: Files that cannot be injected safely (e.g., incompatible kernel modules) are skipped and logged. These are typically files that conflict with the base kernel or violate signing constraints. All injection strategies are configurable and customizable to support a wide variety of vendors and devices. However, depending on the file to inject dependency and security constraints have to be considered. Step 6: AOSP Emulator Packer: The final build step in AOSP is the image-packing process. During this stage, intermediate files are copied into the partition directories and overwritten by any differing output artifact. By modifying intermediate files and placing additional files using our injection routines, we ensure that the resulting emulator image includes all vendor-specific components required for testing. Our modifications to AOSP are minimal (less than 300 lines of code) and do not break the integrity of the AOSP source, making the method portable across different Android versions. B. Cross-Cutting Considerations Pipeline Reproducibility and Automation: For the emulator images, we used the sdk_phone64_arm64-userdebug AOSP build target. This configuration produces a minimal ARM64-based image that includes the Android SDK, a design choice aimed at maximizing compatibility across a wide range of Android smartphone samples. Supporting other device classes (e.g., Android Automotive) would require selecting an appropriate build target for the respective platform. Android Integrity and Signature Mechanisms: APK files are signed using the certificates defined in the AOSP build configuration. APEX containers require dual (or, in some cases, trial) signing: one signature for the internal payload file system and another for the APEX container itself. Additionally, if the APEX package includes an embedded APK, that APK must also be individually signed [25]. If any of these signatures are invalid or missing, the Android system will
either reject the module or fail to boot entirely. Thus, correct signing is essential for multiple steps of the pipeline. Our signing routines automate this multi-layered signing process by leveraging AOSP’s existing key infrastructure. In particular, these routines allow us to overwrite the contents of APEX files without breaking their integrity. This is essential as APEX packages often contain core system components required for the OS to start, such as the Android Runtime. This design allows for any modifications that do not violate Android’s integrity mechanisms (e.g., signature mismatches, critical path conflicts). VI. E VALUATION S ETUP This section describes the setup used to evaluate the feasibility and effectiveness of our re-hosting approach for Android firmware. We focus on systematically assessing how well application-layer components can be re-hosted and executed in the emulator. Our evaluation is guided by the following research questions: RQ1 To what extent can application-layer components — including framework files, native libraries, and pre-installed apps — be automatically re-hosted? RQ2 Can Android’s vendor-specific application-layer components be successfully re-hosted and executed within an emulator environment? RQ3 What is the computational and build-time overhead introduced by the re-hosting process compared to a baseline AOSP build? RQ4 Under what conditions does the proposed re-hosting approach fail, and what are the root causes of these failures? Overall, RQ1 assesses how much of the Android application layer can be re-hosted automatically, indicating the achievable analysis coverage and scalability to large firmware sets. RQ2 evaluates whether vendor-specific components execute correctly in an emulator, which is essential for reliable dynamic analysis without physical devices. RQ3 measures the computational and build-time overhead of re-hosting, informing its practicality for large-scale and continuous analysis pipelines. Finally, RQ4 analyses failure modes and their root causes, clarifying the limitations of the approach and guiding future improvements. To address these questions, we assess (i) the compatibility of the method across diverse firmware images, (ii) the coverage of application-layer components that can be successfully injected and executed, and (iii) the runtime behaviour of re-hosted applications in the emulator environment. A. Experimental Subjects We apply our prototype to a dataset of real-world firmware images from multiple vendors (e.g., Google, Xiaomi, etc.), collected from websites that freely provide official firmware downloads; the complete dataset is included in our replication package. In sum, we extract application-layer files from 184 samples, which serve as the basis for our evaluation. All samples in our dataset are based on the SDK versions 31 to 33.
The tests were conducted using the official Android emulator for ARM64 (v33.1.24.0). Runtime experiments were performed on an ARM-based host system, while firmware builds were executed on Intel x86 64 based machines equipped with 64 GB of RAM and 64 vCPU cores. Formally, we denote the dataset by D = {x1 , x2 , . . . , xn }, where n is the total number of samples. The dataset is partitioned into three disjoint subsets according to the SDK version: D31 = {x ∈ D | SDK(x) = 31},
E31 = android-12.0.0 r34,
D32 = {x ∈ D | SDK(x) = 32},
E32 = android-12.1.0 r11,
D33 = {x ∈ D | SDK(x) = 33},
E33 = android-13.0.0 r16.
Here, each subset Di corresponds to samples built from the Android build target Ei . The build targets were selected by Android SDK version. The build target defines the exact AOSP source version used to construct the system image for the corresponding API level. To demonstrate the capabilities of our approach, we re-host the Zygote process and core framework components (i.e., /system/framework, /vendor/ framework, /product/framework, and /system_ ext/framework). We define the set of binaries to be rehosted as B = {b1 , b2 , . . . , bk }, where each bi represents a re-hosted binary component of the system. We denote the set of partitions containing framework components by P = {/system, /vendor, /product, /system ext}. The set of framework components can then be defined as F = {F | F is a framework directory in some partition P ∈ P}. In addition to the framework, our approach re-hosts a selection of native libraries and pre-installed Android applications. We denote these sets by L = {ℓ1 , ℓ2 , . . . , ℓm },
A = {a1 , a2 , . . . , an },
where ℓi represents a native library and aj a pre-installed application. The complete set of re-hosted components is therefore C = B ∪ F ∪ L ∪ A. B. Injection Strategy All the conducted experiments use a single, well-defined baseline injection strategy applied to each sample x ∈ D. Injection is performed according to these rules: (i) B (binaries/APEX) are injected via the post build injector; APEX files are either directly injected as vendor APEXes or merged with emulator APEX files and for every image we inject the Android Runtime and SDK-Extension APEX files; (ii) F (framework) components overwrite existing emulator components. A (Android applications) are injected directly only if they do not already exist on the target partition, otherwise
SDK Version
they are applied indirectly (i.e., via build-time integration or overlay); (iii) L native libraries are injected only if absent on the target system. We deliberately restricted our evaluation to this single strategy in order to establish a reproducible, automationfriendly baseline for re-hosting. Exploring alternative injection heuristics with the goal of maximizing per-sample success and coverage rates is beyond the scope of this work. Nevertheless, the strategy can be adapted on a per-device basis where necessary to support a wider range of vendor firmwares, and we view the systematic exploration of such optimizations as promising future work.
Similarly, for a subset of samples Di ⊆ D, the average coverage ratio is 1 X R(Di ) = R(x). |Di | x∈Di
To evaluate the success of executing re-hosted components within an emulator environment (RQ2), we define a set of tasks to be executed. The first task is to generate an AOSP compatible firmware that can be built in AOSP and loaded by the emulator. The second task measures whether the system successfully boots the OS. We define a successful boot as moment when the Android Debug Bridge (adb) is started and available. The third task assesses whether the re-hosted framework core services initialize correctly without crashing. In particular, if Zygote and the Android Runtime start correctly without fatal crashes. For the fourth tasks, we define success in case the user-interface is shown via a launcher app and usable in the emulator. Let the set of tasks to evaluate the re-hosted system be build success, boot success, T = . init core services, init launcher app For each sample x ∈ D, we define a success function ( 1, if task t ∈ T succeeds on sample x, s(x, t) = 0, otherwise.
SDK 32 SDK 31 0.1
0.2 0.3 0.4 Coverage Ratio
0.5
Fig. 3. Application-Layer Coverage Ratios
C. Evaluation Metrics Our evaluation metrics for assessing the re-hosting capabilities in our experiments are inspired by related work on firmware re-hosting (see Section IX), adapted to our context of the Android application layer. For RQ1, we measure, for each sample x ∈ D, the coverage of application-layer components that are successfully re-hosted. Let Cx ⊆ C denote the subset of components from C that are successfully re-hosted on sample x. Further, let Ix ⊆ C denote the set of all components from the same sample that could in principle be injected. Note that the number of files that could be injected depends on how many files were successfully extracted from a sample. The per-sample coverage ratio is then defined as |Cx | . R(x) = |Ix |
SDK 33
as
The overall success rate of a sample can then be expressed P s(x, t) S(x) = t∈T . |T |
Similarly, the average success rate across a subset of samples Di ⊆ D is 1 X S(Di ) = S(x). |Di | x∈Di
Finally, for RQ3, we compare the running times in our build pipeline to unmodified baseline AOSP builds, and resort to a qualitative failure analysis for RQ4. VII. E XPERIMENTAL R ESULTS This section presents the empirical evaluation of our rehosting approach using the firmware dataset introduced in Section VI. The goal is to assess its feasibility, correctness, and efficiency across different SDK versions and vendors. We report results along four dimensions corresponding to our research questions: coverage of application-layer components successfully integrated into the emulator, correctness and runtime behaviour of re-hosted services and pre-installed apps, computational overhead introduced by the injection process, and root causes of remaining failures. A. RQ1: Coverage of Application-Layer Files Using the baseline injection strategy, our experiments achieved an average coverage, R(Di ), of 31% for D31 (sample size 73), 19% for D32 (sample size 25), and 42% for D33 (sample size 86). Figure 3 shows the distribution of applicationlayer coverage across all samples. As shown, the baseline injection strategy attains the highest coverage for SDK 33, while the lowest coverage was achieved for SDK-32. The observed variation in coverage is influenced by differences in vendor modifications, framework complexity, and the presence of device-specific dependencies across SDK versions. SDK 33 shows higher coverage, likely due to more consistent file structures and fewer missing dependencies in the analysed samples. Conversely, SDK 31 presents less heterogeneous layouts, which challenge the baseline strategy. These findings highlight the trade-off between a general, reproducible injection approach and the potential benefits of device-specific tuning.
#Sample
Build
Boot
Core
Launch
Avg. S(Di )
D33
86
1.0
1.0
0.41
0.41
0.70
D32
25
1.0
1.0
0.68
0.68
0.80
D31
73
0.9
0.9
0.18
0.18
0.54
Overall
184
0.97
0.97
0.35
0.35
0.68
RQ1: The average coverage across SDK versions ranges from 19% to 42%, with the highest value observed for SDK 33. B. RQ2: Correctness of Re-hosting We measure the ability of the re-hosting system to perform the set of evaluation tasks T on the dataset D. The re-hosting of the components C is applied individually to each subset D31 , D32 , and D33 . The results for the average success rate are shown in Table I. Using our re-hosting approach, we successfully re-hosted core components across multiple devices and vendors. The consistently high build and boot success rates under the baseline strategy demonstrate that our combination of pre- and post-build injection is robust and preserves the integrity of the AOSP build system. For example, despite challenges such as complex signing requirements and singleton app constraints described in Section III, our method consistently maintained system integrity across all tested SDK versions. These results show that the challenges discussed in Section III can be effectively addressed by our approach. We observed that the launcher task generally followed similar success trends as the core service initialization. Notably, while the launcher application typically started, it did not always function as expected. In some cases, the user interface exhibited transient flickering, likely caused by repeated failures of other services that disrupted execution. These observations suggest that, although the underlying system services and the launcher were successfully initialized, subtle timing or rendering inconsistencies within the emulator environment can affect launcher stability, revealing opportunities for refinement in post-build injection and runtime configuration. RQ2: Our results demonstrate that vendor-specific components can be reliably re-hosted in an ARM emulator, achieving correct core initialization for 35% of the samples and an average success rate of 68%.
RQ3: The pre- and post-injection stages add less than three minutes of overhead, confirming that injection performance costs are negligible for large-scale use.
SDK33 SDK Version
Task Success Subset
across all samples. A default AOSP build without modifications takes approximately 60 minutes for SDK 33, 75 minutes for SDK 32, and 90 minutes for SDK 31 to complete on our test systems. As expected, build times increase when additional AOSP modules are injected. On average, one build with vendor modules injected requires only slightly more time than the baseline. The module pre-injection phase completes in less than three minutes and newer SDK versions have generally faster build times. Furthermore, Figure 5 shows that the post-injection step accounts for only a small fraction of the total build time, as Algorithm 1 operates with linear time complexity. Overall, the injection process introduces only minimal computational overhead, completing on average in under three minutes.
SDK32
SDK31 65
70
75
80 85 Minutes
90
95
100
105
Fig. 4. AOSP Build Times with Injected Modules
SDK33 SDK Version
TABLE I C ORRECTNESS OF RE - HOSTING : TASK SUCCESS WITHIN THE EMULATOR .
SDK32
SDK31 0.00
0.02 0.04 Fraction of Build Time
0.06
Fig. 5. Post Injector Build Times in Fraction of the Build Time
C. RQ3: Performance Overhead
D. RQ4: Failure Analysis
We measure the time required for the injection steps in our build pipeline and compare it against a baseline AOSP build for each API version without any modifications. Figure 4 illustrates the distribution of build times for each SDK version
Our approach achieved consistently high build and boot success rates across all SDK subsets (see Table I). Nonetheless, a number of failures persisted, primarily during core-service initialization. To better understand these residual issues, we
TABLE II S UMMARY OF PLATFORM , APP, AND SECURITY CAPABILITIES AND LIMITATIONS . ✓= FULL SUPPORT, (✓) = PARTIAL SUPPORT, ✗ = NO SUPPORT. Platform Capabilities / Limitations
Security Capabilities / Limitations
Singleton App Support ✓ System File Installation ✓ Core Framework Re-hosting ✓ File & Native-Library Support (✓) Daemon Re-hosting (✓)
Supports one active app instance. Verified Boot (AVB) ✓ Correct installation into system paths (e.g., /priv-app). Read-Only File Systems ✓ Full re-hosting of Java framework components. App Integrity Protection ✓ Selective re-hosting of system files and native libraries. APEX Integrity Protection ✓ Partial re-hosting of essential native daemons. Permission Whitelisting (✓) Device Root Access ✓ Kernel Module Support ✗ Kernel modules are not re-hosted. Hardware Emulation (✓) Default emulator hardware device emulation. SELinux Enforcement (✓) Device Attestation ✗ App-Level Capabilities / Limitations Inter-App Dependence ✓ App File & Library Support (✓)
Supports colluding or dependent apps. Selective re-hosting of app files and libraries.
External Service Dependence ✗ Anti-Analysis Mitigation ✗
No support for external API dependencies. Does not prevent app anti-analysis or env-checks.
conducted a root-cause analysis and summarised the results in Table II. The analysis revealed that failures mainly stem from (i) limitations of the baseline injection strategy, (ii) missing or unresolved native dependencies, (iii) integrity verification errors triggered by device-protection mechanisms, and (iv) limited emulator support for ARM 32-bit routines or peripherals (e.g., key-master interface). The first three categories represent engineering limitations that can be mitigated by refining the injection and signing procedures or by improving dependency resolution, whereas the fourth reflects an inherent constraint of the emulator platform rather than a deficiency of our approach. Consequently, the observed failures delineate practical—rather than conceptual—boundaries of re-hosting, underscoring the robustness and generality of the proposed method. RQ4: Re-hosting failures primarily occur during core service initialization due to missing symbols, integrity checks, or limited emulator support. VIII. D ISCUSSION In this section, we summarize the key observations from our evaluation wrt. to our primary evaluation goal of demonstrating the general feasibility of our approach (Section VIII-A), before we discuss the major threats to validity of our experimental results (Section VIII-B). A. Feasibility of the Approach Relocation and emulation: Pre- and post-injection steps around our AOSP build process wrapper represent a crucial and configurable aspect of our re-hosting method. The generic baseline injection strategy chosen for the experiments was deliberately conservative to ensure reproducibility. Despite this, a significant portion of key components is re-hosted, and device-specific tuning could further increase coverage ratios and thus execution success rates within the emulator. Core framework services and pre-installed apps successfully boot and initialize, demonstrating that vendor binaries and framework files can be re-hosted while preserving system integrity, and thus vendor-specific Android application-layer
Passes all AVB security checks. Maintains read-only partitions at runtime. All apps signed with correct platform keys. APEX files signed and verified. Re-hosts permissions and logs violations. Full root and unrestricted kernel control. Only permissive mode supported. Attestation fails (due to permissive SELinux).
components can be dynamically executed in an emulator. This unlocks the potential for vendor-flavoured emulators, empowering scalable and reproducible dynamic analysis, which is currently not possible within the Android ecosystem. Failures arise from unresolved native dependencies, integrity verification errors, or emulator constraints (e.g., missing peripherals), representing mainly practical, not conceptual, limits. Performance overhead: For the conducted experiments, pre- and post-build injection completes in under three minutes, and full vendor-flavoured builds average between 60 to 95 minutes. Compared to baseline AOSP builds without any modifications, this represents a moderate overhead of around 5% on average, without observing any significant outliers. While both performance optimization and systematic performance benchmarking are out of the scope this paper, our performance measurements further demonstrate the applicability of our approach in practice. Maintainability and portability: Our method is designed to be largely generic and not tightly coupled to any specific vendor firmware layout. By relying on the standard AOSP build system and focusing solely on application-layer components, we maintain broad compatibility and portability across different devices and SDK versions. Our research prototype shows that our approach may be implemented with minimal modifications to the AOSP source. Nonetheless, adjustments to injection strategies may be required to support newer Android versions. Findings: Our results show that vendor-specific Android application-layer components can be re-hosted and dynamically executed in an emulator. Across 184 firmware images from multiple vendors and SDK versions, we achieve high build and boot success rates and demonstrate correct initialization of core framework services under a single, reproducible baseline strategy. These findings establish emulator-based rehosting as a practical and scalable foundation for dynamic analysis, while also revealing dependency resolution and integrity checks as the primary remaining challenges.
B. Threats to Validity We discuss threats to validity following standard guidelines [26], distinguishing between internal, construct, external, and conclusion validity. a) Internal Validity: Our evaluation uses a single, uniform baseline injection strategy to ensure reproducibility. While this limits confounding factors, it may reduce success and coverage rates, as device-specific tuning could resolve additional dependencies or configuration issues. Residual failures during core service initialization may also stem from extraction or signing artefacts. Furthermore, emulator-based execution cannot fully capture hardware-dependent behaviour (e.g., sensors, peripherals, or ARM 32-bit components), which may affect runtime correctness. b) Construct Validity: We measure re-hosting success using build and boot success, initialization of core services and the launcher, and coverage ratios of re-hosted application-layer components. These metrics provide a practical approximation of functional correctness but do not guarantee full behavioural equivalence to physical devices, for example with respect to timing or subtle service interactions. c) External Validity: Our dataset comprises 184 firmware images from SDK versions 31–33 and may not represent all Android devices, vendors, or OS versions. Nevertheless, it includes multiple major vendors and recent Android releases, capturing realistic variation in vendor-specific framework and application-layer modifications. d) Conclusion Validity: All samples are evaluated using a consistent experimental setup, reducing random effects and selective bias. Although absolute success rates depend on the conservative baseline strategy and emulator limitations, the observed trends across vendors and SDK versions consistently support our conclusions on feasibility, scalability, and reproducibility. IX. R ELATED W ORK Research on firmware analysis and system emulation has produced many frameworks for reverse engineering, vulnerability discovery, and behavioural analysis. Our work intersects with but differs from prior approaches in firmware rehosting [18], [19], [27], [28]. Our approach addresses a unique problem space: the re-hosting of vendor-modified Android application frameworks within the AOSP build system to generate emulator-compatible images. This design enables reproducible and scalable dynamic analysis of frameworklevel behaviour without relying on physical devices, manual hardware modelling, or peripheral pass-through. Several works address automated re-hosting of Linux-based firmware to facilitate dynamic analysis. Firmadyne [18] pioneered large-scale emulation of embedded Linux firmware, focusing primarily on network appliances such as routers and cameras. It leverages QEMU for full-system emulation and automates filesystem extraction, but does not support Androidspecific frameworks or services. FirmAE [19] extends this concept for large-scale IoT firmware emulation, improving automation and scalability. FirmDiff [27] focuses on refining
Linux kernel configurations to improve compatibility during firmware re-hosting, reducing emulation failures due to module layout mismatches. The work of Wright et al. [29] surveys the broader challenges in firmware re-hosting, highlighting hardware modelling, dependency resolution, and scalability as recurring obstacles. Pandawan [17] proposes a benchmarking methodology to quantify progress in Linux-based firmware rehosting, introducing the Firmware Initialization Completion Detection (FICD) metric. Pretender [30] automates re-hosting by dynamically inferring hardware interfaces and adapting the emulation environment accordingly. SURGEON [28] advances re-hosting by introducing a binary-rewriting approach to rehost functional components from one firmware image into another. These efforts significantly advance the state of firmware re-hosting but largely target general-purpose embedded Linux environments. Android frameworks introduce additional challenges, such as service initialization ordering, binder IPC dependencies, and AOSP build integration, which are not addressed by these systems. Binary analysis frameworks like Angr [31] provide deep static and dynamic program analysis at the application or binary level, while HALucinator [21] facilitates selective rehosting of system components by modelling HAL code; however, neither approach targets the integration of vendor-specific Android frameworks nor compatibility with the AOSP build system, which is the primary focus of our work. Table III summarises the comparison of our re-hosting approach with the most closely related firmware re-hosting systems, including Pandawan [17], Firmadyne [18], FirmAE [19], and HALucinator [21]. Unlike Firmadyne, FirmAE, and HALucinator, our approach does not require hardware modelling, which improves scalability and simplifies automation. Vendor-specific support is provided, similar to HALucinator, enabling evaluation across multiple device manufacturers. Our evaluation focuses on success per component or task, which provides a quantitative measure of functionality, while HALucinator focuses on coverage, i.e., how much of the system is represented. Finally, although full system re-hosting is supported by most existing approaches, our work emphasizes selective component re-hosting, particularly the framework and application-layer components, to facilitate modular analysis and testing of this components. X. C ONCLUSION We presented a systematic approach for re-hosting Android system components and applications in an emulator, maintaining compatibility across core services, framework binaries, and pre-installed apps while preserving device integrity. Our evaluation demonstrates that critical services and vendorspecific binaries can be executed successfully, resulting in a fully operational emulator that mirrors the behaviour of original hardware and supports scalable dynamic analysis. Overall, our re-hosting strategy provides a reproducible and extensible framework for exploring Android system internals, performing security analyses, and investigating vendor-specific modifications in a controlled emulator environment. While
TABLE III C OMPARISON OF FIRMWARE RE - HOSTING APPROACHES . Feature / Metric Target OS / Platform Focus Vendor-specific support Hardware Modelling Required Scalability / Automation Full System Re-Hosting
Pandawan Linux IoT No No High Yes
Firmadyne Linux IoT No Yes High Yes
this work establishes the foundations for dynamic execution of vendor components, future work will focus on adapting specific dynamic analysis workflows—such as automated UI interaction, runtime monitoring of framework and pre-installed app behaviour, and system call or network tracing. These targeted analyses will enable reproducible end-to-end studies of vendor-specific services and pre-installed apps in a controlled and scalable setting. In addition, future work will focus on extending compatibility across diverse vendor images, integrating advanced injection strategies, and further improving correctness and performance fidelity. In summary, our results show that emulator-based re-hosting enables reliable testing of pre-installed apps, evaluation of vendor frameworks, and large-scale dynamic analysis, while laying the foundation for broader coverage, enhanced compatibility, and automated evaluation of Android firmware. A PPENDIX A: DATA AVAILABILITY Artefacts available: • https://sites.google.com/view/relocate-and-emulate ACKNOWLEDGEMENTS This work was supported in part by armasuisse Science and Technology. R EFERENCES [1] B. Lee, L. Lu, T. Wang, T. Kim, and W. Lee, “From zygote to morula: Fortifying weakened aslr on android,” in Proceedings of the 2014 IEEE Symposium on Security and Privacy. San Jose, California, USA: IEEE, 2014, pp. 424–439, presented at IEEE S&P 2014. [Online]. Available: https://ieeexplore.ieee.org/document/6853550 [2] E. Wen, J. Shen, and B. Wuensche, “Keep me updated: An empirical study of proprietary vendor blobs in android firmware,” in Proceedings of the 2024 IEEE 30th International Conference on Parallel and Distributed Systems (ICPADS). Singapore: IEEE, 2024, pp. 116–125, accepted for publication; presented at ICPADS 2024. [Online]. Available: https://www.computer.org/csdl/proceedings-article/ icpads/2024/159600a116/22f0yTuP4Fq [3] J. A. P. Gamba, “Do androids dream of electric sheep? on privacy in the android supply chain,” Ph.D. dissertation, Universidad Carlos III de Madrid (UC3M), Madrid, Spain, 2022, awarded the CNIL-INRIA Privacy Protection Award and the 2020 AEPD Emilio Aced Prize. [Online]. Available: https://e-archivo.uc3m.es/bitstream/handle/10016/ 35812/tesis gamba.pdf [4] L. Wei, Y. Liu, and S.-C. Cheung, “Taming android fragmentation: characterizing and detecting compatibility issues for android apps,” in Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering, ser. ASE ’16. New York, NY, USA: Association for Computing Machinery, 2016, p. 226–237. [Online]. Available: https://doi.org/10.1145/2970276.2970312
FirmAE Linux IoT No Yes High Yes
HALucinator Android HAL Yes Yes Medium No
Our Work Android Framework Yes No High No
[5] L. Wei, Y. Liu, S.-C. Cheung, H. Huang, X. Lu, and X. Liu, “Understanding and detecting fragmentation-induced compatibility issues for android apps,” IEEE Transactions on Software Engineering, vol. 46, no. 11, pp. 1176–1199, 2020. [6] L. Wu, M. Grace, Y. Zhou, C. Wu, and X. Jiang, “The impact of vendor customizations on android security,” in Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security, ser. CCS ’13. New York, NY, USA: Association for Computing Machinery, 2013, p. 623–634. [Online]. Available: https: //doi.org/10.1145/2508859.2516728 [7] C. Li, C. Xu, L. Wei, J. Wang, J. Ma, and J. Lu, “Elegant: Towards effective location of fragmentation-induced compatibility issues for android apps,” in Proceedings of the 2018 25th Asia-Pacific Software Engineering Conference (APSEC). Nara, Japan: IEEE, 2018, pp. 278–287, accepted for publication; presented at APSEC 2018. [Online]. Available: https://ieeexplore.ieee.org/document/8612116 [8] Y. Ji, M. Elsabagh, R. Johnson, and A. Stavrou, “Definit: An analysis of exposed android init routines,” in Proceedings of the 30th USENIX Security Symposium (USENIX Security ’21). Virtual: USENIX Association, 2021, pp. 3685–3702. [Online]. Available: https://www.usenix.org/conference/usenixsecurity21/presentation/ji [9] M. Elsabagh, R. Johnson, A. Stavrou, C. Zuo, Q. Zhao, and Z. Lin, “FIRMSCOPE: Automatic uncovering of privilegeescalation vulnerabilities in pre-installed apps in android firmware,” in Proceedings of the 29th USENIX Security Symposium (USENIX Security ’20). Boston, MA, USA: USENIX Association, Aug. 2020, pp. 2379–2396. [Online]. Available: https: //www.usenix.org/conference/usenixsecurity20/presentation/elsabagh [10] D. Wu, D. Gao, E. K. T. Cheng, Y. Cao, J. Jiang, and R. H. Deng, “Towards understanding android system vulnerabilities: Techniques and insights,” in Proceedings of the 2019 ACM Asia Conference on Computer and Communications Security, ser. Asia CCS ’19. New York, NY, USA: Association for Computing Machinery, 2019, p. 295–306. [Online]. Available: https://doi.org/10.1145/3321705.3329831 [11] T. Sutter, T. Kehrer, M. Rennhard, B. Tellenbach, and J. Klein, “Dynamic security analysis on android: A systematic literature review,” IEEE Access, vol. 12, pp. 57 261–57 287, 2024. [12] J. Gamba, M. Rashed, A. Razaghpanah, J. Tapiador, and N. VallinaRodriguez, “An analysis of pre-installed android software,” in Proceedings of the 2020 IEEE Symposium on Security and Privacy (SP). San Francisco, CA, USA: IEEE, 2020, pp. 1039–1055. [13] T. Sutter and B. Tellenbach, “Firmwaredroid: Towards automated static analysis of pre-installed android apps,” in Proceedings of the 2023 IEEE/ACM 10th International Conference on Mobile Software Engineering and Systems (MOBILESoft). Melbourne, Australia: IEEE/ACM, 2023, pp. 12–22. [14] G. Hernandez, D. J. Tian, A. S. Yadav, B. J. Williams, and K. R. Butler, “BigMAC: Fine-grained policy analysis of android firmware,” in Proceedings of the 29th USENIX Security Symposium (USENIX Security ’20). Boston, MA, USA: USENIX Association, Aug. 2020, pp. 271–287. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity20/presentation/hernandez [15] J. Gamba, M. Rashed, A. Razaghpanah, J. Tapiador, and N. VallinaRodriguez, “An analysis of pre-installed android software,” in 2020 IEEE symposium on security and privacy (SP). IEEE, 2020, pp. 1039–1055. [16] S.-T. Sun, A. Cuadros, and K. Beznosov, “Android rooting: Methods, detection, and evasion,” in Proceedings of the 5th Annual ACM CCS Workshop on Security and Privacy in Smartphones and Mobile Devices, ser. SPSM ’15. New York, NY, USA: Association for Computing Machinery, 2015, p. 3–14. [Online]. Available: https://doi.org/10.1145/2808117.2808126
[17] I. Angelakopoulos, G. Stringhini, and M. Egele, “Pandawan: Quantifying progress in linux-based firmware rehosting,” in 33rd USENIX Security Symposium (USENIX Security 24). Philadelphia, PA: USENIX Association, Aug. 2024, pp. 5859–5876. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity24/presentation/angelakopoulos [18] D. D. Chen, M. Woo, D. Brumley, and M. Egele, “Towards automated dynamic analysis for linux-based embedded firmware,” in Proceedings of the Network and Distributed System Security Symposium (NDSS). San Diego, CA, USA: Internet Society, Feb. 2016, pp. 1–10. [Online]. Available: https://www.ndss-symposium.org/wp-content/uploads/2017/09/ towards-automated-dynamic-analysis-linux-based-embedded-firmware. pdf [19] M. Kim, D. Kim, E. Kim, S. Kim, Y. Jang, and Y. Kim, “Firmae: Towards large-scale emulation of iot firmware for dynamic analysis,” in Proceedings of the 36th Annual Computer Security Applications Conference, ser. ACSAC ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 733–745. [Online]. Available: https://doi.org/10.1145/3427228.3427294 [20] M. Xin, H. Wen, L. Deng, H. Li, Q. Li, and L. Sun, “Firmporter: Porting rtoses at the binary level for firmware re-hosting,” in Information and Communications Security: 26th International Conference, ICICS 2024, Mytilene, Greece, August 26–28, 2024, Proceedings, Part II. Berlin, Heidelberg: Springer-Verlag, 2024, p. 310–331. [Online]. Available: https://doi.org/10.1007/978-981-97-8801-9 16 [21] A. A. Clements, E. Gustafson, T. Scharnowski, P. Grosen, D. Fritz, C. Kruegel, G. Vigna, S. Bagchi, and M. Payer, “HALucinator: Firmware re-hosting through abstraction layer emulation,” in Proceedings of the 29th USENIX Security Symposium (USENIX Security ’20). Boston, MA, USA: USENIX Association, Aug. 2020, pp. 1201–1218. [Online]. Available: https: //www.usenix.org/conference/usenixsecurity20/presentation/clements [22] A. Dawoud and S. Bugiel, “Bringing balance to the force: Dynamic analysis of the android application framework,” in Proceedings of the 28th USENIX Security Symposium (USENIX Security 19). Vancouver, BC, Canada: USENIX Association, Feb. 2021. [Online]. Available: https://www.ndss-symposium.org/ wp-content/uploads/ndss2021 2B-1 23106 paper.pdf [23] A. Sinha, F. Di Troia, P. Heller, and M. Stamp, “Emulation versus instrumentation for android malware detection,” in Digital Forensic Investigation of Internet of Things (IoT) Devices. Springer, 2020, pp. 1–20. [24] O. Zungur, A. Bianchi, G. Stringhini, and M. Egele, “Appjitsu: Investigating the resiliency of android applications,” in 2021 IEEE European Symposium on Security and Privacy (EuroS&P), 2021, pp. 457–471. [Online]. Available: https://seclab.bu.edu/papers/appjitsu-eurosp2021.pdf [25] Android Open Source Project, “Apex file format,” https://source. android.com/docs/core/ota/apex, 2023, accessed: 2025-09-17. [Online]. Available: https://source.android.com/docs/core/ota/apex [26] C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, A. Wesslén et al., Experimentation in software engineering. Springer, 2012, vol. 236. [27] I. Angelakopoulos, G. Stringhini, and M. Egele, “Firmdiff: Improving the configuration of linux kernels geared towards firmware rehosting,” in Proceedings of the Workshop on Binary Analysis Research (BAR’24), N. P. Committee, Ed. San Diego, CA, USA: Internet Society, Mar. 2024, pp. 1–10. [Online]. Available: https: //www.ndss-symposium.org/wp-content/uploads/bar2024-12-paper.pdf [28] F. Hofhammer, M. Busch, Q. Wang, M. Egele, and M. Payer, “Surgeon: Performant, flexible, and accurate re-hosting via transplantation,” in Proceedings of the Workshop on Binary Analysis Research (BAR’24). Reston, VA, USA: Internet Society, Mar. 2024, pp. 1–10. [Online]. Available: https://www.ndss-symposium.org/ndss-paper/auto-draft-430/ [29] C. Wright, W. A. Moeglein, S. Bagchi, M. Kulkarni, and A. A. Clements, “Challenges in firmware re-hosting, emulation, and analysis,” ACM Comput. Surv., vol. 54, no. 1, jan 2021. [Online]. Available: https://doi.org/10.1145/3423167 [30] E. Gustafson, M. Muench, C. Spensky, N. Redini, A. Machiry, Y. Fratantonio, D. Balzarotti, A. Francillon, Y. R. Choe, C. Kruegel, and G. Vigna, “Toward the analysis of embedded firmware through automated re-hosting,” in 22nd International Symposium on Research in Attacks, Intrusions and
Defenses (RAID 2019). Chaoyang District, Beijing: USENIX Association, Sep. 2019, pp. 135–150. [Online]. Available: https://www.usenix.org/conference/raid2019/presentation/gustafson [31] F. Wang and Y. Shoshitaishvili, “Angr: The next generation of binary analysis,” in Proceedings of the 2017 IEEE Cybersecurity Development Conference (SecDev). San Francisco, CA, USA: IEEE, 2017, pp. 8–9. [Online]. Available: https://doi.org/10.1109/SecDev.2017.14