# Abstraction-Based Malware Analysis Using Rewriting and Model Checking

10 Sep 2012-Vol. 7459, pp 806-823

TL;DR: This work uses a rewriting-based abstraction mechanism, producing abstracted forms of program traces, independent of the program implementation, which allows it to handle similar behaviors in a generic way and thus to be robust with respect to variants.

Abstract: We propose a formal approach for the detection of high-level malware behaviors. Our technique uses a rewriting-based abstraction mechanism, producing abstracted forms of program traces, independent of the program implementation. It then allows us to handle similar behaviors in a generic way and thus to be robust with respect to variants. These behaviors, defined as combinations of patterns given in a signature, are detected by model-checking on the high-level representation of the program. We work on unbounded sets of traces, which makes our technique useful not only for dynamic analysis, considering one trace at a time, but also for static analysis, considering a set of traces inferred from a control flow graph. Abstracting traces with rewriting systems on first order terms with variables allows us in particular to model dataflow and to detect information leak.

Topics: Malware analysis (59%), Rewriting (55%), Control flow graph (53%), Model checking (52%), Abstraction (linguistics) (52%)

HAL Id: hal-00762252

https://hal.inria.fr/hal-00762252

Submitted on 10 Dec 2012

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of sci-

entic research documents, whether they are pub-

lished or not. The documents may come from

teaching and research institutions in France or

abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diusion de documents

scientiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

publics ou privés.

Abstraction-based Malware Analysis Using Rewriting

and Model Checking

Philippe Beaucamps, Isabelle Gnaedig, Jean-Yves Marion

To cite this version:

Philippe Beaucamps, Isabelle Gnaedig, Jean-Yves Marion. Abstraction-based Malware Analysis Using

Rewriting and Model Checking. ESORICS - 17th European Symposium on Research in Computer

Security - 2012, Sep 2012, Pisa, Italy. pp.806-823, �10.1007/978-3-642-33167-1�. �hal-00762252�

Abstraction-based Malware Analysis Using

Rewriting and Model Checking

Philippe Beaucamps

1

, Isabelle Gnaedig

2

, Jean-Yves Marion

1

1

Universit´e de Lorraine, LORIA, UMR 7503, Vandoeuvre-l`es-Nancy, F-54506, France

2

Inria, Villers-l`es-Nancy, F-54600, France

{Philippe.Beaucamps,Isabelle.Gnaedig,Jean-Yves.Marion}@loria.fr

Abstract. We propose a formal approach for the detection of high-level

malware behaviors. Our technique uses a rewriting-based abstraction

mechanism, producing abstracted forms of program traces, independent

of the program implementation. It then allows us to handle similar be-

haviors in a generic way and thus to be robust with respect to variants.

These behaviors, deﬁned as combinations of patterns given in a signa-

ture, are detected by model-checking on the high-level representation of

the program. We work o n unbounded sets of traces, which makes our

technique useful not only for dynamic analysis, considering one trace at

a time, but also for static analysis, considering a set of traces inferred

from a control ﬂow graph. Abstrac ting traces with rewriting systems on

ﬁrst order terms with variables allows us in particular to model dataﬂow

and to detect information leak.

Keywords: Malware, behavioral detection, behavior abstraction, trace,

term rewriting, model checking, ﬁrst order temporal logic, ﬁnite state

automaton, formal language.

1 Introduction

Behavior analysis was introduced by Cohen’s seminal work [11] to detect mal-

ware and in particular unknown malware. In general, a behavior is described by

a sequence of system calls and recognition uses the formalism of ﬁnite state au-

tomata [22, 26, 24, 6]. New approaches have been proposed recently. In [18, 27],

malicious behaviors ar e speciﬁed by temporal logic formulas with parameters

and detection is carried out by model-checking. However, th ese approaches are

tightly dependent on the way malicious actions are realized: using any oth er

system facility to realize an action allows a malware to go undetected. This has

motivated yet another approach where a malicious behavior is speciﬁed as a

combination of high-level actions, in order to be independent from the way these

actions are realized and to only consider their eﬀect on a system. In [23] and

in [3], a captured execution trace is transformed into a higher-level represen-

tation capturing its semantic m eaning, i.e., the trace is ﬁrst abstracted before

being compared to a malicious behavior. In [17], the authors propose to use

attribute automata, at the price of an exponential time complexity detection.

These dynamic abstraction-based approaches, though they can detect unknown

