OctoMap: An Efficient Probabilistic 3D Mapping Framework Based on Octrees Abstract Three-dimensional models provide a volumetric representation of space which is important for a variety of robotic applications including flying robots and robots that are equipped with manipulators. In this paper, we present an open-source framework to generate volumetric 3D environment models. Our mapping approach is based on octrees and uses probabilistic occupancy estimation. It explicitly represents not only occupied space, but also free and unknown areas. Furthermore, we propose an octree map compression method that keeps the 3D models compact. Our framework is available as an open-source C++ library and has already been successfully applied in several robotics projects. We present a series of experimental results carried out with real robots and on publicly available real-world datasets. The results demonstrate that our approach is able to update the representation efficiently and models the data consistently while keeping the memory requirement at a minimum. In this paper, we presented OctoMap, an open source framework for three-dimensional mapping. Our approach uses an efficient data structure based on octrees that enables a compact memory representation and multi-resolution map queries. Using probabilistic occupancy estimation, our approach is able to represent volumetric 3D models that include free and unknown areas. The proposed approach uses a bounded per-volume confidence that allows for a lossless compression scheme and leads to substantially reduced memory usage. We evaluated our approach with various real-world data sets. The results demonstrate that our approach is able to model the environment in an accurate way and, at the same time, minimizes memory requirements.. OctoMap can easily be integrated into robotic systems and has already been successfully applied in a variety of robotic projects. The implementation is available as BSDlicensed C++ source code. Data sets are available online to verify our experimental results and to compare against them. Three-dimensional models of the environment are a key prerequisite for many robotic systems and consequently they have been the subject of research for more than two decades.. A popular approach to modeling environments in 3D is to use a grid of cubic volumes of equal size, called voxels, to discretize the mapped area. Roth-Tabak and Jain (1989) as well as Moravec (1996) presented early works using such a representation. A major drawback of rigid grids is their large memory requirement. The grid map needs to be initialized so that it is at least as big as the bounding box of the mapped area, regardless of the actual distribution of map cells in the volume. In large-scale outdoor scenarios or when there is the need for fine resolutions, memory consumption can become prohibitive. Furthermore, the extent of the mapped area needs to be known beforehand or costly copy operations need to be performed every time the map area is expanded.. A discretization of the environment can be avoided by storing 3D range measurements directly. The occupied space in the environment is then modeled by the 3D point clouds returned by range sensors such as laser range finders or stereo cameras. This point cloud approach has been used in several 3D SLAM systems such as those presented by Cole and Newman (2006) as well as in the SLAM approach of Nüchter et al. (2007) . The drawbacks of this method are that neither free space nor unknown areas are modeled and that sensor noise and dynamic objects cannot be dealt with directly. Thus, point clouds are only suitable for high precision sensors in static environments and when unknown areas do not need to be represented. Furthermore, the memory consumption of this representation increases with the number of measurements which is problematic as there is no upper bound.. If certain assumptions about the mapped area can be made, 2.5D maps are sufficient to model the environment. Typically, a 2D grid is used to store the measured height for each cell. In its most basic form, this results in an elevation map where the map stores exactly one value per cell (Hebert et al., 1989) . One approach in which such maps have been demonstrated to be sufficient is the outdoor terrain navigation method described by Hadsell et al. (2009) . Whenever there is a single surface that the robot uses for navigation, an elevation map is sufficient to model the environment, since overhanging obstacles that are higher than the vehicle, such as trees, bridges or underpasses, can be safely ignored. The strict assumption of a single surface can be relaxed by allowing multiple surfaces per cell (Triebel et al., 2006; Pfaff et al., 2007) , or by using classes of cells which correspond to different types of structures (Gutmann et al., 2008) . A general drawback of most 2.5D maps is that they do not represent the environment in a volumetric way but discretize it in the vertical dimension based on the robot's height. While this is sufficient for path planning and navigation with a fixed robot shape, the map does not represent the actual environment, e.g. for localization.. To overcome this problem, a related approach was proposed by Ryde and Hu (2010) . The approach stores a list of occupied voxels for each cell in a 2D grid. Although this representation is volumetric, it does not differentiate between free and unknown volumes. Dryanovski et al. (2010) store lists of occupied and free voxels for each 2D cell in their Multi-Volume Occupancy Grid approach. In contrast to our approach, however, the map extent needs to be known beforehand, map updates are more computationally involved, and there is no multi-resolution capability. Another potential problem is that subsequent map updates cannot subdivide existing volumes, leading to an incorrect model of the environment. Similarly, Douillard et al. (2010) combine a coarse elevation map for background structures with object voxel maps at a higher resolution. In contrast to our work, this approach focuses on 3D segmentation of single measurements and does not integrate several measurements into a model of the environment.. In robotic mapping, octrees avoid one of the main shortcomings of fixed grid structures: They delay the initialization of map volumes until measurements need to be integrated. In this way, the extent of the mapped environment does not need to be known beforehand and the map only contains volumes that have been measured. If inner nodes of a tree are updated properly, the tree can also be used as a multi-resolution representation since it can be cut at any level to obtain a coarser subdivision. The use of octrees for mapping was originally proposed by Meagher (1982) . Early works mainly focused on modeling a Boolean property such as occupancy (Wilhelms and Van Gelder, 1992) . Payeur et al. (1997) used octrees to adapt occupancy grid mapping from 2D to 3D and thereby introduced a probabilistic way of modeling occupied and free space. A similar approach was used by Fournier et al. (2007) and Pathak et al. (2007) . In contrast to the approach presented in this paper, however, the authors did not explicitly address the issues of map compression or bounded confidence in the map.. An octree-based 3D map representation was also proposed by Fairfield et al. (2007) . Their map structure called Deferred Reference Counting Octree is designed to allow for efficient map updates, especially in the context of particle filter SLAM. To achieve map compactness, a lossy maximum-likelihood compression is performed periodically. Compared to the compression technique used in our approach, this discards the probability information for future updates. Furthermore, the problem of overconfident maps and multi-resolution queries are not addressed.. As a data structure, octrees are applied in a variety of applications, most notably in the area of computer graphics for efficient rendering (Botsch et al., 2002; Surmann et al., 2003; Laine and Karras, 2010) and in the field of photogrammetry to store and address large point clouds (GirardeauMontaut et al., 2005; Elseberg et al., 2011) . Another popular use case is the compression of static point clouds (Schnabel and Klein, 2006) or point cloud streams (Kammerl et al., 2012) . While our framework is general enough to also store raw point clouds, its main purpose is to integrate these point clouds into a memory-efficient, volumetric occupancy map, since point clouds as environment representation in robotics have a number of disadvantages as detailed at the beginning of this section. Yguel et al. (2007b) presented a 3D map based on the Haar wavelet data structure. This representation is also multi-resolution and probabilistic. However, the authors did not evaluate applications to 3D modeling in-depth. In their evaluation, unknown areas are not modeled and only a single simulated 3D dataset is used. Whether this map structure is as memory-efficient as octrees is hard to assess without a publicly available implementation.. Surface representations such as the 3D Normal Distribution Transform (Magnusson et al., 2007) or Surfels (Habbecke and Kobbelt, 2007) were recently used for 3D path planning (Stoyanov et al., 2010) and object modeling (Weise et al., 2009; Krainin et al., 2011) . Similarly, an accurate real-time 3D SLAM system based on a low-cost depth camera and GPU processing was proposed by Newcombe et al. (2011) to reconstruct dense surfaces in indoor scenes. Recently, this work has been extended to work in larger indoor environments (Whelan et al., 2012) . However, surface representations are unable to distinguish between free and unknown space, may require large memory particularly outdoors, and are often based on strong assumptions about the corresponding environment. In mobile manipulation scenarios, for example, being able to differentiate free from unknown space is essential for safe navigation.. Finally, to the best of our knowledge, no open source implementation of a 3D occupancy mapping framework meeting the requirements outlined in the introduction is freely available.

