Selective control-flow abstraction via jumping

Blackshear, Sam; Chang, Bor-Yuh Evan; Sridharan, Manu

doi:10.1145/2814270.2814293

Cited by 22 publications

(10 citation statements)

References 27 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…However, these approaches just focus on components' callbacks and some GUI events and can be incomplete for the rest of the Android API [7]. Besides control flow constraints offered by lifecycle of components, Blackshear et al [34] use data dependencies between callbacks to identify more ordering constraints between callbacks.…”

Section: Related Workmentioning

confidence: 99%

Specifying Callback Control Flow of Mobile Apps Using Finite Automata

Perez

2021

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

Given the event-driven and framework-based architecture of Android apps, finding the ordering of callbacks executed by the framework remains a problem that affects every tool that requires inter-callback reasoning. Previous work has focused on the ordering of callbacks related to the Android components and GUI events. But the execution of callbacks can also come from direct calls of the framework (API calls). This paper defines a novel program representation, called Callback Control Flow Automata (CCFA), that specifies the control flow of callbacks invoked via a variety of sources. We present an analysis to automatically construct CCFAs by combining two callback control flow representations developed from the previous research, namely, Window Transition Graphs (WTGs) and Predicate Callback Summaries (PCSs). To demonstrate the usefulness of our representation, we integrated CCFAs into two client analyses: a taint analysis using FLOWDROID, and a value-flow analysis that computes source and sink pairs of a program. Our evaluation shows that we can compute CCFAs efficiently and that CCFAs improved the callback coverages over WTGs. As a result of using CCFAs, we obtained 33 more true positive security leaks than FLOWDROID over a total of 55 apps we have run. With a low false positive rate, we found that 22.76% of source-sink pairs we computed are located in different callbacks and that 31 out of 55 apps contain source-sink pairs spreading across components. Thus, callback control flow graphs and inter-callback analysis are indeed important. Although this paper mainly uses Android, we believe that CCFAs can be useful for modeling control flow of callbacks for other event-driven, framework-based systems.

show abstract

Section: Related Workmentioning

confidence: 99%

Specifying Callback Control Flow of Mobile Apps Using Finite Automata

Perez

2021

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

show abstract

“…Backward analysis Several works on backward analysis [2,3,4,7] check the validity of given queries. Their techniques keep applying transfer functions that infer preconditions backward from given post-conditions until they find any contradictory condition that refutes the queries.…”

Section: Related Workmentioning

confidence: 99%

Automatically Tracing Imprecision Causes in JavaScript Static Analysis

2019

View full text Add to dashboard Cite

Researchers have developed various techniques for static analysis of JavaScript to improve analysis precision. To develop such techniques, they first identify causes of the precision losses for unproven properties. While most of the existing work has diagnosed main causes of imprecision in static analysis by manual investigation, manually tracing the imprecision causes is challenging because it requires detailed knowledge of analyzer internals. Recently, several studies proposed to localize the analysis imprecision causes automatically, but these localization techniques work for only specific analysis techniques.In this paper, we present an automatic technique that can trace analysis imprecision causes of JavaScript applications starting from user-selected variables. Given a set of program variables, our technique stops an analysis when any of the variables gets imprecise analysis values. It then traces the imprecise analysis values using intermediate analysis results back to program points where the imprecision first started. Our technique shows the trace information with a new representation called tracing graphs, whose nodes and edges together represent traces from imprecise points to precise points. In order to detect major causes of analysis imprecision automatically, we present four node/edge patterns in tracing graphs for common imprecision causes. We formalized the technique of generating tracing graphs and identifying patterns, and implemented them on SAFE, a state-of-the-art JavaScript static analyzer with various analysis configurations, such as contextsensitivity, loop-sensitivity, and heap cloning. Our evaluation demonstrates that the technique can easily find 96 % of the major causes of the imprecision problems in 17 applications by only automatic detection in tracing graphs using the patterns, and selectively adopting various advanced techniques can eliminate the found causes of imprecision. ACM CCS 2012Software and its engineering → Software verification; Automated static analysis;

show abstract

“…In the context of software model checking, path slicing was proposed to find statements in a given path that are relevant to show its (in)feasibility [35]. Slicing has also been used to reduce the number of interlivings in event-oriented applications [10], and recently it has been combined with runtime analysis to extract values of variables that make an application difficult to statically analyse [48].…”

Section: Slicingmentioning

confidence: 99%

Sub-Turing Islands in the Wild

Barr¹,

Binkley²,

Harman³

et al. 2019

Preprint

View full text Add to dashboard Cite

Recently, there has been growing debate as to whether or not static analysis can be truly sound. In spite of this concern, research on techniques seeking to at least partially answer undecidable questions has a long history. However, little attention has been given to the more empirical question of how often an exact solution might be given to a question despite the question being, at least in theory, undecidable. This paper investigates this issue by exploring sub-Turing islands -regions of code for which a question of interest is decidable. We define such islands and then consider how to identify them. We implemented Endeavour, a prototype for finding sub-Turing islands and applied it to a corpus of 1100 Android applications, containing over 2 million methods. Results reveal that 55% of the all methods are sub-Turing. Our results also provide empirical, scientific evidence for the scalability of sub-Turing island identification.Sub-Turing identification has many downstream applications, because islands are so amenable to static analysis. We illustrate two downstream uses of the analysis. In the first, we found that over 37% of the verification conditions associated with runtime exceptions fell within sub-Turing islands and thus are statically decidable. A second use of our analysis is during code review where it provides guidance to developers. The sub-Turing islands from our study turns out to contain significantly fewer bugs than "the swamp" (non sub-Turing methods). The greater bug density in the swamp is unsurprising; the fact that bugs remain prevalent in islands is, however, surprising: these are bugs whose repair can be fully automated.

show abstract

Selective control-flow abstraction via jumping

Cited by 22 publications

References 27 publications

Specifying Callback Control Flow of Mobile Apps Using Finite Automata

Specifying Callback Control Flow of Mobile Apps Using Finite Automata

Automatically Tracing Imprecision Causes in JavaScript Static Analysis

Sub-Turing Islands in the Wild

Contact Info

Product

Resources

About