viruses whose execution traces exhibit known malicious behaviors, only deal with

a single execution trace.

In this paper, we propose a formal approach for high-level behavior analysis,

with the following features. Underpinned by language theory, term rewriting and

ﬁrst-order temporal logic, it allows us to determine whether a program exhibits

a high-level behavior. Detection is achieved in two steps. First, traces of the pro-

gram are abstracted in order to reveal the sequences of high-level functionalities

they realize. Then, abstracted traces are compared with the behavior formula,

using usual model-checking techniques. Functionalities have parameters repre-

senting the manipulated data, so our formalism is adapted to the protection

against generic threats like the leak of sensitive information.

Our goal here is not to provide a ready-made software to detect behaviors, but

to propose a formal framewok emphasizing fundamental detection mechanisms,

which are independent of implementation-based solutions.

Our approach has two main characteristics. First, we work on an unbounded

set of traces representing the behavior of a program, in order to consider a more

complete representation of the program than with a single trace. To deal with

the inﬁnity of the set of traces, we restrict to regular sets an d safely approximate

the set of abstract traces, so that we detect in linear time whether a program

exhibits a given behavior. Second, we work on abstract forms of traces, in or-

der to only keep the essence of the functions performed by the program, to be

independent of their possible implementations and to be generic with respect

to behavior mutations. Behavior components are abstracted in program traces,

by identifying known functionalities and marking them by inserting abstract

functionality symbols.

By working on sets of tr aces, which may consist of a single trace as well

as of an unbounded numb er of traces, our approach may be used not only for

classical, dynamic behavior analysis, but also for static behavior analysis i.e.,

behavior analysis in a static analysis setting.

Static behavior analysis by abstraction is more challenging than its dynamic

counterpart because, precisely, this approach needs to abstract a program behav-

ior potentially representing an inﬁnite set of execution traces. The construction

of an exhaustive representation of a program behavior is an intractable prob-

lem in general: in particular, a program ﬂow may not be easily followed due to

indirect jumps, and a program may use complex code protection, for instance

by dynamically modifying its code or by using obfuscation. Self modiﬁcation is

usually tackled by emulating the program long enough to deactivate most code

protections. Indirect jumps and obfuscation are usually handled by abstract in-

terpretation [25, 19] or symbolic execution [7].

Static behavior analysis has many advantages and applications. First, it al-

lows us to analyze the behavior of a program in a more exhaustive way, as it

analyzes the unbounded set of the program execution traces, or an approxima-

tion of it. Second, static behavior analysis can complement classical, dynamic,

behavior analysis with an analysis of the future behavior, to prevent damages

when some critical point is reached in an execution.

An interesting application of static behavior analysis is the audit of pro-

grams in high-level technologies, like mobile applications, browser extensions,

web page scripts, .NET or Java programs. Auditing these programs is complex

and mostly manual, resulting in highly publicized infections [2, 1]. In this con-

text, static analysis can provide an appropriate help, because it is usually easier

than for usual programs, especially when additionally enforcing a security pol-

icy (e.g. p rohibiting self-modiﬁcation [28]) or when enforcing strict development

guidelines (e.g. for iPhone applications).

To our knowledge, the use of behavior abstraction on top of static behavior

analysis has not been investigated so far. As our detection mechanism relies on

satisfaction of temporal logic formulas, it is akin to model checking [21], for which

there already exist numerous frameworks and tools [16, 14, 8]. Th e speciﬁcity of

our approach, however, is that, rather than being applied on the set of program

traces, veriﬁcation is applied on the set of abstract forms of these traces, which is

not computable in general. Accordingly, we identify a property of practical high-

level behaviors allowing us to approximate this set, in a sound and complete way

with respect to detection, and then to apply classical veriﬁcation techniques.

Our abstraction framework can be used in two scenarios:

– Detection of given behaviors: signatures of given high-level behaviors are ex-

pressed in terms of abstract functionalities. Given some program, we then

assess whether one of its execution traces exhibits a s equence of known func-

tionalities, in a way speciﬁc to one of the given behaviors. This can be applied

to detection of suspicious behaviors. Although detection of such suspicious

behaviors may not suﬃce to label a program as malicious, it can be used to

supplement existing detection techniques with additional decision criteria.

– Analysis of programs: abstraction provides a simple and high-level represen-

tation of a program behavior, which is more suitable than the original traces

for manual analysis, or for analysis of behavior similarity with known be-

