You Shall not Repackage! Demystifying Anti-Repackaging on Android

Merlo, Alessio; Ruggia, Antonio; Sciolla, Luigi; Verderame, Luca

doi:10.1016/j.cose.2021.102181

Cited by 23 publications

(29 citation statements)

References 25 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The remaining 508 apps (i.e., 11.3%) were not tracked by HideDroid due to the failure of the repackaging phase. This is mainly related to the presence of antirepackaging protections [32], [33] that block HideDroid from injecting the network configuration and re-install the AUT. Furthermore, we also evaluated the compatibility of HideDroid for the leading analytics services during the experimental phase.…”

Section: Testing Hidedroid In the Wildmentioning

confidence: 99%

You can't always get what you want: towards user-controlled privacy on Android

Caputo,

Pagano,

Bottino

et al. 2021

Preprint

Self Cite

View full text Add to dashboard Cite

Mobile applications (hereafter, apps) collect a plethora of information regarding the user behavior and his device through third-party analytics libraries. However, the collection and usage of such data raised several privacy concerns, mainly because the end-user -i.e., the actual owner of the data -is out of the loop in this collection process. Also, the existing privacy-enhanced solutions that emerged in the last years follow an "all or nothing" approach, leaving the user the sole option to accept or completely deny the access to privacy-related data. This work has the two-fold objective of assessing the privacy implications on the usage of analytics libraries in mobile apps and proposing a data anonymization methodology that enables a trade-off between the utility and privacy of the collected data and gives the user complete control over the sharing process. To achieve that, we present an empirical privacy assessment on the analytics libraries contained in the 4500 most-used Android apps of the Google Play Store between November 2020 and January 2021. Then, we propose an empowered anonymization methodology, based on MobHide [1], that gives the end-user complete control over the collection and anonymization process. Finally, we empirically demonstrate the applicability and effectiveness of such anonymization methodology thanks to HideDroid, a fully-fledged anonymization app for the Android ecosystem.

show abstract

Section: Testing Hidedroid In the Wildmentioning

confidence: 99%

You can't always get what you want: towards user-controlled privacy on Android

Caputo,

Pagano,

Bottino

et al. 2021

Preprint

Self Cite

View full text Add to dashboard Cite

show abstract

“…Merlo et al [34] leverage native code for performing app integrity checks. Merlo et al [35] look at current anti-repackaging techniques and how to circumvent them.…”

Section: Device and App Integritymentioning

confidence: 99%

SafetyNOT

Ibrahim

Imran

Bianchi

2021

Proceedings of the 19th Annual International Conference on Mobile Systems, Applications, and Services

View full text Add to dashboard Cite

Many apps performing security-sensitive tasks (e.g., online banking) attempt to verify the integrity of the device they are running in and the integrity of their own code. To ease this goal, Android provides an API, called the SafetyNet Attestation API, that can be used to detect if the device an app is running in is in a "safe" state (e.g., non-rooted) and if the app's code has not been modified (using, for instance, app repackaging). In this paper, we perform the first large-scale systematic analysis of the usage of the SafetyNet API. Our study identifies many common mistakes that app developers make when attempting to use this API. Specifically, we provide a systematic categorization of the possible misusages of this API, and we analyze how frequent each misuse is. Our results show that, for instance, more than half of the analyzed apps check SafetyNet results locally (as opposed to using a remote trusted server), rendering their checks trivially bypassable. Even more surprisingly, we found that none of the analyzed apps invoking the SafetyNet API uses it in a fully correct way. CCS CONCEPTS• Security and privacy → Software reverse engineering; Intrusion detection systems.

show abstract

“…1). The idea of detection nodes has been put forward in [6] and it refers to a self-protecting mechanism made by a piece of code inserted into the original , which carries out integrity checks -called anti-tampering controls (e.g., signature check, package name check) -when executed at runtime [11]. More specifically, anti-tampering checks compare the signature of a specific part of the with a value pre-computed during the building of the original app;…”

Section: Anti-repackaging Techniquesmentioning

confidence: 99%

“…ARMAND supports several controls in either Java and native code, such as environment controls (e.g., emulator detection), signature check, package name check, and file integrity check (e.g., resource and image files). We refer the interested reader to [11] for a detailed description of the different AT techniques that can be used in an anti-repackaging scheme.…”

Section: Multi-patterning Logic Bombs and At Checksmentioning

confidence: 99%

ARMAND: Anti-Repackaging through Multi-pattern Anti-tampering based on Native Detection

Merlo,

Ruggia,

Sciolla

et al. 2020

Preprint

Self Cite

View full text Add to dashboard Cite

App repackaging refers to the practice of customizing an existing mobile app and redistributing it in the wild to fool the final user into installing the repackaged app instead of the original one. In this way, an attacker can embed malicious payload into a legitimate app for different aims, such as access to premium features, redirect revenue, or access to user's private data. In the Android ecosystem, apps are available on public stores, and the only requirement for an app to execute properly is to be digitally signed. Due to this, the repackaging threat is widely spread.Anti-repackaging techniques aim to make harder the repackaging process for an attack adding logical controls -called detection node -in the app at compile-time. Such controls check the app integrity at runtime to detect tampering. If tampering is recognized, the detection nodes lead the repackaged app to fail (e.g., throwing an exception). From an attacker's standpoint, she must detect and bypass all controls to repackage safely.In this work, we propose a novel anti-repackaging scheme -called ARMANDwhich aims to overcome the limitations of the current protection schemes. We have implemented this scheme into a prototype -named ARMANDroid -which leverages multiple protection patterns and relies on native code. The evaluation phase of ARMANDroid on 30.000 real-world Android apps showed that the scheme is robust against the common attack vectors and efficient in terms of time and space overhead.

show abstract

You Shall not Repackage! Demystifying Anti-Repackaging on Android

Cited by 23 publications

References 25 publications

You can't always get what you want: towards user-controlled privacy on Android

You can't always get what you want: towards user-controlled privacy on Android

SafetyNOT

ARMAND: Anti-Repackaging through Multi-pattern Anti-tampering based on Native Detection

Contact Info

Product

Resources

About