Results 1 - 10
of
790
Model Checking Programs
, 2003
"... The majority of work carried out in the formal methods community throughout the last three decades has (for good reasons) been devoted to special languages designed to make it easier to experiment with mechanized formal methods such as theorem provers, proof checkers and model checkers. In this pape ..."
Abstract
-
Cited by 592 (63 self)
- Add to MetaCart
(Show Context)
The majority of work carried out in the formal methods community throughout the last three decades has (for good reasons) been devoted to special languages designed to make it easier to experiment with mechanized formal methods such as theorem provers, proof checkers and model checkers. In this paper we will attempt to give convincing arguments for why we believe it is time for the formal methods community to shift some of its attention towards the analysis of programs written in modern programming languages. In keeping with this philosophy we have developed a verification and testing environment for Java, called Java PathFinder (JPF), which integrates model checking, program analysis and testing. Part of this work has consisted of building a new Java Virtual Machine that interprets Java bytecode. JPF uses state compression to handle big states, and partial order and symmetry reduction, slicing, abstraction, and runtime analysis techniques to reduce the state space. JPF has been applied to a real-time avionics operating system developed at Honeywell, illustrating an intricate error, and to a model of a spacecraft controller, illustrating the combination of abstraction, runtime analysis, and slicing with model checking.
A Taxonomy of Obfuscating Transformations
, 1997
"... It has become more and more common to distribute software in forms that retain most or all of the information present in the original source code. An important example is Java bytecode. Since such codes are easy to decompile, they increase the risk of malicious reverse engineering attacks. In this p ..."
Abstract
-
Cited by 313 (22 self)
- Add to MetaCart
It has become more and more common to distribute software in forms that retain most or all of the information present in the original source code. An important example is Java bytecode. Since such codes are easy to decompile, they increase the risk of malicious reverse engineering attacks. In this paper we review several techniques for technical protection of software secrets. We will argue that automatic code obfuscation is currently the most viable method for preventing reverse engineering. We then describe the design of a code obfuscator, a tool which converts a program into an equivalent one that is more difficult to understand and reverse engineer. The obfuscator is based on the application of code transformations, in many cases similar to those used by compiler optimizers. We describe a large number of such transformations, classify them, and evaluate them with respect to their potency (To what degree is a human reader confused?), resilience (How well are automatic deobfuscati...
Simplifying and isolating failure-inducing input
- IEEE TRANSACTIONS ON SOFTWARE ENGINEERING
, 2002
"... Given some test case, a program fails. Which circumstances of the test case are responsible for the particular failure? The Delta Debugging algorithm generalizes and simplifies the failing test case to a minimal test case that still produces the failure. It also isolates the difference between a pas ..."
Abstract
-
Cited by 294 (11 self)
- Add to MetaCart
(Show Context)
Given some test case, a program fails. Which circumstances of the test case are responsible for the particular failure? The Delta Debugging algorithm generalizes and simplifies the failing test case to a minimal test case that still produces the failure. It also isolates the difference between a passing and a failing test case. In a case study, the Mozilla web browser crashed after 95 user actions. Our prototype implementation automatically simplified the input to three relevant user actions. Likewise, it simplified 896 lines of HTML to the single line that caused the failure. The case study required 139 automated test runs or 35 minutes on a 500 MHz PC.
Isolating Cause-Effect Chains from Computer Programs
, 2002
"... Consider the execution of a failing program as a sequence of program states. Each state induces the following state, up to the failure. Which variables and values of a program state are relevant for the failure? We show how the Delta Debugging algorithm isolates the relevant variables and values by ..."
Abstract
-
Cited by 262 (9 self)
- Add to MetaCart
(Show Context)
Consider the execution of a failing program as a sequence of program states. Each state induces the following state, up to the failure. Which variables and values of a program state are relevant for the failure? We show how the Delta Debugging algorithm isolates the relevant variables and values by systematically narrowing the state difference between a passing run and a failing run---by assessing the outcome of altered executions to determine wether a change in the program state makes a difference in the test outcome. Applying Delta Debugging to multiple states of the program automatically reveals the cause-effect chain of the failure---that is, the variables and values that caused the failure.
Backtracking intrusions
, 2003
"... Analyzing intrusions today is an arduous, largely manual task because system administrators lack the information and tools needed to understand easily the sequence of steps that occurred in an attack. The goal of BackTracker is to identify automatically potential sequences of steps that occurred in ..."
Abstract
-
Cited by 240 (11 self)
- Add to MetaCart
Analyzing intrusions today is an arduous, largely manual task because system administrators lack the information and tools needed to understand easily the sequence of steps that occurred in an attack. The goal of BackTracker is to identify automatically potential sequences of steps that occurred in an intrusion. Starting with a single detection point (e.g., a suspicious file), BackTracker identifies files and processes that could have affected that detection point and displays chains of events in a dependency graph. We use BackTracker to analyze several real attacks against computers that we set up as honeypots. In each case, BackTracker is able to highlight effectively the entry point used to gain access to the system and the sequence of steps from that entry point to the point at which we noticed the intrusion. The logging required to support BackTracker added 9 % overhead in running time and generated 1.2 GB per day of log data for an operating-system intensive workload.
Amorphous Program Slicing
- Software Focus
, 1997
"... Traditional, syntax-preserving program slicing simpli es a program by deleting components (e.g., statements and predicates) that do not aect a computation of interest. Amorphous slicing removes the limitation to component deletion as the only means of simpli cation, while retaining the semantic p ..."
Abstract
-
Cited by 149 (60 self)
- Add to MetaCart
Traditional, syntax-preserving program slicing simpli es a program by deleting components (e.g., statements and predicates) that do not aect a computation of interest. Amorphous slicing removes the limitation to component deletion as the only means of simpli cation, while retaining the semantic property that a slice preserves the selected behaviour of interest from the original program. This leads to slices which are often considerably smaller than their syntax-preserving counterparts.
Chianti: A tool for change impact analysis of java programs
- Conference on Object-Oriented Programming, Systems, Languages, and Applications
, 2004
"... This paper reports on the design and implementation of Chianti, a change impact analysis tool for Java that is implemented in the context of the Eclipse environment. Chianti analyzes two versions of an application and decomposes their difference into a set of atomic changes. Change impact is then re ..."
Abstract
-
Cited by 148 (5 self)
- Add to MetaCart
(Show Context)
This paper reports on the design and implementation of Chianti, a change impact analysis tool for Java that is implemented in the context of the Eclipse environment. Chianti analyzes two versions of an application and decomposes their difference into a set of atomic changes. Change impact is then reported in terms of affected (regression or unit) tests whose execution behavior may have been modified by the applied changes. For each affected test, Chianti also determines a set of affecting changes that were responsible for the test’s modified behavior. This latter step of isolating the changes that induce the failure of one specific test from those changes that only affect other tests can be used as a debugging technique in situations where a test fails unexpectedly after a long editing session. We evaluated Chianti on a year (2002) of CVS data from M. Ernst’s Daikon system, and found that, on average, 52% of Daikon’s unit tests are affected. Furthermore, each affected unit test, on average, is affected by only 3.95 % of the atomic changes. These findings suggest that our change impact analysis is a promising technique for assisting developers with program understanding and debugging.
Program slicing
"... Program slicing is a decomposition technique that elides program components not relevant to a chosen computation, referred to as a slicing criterion. The remaining components form an executable program called a slice that computes a projection of the original program’s semantics. Using examples coup ..."
Abstract
-
Cited by 147 (25 self)
- Add to MetaCart
(Show Context)
Program slicing is a decomposition technique that elides program components not relevant to a chosen computation, referred to as a slicing criterion. The remaining components form an executable program called a slice that computes a projection of the original program’s semantics. Using examples coupled with fundamental principles, a tutorial introduction to program slicing is presented. Then applications of program slicing are surveyed, ranging from its first use as a debugging technique to current applications in property verification using finite state models. Finally, a summary of research challenges for the slicing community is discussed.
A Schema for Interprocedural Modification Side-Effect Analysis With Pointer Aliasing
, 2001
"... The first interprocedural modification side-effects analysis for C (MODC) that obtains better than worst-case precision on programs with general-purpose pointer usage is presented with empirical results. The analysis consists of an algorithm schema corresponding to a family of MODC algorithms with t ..."
Abstract
-
Cited by 139 (12 self)
- Add to MetaCart
The first interprocedural modification side-effects analysis for C (MODC) that obtains better than worst-case precision on programs with general-purpose pointer usage is presented with empirical results. The analysis consists of an algorithm schema corresponding to a family of MODC algorithms with two independent phases: one for determining pointer-induced aliases and a subsequent one for propagating interprocedural side effects. These MODC algorithms are parameterized by the aliasing method used. The empirical results compare the performance of two dissimilar MODC algorithms: MODC(FSAlias) uses a flow-sensitive, calling-context-sensitive interprocedural alias analysis; MODC(FIAlias) uses a flow-insensitive, calling-context-insensitive alias analysis which is much faster, but less accurate. These two algorithms were profiled on 45 programs ranging in size from 250 to 30,000 lines of C code, and the results demonstrate dramatically the possible costprecision trade-offs. This first comparative implementation of MODC analyses offers insight into the differences between flow-/context-sensitive and flow-/context-insensitive analyses. The analysis cost versus precision trade-offs in side-effect information obtained are reported. The results show surprisingly that the precision of flow-sensitive side-effect analysis is not always prohibitive in cost, and that the precision of flow-insensitive analysis is substantially better than worst-case estimates
Designing the Whyline: A debugging interface for asking questions about program behavior
- In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. ACM
"... Debugging is still among the most common and costly of programming activities. One reason is that current debugging tools do not directly support the inquisitive nature of the activity. Interrogative Debugging is a new debugging paradigm in which programmers can ask why did and even why didn’t quest ..."
Abstract
-
Cited by 132 (22 self)
- Add to MetaCart
(Show Context)
Debugging is still among the most common and costly of programming activities. One reason is that current debugging tools do not directly support the inquisitive nature of the activity. Interrogative Debugging is a new debugging paradigm in which programmers can ask why did and even why didn’t questions directly about their program’s runtime failures. The Whyline is a prototype Interrogative Debugging interface for the Alice programming environment that visualizes answers in terms of runtime events directly relevant to a programmer’s question. Comparisons of identical debugging scenarios from user tests with and without the Whyline showed that the Whyline reduced debugging time by nearly a factor of 8, and helped programmers complete 40 % more tasks.
