Sequences Of Function Calls Research Articles

PP-CSA: Practical Privacy-Preserving Software Call Stack Analysis

Software call stack is a sequence of function calls that are executed during the runtime of a software program. Software call stack analysis (CSA) is widely used in software engineering to analyze the runtime behavior of software, which can be used to optimize the software performance, identify bugs, and profile the software. Despite the benefits of CSA, it has recently come under scrutiny due to concerns about privacy. To date, software is often deployed at user-side devices like mobile phones and smart watches. The collected call stacks may thus contain privacy-sensitive information, such as healthy information or locations, depending on the software functionality. Leaking such information to third parties may cause serious privacy concerns such as discrimination and targeted advertisement. This paper presents PP-CSA, a practical and privacy-preserving CSA framework that can be deployed in real-world scenarios. Our framework leverages local differential privacy (LDP) as a principled privacy guarantee, to mutate the collected call stacks and protect the privacy of individual users. Furthermore, we propose several key design principles and optimizations in the technical pipeline of PP-CSA, including an encoder-decoder scheme to properly enforce LDP over software call stacks, and several client/server-side optimizations to largely improve the efficiency of PP-CSA. Our evaluation over real-world Java and Android programs shows that our privacy-preserving CSA pipeline can achieve high utility and privacy guarantees while maintaining high efficiency. We have released our implementation of PP-CSA as an open-source project at https://github.com/wangzhaoyu07/PP-CSA for results reproducibility. We will provide more detailed documents to support and the usage and extension of the community.

Anomaly Detection Based on Temporal Behavior Monitoring in Programmable Logic Controllers

As Programmable Logic Controllers (PLCs) are increasingly connected and integrated into the industrial Internet of things, cybersecurity threats to PLCs are also increasing. Adversaries can perform a denial of service (DoS) attack based on the transmission of a large number of network packets, and a control-logic injection attack through sophisticated packet transmission. We propose an approach to detecting and defending against attacks that exploit security vulnerabilities in a PLC system. In order to protect against indiscriminate packet transmission attacks that exploit uncontrolled resource consumption vulnerabilities, an abnormal temporal behavior detection method is proposed that monitors the CPU usage of tasks. If a temporal anomaly is detected, the proposed approach tries to detect control-flow anomalies by examining the sequences of function calls, then detects stack-based buffer overflow attacks. The proposed method is implemented in a water tank control system for evaluation purposes. The experimental results show that the proposed method can improve the security of the system by detecting anomalies in temporal behavior with little system overhead.

End-to-end automated cache-timing attack driven by machine learning

Cache-timing attacks are serious security threats that exploit cache memories to steal secret information. We believe that the identification of a sequence of function calls from cache-timing data measurements is not a trivial step when building an attack. We present a recurrent neural network model able to automatically retrieve a sequence of operations from cache timings. Inspired from natural language processing, our model is able to learn on partially labelled data. We use the model to unfold an end-to-end automated attack on OpenSSL ECDSA on the secp256k1 curve. Our attack is able to extract the 256 bits of the secret key by automatic analysis of about 2400 traces without any human processing.

In-the-field monitoring of functional calls: Is it feasible?

Collecting data about the sequences of function calls executed by an application while running in the field can be useful to a number of applications, including failure reproduction, profiling, and debugging. Unfortunately, collecting data from the field may introduce annoying slowdowns that negatively affect the quality of the user experience. So far, the impact of monitoring has been mainly studied in terms of the overhead that it may introduce in the monitored applications, rather than considering if the introduced overhead can be really recognized by users. In this paper we take a different perspective studying to what extent collecting data about sequences of function calls may impact the quality of the user experience, producing recognizable effects. Interestingly we found that, depending on the nature of the executed operation and its execution context, users may tolerate a non-trivial overhead. This information can be potentially exploited to collect significant amount of data without annoying users.

Fault Localization Using Function Call Sequences

Fault localization techniques locate faults in a program. Many predicate based statistical fault localization techniques have been proposed in order to locate faults effectively and efficiently. Most of the faults exist in independent functions rather than independent predicates in a program and the majority of these faults will cause abnormal sequences of function calls. This paper proposes a novel function-level sequence matching fault localization technique called SMFL, which use abnormal start points of function call sequences between normal traces and faulty traces. Our approach runs a program to calculate the suspiciousness of each function, and gives a ranking list of all functions in descending order of the suspiciousness. The disparities of function call sequences in different versions of the same software program on a test case are very small and these disparities provide information about faulty functions. We use Siemens program as our subjects. The experimental results show that our approach can improve the effectiveness of fault localization.

