d i g i t a l i n v e s t i g a t i o n 4 S ( 2 0 0 7 ) S 1 1 4 S 1 2 5

available at www.sciencedirect.com

journal homepage: www.elsevier.com/locate/diin

Forensic memory analysis: From stack and code to

execution history5

Ali Reza Arasteh*, Mourad Debbabi

Computer Security Laboratory, Concordia Institute for Information Systems Engineering, Concordia University, Montreal, Quebec, Canada

abstract

Keywords: Forensics memory analysis has recently gained great attention in cyber forensics commu-
Cyber forensics nity. However, most of the proposals have focused on the extraction of important kernel
Physical memory data structures such as executive objects from the memory. In this paper, we propose a for-
Stack mal approach to analyze the stack memory of process threads to discover a partial execu-
Thread tion history of the process. Our approach uses a process logic to model the extracted
Process logic properties from the stack and then verify these properties against models generated
from the program assembly code. The main focus of the paper is on Windows thread stack
analysis though the same idea is applicable to other operating systems.
ª 2007 DFRWS. Published by Elsevier Ltd. All rights reserved.

1. Motivations and background such sources is the most pertinent and definitive evidence
which should be analyzed during the initial phases of investi-
Nowadays, more and more cyber attacks are affecting corpo- gation. In this paper, we propose a new technique in memory
rate and government networks and sometimes even the IT analysis and present the system that has been developed to
systems underlying the critical infrastructure. These attacks realize the application of this technique. The proposed tech-
raise major concerns from the law enforcement standpoint. nique would help forensics analysts to determine what a pro-
Owing to the borderless nature of cyber attacks, many crimi- cess has done during the incident by recovering the chain of
nals/offenders have been able to walk away due to the lack function calls it has made during its execution. The technique
of supporting evidence to convict them. In this context, cyber consists of the following phases:
forensics plays a major role by providing scientifically proven
methods to gather, process, interpret, and use digital evidence  Parsing the internal memory structures.
to bring a conclusive description of cyber crime activities. In  Retrieving the process assembly code and stack from the
the commercial software market flooded by security products, memory.
the development of forensics IT solutions for law enforcement  Constructing the CFG from the executable code.
has been limited. Though outstanding results have been  Modeling the program execution by transforming the CFGs
achieved for forensically sound evidence gathering, little has to local automata and combining the local automata models
been done on the analysis of the acquired evidence. This is into a Push Down System (PDS).
particularly true for volatile evidence sources such as physical  Modeling the stack residues properties using process logic.
memory and cache which is mainly due to the volatile and un-  Extracting all the possible execution paths by correlating
stable nature of data which is residing on these media. How- the stack residues properties and the program execution
ever, if not damaged, the information that is acquired from model.

5
The research reported in this paper is the result of a fruitful collaboration with Bell Canada under the PROMPT Quebec research part-
nership program.
* Corresponding author.
E-mail addresses: [email protected] (A.R. Arasteh), [email protected] (M. Debbabi).
1742-2876/$  see front matter ª 2007 DFRWS. Published by Elsevier Ltd. All rights reserved.
doi:10.1016/j.diin.2007.06.010
 d i g i t a l i n v e s t i g a t i o n 4 S ( 2 0 0 7 ) S 1 1 4 S 1 2 5 S115