haviors, etc. For instance, it could be used to detect not necessarily harmful

behaviors, in order to get a basic understanding of the program and to fur-

ther investigate if deemed necessary. It could also be used to automatically

discover sequences of high-level functionalities and their dataﬂow dependen-

cies, exhibited by a program.

Previous work. In [4], we already proposed to abstract program sets of traces

with respect to behavior patterns, for detection and analysis. We tested our

approach on samples of malicious programs collected using a honeypot

3

and

identiﬁed using Kaspersky Antivirus. These samples belonged to known malware

families, like Allaple, Virut, Agent, R bot, Afcore and Mimail. Most of them were

successfully matched to our malware database.

3

The honeypot of the Loria’s High Security Lab: http://lhs.loria.fr

But patterns were deﬁned by string rewriting systems, which did not allow

the actions composing a trace to have parameters, precluding dataﬂow analysis.

Moreover, abstraction rules replaced identiﬁed patterns by abstraction symbols

in the original trace, precluding a further detection of patterns interleaved with

the rewritten ones.

The formalism proposed in this paper addresses both issues: ﬁrst, we handle

interleaved patterns by keeping the identiﬁed patterns when abstracting them.

Second, we extend the rewriting framework to express data constraints on action

parameters by using term rewriting systems. An important consequence is that,

unlike in [4], using the dataﬂow, we can detect information leaks in order to

prevent unauthorized disclosure or modiﬁcations of information.

2 Background

Term Algebras. Let S = {T race, Action, Data} be a set of sorts, F = F

t

∪ F

a

∪F

d

be a ﬁnite S-sorted signature, where F

t

, F

a

, F

d

are mutually distinct and:

– F

t

= {ǫ, ·} is the set of the trace constructors, where ǫ :→ T race denotes

the empty trace, . has proﬁle Data T race → T race;

– F

a

is a set of function symbols or constants, with proﬁle Data

n

→ Action,

n ∈ N, describing actions;

– F

d

is a set of data constructors, with proﬁle → Data or Data

n

→ Data,

n ∈ N.

Let N

∗

+

be the set of ﬁnite strings of positive natural numbers, called positions.

The empty string is denoted by λ, and u ≤ v means that u is preﬁx of v. Let X

be a set of S-sorted variables. A S-sorted term over (F, X) is a partial function

t : N

∗

+

→ F ∪ X, such that the domain of deﬁnition of t, denoted by Pos(t),

is ﬁnite and satisﬁes, for w ∈ N

∗

+

and i ∈ N: (1) wi ∈ Pos(t) ⇒ w ∈ Pos(t),

(2) w ∈ Pos(t) ⇒ t(w) ∈ F ∪ X. Pos(t) is called the set of positions of t. We

denote by T (F, X) (resp. T (F)) the set of S-sorted terms over ( F, X) (resp. the

set of ﬁnite ground terms over F). For any sort s ∈ S, and any of the above sets

of terms T we denote by T

s

the restriction of T to terms of sort s and by X

s

the subset of variables of X of sort s. For a term t with p ∈ Pos(t), we denote

by t|

p

the subterm of t at position p. We denote by t[t

′

]

p

the term obtained by

replacing by t

′

the subterm at position p in t. We use the abbreviated notation

x for variables x

1

, . . . , x

n

. So x ∈ X stands for x

1

, . . . , x

n

∈ X, and if f ∈ F is

a symbol of arity n ∈ N, we denote by f (

x) the term f (x

1

, . . . , x

n

).

The elements of T

Trace

(F) are called traces, the elements of T

Action

(F) are

called actions. We distinguish the sort Action f rom the sort Trace but, for a

sake of readability, we may denote by a the trace · (a, ǫ), for some action a.

Similarly, we use the · symbol with inﬁx notation and right associativity, and

ǫ is understood when the context is unambiguous. For instance, if a, b, c are

actions, a · b · c denotes the trace · (a, · ( b , · (c, ǫ)) ).

We partition F

a

in a set Σ of symbols, denoting concrete program-le vel ac-

tions, and a set Γ , denoting abstract actions identifying abstracted functional-

ities. To construct purely concrete (resp. abstract) terms, we use F

Σ

= F \ Γ

##### Citations

More filters

••

TL;DR: An evaluation of both AutoMal and MaLabel based on medium-scale and large-scale datasets shows AMAL's effectiveness in accurately characterizing, classifying, and grouping malware samples, and several benchmarks, cost estimates and measurements highlight the merits of AMAL.