O O O B B B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O B O O O O O O O O O O O


Utilising urban context recognition and machine learning to improve the generalisation of buildings The introduction of automated generalisation procedures in map production systems requires that generalisation systems are capable of processing large amounts of map data in acceptable time and that cartographic quality is similar to traditional map products. With respect to these requirements, we examine two complementary approaches that should improve generalisation systems currently in use by national topographic mapping agencies. Our focus is particularly on self-evaluating systems, taking as an example those systems that build on the multi-agent paradigm. The first approach aims to improve the cartographic quality by utilising cartographic expert knowledge relating to spatial context. More specifically, we introduce expert rules for the selection of generalisation operations based on a classification of buildings into five urban structure types, including inner city, urban, suburban, rural, and industrial and commercial areas. The second approach aims to utilise machine learning techniques to extract heuristics that allow us to reduce the search space and hence the time in which a good cartographical solution is reached. Both approaches are tested individually and in combination for the generalisation of buildings from map scale 1:5000 to the target map scale of 1:25 000. Our experiments show improvements in terms of efficiency and effectiveness. We provide evidence that both approaches complement each other and that a combination of expert and machine learnt rules give better results than the individual approaches. Both approaches are sufficiently general to be applicable to other forms of self-evaluating, constraintbased systems than multi-agent systems, and to other feature classes than buildings. Problems have been identified resulting from difficulties to formalise cartographic quality by means of constraints for the control of the generalisation process. The number of national mapping agencies (NMAs) that introduce automated map generalisation procedures into their map production workflows is steadily increasing (Stoter 2005) . Conventional and automated map generalisation share the same basic objectives, which include fulfilling the intended map purpose and ensuring mapIn order to achieve these objectives for automated map generalisation it is necessary to transfer the cartographic knowledge into a machine understandable form. Armstrong (1991) has identified three types of cartographic knowledge: (a) geometric, (b) procedural and (c) structural knowledge. The geometric knowledge describes information on the size, shape and topology of map objects and can be obtained from measures applied on the objects' geometry. Procedural knowledge describes rules for the selection of appropriate generalisation algorithms in the presence of cartographic conflicts. For instance, if a building is too small to be clearly legible on the reduced scale map (a conflict), then the building may be enlarged (algorithm A) or eliminated (algorithm B). Finally, structural knowledge covers the cartographic knowledge needed to identify which objects and 'structures' are important, for example, in terms of their cultural, economical or geomorphological meaning. Thus, the structural knowledge influences the decision whether the small building of the above example must be preserved (enlarge building) or whether it is unimportant for the map reader (eliminate building).. An analysis of the pertinent literature as well as discussions with map production experts in NMAs that we have conducted revealed that existing automated generalisation systems need to be fine tuned, that is, their knowledge refined, if they should be used (more) successfully in production lines. Hence, a specific focus of current map generalisation research is on the refinement of existing procedural knowledge that is currently applied in self-evaluating cartographic systems. In this article, we particularly consider self-evaluating systems that are used for the production of (static) topographic maps by NMAs (Mackaness et al. 2007 ). As an example for self-evaluating systems, we use systems that build on the multi-agent system (MAS) paradigm. In the context of such generalisation systems, we consider primarily two issues.. First, a high cartographic quality that is comparable to the quality of traditional maps can only be obtained with automated systems that treat every map object according to its context (SSC 2005) . Hence, a topographic map production system should be able to account for spatial and semantic context information in the generalisation process. This requirement is exemplified by a recent call for tender by the Swiss NMA Swisstopo, who demanded the functionality to create and utilise generalisation zones, such as dense versus scattered settlement zones, where every topographic feature (e.g. building or road) is treated differently depending on the zone (or context) that it is located in.. To make the generalisation process context-aware, the structural knowledge needs to be extracted and stored in a process that has been termed data enrichment Plazanet 1996, Neun et al. 2004) . Afterwards the procedural knowledge can be refined with respect to the enriched data and structural knowledge. A contextdependent treatment can then be realised for instance by inclusion of expert rules into the system.. A second problem that has been reported for MAS in cartography is that the generalisation process can be computationally very expensive. This can be attributed on the one hand to the computational complexity of the generalisation task (see Haunert and Wolff 2008) but on the other hand also to the iterative local search approach used for the selection of a generalisation algorithm in a particular map situation (see Section 2). Thus, acquiring and fine-tuning procedural knowledge, that is, rules for the selection of an appropriate generalisation algorithm, or an appropriate sequence of algorithms, should improve the efficiency of such systems.