In this paper, for the sake of illustration, we focus on operating system by following the unbroken links between
Windows operating system. However, the same approach is data structures in the memory. The work in Walters and Pet-
applicable to any operating system that applies stacking mech- roni presents an extensible framework (FATKit), which pro-
anisms to handle function calls. The paper is organized as fol- vides the analyst with the ability to automatically derive
lows. In Section 2, the related work on forensic analysis and digital object definitions from C source code and extract the
physical memory analysis, though limited, is discussed. In Sec- underlying objects from memory. Walters and Petroni (2007)
tion 3, a summary of our approach is presented and Section 4 present an approach for extracting in-memory cryptographic
details different aspects of our approach by introducing the keying material from disk encryption applications.
problem, and then detailing the solution. Section 5 gives a gen- Schuster (2006) proposes an approach to define signatures
eral overview of the pertinent kernel data structures and Win- for executive object structures in the memory and recover the
dows memory layout. Section 6 summarizes our discussion by hidden and lost structures by scanning the memory looking
providing the conclusion and future research directions. for predefined signatures. However, defining a signature that
uniquely identifies most of the data structures is not achiev-
able except for a small set of kernel structures. B. Carrier
2. Related work and J. Grand in Kornblum (2007) discuss a strategy for robust
address translation by incorporating invalid pages and paging
In spite of the limited research result available on forensic file to improve the completeness of the analysis.
analysis, there are some important proposals that we detail In this paper, instead of relying on the signatures of
hereafter. The state of the art on cyber forensic analysis could the structures, we try to determine some of the actions that a
be categorized as follows: baseline analysis, root cause process has performed during its course of execution and by
analysis, common vulnerability analysis, timeline analysis, correlating these actions with each other and the process
semantic integrity check analysis and memory analysis. source code we will be able to extract a partial execution
Baseline analysis, proposed in Monroe and Bailey (2003), history of the process.
uses an automated tool that checks for the differences be-
tween a baseline of the safe state of the system and the state
during the incident. An approach to post-incident root cause 3. Approach
analysis of digital incidents through the separation of the in-
formation systems into different security domains and mod- In this section, we lay out the principles underlying our ap-
eling the transactions between these domains is proposed in proach to the forensic analysis of stack leftovers. What makes
Stephenson (2003). this approach possible is the way the stack operates in the
The common vulnerability analysis (Tenable Network course of program execution. The stack mechanism is used
Security), involves searching through a database of common in most of the prevalent operating systems to make structured
vulnerabilities and investigating the case according to the re- programming possible. For each function call made by a pro-
lated past and known vulnerabilities. The timeline analysis cess, a stack frame is created and stored on the stack. The
approach (Hosmer, 1998) consists of analyzing logs, and stack frame contains the parameters passed to the function,
scheduling information to develop a timeline of the events the return address, the previous value of the EBP register
that led to the incident. The semantic integrity checking ap- and the local variables of the function. These function call
proach (Stallard and Levitt, 2003) uses a decision engine that traces enclose the history of what a process has done during
is endowed with a tree to detect semantic incongruities. The its course of execution.
decision tree reflects pre-determined invariant relationships After a function returns, the stack pointer is moved down
between redundant digital objects. to point to the previous stack. However, returned function
Gladyshev and Patel (2004) propose a formalization of dig- stack frame still resides in the memory until another call is
ital evidence and event reconstruction based on finite state made by the process, and the stack grows up enough to over-
machines. Other research on formalized forensic analysis in- write the frame. The depth of the stack at each point of the ex-
cludes the formalization of event time binding in digital inves- ecution depends on the number of nested function calls that
tigation (Gladyshev and Patel, 2005; Leigland and Krings, 2004), are made by the process as well as the length of each stack
which proposes an approach to constructing formalized fo- frame. Due to the fact that the depth of the stack has arbitrary
rensic procedures. The absence of a satisfactory and general values during the execution, a large number of previously
methodology for forensic log analysis has resulted in ad hoc called function stack frames stay on top of the stack un-
analysis techniques such as log analysis (Peikari and Chuva- touched or partially overwritten. Moreover, current software
kin, 2004) and operating system-specific analysis (Kruse and engineering best practices encourage the implementation of
Heiser, 2002). a service through long chain of function calls with each com-
The DFRWS memory forensics challenge (DFRWS, 2005) is ponent serving some part of the requested service. This fact
considered as one of the initiatives for the research on mem- intuitively enforces our doctrine.
ory analysis. The challenge led to the development of two The correlation of the stack with the program source re-
memory analysis tools: Memparser (Betz, 2005) and Kntlist veals the execution history of the program in terms of func-
(Garner) each capable of traversing the link list of process tion call chains. We have developed modeling techniques,
structures kept by the operating system to extract information and the system that makes this approach possible. As shown
about a running process. Burdach presents an approach to re- in Fig. 1, the physical image acquired from the system under
trieve process and file information from the memory of Unix analysis is parsed to retrieve the process executable code
S116 d i g i t a l i n v e s t i g a t i o n 4 S ( 2 0 0 7 ) S 1 1 4 S 1 2 5

Stack
Parse Parse
Executable Image Stack traces

Disassemble

Control Flow Program

ASM code execution Model
Diagrams Check
model

All possible
execution paths

Fig. 1  Our approach. The program model is verified against stack residues ADM model.

and thread stacks. The stack frames are extracted by analyz-

ing the thread stacks. The extracted executable is analyzed 4. Modeling the process and the stack traces
to produce the control flow graph of each function and all
the resulting CFGs are combined to form an abstract model In this section, we detail our approach. The approach consists
of the program execution. The stack frames and their interre- of five phases. First, we generate the CFG of all functions of
lations are modeled using the ADM process logic. The created the program. Second, the CFGs are transformed into finite
model is verified against the generated program models using state machines. Third, the finite state machines are combined
the tableau based proof system introduced in Debbabi et al. to form a PDS system. The resulting PDS models the program
(2003). The next section discusses the details involved in this execution in terms of function calls and returns made by
process. the program. Fourth, we model the stack residues as a
Some of the advantages of this technique include: process logic property using ADM process logic (Debbabi
et al., 2003). Fifth the resulting stack property is verified
 The analysis is performed on the extracted assembly code of against the execution traces which can be generated by
the process from the memory and there is no need for the the PDS model of the program. The verification in this
external provision of the source code or executable. This step is done based on the tableau based proof system
feature overcomes the anti-forensics that hide the execut- introduced for ADM logic in Debbabi et al. (2003). In the
able in the filesystem by hooking operating system APIs. following sections, we elaborate on each phase. As an
 The technique integrates the formal analytical power of example, consider the program shown in Fig. 2. We use this
process logic and program models to retrieve the execution program to clarify each phase. For simplicity, we chose a pro-
history of the process. This feature bestows the precision re- gram written in the C language. However, it is important to
quired in most jurisdiction systems from the digital note that since our approach only deals with function calls
investigation. and returns, exactly the same procedure is applicable to the
 As stated before, the result of the analysis could reveal im- assembly code.
portant fact about what a process has done rather than
what is currently existing in the memory. This is of para- 4.1. Control flow graph
mount importance to forensics investigation since the final
goal of the forensics science is to discover what has been A control flow graph (CFG) is a structure that characterizes
done during the incident. possible execution paths in a program. Vertices of the graph
 The application of process logic instead of other modeling contain one or more instructions of the program that execute
approaches such as state machines and PDAs to model the sequentially. Edges in the graph show how control flow trans-
stack properties provides for higher performance in the fers between blocks.
analysis. The stack residues are naturally constraints on Let f be a function in a program P. The control flow graph
the execution history of the process. This is while, the state for f is denoted by Gf ¼ CVf, EfD where Vf is the set of vertices
machine based modeling approaches are most effective and Ef 4 Vf  Vf is the set of edges. A vertex in Gf is a basic
when modeling the behavior of a whole system rather block.
than the properties of the system. Using process logic favors Each v ˛ Vf contains a sequential list of instructions in f sat-
the analysis by providing a means to model the constraints isfying the following properties: there is no control flow trans-
(in our case stack constraints) rather than developing a com- fer into the middle of a basic block nor a transfer out of the
plete system. middle of a basic block. In defining basic blocks, notice that
 d i g i t a l i n v e s t i g a t i o n 4 S ( 2 0 0 7 ) S 1 1 4 S 1 2 5 S117