Abstract: This paper introduces AMAL, an automated and behavior-based malware analysis and labeling system that addresses shortcomings of the existing systems. AMAL consists of two sub-systems, AutoMal and MaLabel. AutoMal provides tools to collect low granularity behavioral artifacts that characterize malware usage of the file system, memory, network, and registry, and does that by running malware samples in virtualized environments. On the other hand, MaLabel uses those artifacts to create representative features, use them for building classifiers trained by manually vetted training samples, and use those classifiers to classify malware samples into families similar in behavior. AutoMal also enables unsupervised learning, by implementing multiple clustering algorithms for samples grouping. An evaluation of both AutoMal and MaLabel based on medium-scale (4000 samples) and large-scale datasets (more than 115,000 samples)—collected and analyzed by AutoMal over 13 months—shows AMAL's effectiveness in accurately characterizing, classifying, and grouping malware samples. MaLabel achieves a precision of 99.5% and recall of 99.6% for certain families' classification, and more than 98% of precision and recall for unsupervised clustering. Several benchmarks, cost estimates and measurements highlight the merits of AMAL.

143 citations

### Cites background from "Abstraction-Based Malware Analysis ..."

...In the same direction, several static filters and tools are proposed in the literature to speed up the detection of similar malware samples [31, 9, 23, 60, 39, 44, 61, 41, 17, 27, 36, 48, 49]....

[...]

••

TL;DR: This paper presents a detailed review on malware detection approaches and recent detection methods which use these approaches, and the pros and cons of each detection approach, and methods that are used in these approaches.

Abstract: According to the recent studies, malicious software (malware) is increasing at an alarming rate, and some malware can hide in the system by using different obfuscation techniques. In order to protect computer systems and the Internet from the malware, the malware needs to be detected before it affects a large number of systems. Recently, there have been made several studies on malware detection approaches. However, the detection of malware still remains problematic. Signature-based and heuristic-based detection approaches are fast and efficient to detect known malware, but especially signature-based detection approach has failed to detect unknown malware. On the other hand, behavior-based, model checking-based, and cloud-based approaches perform well for unknown and complicated malware; and deep learning-based, mobile devices-based, and IoT-based approaches also emerge to detect some portion of known and unknown malware. However, no approach can detect all malware in the wild. This shows that to build an effective method to detect malware is a very challenging task, and there is a huge gap for new studies and methods. This paper presents a detailed review on malware detection approaches and recent detection methods which use these approaches. Paper goal is to help researchers to have a general idea of the malware detection approaches, pros and cons of each detection approach, and methods that are used in these approaches.

56 citations

### Cites background from "Abstraction-Based Malware Analysis ..."

...represented rewriting and model checking which capture high-level malware behaviors when detecting malware [89]....

[...]

••

16 Mar 2013

TL;DR: This work shows that several malware specifications could be expressed in a more precise manner using LTL instead of CTL, and reduces the malware detection problem to SLTPL model-checking for PDSs.

Abstract: Nowadays, malware has become a critical security threat. Traditional anti-viruses such as signature-based techniques and code emulation become insufficient and easy to get around. Thus, it is important to have efficient and robust malware detectors. In [20,19], CTL model-checking for PushDown Systems (PDSs) was shown to be a robust technique for malware detection. However, the approach of [20,19] lacks precision and runs out of memory in several cases. In this work, we show that several malware specifications could be expressed in a more precise manner using LTL instead of CTL. Moreover, LTL can express malicious behaviors that cannot be expressed in CTL. Thus, since LTL model-checking for PDSs is polynomial in the size of PDSs while CTL model-checking for PDSs is exponential, we propose to use LTL model-checking for PDSs for malware detection. Our approach consists of: (1) Modeling the binary program as a PDS. This allows to track the program's stack (needed for malware detection). (2) Introducing a new logic (SLTPL) to specify the malicious behaviors. SLTPL is an extension of LTL with variables, quantifiers, and predicates over the stack. (3) Reducing the malware detection problem to SLTPL model-checking for PDSs. We reduce this model checking problem to the emptiness problem of Symbolic Buchi PDSs. We implemented our techniques in a tool, and we applied it to detect several viruses. Our results are encouraging.

33 citations

### Cites methods from "Abstraction-Based Malware Analysis ..."

...FO-LTL was used for malware detection in [3]....