Casper: an efficient approach to call trace collection

Call traces, i.e., sequences of function calls and returns, are fundamental to a wide range of program analyses such as bug reproduction, fault diagnosis, performance analysis, and many others. The conventional approach to collect call traces that instruments each function call and return site incurs large space and time overhead. Our approach aims at reducing the recording overheads by instrumenting only a small amount of call sites while keeping the capability of recovering the full trace. We propose a call trace model and a logged call trace model based on an LL(1) grammar, which enables us to define the criteria of a feasible solution to call trace collection. Based on the two models, we prove that to collect call traces with minimal instrumentation is an NP-hard problem. We then propose an efficient approach to obtaining a suboptimal solution. We implemented our approach as a tool Casper and evaluated it using the DaCapo benchmark suite. The experiment results show that our approach causes significantly lower runtime (and space) overhead than two state-of-the-arts approaches.

A new detection scheme of software copyright infringement using software birthmark on windows systems

As software is getting more valuable, unauthorized users or malicious programmers illegally copies and distributes copyrighted software over online service provider (OSP) and P2P networks. To detect, block, and remove pirated software (illegal programs) on OSP and P2P networks, this paper proposes a new filtering approach using software birthmark, which is unique characteristics of program and can be used to identify each program. Software birthmark typically includes constant values, library information, sequence of function calls, and call graphs, etc. We target Microsoft Windows applications and utilize the numbers and names of DLLs and APIs stored in a Windows executable file. Using that information and each cryptographic hash value of the API sequence of programs, we construct software birthmark database. Whenever a program is uploaded or downloaded on OSP and P2P networks, we can identify the program by comparing software birthmark of the program with birthmarks in the database. It is possible to grasp to some extent whether software is an illegally copied one. The experiments show that the proposed software birthmark can effectively identify Windows applications. That is, our proposed technique can be employed to efficiently detect and block pirated programs on OSP and P2P networks.

A Theoretical and Empirical Analysis of the Role of Test Sequence Length in Software Testing for Structural Coverage

In the presence of an internal state, often a sequence of function calls is required to test software. In fact, to cover a particular branch of the code, a sequence of previous function calls might be required to put the internal state in the appropriate configuration. Internal states are not only present in object-oriented software, but also in procedural software (e.g., static variables in C programs). In the literature, there are many techniques to test this type of software. However, to the best of our knowledge, the properties related to the choice of the length of these sequences have received only a little attention in the literature. In this paper, we analyze the role that the length plays in software testing, in particular branch coverage. We show that, on “difficult” software testing benchmarks, longer test sequences make their testing trivial. Hence, we argue that the choice of the length of the test sequences is very important in software testing. Theoretical analyses and empirical studies on widely used benchmarks and on an industrial software are carried out to support our claims.

WYSIWIB: exploiting fine‐grained program structure in a scriptable API‐usage protocol‐finding process

SUMMARYBug‐finding tools rely on specifications of what is correct or incorrect code. As it is difficult for a tool developer or user to anticipate all possible specifications, strategies for inferring specifications have been proposed. These strategies obtain probable specifications by observing common characteristics of code or execution traces, typically focusing on sequences of function calls. To counter the observed high rate of false positives, heuristics have been proposed for ranking or pruning the results. These heuristics, however, can result in false negatives, especially for rarely used functions. In this paper, we propose an alternate approach to specification inference, in which the user guides the inference process using patterns of code that reflect the user's understanding of the conventions and design of the targeted software project. We focus on specifications describing the correct usage of API functions, which we refer to as API protocols. Our approach builds on the Coccinelle program matching and transformation tool, which allows a user to construct patterns that reflect the structure of the code to be matched. We evaluate our approach on the source code of the Linux kernel, which defines a very large number of API functions with varying properties. Linux is also critical software, implying that fixing even bugs involving rarely used protocols is essential. In our experiments, we use our approach to find over 3000 potential API protocols, with an estimated false positive rate of under 15% and use these protocols to find over 360 bugs in the use of API functions. Copyright © 2012 John Wiley & Sons, Ltd.

Analysis of Computer Intrusions Using Sequences of Function Calls

This paper demonstrates the value of analyzing sequences of function calls for forensic analysis. Although this approach has been used for intrusion detection (that is, determining that a system has been attacked), its value in isolating the cause and effects of the attack has not previously been shown. We also look for not only the presence of unexpected events but also the absence of expected events. We tested these techniques using reconstructed exploits in su, ssh, and lpr, as well as proof-of-concept code, and, in all cases, were able to detect the anomaly and the nature of the vulnerability.