Towards self-healing smartphone software via automated patching

Abstract

Frequent app bugs and low tolerance for loss of functionality create an impetus for self-healing smartphone software. We take a step towards this via on-the-fly error detection and automated patching. Specifically, we add failure detection and recovery to Android by detecting crashes and "sealing off" the crashing part of the app to avoid future crashes. In the detection stage, our system dynamically analyzes app execution to detect certain exceptional situations. In the recovery stage, we use bytecode rewriting to alter app behavior as to avoid such situations in the future. When using our implementation, apps can resume operation (albeit with limited functionality) instead of repeatedly crashing. Our approach does not require access to app source code or any system (e.g., kernel-level) modification. Experiments on several real-world, popular Android apps and bugs show that our approach manages to recover the apps from crashes effectively, timely, and without introducing overhead.

Security and Science of Agility

“…While the OS can restart the application when a fault occurs, application state can be lost, and the application will crash again when faulty code is invoked. To address this problem, in prior work [1] we added failure detection and recovery to Android applications by detecting faults and "sealing off" the faulty part of the application to avoid future faults. An overview of our approach is shown in Figure 2; the reader can ignore the blue callout boxes for now.…”

“…Given a patch size of b bytes, throughput between arbitrary nodes i and j is t i, j and the power to transmit is p tx and power to receive p rx , and the cost to deliver the patch is P patch delivery = bt 0,1 p tx + n−1 ∑ i=1 bt i, j (p tx + p rx ) + bt n−1,n p rx (1) Overall the cost to patch is represented as: p patch = p apply patch + p patch delivery In situations where the network is constrained, the distance from the patch location to the node is many hops (large n) and/or the patch size is large. We may find that p patch >> p(self heal) and p patch >> p(seal off ).…”

“…More concretely, MTDs are maneuvers executed by a human or autonomous defender in an attempt to increase the security of an environment. The basic MTD tenet is that randomization renders the perceived attack surface stochastic, it increases the spatio-temporal diversity of the attack surface and thus the cost to the adversary and the time it takes to learn network configurations and exploit vulnerabilities 1 . Absent from the current literature is a systems approach that takes a holistic view of adaptation across multiple layers, multiple time scales and across the network.…”

Controlling Interactions with Libraries in Android Apps Through Runtime Enforcement

“…In addition to studying how to turn regular libraries into proactive libraries that can be exploited to make software systems more reliable, we defined a model-based approach for both the definition of the enforcers and the automatic generation of their implementation, that we call proactive module, for the Android environment. Although the concepts of enforcers and proactive libraries are general, we studied them in the context of the Android ecosystem because many non-trivial and rapidly evolving APIs for resource management are available and problems with resources are frequent [6,7,55].…”

“…The design and implementation of enforcers is for library developers and in general for developers who want to contribute to the Android ecosystem, while the runtime activation of the enforcers is under the control of the final users.In addition to studying how to turn regular libraries into proactive libraries that can be exploited to make software systems more reliable, we defined a model-based approach for both the definition of the enforcers and the automatic generation of their implementation, that we call proactive module, for the Android environment. Although the concepts of enforcers and proactive libraries are general, we studied them in the context of the Android ecosystem because many non-trivial and rapidly evolving APIs for resource management are available and problems with resources are frequent [6,7,55].This work extends our previous work on proactive libraries [44] by (i) introducing a process, a modelling environment, and a code generation strategy to automatically generate the proactive libraries from a specification of the enforcers, (ii) extending the modelling language used to specify the enforcers with special operations for restoring resources and with the possibility to distinguish if an action taken by an enforcer must be executed before or after an operation performed by the monitored software, (iii) increasing the sophistication of the proactive module to consider the status of Android components, enforcement strategies, and resources simultaneously, (iv) providing a more detailed presentation of the approach and additional background material, (v) extending the empirical evaluation with 15 additional real-world cases from popular Android markets and open-source Android community; and (vi) studying the scalability of the proactive modules and the usefulness of the model-based approach compared to the manual implementation of the enforcers.The paper is organized as follows. Section 2 provides background information about edit automata, which is the formalism used in this paper to specify enforcers, model-driven software development, which is the methodology used to specify and generate the proactive libraries, and Xposed, which is the framework we used to implement the proactive modules for Android.…”