The first step of our approach is the generation of a control

flow graph of each function called in the program. As an ex-
ample, the control flow graph of function op of the sample
program is shown in Fig. 3.
Having the CFG of a function, we generate the local autom-
ata model of the CFG as discussed in Giffin (2006). The local
automata model of a CFG is a finite state machine whose
states represent nodes of the CFG and its transitions are de-
fined based on the control flows among different nodes of
the CFG. Below is the formal definition of the local automata
model.
Suppose that F is the set of functions in program P, C is the
set of function call sites in P, and q(c) denotes the target func-
tion of call site c. The local automata model of function f with
control flow graph of Gf ¼ CVf, EfD is defined as follows:
Let a 9 v indicate that vertex v ˛ Vf contains call site a. The
local model for f is Af ¼ CQf, Sf, df, qf, FfD where:

 Qf ¼ Vf.
 Sf ¼ Cf W {e}.
 Ff ¼ Cf where Cf 4 C.
 qf ˛ Vf is the CFG entry state.
 Ff ¼ {v ˛ Vfjv is a CFG exit state}.
 Function call transition: df ( p, a) ¼ q if a 9 p, a ˛ Cf, and
Cp, qD ˛ Ef.
 e-transition: d( p, e) ¼ q if Cp, qD ˛ Ef and ca ˛ Cf::(a 9 p)

Fig. 2  Sample program to analyze.

the call to a function is considered as a transfer of control out

of the basic block and therefore, each basic block at most has
one function call instruction. An edge Cvj, vkD ˛ Ef if there exists
a possible control flow from vj to vk. Fig. 3  The control flow graph of op.
S118 d i g i t a l i n v e s t i g a t i o n 4 S ( 2 0 0 7 ) S 1 1 4 S 1 2 5

Please notice that we have changed the above model from contains the concept of the function call site rather than the
the original version in Giffin (2006) by removing the system function name.
call transitions. This is due to the fact that, firstly since we Until now, we have modeled the execution of the program
are analyzing the kernel stack as well as the user land stack as a set of local state machines each representing the execu-
we do not need to restrict our analysis only to the user land tion of a function in the program. However, in order to analyze
system calls. Secondly, depending on the extent of the analy- the execution of a program as a whole, we have to combine
sis, a stack trace analysis could expand to only the functions the local state machine models into a global model. The
inside the program, the system calls, the library calls or even resulting model should encompass all the possible control
the low level kernel function calls. Therefore, we have intro- flows among the basic blocks of the program, while preserving
duced the concept of the end function calls which are a set the inter-procedural control flows. We have developed a mod-
of function names that are defined by the analyst to limit eling approach using Push Down System (PDS) that accurately
the depth of the analysis. The CFG of end function calls has models the execution of the program in terms of function calls
only one state which is both an entry and an exit state. Intui- and returns made by the program. The model maintains the
tively, the local automata model of a CFG is a finite state ma- inter-procedural execution flows.
chine whose states represent the nodes of the CFG and edges A PDS is a triple P ¼ (Q, G, s) where Q is the final set of
are either the name of a function called from the originating control locations, G is the finite set of stack alphabets and
node, or e. s 4 (Q  G)  (Q  G*) is a finite set of transition rules. The
As explained in Giffin (2006), the e-reduction algorithm is program execution in terms of the chain of function calls
performed on the local models to remove the e transitions. and returns made by the program is modeled using a
This will increase the performance of the system since the e PDS. We combine the local automata models of individual
edges are always traversed without consuming any symbol functions to form the PDS model of the whole program as
from the input. As an example, Fig. 4 depicts the local autom- follows:
ata model of function op. Notice that in Fig. 4, we have Again suppose that F is the set of functions in program P,
included the line number in the transition names to differen- C is the set of function call sites in P, q(c) denotes the target
tiate among different calls to the same function. For the same function of call site c. The combination of the local models
reason, the definition of the local automata model of a CFG of the functions of a program is defined as the PDS P ¼ (Q, G, s)
where:

 Q ¼ WQf for all f ˛ F.

 G ¼ C is the set of stack variables.
 Function call transition: s( p, e) ¼ (q, r) if df ˛ F, c ˛ C such
that df( p, c) ¼ r, q ¼ qq(c) where qq(c) is the entry state of the
local automata model of q(c).
 Function return transition: s( p, t) ¼ (q, e) if df ˛ F, r ˛ Q such
that df(r, c) ¼ q, p ˛ Fq(c) where Fq(c) is the set of final states of
the local automata model of function q(c).

As an example, Fig. 5 shows the resulting PDS model of the

program in Fig. 2. For clarity, in the diagram, the stack opera-
tions are represented as labels of edges. An edge labeled as
a call site represents the push operation and an edge labeled
as a bared call site represents the pop operation. Notice that
in our analysis we have considered the scanf and printf func-
tions as end functions. However, a more detailed analysis
could involve modeling the function calls inside these
functions.

4.2. Modeling the stack

The stack has a partial execution history of the program. How-

ever, based on the function call model of the program, the
stack remnant could be interpreted in several different
ways. A set of rules could be derived from the function call
implementation using stacking mechanism as follows:

 If stack frame b is on top of stack frame c, then either c has

called b or b has been called before c.
 The function call history should generate exactly the same
stack trace and should not overwrite any of the currently
Fig. 4  The local automata model of op. existing stack frames.
 d i g i t a l i n v e s t i g a t i o n 4 S ( 2 0 0 7 ) S 1 1 4 S 1 2 5 S119

