approaches can be used to defining the same two functions, a hypothesis can be formulated using one technique and tested with another. Overall, these are impractical in real investigations, but are presented below for completeness.
Observation methods use direct observation of an output device to define its state in the inferred history, and are only applicable to output device controllers; they cannot work for internal devices, such as hard disks.
Capabilities techniques employ the primitive system capabilities to formulate and test state and event hypotheses. To formulate a hypothesis, the investigator chooses a possible state or event at random; this is impractical for almost all real systems as the state space is enormous.
Sample data techniques extract samples from observations of similar systems or from previous executions of the system being investigated; the results are metrics on the occurrence of events and states. To build a hypothesis, states and events are chosen based on how likely they are to occur. Testing the hypothesis reveals if there is evidence to support the state or event. Note that this is a conceptual class not used in practice as there are no relevant sample data.
Reconstruction techniques use a known state to formulate and test hypotheses about the event and state that existed immediately prior to the known state. This is not performed in practice, as questions are rarely formulated about primitive events.
Construction methods are the forward-looking techniques that use a known state to formulate and test hypotheses about the next event and state. This is not useful in practice as the typical starting point is an end state; further, any hypothesis about the future state would not be testable.
Complex storage system configuration. Techniques in this category define the complex storage capabilities of the system, and are needed to formulate and test hypotheses about complex states. The techniques define the names of the complex storage types (Dcs), the attribute names for each complex storage type (DATcs), the domain of each attribute (ADOcs), the set of identifiers for the possible instances of each complex storage type (DADcs), the abstraction transformation functions for each complex storage type (ABScs), the materialization transformation functions for each complex storage type (MATcs), and the complex storage types that existed at each time and at each abstraction layer X ∊ L(ccs–X).
Two types of hypotheses are formulated in this category: the first one defines the names of the complex storage types and the states at which they existed; the second defines the attributes, domains, and transformation functions for each complex storage type. As discussed earlier, complex storage locations are program data structures. Consequently, to enumerate the complex storage types in existance at a particular point in time requires the reconstruction of the state of the computer, so that program state could be analyzed.
Identification of existing programs can be accomplished in one of two ways: program identification—by searching for programs on the system to be subsequently analyzed; and data type observation—by inferring the presence of complex storage types that existed based on the data types that are found. This latter technique may give false positives in that a complex type may have been created elsewhere and transferred to the system under investigation.
Three classes of techniques can be used to define the attributes, domains, and transformation functions for each complex storage type: (a) complex storage specification observation, which uses a specification to define a program’s complex storage types; (b) complex storage reverse engineering, which uses design recovery reverse engineering to define complex storage locations; (c) complex storage program analysis, which uses static, or dynamic, code analysis of the programs to identify the instructions creating, or accessing, the complex storage locations and to infer their structure.
It is both impractical and unnecessary to fully enumerate the data structures used by programs; only a set of the most relevant and most frequently used ones are supported by investigative tools, and the identification process is part of the tool development process.
Complex event system configuration. These methods define the capabilities of the complex event system: the names of the programs that existed on the system (Dce), the names of the abstraction layers(L), the symbols for the complex events in each program (DSYce–X), the state change functions for the complex events (DCGce–X), the abstraction transformation functions (ABSce), the materialization transformation functions (MATce), and the set of programs that existed at each time (cce).
Inferences about events are more difficult than those about storage locations because the latter are both abstracted and materialized and tend to be long-lived because of backward compatibility; the former are usually designed from the top-down, and backward compatibility is a much lesser concern.
Three types of hypotheses can be tested in this category: (a) programs existence, including period of their existence; (b) abstraction layers, event symbols, and state change functions for each program; (c) the materialization and abstraction transformation functions between the layers.
With respect to (a), both program identification and data type reconstruction can be used in the forms already described.
For hypotheses in regard to (b), there are two relevant techniques—complex event specification observation and complex event program analysis. The former uses a specification of the program to determine the complex events that it could cause. The latter works directly with the program to observe the events; depending on the depth of the analysis, this could be as simple as running the program under specific circumstances, or it could be a massive reverse engineering effort, if a (near-)complete picture is needed.
The hypotheses in part (c) concern the rules defining the mappings between higher-level and lower-level events. Identifying these rules is an inherently difficult task, and Carrier proposed only one type of technique with very limited applicability—development tool and process analysis. It analyzes the programming tools and development process to determine how complex events are defined.
Complex state and event definition. This category of techniques defines the complex states that existed (hcs) and the complex events that occurred (hce). It includes eight classes of analysis techniques and each has a directional component (Figure 3.3). Two concern individual states and events, two are forward- and backward-based, and four are upward- and downward-based.
Complex state and event system capabilities methods use the capabilities of the complex system to formulate and test state and event hypotheses based on what is possible. The main utility of this approach is that it can show that another hypothesis is impossible because it is outside of the system’s capabilities.
Complex state and event sample data techniques use sample data from observations of similar systems or from previous executions. The results include metrics on the occurrence of events and states and would show which states and events are most likely. This class of techniques is employed in practice in an ad hoc manner; for example, if a desktop computer is part of the investigation, an analyst would have a hypothesis about what type of content might be present.
Complex state and event reconstruction methods use a state to formulate and test hypotheses about the previous complex event and state. This approach is frequently employed, although the objective is rarely to reconstruct the state immediately preceeding a known one, but an earlier one. Common examples include analyzing web browser history, or most recently used records to determine what the user has recently done.
Figure 3.3:
