Two-factor Protection Scheme in Securing the Source Code of Android Applications

As the number of android applications (apps) available in the market are increasing rapidly, various types of security attacks using the android apps are also increasing with the same pace. The ransomware attack is one of these kind of security attacks in which the attackers locks the user's phone, encrypts user's data or blocks the user's access to their own data and threatens the user to pay a ransom to gain the access back. This cyber-threat is terrorizing the world from many years as it performs mimicry attacks i. e. combination of encryption & locking attacks. Android devices are more prone to these ransomware attacks compared to Windows and IOS devices. RansomwareElite is an android application which detects the presence of ransomware in the apps installed on an android device by checking the presence of any threatening text in app code or by verifying the permissions requested by the app from the user. In this paper, we focused on improving the performance of RansomwareElite app by extending its features. Now, the RansomwareElite app also searches the presence of any threatening image or file containing threatening text by analyzing the Android Package Kit(APK) file of android app. Moreover, it also detects some specific methods and classes in the code of the APK which could be used for locking the device and checks some specific permissions requested, for uninstalled apps now. Further, it maintains a database on the online server for the records of all the suspicious and ransomware apps detected by RansomwareElite. We have tested RansomwareElite with 9 Test Apps which are manually created based on the features of ransomware family and on 48 android devices. After analyzing the test results, we have found that the performance of RansomwareElite is improved after incorporating the new features and RansomwareElite app detects the presence of ransomware in installed as well as uninstalled apps present on an android's device in an efficient manner.

Android apps include third-party native libraries to increase performance and to reuse functionality. Native code is directly executed from apps through the Java Native Interface or the Android Native Development Kit. Android developers add precompiled native libraries to their projects, enabling their use. Unfortunately, developers often struggle or simply neglect to update these libraries in a timely manner. This results in the continuous use of outdated native libraries with unpatched security vulnerabilities years after patches became available. To further understand such phenomena, we study the security updates in native libraries in the most popular 200 free apps on Google Play from Sept. 2013 to May 2020. A core difficulty we face in this study is the identification of libraries and their versions. Developers often rename or modify libraries, making their identification challenging. We create an approach called LibRARIAN (LibRAry veRsion IdentificAtioN) that accurately identifies native libraries and their versions as found in Android apps based on our novel similarity metric bin2sim. LibRARIAN leverages different features extracted from libraries based on their metadata and identifying strings in read-only sections. We discovered 53/200 popular apps (26.5%) with vulnerable versions with known CVEs between Sept. 2013 and May 2020, with 14 of those apps remaining vulnerable. We find that app developers took, on average, 528.71 ±40.20 days to apply security patches, while library developers release a security patch after 54.59 ± 8.12 days---a 10 times slower rate of update.

Systematic exploration of Android apps is an enabler for a variety of app analysis and testing tasks. Performing the exploration while apps run on actual phones is essential for exploring the full range of app capabilities. However, exploring real-world apps on real phones is challenging due to non-determinism, non-standard control flow, scalability and overhead constraints. Relying on end-users to conduct the exploration might not be very effective: we performed a 7-use study on popular Android apps, and found that the combined 7-use coverage was 30.08% of the app screens and 6.46% of the app methods. Prior approaches for automated exploration of Android apps have run apps in an emulator or focused on small apps whose source code was available. To address these problems, we present A3E, an approach and tool that allows substantial Android apps to be explored systematically while running on actual phones, yet without requiring access to the app's source code. The key insight of our approach is to use a static, taint-style, dataflow analysis on the app bytecode in a novel way, to construct a high-level control flow graph that captures legal transitions among activities (app screens). We then use this graph to develop an exploration strategy named Targeted Exploration that permits fast, direct exploration of activities, including activities that would be difficult to reach during normal use. We also developed a strategy named Depth-first Exploration that mimics user actions for exploring activities and their constituents in a slower, but more systematic way. To measure the effectiveness of our techniques, we use two metrics: activity coverage (number of screens explored) and method coverage. Experiments with using our approach on 25 popular Android apps including BBC News, Gas Buddy, Amazon Mobile, YouTube, Shazam Encore, and CNN, show that our exploration techniques achieve 59.39--64.11% activity coverage and 29.53--36.46% method coverage.