O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Deterministic parallel random-number generation for dynamic-multithreading platforms Existing concurrency platforms for dynamic multithreading do not provide repeatable parallel random-number generators. This paper proposes that a mechanism called pedigrees be built into the runtime system to enable efficient deterministic parallel randomnumber generation. Experiments with the open-source MIT Cilk runtime system show that the overhead for maintaining pedigrees is negligible. Specifically, on a suite of 10 benchmarks, the relative overhead of Cilk with pedigrees to the original Cilk has a geometric mean of less than 1%.We persuaded Intel to modify its commercial C/C++ compiler, which provides the Cilk Plus concurrency platform, to include pedigrees, and we built a library implementation of a deterministic parallel random-number generator called DOTMIX that compresses the pedigree and then "RC6-mixes" the result. The statistical quality of DOTMIX is comparable to that of the popular Mersenne twister, but somewhat slower than a nondeterministic parallel version of this efficient and high-quality serial random-number generator. The cost of calling DOTMIX depends on the "spawn depth" of the invocation. For a naive Fibonacci calculation with n = 40 that calls DOTMIX in every node of the computation, this "price of determinism" is about a factor of 2.3 in running time over the nondeterministic Mersenne twister, but for more realistic applications with less intense use of random numbers -such as a maximalindependent-set algorithm, a practical samplesort program, and a Monte Carlo discrete-hedging application from QuantLib -the observed "price" was at most 21%, and sometimes much less. Moreover, even if overheads were several times greater, applications using DOTMIX should be amply fast for debugging purposes, which is a major reason for desiring repeatability. Dynamic multithreading, 1 or dthreading, which integrates a runtime scheduler into a concurrency platform, provides a threading model which allows developers to write many deterministic programs without resorting to nondeterministic means. Dthreading concurrency platforms -including MIT Cilk [20] , Cilk++ [34] , Cilk Plus [28] , Fortress [1] , Habenero [2, 12] , Hood [6] , Java Fork/Join Framework [30] , OpenMP 3.0 [40] , Task Parallel Library (TPL) [33] , Threading Building Blocks (TBB) [42] , and X10 [13] -offer a processor-oblivious model of computation, where linguistic extensions to the serial base language expose the logical parallelism within an application without reference to the number of processors on which the application runs. The platform's runtime system schedules and executes the computation on whatever set of worker threads is available at runtime, typically employing a "work-stealing" scheduler [5, 10, 23] , where procedure frames are migrated from worker to worker. Although a dthreading concurrency platform is itself nondeterministic in the way that it schedules a computation, it encapsulates the nondeterminism, providing the developer with a programming abstraction in which deterministic applications can be programmed without concern for the nondeterminism of the underlying scheduler.. A major reason parallel programming is hard is because nondeterminism precludes the repeatability programmers rely on to debug their codes. For example, the popular pthreading model -as exemplified by POSIX threads [27] , Windows API threads [24] , and the threading model of the Java programming language [22] -is well known to produce programs replete with nondeterminism and which are thus difficult to debug. Lee [31] cites the nondeterminism of multithreaded programs as a key reason that programming large-scale parallel applications remains error prone and difficult. Bocchino et al. [7] argue persuasively that multithreaded programs should be deterministic by default. The growing popularity of dthreading concurrency platforms seems due in part to their ability to encapsulate nondeterminism and provide a more deterministic environment for parallel programming and debugging.. Nevertheless, dthreading concurrency platforms fail to encapsulate an important source of nondeterminism for applications that employ (pseudo)random number generators (RNG's). RNG's are useful for randomized algorithms [37] , which provide efficient solutions to a host of combinatorial problems, and are essential for Monte Carlo simulations, which consume a large fraction of computing cycles [35] for applications such as option pricing, molecular modeling, quantitative risk analysis, and computer games.. Unfortunately, typical implementations of RNG's are either nondeterministic or exhibit high overheads when used in dthreaded code. To understand why, we first review conventional serial RNG's and consider how they are traditionally adapted for use in parallel programs. Then we examine the ramifications of this adaptation on dthreaded programs.. A serial RNG operates as a stream. The RNG begins in some initial state S0. The ith request for a random number updates the state Si−1 to a new state Si, and then it returns some function of Si as the ith random number. One can construct a parallel RNG using a serial RNG, but at the cost of introducing nondeterminism. One way that a serial RNG can be used directly in a dthreaded application is as a global RNG where the stream's update function is protected by a lock. This strategy introduces nondeterminism, however, as well as contention on the lock that can adversely affect performance.. A more practical alternative that avoids lock contention is to use worker-local RNG's, i.e., construct a parallel RNG by having each worker thread maintain its own serial RNG for generating random numbers. Unfortunately, this solution fails to eliminate nondeterminism because the underlying nondeterministic scheduler may execute a given call to the RNG on different workers during different runs of the program, even if the sequence of random numbers produced by each worker is deterministic.. Deterministic parallel random-number generators (DPRNG's) exist for pthreading platforms, but they are ineffective for dthreading platforms. For example, SPRNG [35] is an excellent DPRNG which creates independent RNG's via a parameterization process. For a few pthreads that are spawned at the start of a computation and which operate independently, SPRNG can produce the needed RNG for each pthread. For a dthreaded program, however, which may contain millions of strands -serial sequences of executed instructions containing no parallel control -each strand may need its own RNG, and SPRNG cannot cope.. Consider, for example, a program that uses SPRNG to generate a random number at each leaf of the computation of a parallel, exponential-time, recursive Fibonacci calculation fib. Every time fib spawns a recursive subcomputation, a new strand is created, and the program calls SPRNG to produce a new serial RNG stream from the existing serial RNG. The fib program is deterministic, since each strand receives the same sequence of random numbers in every execution. In an implementation of this program, however, we observed two significant problems:. • When computing fib (21) , the program using SPRNG was almost 50,000 times slower than a nondeterministic version that maintains worker-local Mersenne twister [36] RNG's from the GNU Scientific Library [21] . • SPRNG's default RNG only guarantees the independence of 2 19 streams, and computing fib(n) for n > 21 forfeits this guarantee.. Of course, SPRNG was never intended for this kind of use case where many streams are created with only a few random numbers generated from each stream. This example does show, however, the inadequacy of a naive solution to the problem of deterministic parallel random-number generation for dthreading platforms. We conclude by discussing two enhancements for pedigrees and DPRNG's. We also consider how the notion of pedigrees might be extended to work on other concurrency platforms.. The first enhancement addresses the problem of multiple calls to a DPRNG within a strand. The mechanism described in Section 2 involves calling the STRANDBREAK function, which increments the rank whenever a call to the DPRNG is made, thereby ensuring that two successive calls have different pedigrees. An alternative idea is to have the DPRNG store for each worker p an event counter ep that the DPRNG updates manually and uses as an additional pedigree term so that multiple calls to the DPRNG per strand generate different random numbers.. The DPRNG can maintain an event counter for each worker as follows. Suppose that the DPRNG stores for each worker p the last pedigree p read. When worker p calls the DPRNG to generate another random number, causing the DPRNG to read the pedigree, the DPRNG can check whether the current pedigree matches the last pedigree p read. If it matches, then p has called the DPRNG again from the same strand, and so the DPRNG updates ep. If it does not match, then p must be calling the DPRNG from a new strand. Because each strand is executed by exactly one worker, the DPRNG can safely reset ep to a default value in order to generate the next random number.. This event counter scheme improves the composability of DPRNG's in a program, because calls to one DPRNG do not affect calls to another DPRNG in the same program, as they do for the scheme from Section 2. In practice, however, event counters may hurt the performance of a DPRNG. From experiments with the fib benchmark, we found that an event-counter scheme runs approximately 20%-40% slower per function call than the scheme from Section 2, and thus we favored the use of STRANDBREAK for our main results. Nevertheless, more efficient ways to implement an event-counter mechanism may exist, which would enhance composability.. Our second enhancement addresses the problem of "climbing the tree" to access all ranks in the pedigree for each call to the DPRNG, the cost of which is proportional to the spawn depth d. Some compression functions, including Definitions 1 and 3, can be computed incrementally, and thus results can be "memoized" to avoid walking up the entire tree to compress the pedigree. In principle, one could memoize these results in a frame-data cache -a worker-local cache of intermediate results -and then, for some computations, generate random numbers in O(1) time instead of O(d) time. Preliminary experiments with using frame-data caches indicate, however, that in practice, the cost of memoizing the intermediate results in every stack frame outweighs the benefits from memoization, even in an example such as fib, where the spawn depth can be quite large. Hence, we opted not to use framedata caches for DOTMIX. Nevertheless, it is an interesting open question whether another memoization technique, such as selective memoization specified by the programmer, might improve performance for some applications.. We now turn to the question of how to extend the pedigree ideas to "less structured" dthreading concurrency platforms. For some parallel-programming models with less structure than Cilk, it may not be important to worry about DPRNG's at all, because these models do not encapsulate the nondeterminism of the scheduler. Thus, a DPRNG would seem to offer little benefit over a nondeterministic parallel RNG. Nevertheless, some models that support more complex parallel control than the fork-join model of Cilk do admit the writing of deterministic programs, and for these models, the ideas of pedigrees can be adapted.. As an example, Intel Threading Building Blocks [42] supports software pipelining, in which each stage of the pipeline is a forkjoin computation. For this control construct, one could maintain an outer-level pedigree to identify the stage in the pipeline and combine it with a pedigree for the interior fork-join computation within a stage.. Although Cilk programs produce instruction traces corresponding to fork-join graphs, the pedigree idea also seems to extend to general dags, at least in theory. One can define pedigrees on general dags as long as the children (successors) of a node are ordered. The rank of a node x indicates the birth order of x with respect to its siblings. Thus, a given pedigree (sequence of ranks) defines a unique path from the source of the task graph. The complication arises because in a general dag, multiple pedigrees (paths) may lead to the same node. Assuming there exists a deterministic procedure for choosing a particular path as the "canonical" pedigree, one can still base a DPRNG on canonical pedigrees. It remains an open question, however, as to how efficiently one can maintain canonical pedigrees in this more general case, which will depend on the particular parallel-programming model. The problem of generating random numbers deterministically in multithreaded programs has received significant attention. SPRNG [35] is a popular DPRNG for pthreading platforms that works by creating independent RNG's via a parameterization process. Other approaches to parallelizing RNG's exist, such as leapfrogging and splitting. Coddington [14] surveys these alternative schemes and their respective advantages and drawbacks. It may be possible to adapt some of these pthreading RNG schemes to create similar DPRNG's for dthreaded programs.. The concept of deterministically hashing interesting locations in a program execution is not new. The maxIndSet and sampleSort benchmarks we borrowed from [4] used an ad hoc hashing scheme to afford repeatability, a technique we have used technique ourselves in the past and which must have been reinvented numerous times before us. More interesting is the pedigree-like scheme due to Bond and McKinley [8] where they use an LCG strategy similar to LCGMIX to assign deterministic identifiers to calling contexts for the purposes of residual testing, anomaly-based bug detection, and security intrusion detection.. Recently, Salmon et al. [44] independently explored the idea of "counter-based" parallel RNG's, which generate random numbers via independent transformations of counter values. Counter-based RNG's use similar ideas to pedigree-based DPRNG's. Intuitively, the compressed pedigree values generated by DOTMIX and LCG-MIX can be thought of as counter values, and the mixing function corresponds to a particular kind of transformation. Salmon et al. focus on generating high-quality random numbers, exploring several transformations based on both existing cryptographic standards and some new techniques, and show that these transformations lead to RNG's with good statistical properties. Counter-based RNG's do not directly lead to DPRNG's for a dthreaded programs, however, because it can be difficult to generate deterministic counter values. One can, however, apply these transformations to compressed pedigree values and automatically derive additional pedigree-based DPRNG's. To implement the get method of a DPRNG, we use the API in Figure 2 to extract the current pedigree during the call to get, and then we hash the pedigree. The principal remaining difficulty in the DPRNG's implementation is in handling scopes. Figure 6 : A program that generates NSTREAMS identical streams of random numbers. Inside function f, the code in lines 3-4 limits the scope of rand so that it can generate random numbers only within f.. Intuitively, a scope can be represented by a pedigree prefix that should be common to the pedigrees of all strands generating random numbers within the scope. Let y be the instruction corresponding to a call to current_scope(), and let x be a call to get() within the scope J(y). Let J(x) = j1, j2, . . . , j d(x) and J(y) = j for all k < d(y). We now define the scoped pedigree of x with respect to scope J(y) as. To compute a random number for J(x) excluding the scope J(y), we simply perform a DPRNG scheme on the scoped pedigree J J(y) (x). For example, DOTMIX computes µ(cΓ(J J(y) (x))). Furthermore, one can check for scoping errors by verifying that J(y) is indeed the prefix of J(x) via a direct comparison of all the pedigree terms.. Scoped pedigrees allow DPRNG's to optimize the process of reading a pedigree. By hashing scoped pedigrees, a call to the DPRNG need only read a suffix of the pedigree, i.e. the scoped pedigree itself, rather than the entire pedigree. To implement this optimization, each scope may store a pointer to the spawn parent for the deepest rank of the scope, and then the code for reading the pedigree extracts ranks as usual until it observes the spawn parent the scope points to. One problem with this optimization is that a DPRNG may not detect if it is hashing a pedigree outside of its scope. To overcome this problem, DOTMIX supports a separate mode for debugging, in which calls checks their pedigrees termby-term to verify they are within the scope.