[...]

••

18 Aug 2013

TL;DR: PoMMaDe was able to detect several malwares that could not be detected by well-known anti-viruses such as Avira, Avast, Kaspersky, McAfee, AVG, BitDefender, Eset Nod32, F-Secure, Norton, Panda, Trend Micro and Qihoo 360.

Abstract: We present PoMMaDe, a Pushd own Model-checking based M alware D etector. In PoMMaDe, a binary program is modeled as a pushdown system (PDS) which allows to track the stack of the program, and malicious behaviors are specified in SCTPL or SLTPL, where SCTPL (resp. SLTPL) is an extension of CTL (resp. LTL) with variables, quantifiers, and predicates over the stack (needed for malware specification). The malware detection problem is reduced to SCTPL/SLTPL model-checking for PDSs. PoMMaDe allows us to detect 600 real malwares, 200 new malwares generated by two malware generators NGVCK and VCL32, and prove benign programs are benign. In particular, PoMMaDe was able to detect several malwares that could not be detected by well-known anti-viruses such as Avira, Avast, Kaspersky, McAfee, AVG, BitDefender, Eset Nod32, F-Secure, Norton, Panda, Trend Micro and Qihoo 360.

26 citations

### Cites background from "Abstraction-Based Malware Analysis ..."

...F.3.1 [Theory of Computation]: Specifying and Verifying and Reasoning about Programs—Malware Detection...

[...]

••

TL;DR: This paper conducts a survey on malware behavior description and analysis considering three aspects: malware behavior described, behavior analysis methods, and visualization techniques.

Abstract: Behavior-based malware analysis is an important technique for automatically analyzing and detecting malware, and it has received considerable attention from both academic and industrial communities. By considering how malware behaves, we can tackle the malware obfuscation problem, which cannot be processed by traditional static analysis approaches, and we can also derive the as-built behavior specifications and cover the entire behavior space of the malware samples. Although there have been several works focusing on malware behavior analysis, such research is far from mature, and no overviews have been put forward to date to investigate current developments and challenges. In this paper, we conduct a survey on malware behavior description and analysis considering three aspects: malware behavior description, behavior analysis methods, and visualization techniques. First, existing behavior data types and emerging techniques for malware behavior description are explored, especially the goals, principles, characteristics, and classifications of behavior analysis techniques proposed in the existing approaches. Second, the inadequacies and challenges in malware behavior analysis are summarized from different perspectives. Finally, several possible directions are discussed for future research.

20 citations

##### References

More filters

••

29 Mar 2004

TL;DR: This work introduces a temporal logic of calls and returns (CaRet) for specification and algorithmic verification of correctness requirements of structured programs and presents a tableau construction that reduces the model checking problem to the emptiness problem for a Buchi pushdown system.

Abstract: Model checking of linear temporal logic (LTL) specifications with respect to pushdown systems has been shown to be a useful tool for analysis of programs with potentially recursive procedures. LTL, however, can specify only regular properties, and properties such as correctness of procedures with respect to pre and post conditions, that require matching of calls and returns, are not regular. We introduce a temporal logic of calls and returns (CaRet) for specification and algorithmic verification of correctness requirements of structured programs. The formulas of CaRet are interpreted over sequences of propositional valuations tagged with special symbols call and ret. Besides the standard global temporal modalities, CaRet admits the abstract-next operator that allows a path to jump from a call to the matching return. This operator can be used to specify a variety of non-regular properties such as partial and total correctness of program blocks with respect to pre and post conditions. The abstract versions of the other temporal modalities can be used to specify regular properties of local paths within a procedure that skip over calls to other procedures. CaRet also admits the caller modality that jumps to the most recent pending call, and such caller modalities allow specification of a variety of security properties that involve inspection of the call-stack. Even though verifying context-free properties of pushdown systems is undecidable, we show that model checking CaRet formulas against a pushdown model is decidable. We present a tableau construction that reduces our model checking problem to the emptiness problem for a Buchi pushdown system. The complexity of model checking CaRet formulas is the same as that of checking LTL formulas, namely, polynomial in the model and singly exponential in the size of the specification.

3,507 citations

•

01 May 2011Abstract: The SPIN Model Checker is used for both teaching software verification techniques, and for validating large scale applications. The growing number of users has created a need for a more comprehensive user guide and a standard reference manual that describes the most recent version of the tool. This book fills that need. SPIN is used in over 40 countries. The offical SPIN web site, spinroot.com receives between 2500 and 3000 hits per day. It has been estimated that up to three-quarters of the $400 billion spent annually to hire programmers in the United States is ultimately spent on debugging