I’ve covered much of what you need to know about Java to give you a solid foundation on which to build with Android app fundamentals. However, there still are a few topics that you should first understand. In this chapter, I introduce you to various language, API, and miscellaneous topics (such as design patterns and the Java Native Interface) that you’ll find helpful in an Android context. I also present additional APIs (such as Preferences) that are not as useful for Android apps, but are sure to be useful for non-Android applications.KeywordsVirtual MachineOutput StreamLocale LocaleStatic VoidProperty FileThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

With the continuous growth in the usage of Android apps, ensuring their security has become critically important. An increasing number of malicious apps adopt anti-analysis techniques to evade security measures. Although some research has started to consider anti-runtime analysis (ARA), it is unfortunate that they have not systematically examined ARA techniques. Furthermore, the rapid evolution of ARA technology exacerbates the issue, leading to increasingly inaccurate analysis results. To effectively analyze Android apps, understanding their adopted ARA techniques is necessary. However, no systematic investigation has been conducted thus far. <p xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">In this paper, we conduct the first systematic study of the ARA implementations in a wide range of 117,270 Android apps (including both malicious and benign ones) collected between 2016 and 2023. Additionally, we propose a specific investigation tool named <small>ARAP</small> to assist this study by leveraging both static and dynamic analysis. According to the evaluation results, <small>ARAP</small> not only effectively identifies the ARA implementations in Android apps but also reveals many important findings. For instance, almost all apps have implemented at least one category of ARA technology (99.6% for benign apps and 97.0% for malicious apps).

While many tutorials, code examples, and documentation about Android APIs exist, developers still face various problems with the implementation of Android Apps. Many of these issues are discussed on QaA-sites, such as Stack Overflow. In this paper we present a manual categorization of 450 Android related posts of Stack Overflow concerning their question and problem types. The idea is to find dependencies between certain problems and question types to get better insights into issues of Android App development. The categorization is developed using card sorting with three experienced Android App developers. An initial approach to automate the classification of Stack Overflow posts using Lucene is also presented. The study highlights that the most common question types are 'How to?' and 'What is the problem?'. The problems that are discussed most often are related to 'User Interface' and 'Core Elements'. In particular, the problem category 'Layout' is often related to 'What is the problem?' and 'Frameworks' issues often come with 'Is it possible?' questions.

Android apps are written in Java and use various Java application program interfaces (APIs). Because you’ll want to write your own apps, but may be unfamiliar with the Java language and these APIs, this book teaches you about Java as a first step into Android app development. It provides you with Java language fundamentals and Java APIs that are useful when developing apps.

One of the challenges to analyze, test and debug Android apps is that the potential execution orders of callbacks are missing from the apps' source code, however, bugs, vulnerabilities and refactoring transformations have been found to be related to callback sequences. Existing work on control flow analysis of Android apps focuses on analyzing GUI behaviors. Our observation is that orthogonal to GUI, the Android API methods also play an important role in determining the order of callbacks, and previously, the APIs were modeled manually in an ad-hoc way. This paper presents a complementary solution of constructing program paths for Android apps. We proposed a specification called Predicate Callback Summary (PCS) that represents the callback control flow information (including callback sequences as well as the conditions the callbacks are invoked) in Android API methods. Our experiments show we can compute PCSs with reasonable accuracy and scalability and use them to build inter-callback control flow graphs for apps. Our detailed experimental data are available at: http://www.cs.iastate.edu/~weile/toolsdata/SummarizeAndroidFramework/lithium.html.

Android apps often have a “dark mode” option used in low-light situations, for those who find the conventional color palette problematic, or because of personal preferences. Typically developers add a dark mode option for their apps with different backgrounds, text, and sometimes iconic forms. We wanted to understand the actual provision of this dark mode in real-world Android apps through an empirical study of posts from Stack Overflow and real-world Android app analysis. Using these approaches, we identified the aspects of dark mode that developers implemented as well as the key difficulties they experienced in implementing it. We performed a quantitative analysis using open-coding of more than 300 discussion threads to create a taxonomy regarding the aspects discussed by developers with respect to dark mode in Android. Our quantitative analysis of over 6,000 Android apps highlights which dark mode features are typically provided in Android apps and which aspects developers care about during dark mode design. We also examined four app development support tools to see how well they aid Android app development for dark mode. From our analysis, we distilled some key lessons to guide further research and actions in aiding developers with supporting users who require such assistive features. For example, developers should be aware of the potential risks in using unsuitable dark mode design schema and researchers should take dark mode features into consideration when developing app development support tools.