O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B I O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Automating Metadata Web Service Deployment for Problem Solving Environments Abstract. XML-based metadata information services are a crucial core service needed by Problem Solving Environments built over emerging service-based, globally-scaled distributed systems, as envisioned by the Open Grid Services Architecture and the Semantic Web. Developing user interfaces and services bindings for manipulating instances of particular schemas is thus extremely important and needs to be made as simple as possible. In this paper we describe procedures for automating the creation of Web Service environments that can be used to simplify the creation and deployment of schema-based metadata services. One of the most important underpinnings of Problem Solving Environments (PSEs) is the management of diverse types of information. Grid computing and distributed Web services are metadata rich: all entities should be described by XML metadata. Metadata must be used to describe the various parts that must be managed by the PSE, such as available applications, service interfaces and their binding points, batch queuing systems, hardware profiles, and so on. Many projects have attempted to define metadata pieces needed to build service grids, and such pieces will be needed as grid service data in the Open Grid Service Architecture [1, 2] . In addition to the service metadata, there is also need to provide organizational metadata descriptors for the services themselves, and we have suggested data models for describing applications [3, 4] and their associated service bindings. We thus anticipate that metadata richness will only increase.. We may place these issues into larger contexts. Autonomic computing (see [5] for a description and [6, 7] for sample academic projects) seeks to define the interaction of components in next generation computing at all scales. In the autonomic computing vision, components mean everything from the physical component parts of individual computers to the service components of globally-scaled service environments. The ideal autonomic system is self-aware, self-monitoring, adaptive, and self-healing, among other characteristics.. Developing standards for Web services for computational grids is a major (and somewhat independent) component of the autonomic computing vision. Web services are somewhat loosely defined, but may be characterized in general as using existing Web technologies and standards (such as HTTP and XML) to build the distributed computing environments. Important Web service standards include the Web Service Description Language (WSDL) [8] and the Simple Object Access Protocol (SOAP) [9] . The Open Grid Service Architecture, developed under the auspices of the Global Grid Forum and primarily led by IBM and the Globus team, seeks to extend the capabilities of Web services in order to support more sophisticated services. The key to this development is the extension of WSDL portTypes to include metadata and service state information.. In a major alternative effort, other groups are using various XML standards of the World Wide Web Consortium define what it terms the Semantic Web [10] . The Semantic Web vision borrows ideas from federated information systems and artificial intelligent, modified and simplified to apply to the much more ambitious problem of intelligent information retrieval and service execution on a global scale. The cornerstones of the Semantic Web are metadata descriptions (RDF) [11] and ontologies that provide semantic meaning.. XML-based information services are the key to both the OGSA and the Semantic Grid. We may go a step further and claim that the there is a general need for many informal, lightweight information management systems for particular schemas. We have developed such a system, described in Refs [12] and [13] , which provides several per-schema implementations: newsgroups, citation and reference managers, training and conference registration systems. All such systems possess the same general capabilities: browsing, search, "push" and "pull" style event delivery options, and access controls on information and publishing. More sophisticated systems that support schema-spanning searches (with the associated meta-ontology research problems [14, 15] ) may be built on top of this practical base.. Given the demonstrable importance and proliferation of XML metadata, it becomes necessary to automate the creation of publication and editing tools for particular schemas. We describe the details of two such systems, which we refer to as "Schema Wizards". The first is designed to simplify the creation of XML wizards for specific schemas. These wizards are in turn used for creating and publishing instances in the XML messaging system described in [13] . The Schema Wizard is thus a wizard for wizards. The second wizard system, a follow -on to the first, is designed to automate metadata-based Web services (such as service data associated with Grid Web services). In both cases, a particular schema is used as the underlying data model, and the wizard generates the user interface (view) and action bindings (control) necessary to create and deploy the new metadata-based service.

