272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 17: Code Mining

Code Mining There is a lot of code that is available for everyone to access –Can we learn from them? One of the active research directions in software engineering is to mine existing code for various purposes such as –To discover common behaviors which can then be used to extract specifications such as interfaces usage patterns, etc. –To discover anomalies which can then be used to find bugs or problematic behaviors

We will discuss two papers that do this Today we will discuss two papers that use code mining for different purposes: "Graph-based Mining of Multiple Object Usage Patterns" Tung Nguyen, Hoan Nguyen, Nam Pham, Jafar Al-Kofahi, and Tien Nguyen. 7th joint meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE 2009). –"Mining Specifications of Malicious Behavior" Mihai Christodorescu, Somesh Jha, Christopher Kruegel. Joint meeting of European Software Engineering Conference and ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE 2007).

Mining for Object Usage Patterns We discussed papers that automatically extract behavioral interfaces for classes –The papers we discussed earlier focus on usage of a single class and try to identify the ordering of method class on a single object However, there maybe usage patterns that involve multiple objects –Moreover, usage patterns may involve control flow structures –such as calling a method within a loop and data dependencies –such as one argument in a method call being dependent on an argument in another method call

GrouMiner GrouMiner is a tool that extracts usage patterns for objects that takes into account both –temporal usage orders (like we have seen in the interface extraction papers we discussed already), and –data dependencies It defines a graph-based object usage model (groum) and extracts these models from existing code

Object Usage Model A groum is a directed acyclic graph –nodes are labeled, edges are not labeled Nodes correspond to –actions: method calls, access to object fields –control flow structures: conditions, branches or loops such as if, while, for statements Edges represent –temporal ordering: If A is used before (or always generated before) B then there is an edge from A to B –data dependency: There is an edge from A to B if there is a data dependency between A and B A groum can represent multiple objects

How to Extract the Object Usage Model? The temporal ordering of the nodes in a groum is extracted from the AST by adding edges between nodes that are sequentially ordered The data dependency edges are extracted using an intra-procedural dependency analysis –Identify the variables involved in each action to determine the dependencies and add edges to represent the dependencies

Extracting Code Skeletons A groum model can be un-parsed and converted to a code skeleton This code skeleton will demonstrate the usage pattern as code rather than a directed acyclic graph This approach can be used as a reverse engineering approach to discover different usage patterns in the code However, there will be many groums in a given code and not all of them should be reported as usage patterns –They should be filetered somehow

Usage Pattern Mining GrouMiner uses graph mining techniques to identify the common usage patterns in the code They determine the frequency of a pattern by computing the number of independent occurrences –If the frequency of a pattern is higher than a threshold, then it is reported The graph mining algorithm determines the common patterns efficiently by –By identifying common graph patterns incrementally, starting with graphs with small number of nodes and then finding other patterns based on sub-graph relationship –By checking equivalence of patterns approximately using a vector representation that summarizes the features of a pattern, rather than doing an exact matching

Anomaly Detection Using the graph mining algorithm they can identify anomalous usages –They identify an anomalous usage as a sub-graph of an identified pattern that is not extensible to that pattern –This is considered a violation of the pattern A violation is considered an anomaly when it is too rare –i.e., common violations are not reported as anomalies They discuss two types of anomaly detection: 1) anomaly detection in a given project, 2) anomaly detection when a project changes Anomaly detection can be used to identify errors –Ana anomalous usage may correspond to violation of an interface and may point to a bug However, when anomaly detection is used as a bug finding approach it generates a lot of false positives (87.8% in one case) –i.e., many identified anomalies do not correspond to errors

Mining Specifications of Malicious Behavior In the second paper we are discussing, code mining is used to find specifications of malicious behavior Computer security applications rely on manually written specifications to identify malicious code automatically However, the manual specification task is hard and time consuming –This paper tries to automate the specification of malicious behavior

The approach The presented approach works in three steps 1.Collect execution traces from malware and benign programs 2.Construct the corresponding dependence graphs 3.Compute specification of malicious behavior as difference of dependence graphs Note that in this approach mining is done on the execution traces –In the paper we discussed earlier, mining was done on the source code

How to represent behavior? They identify some requirements for representation of behaviors: 1.A specification must not contain independent operations 2.A specification must relate the dependent operations 3.A specification should capture only security relevant operations To meet these requirements they focus only on system calls and represent malicious behavior as a dependence graph of system calls This representation satisfies their requirements –Independent calls will not be connected in this representation –Dependent calls will be connected –Only the system calls will be tracked since they correspond to the security relevant operations

How to represent the behavior? The behavior is represented as a special type of dependence graph Since they are interested in system security, they decide to model execution behavior as a sequence of system calls Each node of the dependence graph they construct corresponds to a system call The edges of the dependence graph corresponds to constraints that represent the dependences between two system calls –Such as argument1 for call1 is equal to the argument 2 of call2

More on dependence graphs The dependence graphs they construct are directed acyclic graphs Each node corresponds to a system call –They define a simple type system for the arguments of the system calls Edges represent dependencies which are characterized as logic formulas –A logic system that allows constraints with modular and bit-vector arithmetic, arrays, and existential and universal quantifiers is sufficient

Comparing Benign Programs and Malware The presented approach first constructs the dependence graphs for the execution traces of the benign program and the malicious programs Then they construct the minimal contrast subgraph of a malware dependence graph and the benign dependence graph –The smallest subgraph of the first graph that does not appear in the second

Empirical evaluation Thee presented approach is applied to 16 well-known malware examples For these 16 examples, the algorithm successfully discovers the same behavioral features as those independently provided by human experts