Android Apps are frequently updated, every couple of weeks, to keep up with changing user, hardware and business demands. Correctness of App updates is checked through extensive testing. Recent research has proposed tools for automated GUI event generation in Android Apps. These techniques, however, are not efficient at checking App updates as the generated GUI events do not prioritise updates, and instead explore other App behaviours. We address this need in this paper with CAT (Change-focused Android GUI Testing). For App updates, at the source code or GUI level, CAT performs change impact analysis to identify GUI elements affected by the update. CAT then generates GUI event sequences to interact with the affected GUI elements. Our empirical evaluations using 21 publicly available open source and 2 commercial Android Apps demonstrate that CAT is able to automatically identify GUI elements affected by App updates, generate and execute GUI event sequences focusing on change-affected GUI elements. Comparison with two popular GUI event generation tools, DroidBot and DroidMate, revealed that CAT was more effective at interacting with the change-affected GUI elements. Finally, CAT was able to detect previously unknown change-related bugs in two open source Apps. Developers of the commercial Apps found CAT was more effective than their in-house GUI testing tool in interacting with changed elements and faster at detecting seeded bugs.

Help Without Borders: How the Google Android Case Threatens to Derail the Limited Scope of the Obligation to Assist Competitors

A majority of today's mobile apps integrate web content of various kinds. Unfortunately, the interactions between app code and web content expose new attack vectors: a malicious app can subvert its embedded web content to steal user secrets; on the other hand, malicious web content can use the privileges of its embedding app to exfiltrate sensitive information such as the user's location and contacts. In this paper, we discuss security weaknesses of the interface between app code and web content through attacks, then introduce defenses that can be deployed without modifying the OS. Our defenses feature WIREframe, a service that securely embeds and renders external web content in Android apps, and in turn, prevents attacks between em- bedded web and host apps. WIREframe fully mediates the interface between app code and embedded web content. Un- like the existing web-embedding mechanisms, WIREframe allows both apps and embedded web content to define simple access policies to protect their own resources. These policies recognize fine-grained security principals, such as origins, and control all interactions between apps and the web. We also introduce WIRE (Web Isolation Rewriting Engine), an offline app rewriting tool that allows app users to inject WIREframe protections into existing apps. Our evaluation, based on 7166 popular apps and 20 specially selected apps, shows these techniques work on complex apps and incur acceptable end-to-end performance overhead.

A large-scale study on the adoption of anti-debugging and anti-tampering protections in android apps

Searching for vulnerabilities in Android apps through approaches based on the app's dex bytecode has been applied to a lot of researches. This approach, called late detection, is applied to apps already released, and usually doesn't identify vulnerabilities before users have been exposed. This article presents a method based on static analysis with matching patterns for identifying these vulnerabilities beforehand, during the app development, avoiding users' exposure. The presented technique was evaluated by an experimental test proofapplied to open-source applications, analyzed by appDroidAnalyzer, identifying dozens of apps affected by vulnerabilities in their source code.

For surviving in the highly competitive market of Android apps, it is fundamental for app developers to deliver apps of high quality and with short release times. A well-architected Android app is beneficial for developers, e.g. in terms of maintainability, testability, performance, and avoidance of resource leaks. However, how to properly architect Android apps is still debated and subject to conflicting opinions usually influenced by technological hypes rather than objective evidence. In this paper we present an empirical study on how developers architect Android apps, what architectural patterns and practices Android apps are based on, and their potential impact on quality. We apply a mixed-method empirical research design that combines (i) semi-structured interviews with Android practitioners in the field and (ii) a systematic analysis of both the grey (i.e., websites, Online blogs) and white literature (i.e., academic studies) on the architecture of Android apps. Based on the analysis of the state of the art and practice about architecting Android apps, we systematically extract a set of 42 evidence-based guidelines supporting developers when architecting their Android apps.