Fig. 5  The PDS model of the program.

To model these properties for a stack trace, we use the 4.4. Logic syntax
ADM logic.
Let X be a formula variable, then the set of logic formulae is
4.3. ADM logic obtained by the grammar given below:
 
FT ¼ Xj:Fj p1 Ip2 FjF1 ^F2 jnX$F
ADM (Debbabi et al., 2003) is a dynamic, linear, modal and
trace based logic that has been developed for modeling The symbols : and ^ represent negation and conjunction,
and verification of security protocols. Through its compact respectively, while p1 I p2 is a modal operator indexed by
and formal syntax and expressive semantic and due to it being the two patterns p1 and p2. The formula nX$F is a recursive for-
a trace based logic rather than a state based process logic, one mula; the greatest fixed point operator n binds all free occur-
can specify a plethora of properties on the traces generated by rences of X in F. There is a syntactic restriction on the body
the system. The syntax of the logic is based on patterns that of nX$F stipulating that any occurrence of X in F must occur
are sequences of actions and pattern variables. A pattern is under the scope of an even number of negations. It is also as-
defined by the following grammar: sumed that the set of pattern variables in p2 is included in the
set of pattern variables in p1 (no new variables appearing in
pda$pjx$pje
p2). For instance [x I x$y]nX$X is not a formula since {x,
where e stands for the empty pattern, a is an action and x is y} ? {x}.
a pattern variable. Actions themselves may contain variables. From now on, L denotes the set of formulae of the logic and
In the sequel, the set of action variables is denoted by V a , the V is the set of formula variables (disjoint form V a and V p ).
set of pattern variables is defined by V p , the set of message Furthermore, for convenience, we use the following standard
variables is represented by V m , the set of session identifier var- abbreviations:
iables is V ses and the set of step identifier variables is referred tthnX$X
by V stp . Here is an example of a pattern containing message ff hmX$X  
variables, session identifier variables and pattern variables: Cp1 Ip2 DFh: p1 Ip2 :F
mX$Fh:nX$:F½:X=X
p ¼ xp $ðxa $i creditðB; M; xm ÞÞ$yp
F1 nF2 h:ð:F1 ^:F2 Þ
Intuitively, a pattern is an abstraction of a trace, where F1 /F2 h:F1 nF2
F1 4F2 hF1 /F2 ^F2 /F1
some actions or some attributes of an action are replaced by
pattern and action variables, respectively. They are the basic where F[G/X] represents the simultaneous replacement of
elements used to specify formulae in the logic. all free occurrences of X in F by G.
S120 d i g i t a l i n v e s t i g a t i o n 4 S ( 2 0 0 7 ) S 1 1 4 S 1 2 5

4.4.1. Denotational semantics the part p2 allows us to modify the trace (delete some actions,
Suppose that Sub denotes the set of all possible substitutions substitute some actions by others, add some actions) in such
s such that: a way the remainder of the formula (F) will be verified on
    the modified version of the trace described by p2. Notice that
s˛ V p /T +½V m /M+½V a /A+½V ses /Ises + V stp /Istp
the restriction on the used patterns (var( p2) 4 var( p1)) en-
where V p is the set of pattern variables, V m is the set of mes- sures that if p1s ¼ t, then p2s is a ground trace, that is, it does
sage variables, V a is the set of action variables, V ses is the set not contain any variables.
of session identifier variables, V stp is the set of step identifier
variables, M is the set of messages, Ises is the set of session 4.4.2. Logical modeling
identifiers, Istp is the set of step identifiers and finally, T is A stack frame contains the address from which the program
the set of valid traces. The operation B denotes function execution should continue after the function is returned.
composition. Based on this address, except for dynamic function calls (using
Env also denotes the set of all possible environments in function pointers), both the callee and the caller and the exact
½V/2T . Furthermore, we use e[X 1 U] to denote the environ- address of the call site in the code are identifiable. Therefore,
ment e0 defined as follows: each stack frame in our trace represents a unique call site
and since the PDS model also captures program flows based
e0ðYÞ ¼ eðYÞ if YsX
e0ðXÞ ¼ U on the call site instead of the function name, each stack
frame can be associated with a transition. The inclusion of
The semantics of formulae is given by the function: the call site in modeling is due to the fact that a function could
;
E F c : L  T  Sub  Env/2T call another function in several different call sites. Accord-
ingly, each stack frame in our trace is modeled as a triple
defined inductively on the structures of formulae as shown in
(a, b, c) which represents function a being called by function
Table 1, where tY is the set of traces inductively defined as
b at call site c. Also the alphabets of the Dyke model are anno-
follows:
tated by the call site as (a, c) showing the call to function a at
call site c.
(i) t˛tY
We define a/b to represent a calling b and a < b with the
(ii) t1 $a$t2 ˛tY 0t1 $t2 ˛tY
meaning of a happened before b. To capture the stated proper-
ties, we need to be able to model the following logical
Informally tY contains all subtraces that could be extracted
statements:
from t by eliminating some actions from the beginning, from
the middle and/or from the end of t. For instance, if t ¼ a$b$c,
 If the stack frame C ¼ (c, callc) is before frame B ¼ (b, callb)