O O O O O O B I I O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O B I O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Mining specifications of malicious behavior Malware detectors require a specification of malicious behavior. Typically, these specifications are manually constructed by investigating known malware. We present an automatic technique to overcome this laborious manual process. Our technique derives such a specification by comparing the execution behavior of a known malware against the execution behaviors of a set of benign programs. In other words, we mine the malicious behavior present in a known malware that is not present in a set of benign programs. The output of our algorithm can be used by malware detectors to detect malware variants. Since our algorithm provides a succinct description of malicious behavior present in a malware, it can also be used by security analysts for understanding the malware. We have implemented a prototype based on our algorithm and tested it on several malware programs. Experimental results obtained from our prototype indicate that our algorithm is effective in extracting malicious behaviors that can be used to detect malware variants. Malicious software (malware) is code that achieves the harmful intent of an attacker. Typical examples include viruses, worms, trojans, and spyware. Although the history of malware reaches back more than two decades, the advent of large-scale computer worm epidemics and waves of email viruses have elevated the problem to a major security threat. Recently, this threat has also acquired an economic dimension as attackers benefit financially from compromised machines (e.g., by selling hosts as email relays to spammers).. Historically, detection tools such as virus scanners have performed poorly, particularly when facing previously unknown malware programs or novel variants of existing ones. The fundamental cause is the disconnect between the malware specification used for detection and the actual malware behavior (which is the attacker's goal). Certain malicious behavior desired by an attacker (e.g., virus self replication through mass-mailing) can be realized in many different ways. However, current detectors focus only on the specific characteristics of individual malware instances, e.g., on the presence of particular instruction sequences. Therefore, they fail to detect different manifestations of the same malicious behavior. Attackers are quick to exploit this weakness by using program obfuscation techniques such as polymorphism and metamorphism [19, 22, 25, 29] . Recent research results have highlighted how shortcomings in both network-based and host-based detection techniques can be effectively exploited by attackers to evade detection [6, 14] .. Advanced detection techniques such as semantics-aware malware detection [7, 16] and malicious-code model checking [12] counter the obfuscation techniques of attackers by using higher-level specifications of malicious behavior. Instead of focusing on individual characteristics of particular malware instances, these detectors specify general behavior exhibited by an entire family of malicious code. Examples of such specifications include self-unpacking and selfpropagation via email. The power of these approaches resides in the use of high-level specifications that abstract details specific to a malware instance. Thus, obfuscation transformations, which preserve the behavior of the malware but may change its form, are no longer effective techniques for evading detection. Unfortunately, the high-level specifications of malicious behavior used by these advanced malware detectors are currently manually developed. Creating specifications manually is a time-consuming task that requires expert knowledge, which reduces the appeal and deployment of these new detection techniques. To address this limitation, this paper introduces a technique to automatically derive specifications of malicious behavior from a given malware sample. Such a specification can then be used by a malware detector, allowing for the creation of an end-to-end tool-chain to update malware detectors when a new malware appears. Since our technique provides a succinct description of the malicious intent of a malware, it can also be used by security analysts for malware understanding.. We cast malicious-specification mining as the problem of finding differences between a malware sample and a set of benign programs. This approach supports the requirement that the specification of malicious behavior must capture aspects that are specific to the malware and absent from any benign programs. The software-engineering research community has put a lot of effort in analyzing commonalities and differences between programs and many techniques for clone detection [3, 11, 13, 30] and program differencing [2, 9, 10, 17] have been proposed. The differencing techniques are closest to our goal of mining specifications of malicious behavior, but they fall short because they generally require access to source code and because they produce differences between low-level elements of the program (e.g., individual statements) or between structural elements (e.g., type hierarchy, procedures). Since we do not have the malware source code and since the malware writer controls the structure of the program, mining malicious specifications requires a new approach.. Our mining technique takes into account an adversarial setting in which the malware writer tries to make his software hard to analyze and detect. We define a new graph representation of program behavior and a mining algorithm that constructs a malicious specification. The representation explicitly captures the system calls made by the program and summarizes all other program code, because system calls are the primary interaction with the operating system. Our algorithm infers the system-call graphs from execution traces, then derives a specification by computing the minimal differences between the system-call graphs of malicious and benign programs. This paper makes the following contributions:. • A language for specifying malicious behavior in terms of dependences between system calls (Section 3).. • An algorithm, called MiniMal 1 that mines specifications of malicious behavior from dependence graphs (Section 4).. • An experimental evaluation that shows that specifications extracted MiniMal are qualitatively equivalent to those manually developed by Symantec's expert virus analysts and can be used with a malware detector to identify subsequent malware variants (Section 5). The goal of our specification language is to describe malicious behavior. In general, the behavior of a program can be described as its observable effect on the execution environment. Depending on what is considered the program's environment, behavior can be specified at different levels of granularity.. One approach is to define behavior as the effect of a sequence of instructions on the state of a process. For this 1 MiniMal is a technique for mining minimally mal icious behavior. call R e g C l o s e K e y Figure 1 : Bagle.J code fragment performing registry cleanup, one of its "administrative" tasks.. purpose, the state of a process is defined as the content of the memory address space. The effect on this state are modifications to the contents of the address space. Another approach to specify program behavior is to view the running program as a black-box and only focus on its interaction with the operating system. In this case, a particularly convenient interface to monitor is the set of operating system calls that this process invokes. Every action that involves communication with the process' environment (e.g., accessing the file system, sending a packet over the network, or launching another program) requires the process to make use of an appropriate operating system service. For this work, we choose the second approach and use system calls as the basic building blocks of our specification language. We only consider the actions of the program at the operating system interface, thus making our technique robust to any code-obfuscation techniques employed by malware authors. The end result is a specification of malicious behavior that captures the intent of the malware writer in terms of its effect on the host operating system. Such a specification can then be used to detect the original malware as well as obfuscated variants that exhibit the same system-call footprint.. At a high level, the mining algorithm works in three steps: Algorithm MiniMal We will walk through the application of the mining algorithm on the email worm Bagle.J, the tenth variant in a long line of malware known as the Bagle malware family. According to the Symantec Security Response [24] , Bagle.J exhibits the following high-level functionality:. • It spreads through email, sending copies of itself using a built-in SMTP engine.. • It opens a backdoor on the infected system, allowing the attacker to access and control the victim system remotely.. • It self-propagates through several file-sharing networks (Kazaa and iMesh).. • It performs multiple "administrative" tasks that include. R e g D e l e t e V a l u e A ( 0 x0007FFC4 , " ssate.exe " ) == 0 We introduced a language for specifying malicious behavior and an algorithm for mining such specifications (malspecs) from dynamic traces of malware samples and benign programs. Our prototype, MiniMal, infers malspecs by dif-ferencing the dependence graphs of a malware sample and of multiple benign programs. Experimental results showed that the malspecs mined by our algorithm compare favorably with behavioral specifications manually constructed by human experts. Malspecs can also be used to detect multiple malware variants.. The current work computed the behavioral difference as a subgraph of the malicious dependence graph, without taking into account the constraints of any similar benign subgraph. One possibility is to define the difference to consider both the malicious constraints and the (negation of) benign constraints -we plan to explore this in future research.. The choice of test programs is an important element of our mining approach. For malicious program we would like to know whether certain classes of malware are more amenable to mining. For benign programs we want to ensure that a broad selection of behaviors are represented in the test set. Thus a goal for future work is to determine the impact the choice of test programs has on the quality of the mined malspecs. A related problem is the incompleteness of the dependence graph built from a finite set of execution traces. Combining dynamic and static analysis could provide techniques to derive a better dependence graph. The evaluation showed that our malspec-mining algorithm was successful in identifying behaviors unique to malware samples. It did so without any a priori security policy that defined malicious or benign behaviors. Furthermore, these malspecs could then be used to provide forward detection of later malware variants.. There were several aspects to address when considering the validity of our experiments. The most important one was the internal validity, i.e., the factors that could influence the observed behavior of the test programs (both benign and malicious). We considered two sources of threats to internal validity: (1) impact of execution monitoring, and (2) relevance of execution traces. The execution monitor simply collected system-call traces for a fixed time period. Since the monitored program could not observe the execution monitor, which was present only in protected kernel space, we expected the monitored program to execute normally, without biasing our results.. The threat of execution relevance arose from differences between our "emulated Internet" environment and the real Internet. If the malware attempted, for example, to download additional components or commands from a remote server, it would fail without executing any malicious behaviors. Similarly, the malware might not execute any malicious behaviors during the monitoring period if it was timedependent. In such cases, MiniMal would not discover any differences between malicious and benign programs. We operated under the assumption that most malware tries to execute in as many environments as possible. In future, we will explore ways to eliminate this assumption, for example by allowing limited interaction with the Internet and by analyzing multiple execution paths [20] .. A second aspect was that of external validity, the lack of which could limit our ability to generalize our malspecmining technique to other classes of malicious programs.. While our experiments focused on mass-mailing worms, the technique was general enough to apply to any class of malware behaviors. In particular, we note that the variants in our test set exhibited behaviors above and beyond those traditionally characteristic of a mass-mailing worm.. Finally, the third aspect of concern was that of construct validity. This relates to how expressive the malspec language is and how powerful the dependence graph construction is. We discussed the malspec language in Section 3. As noted in the results above, the dependence inference failed when the information flow between system-call arguments was complex. We plan to address this limitation in future work, possibly using dynamic information-flow tracing. There is a large body of work in the area of learning program features and program understanding using dynamic traces. We focus on two areas most related to our work, specification mining for software engineering and specification mining for software security.. Mining of specifications has received considerable attention for a variety of program-related aspects, including APIusage and general programming rules [1, 18, 27] . In contrast, we mine specifications of malicious behavior, with no a priori definition of "malicious," by comparing malicious and benign programs. Clone-detection techniques compare programs [3, 11, 13, 30] , but they target similarities, not distinctions, between and within programs. Program-differencing techniques have goals similar to ours, but are limited to distinctions at the statement level or at the structural level [2, 9, 10, 17] . The execution-history matching introduced by Zhang and Gupta [30] is closest to our technique in that it analyzes dynamic data-dependence graphs, albeit with the goal of finding similar programs. Execution-history matching also operates at the instruction level and requires precise information about data and control dependences, and thus it is not directly applicable to our problem.. In computer security, the area of host-based intrusion detection has applied specification mining techniques to derive models of program behavior, which can be used to contain execution. These program models of "good" behavior can be derived through static analysis [8] or learned from dynamic traces [23] . Recent work has looked at the use of constraints over system-call arguments for host-based intrusion detection. Kruegel et al. proposed a system for learning models for the string values of individual system-call arguments without taking into account dependences between system calls [15] . Their models could be used as local constraints in the malspecs we extract. Bhatkar et al. introduced a technique for deriving a dataflow model to be used for intrusion detection [4] . They derived both local constraints and dependences for system-call arguments, using a fine-grained set of relations over strings (e.g., isWithinDir, hasExtension, hasSameDirAs). These types of constraints fit into our malspec language and we will research extending our dependencegraph construction to discover such string constraints.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O


Measuring the impact of temporal context on video retrieval In this paper we describe the findings from the K-Space interactive video search experiments in TRECVid 2007, which examined the effects of including temporal context in video retrieval. The traditional approach to presenting video search results is to maximise recall by offering a user as many potentially relevant shots as possible within a limited amount of time. 'Context'-oriented systems opt to allocate a portion of the results presentation space to providing additional contextual cues about the returned results. In video retrieval these cues often include temporal information such as a shot's location within the overall video broadcast and/or its neighbouring shots. We developed two interfaces with identical retrieval functionality in order to measure the effects of such context on user performance. The first system had a 'recall-oriented' interface, where results from a query were presented as a ranked list of shots. The second was 'contextoriented', with results presented as a ranked list of broadcasts. 10 users participated in the experiments, of which 8 were novices and 2 experts. Participants completed a number of retrieval topics using both the recall-oriented and context-oriented systems. It was expected in the design of the two presentation modes that System A would support rapid iteration through a result-set leading to high recall while System B in presenting matched results in the context of the entire broadcast would provide extra context to the user requiring a more explorative review of temporal neighbourhoods within the broadcast. The usage data presented seems to support that the systems were used as expected with users spending far longer exploring individual result-sets in System B, as a result of the available context. We assert that they explore in a breath-wise manner across the context of a matched result rather than depth-wise into the set of matched results. While they are not interrogating the results as deeply as their recall counterparts they are achieving comparable performance. This suggests that temporal context is significantly and beneficially augmenting the number of relevant items while minimizing user effort (where effort is search formulation). Figure 4 presents a comparison of the time taken for users to discover relevant items (indicated by saving a shot) across systems and across user types. For the first two minutes of a search the recall oriented system locates significantly more results than the context-oriented system. 381 saves were recorded within the first 120 seconds for all topics that used System A, almost double the number recorded for System B (205 saves). This difference is particularly evident in the first two minutes of nonexpert searches and also within the first minute of expert searches. It should be noted that a factor within the first minute of a topic is the time taken to formulate and issue the query before results are presented. We can infer that experts are searching much more efficiently as they are accessing more relevant results earlier than non-experts. However as the search proceeds, an advantage appears to be gained by the context system. Within minutes 3 to 7, the context system sustains high levels of saves (mean 204 saves per minute). This high level of activity is particularly pronounced for the expert user but while they see high performance in the first half of a context-oriented topic search, performance declines noticeably within the second half. In this paper we have presented an investigation into the provision of temporal context within search results for users. An analysis of assessor judged relevance within the TRECVid 2007 collection revealed it to be highly temporally consistent, containing a high number of temporally adjacent relevant shots. Thus it is not surprising that a traditional recall-oriented result presentation and a novel presentation of each matched shot's temporal context within its entire broadcast, Both result in users locating large number of temporal neighbours in their saved results. While users are likely find temporal neighbours regardless of provision of context information, there is a distinct difference in the location of temporal siblings (those shots of relevance which are directly adjacent to one another.) The context-oriented system significantly outperforms here. We have also noted differences in the search strategies adopted as a result of providing context to users. Users employ a detailed exploration of the provided context to locate relevant shots while those using a recall-oriented system explore more deeply into the returned results, following information trails and regularly reformulating their queries. Users provided with temporal context in addition spent longer exploring each individual set of results.. The provision of context shows a mild lag in initial performance, likely due to the time taken to locate broadcasts of high temporal consistency and relevance but offer good or high performance from approximately the 3 rd to 7 th minute inclusive. Overall though, both systems perform equally well. Finally we have demonstrated that the type of user (novice or expert) will impact on the performance of the search and likely the search strategy employed with each system.

O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O