2,530 citations

•

01 Jan 1997

TL;DR: The goal of this book is to provide a textbook which presents the basics ofTree automata and several variants of tree automata which have been devised for applications in the aforementioned domains.

Abstract: CONTENTS 7 Acknowledgments Many people gave substantial suggestions to improve the contents of this book. These are, in alphabetic order, Introduction During the past few years, several of us have been asked many times about references on finite tree automata. On one hand, this is the witness of the liveness of this field. On the other hand, it was difficult to answer. Besides several excellent survey chapters on more specific topics, there is only one monograph devoted to tree automata by Gécseg and Steinby. Unfortunately, it is now impossible to find a copy of it and a lot of work has been done on tree automata since the publication of this book. Actually using tree automata has proved to be a powerful approach to simplify and extend previously known results, and also to find new results. For instance recent works use tree automata for application in abstract interpretation using set constraints, rewriting, automated theorem proving and program verification, databases and XML schema languages. Tree automata have been designed a long time ago in the context of circuit verification. Many famous researchers contributed to this school which was headed by A. Church in the late 50's and the early 60's: B. Trakhtenbrot, Many new ideas came out of this program. For instance the connections between automata and logic. Tree automata also appeared first in this framework, following the work of Doner, Thatcher and Wright. In the 70's many new results were established concerning tree automata, which lose a bit their connections with the applications and were studied for their own. In particular, a problem was the very high complexity of decision procedures for the monadic second order logic. Applications of tree automata to program verification revived in the 80's, after the relative failure of automated deduction in this field. It is possible to verify temporal logic formulas (which are particular Monadic Second Order Formulas) on simpler (small) programs. Automata, and in particular tree automata, also appeared as an approximation of programs on which fully automated tools can be used. New results were obtained connecting properties of programs or type systems or rewrite systems with automata. Our goal is to fill in the existing gap and to provide a textbook which presents the basics of tree automata and several variants of tree automata which have been devised for applications in the aforementioned domains. We shall discuss only finite tree automata, and the …

1,467 citations

### "Abstraction-Based Malware Analysis ..." refers background in this paper

...Tree automata and tree transducers are defined as usual [12]....

[...]

••

11 Jan 2004Abstract: Given a finite-state abstraction of a sequential program with potentially recursive procedures and input from the environment, we wish to check statically whether there are input sequences that can drive the system into “bad/good” executions. Pushdown games have been used in recent years for such analyses and there is by now a very rich literature on the subject. (See, e.g., [BS92,Tho95,Wal96,BEM97,Cac02a,CDT02].)

1,144 citations

•

TL;DR: Given a finite-state abstraction of a sequential program with potentially recursive procedures and input from the environment, whether there are input sequences that can drive the system into “bad/good” executions is checked.

Abstract: Given a finite-state abstraction of a sequential program with potentially recursive procedures and input from the environment, we wish to check statically whether there are input sequences that can drive the system into bad/good executions. Pushdown games have been used in recent years for such analyses and there is by now a very rich literature on the subject. (See, e.g., [BS92,Tho95,Wal96,BEM97,Cac02a,CDT02].) In this paper we use recursive game graphs to model such interprocedural control flow in an open system. These models are intimately related to pushdown systems and pushdown games , but more directly capture the control flow graphs of recursive programs ([AEY01,BGR01,ATM03b]). We describe alternative algorithms for the well-studied problems of determining both reachability and Buchi winning strategies in such games. Our algorithms are based on solutions to second-order data flow equations, generalizing the Datalog rules used in [AEY01] for analysis of recursive state machines. This offers what we feel is a conceptually simpler view of these well-studied problems and provides another example of the close links between the techniques used in program analysis and those of model checking. There are also some technical advantages to the equational approach. Like the approach of Cachat [Cac02a], our solution avoids the necessarily exponential-space blow-up incurred by Walukiewicz's algorithms for pushdown games. However, unlike [Cac02a], our approach does not rely on a representation of the space of winning configurations of a pushdown graph by (alternating) automata. Only minimal sets of exits that can be forced need to be maintained, and this provides the potential for greater space efficiency. In a sense, our algorithms can be viewed as an automaton-free version of the algorithms of [Cac02a].

1,038 citations