then tY ¼ {e, a, b, c, a$b, a$c, b$c, a$b$c}. The notation tY is intro-
then the following logical statement is true:
duced to simplify the presentation of the denotational seman-
tics. Intuitively, given a trace t, the semantics of a formula will ððC < BÞ^ðC/BÞÞnðB < CÞ^:ðB/CÞÞ
be all the traces in tY respecting the conditions specified by
this formula.  Moreover, none of the stack frames currently existing on
Environments are used to give a semantics to the formula X the stack should have been overwritten meaning that for
and to deal with recursive formulae. Substitutions are internal each c ˛ (the set of stack frames) the depth of the stack after
parameters used to give a semantics to the formula [p1 I p2]F. calling the function representing c do not reach the depth
Given an environment e and a substitution s, we say that of c.
a trace t satisfies F if:
t;s To formally model the above statements, we need to for-
t˛EFFe
malize the statement of b happening before c and b calling c.
Intuitively, the trace t satisfies the formula [p1 I p2]F if for These two properties could be modeled using ADM as follows:
all substitutions s such that p1s ¼ t, the new trace p2s (the b < c : < x1 $b$x2 $b0 $x3 $c$x4 Ie > tt
modified version of the trace t) satisfies the remaining part
of the formula (F). In this respect, the notation [p1 I p2] has b/c : nX < x1 $b$c$x2 Ie > ttn
principally two effects. First, the part p1 allows us to verify if < x3 $b$x4 $y1 $x5 $y01 $x6 $c$x7 Ix3 $b$x4 $x5 $x6 $c$x7 > X:
something has happened somewhere in the trace t. Second,
In order to model the third property, we define the com-
bined execution trace:

Definition. If S is the stack trace and E represent an execution

Table 1  The denotational sementics of the logic path that is accepted by the PDS model of the program, the
t;s combined execution trace is defined as follows: comb(S, E ) ¼ S$j$E
EXFe ¼ eðXÞ
t;s t;s
E:FFe ¼ tY  EFFe
t;s
EF1 ^F2 Fe
t;s
¼ EF1 Fe XEF2 Fe
t;s Essentially, the combined execution trace is the concatena-
t;s p ss0 ;s0 Bs tion of both traces while separating the traces using the j sym-
E½p1 Ip2 FFe ¼ fu˛tY jcs : p1 ss0
0
¼ u0p2 ss 0
˛EFFe 2 g
( bol. The reason that we need to combine both traces is that
t;s f : 2T /2T
EnX$FFe ¼ nf ; where t;s with ADM logic we can only express properties on one single
U1EFFe½X1U
trace.
 d i g i t a l i n v e s t i g a t i o n 4 S ( 2 0 0 7 ) S 1 1 4 S 1 2 5 S121

Using the combined execution trace of a system we can some markers in the trace to mark the call site that we
model the third property defined above concerning the persis- have found for b and in the next iteration, we remove
tence of stack frames as follows: them. Since the context specifying the location of b depends
  on the property we specify, depending on which property
nXCz1 $x1 $$x2 $z01 $x3 Ix3 $allowD nYCz2 $x4 $allowIx4 DY
 we want to describe in the previous step, we put the
nCz03 $x5 Ix5 $allowDY$ ^½z4 $x6 Ix6 $allowX
markers separately. In the following formulae [ and Y rep-
Note that in the above formula, the trace variables starting resent the before and after markers, respectively.
with x are subtraces and the variables starting with z are sin-
if z1 /z2 : Cðz1 ; z2 ; Þ$ðz2 ; ; Þ$x1 $j$x16 $ðz2 ; Þ$x9 I
gle events. In analyzing each stack frame, the above formula
ðz2 ; ; Þ$x1 $j$x16 $[$ðz2 ; Þ$Y$x9 $allowD
adds the same number of allow constants at the end of the
trace as the stack depth of the function frame. For each func-
if z2 Cz1 : Cðz1 ; z2 ; Þ$ðz2 ; ; Þ$x1 $j$x12 $ðz2 ; Þ$x17 I
tion call made after the return of the function representing the
stack frame ðz01 Þ the formula removes one allow from the end ðz2 ; ; Þ$x1 $j$x12 $[$ðz2 ; Þ$Y$x17 $allowD
and for each function return it adds an allow at the end.
This way, the formula does not allow the paths that overwrite Note that the reason we add the allow at the end of the for-
the stack frame being analyzed. mula is that the depth of the next stack frame that will be an-
In order to model the whole stack we add all the properties alyzed in the next iteration is one more than the current stack
specified above in one formula by following the steps de- frame and therefore the maximum length of the function call
scribed below for every two consecutive stack frames starting chain can increase by one. Moreover we have removed the
from the bottom toward the top of the stack (stack limit): first frame from the stack to continue the specification of
the properties for the next two consecutive frames.
1. Find the call and return states corresponding to the As stated before, the markers should be removed from the
currently being analyzed frame: trace in the next iteration. Accordingly we will add the for-
   mula to remove the markers from the trace at the beginning
Cðz1 ; ; cÞ$  $x1 $$x2 $ðz1 ; cÞ$x3 $ z01 ; c $x4 Ix3 D
  0   of the iteration after locating the related call site.
 nZCðz3 ; lÞ$x5 $ z3 ; l $x6 Ix5 $x6 DZnempty$tt
Cðz1 ; ; Þ$ðz2 ; ; Þ$x1 $j$x2 $Y$ðz1 ; Þ$[$x20 I
In the above formula, z1 is the function representing the an- ðz1 ; ; Þ$ðz2 ; ; Þ$x1 $j$x2 $ðz1 ; Þ$x20 D
alyzed frame. The formula first chooses a call and return
statements which appear after z01 and both correspond to To model the whole stack, we combine all the formulae
the same function call site. It proceeds by verifying if the using proper operators (n, ^). However, in order to reduce the
right call and return are chosen by trying to match each complexity of the formula we define several macros to repre-
call with its corresponding return statement and removing sent each step in the algorithm. In defining macros, it is
them from the trace. important to specify the trace and stack variables which are
2. Make sure that the stack frame is not overwritten by the fol- used across several formulae as arguments in the macro.
lowing function calls:
   1. Find the call and return states corresponding to the
Cðz1 ; ; cÞ$  $x1 $$x2 $ðz1 ; cÞ$x3 $ z01 ; c $x4 Ix4 D currently being analyzed frame.
 
 nYCz04 $x7 Ix7 $allowDY$nCz4 $x8 $allowIx8 DY$
      
FindCallCiteða; d; eÞhC a; ; y1 $x1 $d$ a; y1 $e$ a0 ; y1 $x2 IeD
    0  
3. Model the properties. The properties consist of z1 /z2 and  nZC z1 ; y2 $x3 $ z1 ; y2 $x4 Ix3 $x4 DZnempty$tt
ðz2 Cz1 ^:z2 /z1 Þ. Using the previous formulae, we have:
z1 /z2 hnUCðz1 ; z2 ; cÞ$ðz2 ; ; Þ$x1 $j$x2 $ðz1 ; cÞ$ðz2 ; Þ$x9 IeD 2. Make sure that the stack frame is not overwritten by latter

 ttnCðz1 ; z2 ; cÞ$ðz2 ; ; Þ$x1 $$x2 $ðz1 ; cÞ$x10 $ðz3 ; dÞ$x11 function calls.
 0        
 $ z3 ; d $x12 $ðz2 ; ; Þ$x9 Iðz1 ; z2 ; cÞ$ðz2 ; ; Þ$x1 $j$x2 NotOverWritenða; d; eÞhC a; ; y1 $x1 $$d$ a; y1 $e$ a0 ; y1 $x2
  0 
 $ðz1 ; cÞ$x10 $x11 $x12 $ðz2 ; Þ$x9 DU Ix2 D nYC z2 ;  $x3 Ix3 $allowDY$nCðz2 ; Þ$x4 $allow

 Ix4 DY$
z2 Cz1 hCz1 $z2 $x1 $$x12 $z2 $x13 $z02 $x14 $z1 $x15 IeDtt

3. Model the properties.

4. In order to be able to specify interrelationships among two       
a/bhCallða; b; d; eÞhnUC a; b; y1 $ b; ; y2 $x1 $$d$ a; y1
consecutive stack frames, we have to locate each function       
call representing the stack frame in the trace. The first $ b; y2 $eIeDttnCða; b; Þ$ b; ; y2 $x1 $$d$ a; y1 $x2
   0       
function call is located in step one. Therefore it remains $ z1 ; y3 $x3 $ z1 ; y3 $x4 $ b; y2 $eI a; ; y1 $ b; ; y2
    
for the second stack frame (b). The call site location for $x1 $$d$ a; y1 $x2 $x3 $x4 $ b; y2 $eDU:
b should be preserved for the specification of properties
among the next two consecutive frames (b, c). This is     
while the variable substitutions do not propagate through b < ahBeforeða; b; e; f ÞhCða; ; Þ$ b; ; y2 $x1 $$f $ b; y2
the iterations in the fix point formulae. Hence we will put $x2 $ða; Þ$e$ða0 ; Þ$x3 IeDtt:
S122 d i g i t a l i n v e s t i g a t i o n 4 S ( 2 0 0 7 ) S 1 1 4 S 1 2 5

4. Mark call site locations.

FastCallEntry Kernel service

  
if a/b : MarkIfCallða; b; eÞhCða; b; Þ$ b; z1 ; y1 $x1 $$x2
   Old EBP
$ðb; Þ$eI b; z1 ; y2 $x1 $$x2 $[$b$Y$e$allowD

kiFastSystemCallRet
Ret into FastCallEntry
   …
if b < a : MarkIfBeforeða; b; f ÞhCða; ; Þ$ b; z1 ; y1 $x1 $$f
      
$ b; y1 $x2 I b; z1 ; y1 $x1 $$f $[$ b; y1 $Y$x2 $allowD Old EBP Old EBP
Ret into Ntdll Service Ret into FastCallEntryRet
5. Unmark call site locations.
       Local Vars
Unmarkða; gÞhC a; z1 ; y1 $x1 $$g$Y$ a; y1 $[$x2 I a; z1 ; y1

Ntdll service
   Old EBP
$x1 $$g$ a; y1 $x2 D
Ret
Arguments …
Using the defined formulae, the whole stack specification
could be modeled as follows:
Previous Frame
nX$Unmarkða; dÞðFindCallCiteða; d; eÞ^NotOverWriteða; d; eÞ
^ððCallða; b; d; f Þ^MarkIfCallða; b; f ÞX$ÞnðBeforeða; b; gÞ
^MarkIfBeforeða; b; gÞX$ÞÞÞ Fig. 6  Windows thread stacks during the execution of
a kernel service.

5. Windows architecture and memory layout

uses the service descriptor table that is located at the address
In this section, we summarize the stacking mechanism used of KeServiceDescriptorTable symbol. This table contains the
in Windows. Knowing the functionality of Windows function address of each service and the number of arguments that
call mechanism, the reader will gain a better understanding of should be passed to the function inside two arrays of the
the importance of the stack analysis in a digital forensics stack same length. A call to ntdll.dll functions loads a service num-
investigation. Windows operating system executes in two ber, which is an index into the arrays kept by the service
modes: user mode and kernel mode. Components that exe- descriptor table, and executes the sysenter command (Butler
cute in the user mode are system support processes, service and Hoglund, 2005). This command changes the execution
processes, user applications and environment subsystem mode from user land to the kernel land and calls kiFastSystem-
server processes. CallEntry. This function locates the service address and jumps
Under Windows, user applications do not call the native to the beginning of it. Fig. 6 shows the threads stack during the
Windows operating system services directly; all the calls execution of a kernel service.
from user applications are redirected through a chain of sub- On returning from a kernel service, sysexit command is
system Dynamic-Link Library (DLL) calls to the appropriate in- called. This command switches the execution mode from ker-
ternal Windows system service calls. The kernel mode nel mode to user mode and jumps to the kiFastSystemCallRet
components of Windows include Windows executive, which that simply returns from the user land ntdll.dll function call
provides for the primary operating system services, Windows to the caller.
kernel, device drivers, Hardware Abstraction Layer (HAL), and The provided kernel services can also be called by the
the windowing and graphics system. drivers and other kernel modules. In this case, the calling is
As stated before, user mode processes cannot directly call performed either in the context of a user application thread
services in kernel. The DLL ntdll.dll exports two sets of func- that has requested a service from the driver or in the context
tions that are mostly wrappers for services inside the kernel of system thread if the driver creates its own execution thread
and start with NT or ZW. Except for the functions that are han- by calling PsCreateSystemThread.
dled inside ntdll.dll such as NtCurrentTeb(.), which performs The addresses of the kernel and user stacks are stored in
a purely user land operation, ntdll.dll exported functions are the kernel structures. For each running process, there exists
routed to a function with the same name in the ntoskrnl.exe an _eprocess block in the kernel that contains the head of
(Schreiber, 2001). The routing mechanism that is performed a link list of _kthread structures. Each _kthread structure repre-
by the system consists of switching the CPU from user mode sents one executing thread of the process. Fig. 7 depicts this
to kernel mode, locating the service inside the kernel, copying structure. The structure fields InitialStack, StackLimit and
the function parameters from user land stack to kernel land KernelStack contain the stack base, the largest address that
and executing the related service inside the kernel. the stack can extend to, and the current position of the stack
In Windows, each user application thread has at least two pointer, respectively. The teb field in the _kthread structure
stacks, one in user land and one in kernel land. Accordingly, points to a structure of type _TEB that contains the user land
all functions that are called during the execution of the thread information about a thread including the user stack. The first
have a stack frame either in kernel land stack or the thread’s field in this structure is of type _nt_tib. The fields StackBase and
user land stack depending on the mode they are executed un- StackLimit in this structure contain the stack base and the
der. In order to locate a service inside the kernel, Windows largest address the stack can extend to, respectively.
 d i g i t a l i n v e s t i g a t i o n 4 S ( 2 0 0 7 ) S 1 1 4 S 1 2 5 S123

Fig. 7  The _kthread structure contains the address of

the stack and the address of the top of the stack.

As stated before, our approach can work on assembly code.

Moreover, the system we have developed is capable of extract-
ing executable code from the memory eliminating the need
for supplying the program executable based on the following Fig. 8  _segment Structure and extraction of executable
technique. Files in Windows are mapped to the memory in content.
two different ways: cached files and executables. The cached
files are managed by Windows cache manager using struc-
tures of type _VACB. The executable files in the memory
are mapped using the prototype PTE (Page Table Entry). The  As it is shown in Fig. 6, the OLD_EBP field on the stack
SectionObject field in _eprocess structure points to an object of holds the address of the previous frame OLD_EBP. In
type section. This object is represented by _section_object struc- this way, stack frames are chained together and the
ture. For process executables, the segment field in this struc- stack parser follows this chain to correctly identify each
ture points to a structure of type _segment (although windbg stack frame. However, some compilers tend to use the EBP
describe it as _segment_object). The _segment structure and pointer within the function as a general purpose register.
the process for extracting the first page of an executable are While this can optimize register utilization, it makes it
shown in Fig. 8. The PrototypePte field in this structure points impossible to trace back the stack by following the EBP
to the beginning of the prototype page table for the process. chain.
This table is essentially a page table. Each entry contains the  A stack frame can be identified by looking for return ad-
page frame number (physical page) of the physical memory dresses that point to right after a call instruction. In this
that the corresponding page (virtual page) is mapped to. technique the stack will be traversed word by word testing
The executable code can be extracted by following each of which address is pointing to an instruction after a call
these entries and copying the content of the pointed page instruction.
frame.
Using these two techniques, we are able to retrieve the
addresses of call instructions as well as the arguments
passed to the function. On the other hand, based on the
6. Implementation and testing technique discussed in the previous section, the parser
extracts the executables from the memory. In order to
The stack analyzer has been developed in a previously imple- disassemble the executable and generate the PDS model,
mented Windows memory forensics environment. The envi- we use IDAPro (The IDA pro, 2007). We have developed a
ronment enables the investigator to add analysis plugins, plugin in IDAPro that generates the CFGs, local automata
introduce new data structures and view the result of parsing and PDS model of the program using the SDK provided by
a chunk of memory based on the introduced structures. The IDAPro.
stack analyzer parses the stack based on two stack tracing Having the addresses (call sites) on the stack and the PDS
techniques: model, the analyzer proceeds to verify the query specified
S124 d i g i t a l i n v e s t i g a t i o n 4 S ( 2 0 0 7 ) S 1 1 4 S 1 2 5

Fig. 9  Extracted stack traces.

before to find the possible execution path. Please note that the (inc,58)->(inc,51)->(inc,51)->(op,53)->(printf,35)
verification proceeds by first generating a possible execution ->(printf,35)’->(scanf,37)->(scanf,37)’->(a,38)->
path using the PDS model and then verifying it against the (g,17)->(g,17)’->(e,18)->(op,13)->(a,38)->(h,21)
properties specified by the query. Which ever path that satisfy ->(h,21)’->(a,38)’->(d,41)->(h,30)->(h,30)’->
the query, could have been taken by the process at the time of (d,41)’->(op,13)’->(e,18)’->(a,38)’->(c,44)->
the incident. (b,26)->(b,26)’->(c,44)’->(op,53)’->(inc,51)’->
As a sample scenario, we have analyzed the program in (inc,51)’->(inc,58)’
Fig. 2. The program is executed with inputs of 1 and 2, in order.
For simplicity, we limited our analysis to the functions called
directly by the program. In this case, since the program has
only two noncritical calls to the functions that are defined 7. Conclusion
outside the program, we would not benefit from analyzing
the kernel stack or other DLLs function calls. This is while In this paper, we presented a new forensic analysis technique
in real situations, a great deal of information can be extrac- by analyzing the thread stacks. The information that is
ted by going deep inside the kernel stack and correlate the retrieved using this technique can reveal what has been
stack traces with program and operating system code. For done by the thread. A great deal of information can be
demonstration purpose, the program also creates a windbg acquired by correlating this information with the source
(Microsoft, 2007) script file that could be executed in the code or the assembly code using different static code analysis
debugger to show the name of the function calls on the stack. approaches. Moreover, the stack trace and stack residue
The script file is essentially a list ln commands each having retrieved by our approach could be considered as a log
a function call address, that was found on the stack, as their from system activities and could be correlated with other
argument. The result of executing this script in a debug sources such as network logs, operating system logs, etc. It
session of windbg attached to our sample program is shown is important to notice that due to the fact that each possible
in Fig. 9. execution path is generated before it is verified, our approach
Submitting the logical statement created in the previous is susceptible to infinite loops. However, the loop detection
section, the system is able to completely generate the exe- techniques could be applied to reduce the effect of infinite
cuted function chain as below: loops.
 d i g i t a l i n v e s t i g a t i o n 4 S ( 2 0 0 7 ) S 1 1 4 S 1 2 5 S125

The stack analyzer.

references Stallard T, Levitt K. Automated analysis for digital forensic

science: semantic integrity checking. In: 19th annual
computer security applications conference, Las Vegas, NV,
USA, December 2003.
Burdach M. Digital forensics of the physical memory.
Stephenson P. Modeling of post-incident root cause analysis. Int
Betz C. MemParser, <http://www.dfrws.org/2005/challenge/
Digit Evid 2003;2(2).
memparser.html>; 2005 [Visited on May 22, 2007].
The IDA pro disassembler and debugger, <http://www.
Butler J, Hoglund G. Rootkits: subverting the Windows kernel.
datarescue.com/ida.htm> [Visited on May 22, 2007].
Addison-Wesley Professional; July 2005.
Tenable Network Security. [Visited on May 22, 2007].
Debugging tools for Windows, <http://www.microsoft.com/whdc/
Walters A, Petroni N. FATKit: a framework for the extraction and
devtools/debugging/default.mspx> [Visited on May 22, 2007].
analysis of digital forensics data from volatile system
Digital Forensic Research Workshop (DFRWS). Memory analysis
memory.
challenge; 2005.
Walters A, Petroni N. Volatools: integrating volatile memory
Debbabi M, Adi K, Mejri M. A new logic for electronic commerce
forensics into the digital investigation process. Black Hat DC
protocols. Int J Theor Comput Sci (TCS) 2003;291(3):22383.
2007; February 2007.
Giffin JT. Model based intrusion detection system design and
evaluation. PhD thesis; 2006.
Ali Reza Arasteh is a M.Sc. student at the Department of Computer
Gladyshev P, Patel A. Finite state machine approach to digital
Science, Concordia University. He holds B.Sc. degree from Amir-
event reconstruction. Digit Investig J 2004;1(2).
kabir University, Tehran, Iran. His main research interests are
Gladyshev P, Patel A. Formalising event time bounding in digital
memory forensics analysis, log analysis and intrusion detection
investigations. Digit Investig J 2005;4(2).
systems.
Garner Jr GM. Kntlist, <http://www.dfrws.org/2005/challenge/
kntlist.html>.
Hosmer C. Time lining computer evidence, <http://www. Mourad Debbabi is a Full Professor and the Associate Director of
wetstonetech.com/f/timelining.pdf>; 1998 [Visited on May 22, the Concordia Institute for Information Systems Engineering at
2007]. Concordia University. He is also a Concordia Research Chair Tier I
Kruse II WG, Heiser JG. Computer forensics: incident response in Information Systems Security. He holds Ph.D. and M.Sc. degrees
essentials. Boston, MA: Addison-Wesley; 2002. in computer science from Paris-XI Orsay University, France. He
Kornblum J. Using every part of the buffalo in Windows memory published several research papers in international journals and
analysis. Digit Investig J January 2007. conferences on computer security, cyber forensics, formal seman-
Leigland R, Krings AW. A formalization of digital forensics. Digit tics, mobile and embedded platforms, Java technology security and
Investig J 2004;3(2). acceleration, cryptographic protocol specification, design and
Monroe K, Bailey D. System base-lining: a forensic perspective, analysis, malicious code detection, programming languages, type
<http://ftimes.sourceforge.net/Files/Papers/baselining.pdf>; theory and specification and verification of safety-critical systems.
2003. In the past, he served as Senior Scientist at the Panasonic Informa-
Peikari C, Chuvakin A. Security warrior. Sebastopol, CA: O’Reilly; tion and Network Technologies Laboratory, Princeton, New Jersey,
2004. USA; Associate Professor at the Computer Science Department of
Schreiber S. Undocumented Windows 2000 secrets: a programmer’s Laval University, Quebec, Canada; Senior Scientist at General Elec-
cookbook. Addison-Wesley Professional; May 2001. tric Corporate Research Center, New York, USA; Research Associ-
Schuster A. Pool allocations as an information source in Windows ate at the Computer Science Department of Stanford University,
memory forensics. In: International conference on IT-incident California, USA; and Permanent Researcher at the Bull Corporate
management & IT-forensics, 2006. Research Center, Paris, France.