Digital Forensics and Cyber Crime

Expediting MRSH-v2 Approximate Matching 147 Extending the file-against-set comparison outlined in [5], an alternative strategy to combat this is to use a hierarchical Bloom filter tree (HBFT) [7]. It is intended to achieve speed benefits over a pairwise comparison while sup- porting the identification of specific matching files. The primary contribution of this paper is to investigate the factors that affect the runtime performance of this approach, compared to the classic pairwise approach. 4 Hierarchical Bloom Filter Trees (HBFT) In a Hierarchical Bloom Filter Tree (HBFT), the root node of the tree is a Bloom filter that represents the entire collection. When searching for a file, if a match is found at the root of the tree, its child nodes can then be searched. Although this structure is inspired by a classic binary search tree, a match at a particular node in a HBFT does not indicate whether the search should continue in the left or right subtree. Instead, both child nodes need to be searched, with the search path ending when a leaf node is reached or a node does not match. Fig. 1. Hierarchical Bloom Filter Tree (HBFT) structure. The tree layout is shown in Fig. 1. Each level in the tree is allocated an equal amount of memory. Thus each Bloom filter occupies half the memory of its parent, and also represents a file set that is half the size of its parent. The expected false positive rates will be approximately equal at all levels in the tree. When a collection is being modelled as a HBFT, each file is inserted into the Bloom filter at some leaf node in the tree, and also into its ancestor nodes. The mechanism of inserting a file into a Bloom filter is the same as for the single Bloom filter approach from [5], which is also very similar to the approach taken by the classic MRSH-v2 algorithm outlined in Sect. 3. The key difference is that instead of creating a similarity digest of potentially multiple small Bloom filters for an individual file, each subhash is used to set 5 bits of the larger Bloom filter within a tree node that usually relates to multiple files. Depending on the design of the tree, a leaf node may represent multiple files. Thus a search that reaches a leaf node will still require a pairwise comparison with each file in this subset, using MRSH-v2. However, given that most searches

148 D. Lillis et al. will reach only a subset of the root nodes, the number of pairwise comparisons required for each file is greatly reduced. The process to check if a file matches a Bloom filter node is similar to the process of inserting a file into the tree. However, instead of inserting each hash into the node, its subhashes are instead checked against the Bloom filter to see if they are contained in it. If a specific number of consecutive hashes are contained in the node, this is considered to be a match. The number of consecutive hashes is configurable as a parameter named min run. The first experiment in this paper (discussed in Sect. 5.2) explores the effects of altering this value. In the construction of a HBFT, memory constraints will have a strong influ- ence on the design of the tree. In practical situations, a typical workstation is unlikely (at present) to have access to over 16 GiB of main memory. Thus trade- offs in the design of the tree are likely. Larger Bloom filters have lower false positive rates (assuming the quantity of data is constant), but lead to shallower trees (thus potentially increasing the number of pairwise comparisons required). 5 Experiments As part of this work, a number of experiments were conducted to examine the factors that affect the performance of the HBFT structure. In each case, a HBFT was used to model the contents of a dataset. Files from another dataset were then searched for in the tree, and the results reported. Because the speed of execution is of paramount importance, and because the original MRSH-v2 implementation was written in C, the HBFT implementation used for these experiments was also written in that language. The source code has been made available (at http:// github.com/ishnid/mrsh-hbft) under the Apache 2.0 licence. The workstation used for the experiments contains a quad-core Intel Core i7 2.67 GHz processor, 12 GiB of RAM and uses a solid state drive for storage. The operating system is Ubuntu Linux 16.04 LTS. The primary constraint this system imposes on the design of experiments is that of the memory that is available for storing the HBFTs. For all experiments, the maximum amount of memory made available for the HBFT was 10 GiB. The size of the individual Bloom filters within the trees then depended on the number of nodes in the tree (which in turn depends on the number of leaf nodes). For each experiment, the number of leaf nodes (n) is specified in advance, from which the total number of nodes can be computed (since this is a binary tree). Given the upper total memory limit (u, in bytes), and that the size of each Bloom filter should be a power of two (per [5]), it is possible to calculate the maximum possible size of each Bloom filter. Because all levels in the tree are allocated the same amount of memory, the size of the root Bloom filter in bytes (r) is given by: r = 2 log2(u/(log2(n)+1)) (1) The size of the other nodes in bytes is then r where d is the depth of the 2d node in the tree (i.e. the size of a Bloom filter is half the size of its parent).

Expediting MRSH-v2 Approximate Matching 149 The ultimate goal of the experiments is to demonstrate that the HBFT app- roach can improve the running time of an investigation over the all-against-all comparison approach of MRSH-v2 without suffering a degradation in effective- ness. It achieves this by narrowing the search space so that each file that is searched for need only be compared against a subset of the dataset. Using a HBFT, the final outcome will be a set of similarity scores. This score is calculated by using MRSH-v2 to compare the search file with all files contained in any leaves that are reached during the search. Therefore, the HBFT approach will not identify a file as being similar if MRSH-v2 does not also do so. In these experiments, the similarity scores generated by MRSH-v2 are consid- ered to be ground truth. Evaluating the degree to which this agrees with the opinion of a human judge, or how it compares with other algorithms, is outside the scope of this paper. The primary difference between the outputs is that the HBFT may fail to identify files that MRSH-v2 considers to be similar (i.e. false negatives) due to an appropriate leaf node not being reached. Therefore the primary metric used, aside from running time, is recall: the proportion of known-similar (or known-identical) files for which the HBFT search reaches the appropriate leaf node. 5.1 Datasets Two datasets were used as the basis for the experiments conducted in this paper: – The t5 dataset [19] is frequently used for approximate matching experimen- tation. It consists of 4,457 files (approximately 1.8 GiB) taken from US gov- ernment websites. It includes plain text files, HTML pages, PDFs, Microsoft Office documents and image files. – The win7 dataset is a fresh installation of a Windows 7 operating system, with default options selected during installation. It consists of 48,384 files (excluding symbolic links and zero-byte files) and occupies approximately 10 GiB. The first two experiments use one or both of these datasets directly. The final experiment includes some modifications, as outlined in Sect. 5.2. 5.2 Experiment Overview The following sections present three experiments that were conducted to evaluate the HBFT approach. Section 5.2 compares the t5 dataset with itself. This is intended to find whether the HBFT approach is effective in finding identical files, and to investigate the effect of varying certain parameters when designing and searching a HBFT. It also aims to demonstrate the extent to which the number of pairwise comparisons required can be reduced by using this technique. Section 5.2 uses disjoint corpora of different sizes (t5 and win7). In a typical investigation, there may be a large difference between the size of the collection of search files and a seized hard disk. This experiment aims to investigate whether it is preferable to use the tree to model the smaller or the larger corpus.

150 D. Lillis et al. Finally, Sect. 5.2 uses overlapping corpora where a number of files have been planted on the disk image. These files are identical to, or similar to, files in the search corpus. This experiment demonstrates that using a HBFT is substantially faster than the pairwise approach. Experiment 1: t5 vs. t5. For the initial experiment, the HBFT was con- structed to represent the t5 corpus. All files from t5 were also used for searching. Thus every file searched for is also located in the tree and should be found. Con- ducting an all-against-all pairwise comparison using MRSH-v2 required a total of 19,864,849 comparisons, which took 319 s. To construct the tree, the smallest number of leaf nodes was 32. Following this, the number of leaf nodes was doubled each time (maintaining a balanced tree). The exception was that 4,457 leaf nodes were used for the final run, thereby representing a single file from the corpus in each leaf. The aims of this experiment were: 1. Evaluate the effectiveness of the HBFT approach for exact matching (i.e. finding identical files) using recall. 2. Identify an appropriate value for MRSH-v2’s min run parameter. 3. Investigate the relationship between the size of the tree and the time taken to build and search the tree. 4. Investigate the relationship between the size of the tree and the number of pairwise comparisons that are required to calculate a similarity score. Table 1. Effect of min run on recall: identical files. min run Recall 4 100% 6 99.96% 8 99.93% When running the experiment, it became apparent that the first two aims are linked. Table 1 shows the recall associated with three values of min run: 4, 6 and 8. Using a min run value of 4 resulted in full recall. However, increasing min run to 6 or 8 resulted in a small number of files being omitted. When min run is set to 8, three files are not found in the tree. This indicates the dangers inherent in requiring longer matching runs. The files in question are 000462.text, 001774.html, 003225.html. These files are 6.5 KiB, 6.6 KiB and 4.5 KiB in size respectively. Although each chunk is approximately 160 bytes, this changes depending on the file content. While these are relatively small files, they are not the smallest in the corpus. This shows that even when the file is large enough to contain 8 chunks of the average size, a min run requirement of

Expediting MRSH-v2 Approximate Matching 151 8 successive matches may still not be possible. Similarly, using 6 as the min run value results in two files being missed. It should be acknowledged that if the aim is solely to identify identical files, then existing hash-based techniques will take less time and yield more reliable results. Intuitively, however, a system that is intended to find similar files should also find identical files. While the chunk size of 160 bytes will always fail to match very small files, it is desirable to find matches when file sizes are larger. Fig. 2. Effect of varying number of leaf nodes on time taken: t5 vs. t5 Figure 2 shows the time taken to build the tree and search for all files. As the number of leaf nodes in the tree increases, so too does the time taken to search the tree. Higher values of min run use slightly less time, due to the fact that it is more difficult for a search to descend to a lower level when more matches are required to do so. However, as the recall for these higher values is lower, 4 was used as the min run value for further experiments. The times shown here relate only to building the tree and searching for files within it, and does not include the time for the pairwise comparisons at the leaves. Therefore, although using 32 leaf nodes results in the shortest search time (due to the shallower tree), it would require a most comparisons, as each leaf node represents 1 of the entire corpus. As an illustration, using a tree with 32 32 leaf nodes and min run value of 4 requires 8,538,193 pairwise comparisons after searching the tree. A similar tree with 4,457 leaves requires 617,860 comparisons. One issue that is important to note is that the time required to perform a full pairwise comparison is 319 s. However, for the largest trees, 274 s were required to build and search the tree, before any comparisons were conducted. Thus, for a relatively small collection such as this, the use of the tree is unlikely to provide benefits in terms of time. Figure 3 plots the number of leaf nodes against the total number of compar- isons required to complete the investigation. As the size of corpora increases, so does the number of pairwise comparisons required by MRSH-v2. Thus reducing

152 D. Lillis et al. Fig. 3. Effect of varying number of leaf nodes on number of comparisons: t5 vs. t5 this search space is the primary function of the tree. Larger trees tend to result in a smaller number of comparisons. For the largest tree (with 4,457 leaves), the min run value does not have a material effect on the number of comparisons required. This implies that although searches tend to reach deeper into the tree (hence the longer running time), they do not reach substantially more leaves. From this experiment, it can be concluded that using a min run value of 4 is desirable in order to find exact matches. This causes the time taken to search to be slightly longer, while having a negligible impact on the number of pairwise comparisons required afterwards. Experiment 2: t5 vs. win7 and win7 vs. t5. The second experiment was designed to operate with larger dataset sizes. t5 was used as a proxy for a set of known-illegal files, and win7 was used to represent a seized disk. The aims of this experiment were: 1. Investigate whether the HBFT should represent the smaller or larger corpus. 2. Measure the effect on overall running time of using a HBFT. The experiment was first run by building a tree to represent t5 and then searching for the files contained in win7. The number of leaf nodes in this tree was varied in the same way as in Experiment 1. Then this was repeated by inserting win7 into a tree and searching for the files from t5. Again the number of leaf nodes was doubled every time, with the exception that the largest tree contained one leaf node for every file in the collection (i.e. 48,384 leaves). The time taken to build and search the trees are shown in Figs. 4 and 5. Figure 4 shows the results when the tree represents t5, with the time subdivided into the time spent building the tree and the time spent searching for all the files from win7. The total time is relatively consistent for this type of tree. This is unsurprising in the context of disjoint corpora. Most files will not match, so many searches will end at the root node, or at an otherwise shallow depth. Figure 5 shows results when the tree models win7. With only 32 leaf nodes, both experimental runs take approximately the same total time. Due to its size,

Expediting MRSH-v2 Approximate Matching 153 Fig. 4. Time to search for win7 in a t5 tree. Fig. 5. Time to search for t5 in a win7 tree. the build time for the win7 tree is substantially longer than for t5. The search time exhibits a generally upward trend as the number of leaf nodes increases. This is because of the hardware constraints associated with the realistic setup. Because memory footprint is constrained, a tree with 48,384 leaf nodes will contain Bloom filters that are much smaller than for trees with fewer nodes. In this experiment, leaves are 8 KiB in size, with a root node of 512 MiB. Overall, the total time taken is less when the tree represents the smaller dataset. Again, the total number of pairwise comparisons decreases as the num- ber of leaves increases. Both approaches yield a similar quantity of necessary comparisons for their largest tree (i.e. with the most leaf nodes). The tree mod- elling t5 requires 98,260 comparisons whereas the one modelling win7 requires 101,386. This, combined with the lower build and search time suggests that the preferred approach should be to use the smaller corpus to construct the

154 D. Lillis et al. HBFT. Memory is an additional consideration. Using a HBFT to model the larger dataset requires the similarity hashes of all its files to be cached at the leaves. This requires a greater memory footprint than for the smaller collection, thus reducing the amount of memory available to store the HBFT itself. Following these observations, the experiment was repeated once more. The tree modelled t5 with 4,457 leaves and win7 was searched for. The total running time, including pairwise comparisons, was 1,094 s. In comparison, the time taken to perform a full pairwise comparison using MRSH-v2 is 2,858 s. Experiment 3: Planted Evidence. The final experiment involved overlapping datasets, constructed as follows: – A set of simulated “known-illegal” files: 4,000 files from t5. – A simulated seized hard disk: the win7 image, plus 140 files from t5, as follows: – 100 files that are contained within the 4,000 “illegal” files. – 40 files that themselves are not contained within the “illegal” files, but that have a high similarity with files in the corpus, according to MRSH-v2. 10 of these files have a similarity of 80% or higher, 10 have a similarity between 60% and 79% (inclusive), 10 have a similarity between 40% and 59% (inclusive) and 10 have a similarity between 20% and 39% (inclusive). The aims of this third experiment were: 1. Evaluate the time taken to perform a full search, compared with MRSH-v2. 2. Evaluate the success of the approach in finding the 100 “illegal” files that are included verbatim in the hard disk image, and the 40 files from the image that are similar to “illegal” files, according to MRSH-v2. For the first aim, the primary metric is the time taken for the entire process to run, comprising the time to build the tree, the time to search the tree and the time required to conduct the pairwise comparisons at the leaves. In evaluating the latter aim, recall is used. Here, “recall” refers to the percentage of the 100 identical files that are successfully identified, and “similar recall” refers to the percentage of the 40 similar files that are successfully found. A file is considered to have been found if the search for the file it is similar or identical to reaches the leaf node that contains it, yielding a pairwise comparison. The total running time for MRSH-v2 was 2,592 s. The running times of the HBFT approach are shown in Fig. 6. The smaller collection of 4,000 “illegal” files was used to construct the tree and then searches were conducted for all of the files in the larger corpus. The “Search Time” includes the time spent searching the tree and the time to perform the comparisons at the leaves. As expected, the maximum number of leaf nodes resulted in the fastest run time. This configuration also yielded the maximum reduction in the number of pairwise comparisons required, without substantially adding to the time required to build and search the tree. The remainder of this analysis focuses on this scenario, where the tree has 4,000 leaf nodes.

Expediting MRSH-v2 Approximate Matching 155 Fig. 6. Time to search for planted evidence (including pairwise comparisons). The total time was 1,182 s (a 54% reduction in the time required for an all- against-all pairwise comparison). Due to the lack of scalability of the pairwise approach, this difference is likely to be even more pronounced for larger datasets. Table 2. Similar recall for planted evidence experiment. MRSH-v2 similarity Files planted Files found Similar recall 80%–100% 10 10 100% 60%–79% 10 10 100% 40%–59% 10 10 100% 20%–39% 10 8 80% Overall 40 38 95% In terms of effectiveness, all 100 files that were common to the two corpora were successfully found. The similar recall is shown in Table 2. All files with a MRSH-v2 similarity of 40% or greater with a file in the “illegal” set were success- fully identified. Two files with a lower similarity (25% and 26%) were not found. This yields an overall similar recall score of 95% for all 40 files. This is an encouraging result, indicating that the HBFT approach is extremely effective at finding files that are similar above a reasonable threshold of 40% and exhibits full recall for identical files. Thus it can be concluded that the HBFT data structure is a viable alternative to all-against-all comparisons in terms of effectiveness, while achieving substantial speed gains. 6 Conclusions and Future Work This paper aimed to investigate the effectiveness of using a Hierarchical Bloom Filter Tree (HBFT) data structure to improve upon the all-against-all pairwise

156 D. Lillis et al. comparison approach used by MRSH-v2. A number of experiments were con- ducted with the aim of improving the speed of the process. Additionally, it was important that files that should be found were not omitted. The first experiment found that while HBFTs with more leaf nodes take longer to build and search, they reduce the number of pairwise comparisons required by the greatest degree. It also suggested the use of a min run value of 4, as higher values resulted in imperfect recall for identical files. The results of the second experiment indicated that when using corpora of different sizes, it is preferable to build the tree to model the smaller collection and then search for the files that are contained the larger corpus. For the final experiment, a Windows 7 image was augmented by the addition of a number of files that were identical to those being searched for, and a further group that were similar. The HBFT approach yielded a recall level of 100% for the identical files and of 95% for the similar files, when using mrsh-v2 as ground truth. On examining the two files that were not found, it was noted that these had a relatively low similarity to the search files (25% and 26% respectively), with all files with a higher similarity score being identified successfully. The run time for this experiment was 54% of the time required for a pairwise comparison. These experiments lead to the conclusion that the HBFT approach is a highly promising technique. Due the poor scalability of the traditional all-against-all approach, it can be inferred that this performance improvement will be even more pronounced as datasets become larger. Given the promising results of the experiments presented in this paper, fur- ther work is planned. Currently, when building the tree, files are allocated to leaf nodes in a round-robin fashion. For trees with multiple files represented at each leaf, it may be possible that a more optimised allocation mechanism could be used for this (e.g. to allocate similar files to the same leaf node). Addition- ally, the current model also uses balanced trees, with the result that all successful searches reach the same depth in the tree. In some circumstances, an unbalanced tree may be preferable so as to shorten some more common searches. References 1. van Baar, R., van Beek, H., van Eijk, E.: Digital forensics as a service: a game changer. Digit. Invest. 11(Supplement 1), S54–S62 (2014). https://doi.org/10. 1016/j.diin.2014.03.007 2. Bloom, B.H.: Space/time trade-offs in hash coding with allowable errors. Commun. ACM 13(7), 422–426 (1970) 3. de Braekt, R.I., Le-Khac, N.A., Farina, J., Scanlon, M., Kechadi, T.: Increas- ing digital investigator availability through efficient workflow management and automation. In: 2016 4th International Symposium on Digital Forensic and Secu- rity (ISDFS), pp. 68–73 (2016). https://doi.org/10.1109/ISDFS.2016.7473520 4. Breitinger, F., Baier, H.: Similarity preserving hashing: eligible properties and a new algorithm MRSH-v2. In: Rogers, M., Seigfried-Spellar, K.C. (eds.) ICDF2C 2012. LNICST, vol. 114, pp. 167–182. Springer, Heidelberg (2013). https://doi. org/10.1007/978-3-642-39891-9 11

Expediting MRSH-v2 Approximate Matching 157 5. Breitinger, F., Baier, H., White, D.: On the database lookup problem of approx- imate matching. Digit. Invest. 11, S1–S9 (2014). https://doi.org/10.1016/j.diin. 2014.03.001 6. Breitinger, F., Guttman, B., McCarrin, M., Roussev, V., White, D.: Approximate matching: definition and terminology. NIST Spec. Publ. 800, 168 (2014) 7. Breitinger, F., Rathgeb, C., Baier, H.: An efficient similarity digests database lookup - a logarithmic divide & conquer approach. J. Digit. Forensics Secur. Law 9(2), 155–166 (2014) 8. Broder, A.Z.: On the resemblance and containment of documents. In: Compression and Complexity of Sequences 1997, Proceedings, pp. 21–29. IEEE (1997). https:// doi.org/10.1109/SEQUEN.1997.666900 9. Casey, E., Ferraro, M., Nguyen, L.: Investigation delayed is justice denied: propos- als for expediting forensic examinations of digital evidence. J. Forensic Sci. 54(6), 1353–1364 (2009) 10. Gupta, J.N., Kalaimannan, E., Yoo, S.M.: A heuristic for maximizing investiga- tion effectiveness of digital forensic cases involving multiple investigators. Comput. Oper. Res. 69, 1–9 (2016). https://doi.org/10.1016/j.cor.2015.11.003 11. Harichandran, V.S., Breitinger, F., Baggili, I.: Bytewise approximate matching: the good, the bad, and the unknown. J. Digit. Forensics Secur. Law: JDFSL 11(2), 59 (2016) 12. James, J.I., Gladyshev, P.: Automated inference of past action instances in digital investigations. Int. J. Inf. Secur. 14(3), 249–261 (2015). https://doi.org/10.1007/ s10207-014-0249-6 13. Kornblum, J.: Identifying identical files using context triggered piecewise hashing. Digit. Invest. 3, 91–97 (2006). https://doi.org/10.1016/j.diin.2006.06.015 14. Lillis, D., Becker, B., O’Sullivan, T., Scanlon, M.: Current challenges and future research areas for digital forensic investigation. In: 11th ADFSL Conference on Digital Forensics, Security and Law (CDFSL 2016), ADFSL, Daytona Beach, FL, USA (2016). https://doi.org/10.13140/RG.2.2.34898.76489 15. Oliver, J., Cheng, C., Chen, Y.: TLSH-a locality sensitive hash. In: Cybercrime and Trustworthy Computing Workshop (CTC), 2013 Fourth, pp. 7–13. IEEE (2013). https://doi.org/10.1109/CTC.2013.9 16. Quick, D., Choo, K.K.R.: Impacts of increasing volume of digital forensic data: a survey and future research challenges. Digit. Invest. 11(4), 273–294 (2014). https:// doi.org/10.1016/j.diin.2014.09.002 17. Rogers, M.K., Goldman, J., Mislan, R., Wedge, T., Debrota, S.: Computer forensics field triage process model. J. Digit. Forensics Secur. Law 1(2), 19–38 (2006) 18. Roussev, V.: Data fingerprinting with similarity digests. In: Chow, K.P., Shenoi, S. (eds.) IFIP International Conference on Digital Forensics. IFIP AICT, vol. 337, pp. 207–226. Springer, Heidelberg (2010). https://doi.org/10.1007/978-3-642-15506- 2 15 19. Roussev, V.: An evaluation of forensic similarity hashes. Digit. Invest. 8, S34–S41 (2011) 20. Roussev, V., Richard III, G.G.: Breaking the performance wall: the case for dis- tributed digital forensics. In: Proceedings of the 2004 Digital Forensics Research Workshop, vol. 94 (2004) 21. Sadowski, C., Levin, G.: Simhash: hash-based similarity detection. Technical report, Google (2007) 22. Scanlon, M.: Battling the digital forensic backlog through data deduplication. In: Proceedings of the 6th IEEE International Conference on Innovative Computing Technologies (INTECH 2016). IEEE, Dublin (2016)

Approxis: A Fast, Robust, Lightweight and Approximate Disassembler Considered in the Field of Memory Forensics Lorenz Liebler(B) and Harald Baier da/sec - Biometrics and Internet Security Research Group, University of Applied Sciences, Darmstadt, Germany {lorenz.liebler,harald.baier}@h-da.de Abstract. The discipline of detecting known and unknown code struc- tures in large sets of data is a challenging task. An example could be the examination of memory dumps of an infected system. Memory forensic frameworks rely on system relevant information and the examination of structures which are located within a dump itself. With the constant increasing size of used memory, the creation of additional methods of data reduction (similar to those in disk forensics) are eligible. In the field of disk forensics, approximate matching algorithms are well known. However, in the field of memory forensics, the application of those algo- rithms is impractical. In this paper we introduce approxis: an approxi- mate disassembler. In contrary to other disassemblers our approach does not rely on an internal disassembler engine, as the system is based on a compressed set of ground truth x86 and x86-64 assemblies. Our first prototype shows a good computational performance and is able to detect code in large sets of raw data. Additionally, our current implementation is able to differentiate between architectures while disassembling. Sum- marized, approxis is the first attempt to interface approximate matching with the field of memory forensics. Keywords: Approximate disassembly · Approximate matching Disassembly · Binary analysis · Memory forensics 1 Introduction Detecting known malicious code in memory is a challenging task. This is mainly due to two reasons: first, malware authors tend to obfuscate their code by tam- pering it for each instance. Second, code in memory differs from persistent code because of changes performed by the memory loader (e.g., the security feature Address Space Layout Randomization (ASLR) makes it impossible to predict the final state of an executable right before run time). Hence an approach to iden- tify malicious code within a memory forensics investigation by comparing code fragments in its untampered shape (e.g., as an image on disk) to its memory loaded representation (e.g., a module with variable code) is a non-trivial task. c ICST Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 2018 P. Matouˇsek and M. Schmiedecker (Eds.): ICDF2C 2017, LNICST 216, pp. 158–172, 2018. https://doi.org/10.1007/978-3-319-73697-6_12

Approxis: Approximate Disassembly 159 Memory forensic tools like volatility use system related structures to extract loaded executables and to list executed processes on a system. The classical approach to identify loaded malware is performed with the help of signatures, static byte sequences or by the examination of access protections. White et al. [10] formulate requirements of investigating a memory image and postulate that methods of data reduction (similar to those in disk forensics) are eligible. In the field of disk forensics approximate matching algorithms (a.k.a. similarity hashing or fuzzy hashing) represent a robust and fast instrument to differentiate between known and unknown data fragments [3,6]. However, White et al. [10] claim that approximate matching algorithms are not suitable in the course of memory forensics, as code in memory always differs to on disk. In this paper we argue that the concept of approximate matching may be transferred from post-mortem or network forensics to the field of memory foren- sics. We differentiate between two stages of research to succeed. First, a technical component is needed, which acquires portions of code in different domains and extracts these fragments out of vast amounts of unknown data. Second, the acquired code fragments must be comparable. As the existing approaches in the field of memory forensics try to solve both issues at once by creating a stack of dependencies and accepting limitations of applicability [8,10], our approach focuses on the technical component first and introduces an interface to transfer the overall problem of code detection into the domain of approximate matching. Our main contribution of this paper is the technical acquisition component approxis: a lightweight, robust, fast and approximate disassembler as a prereq- uisite for memory-based approximate matching. The goal of approxis is to build a technical component for the usage in digital forensics, however, approxis may be used in different fields like real-time systems, too. Its functionality is compa- rable to a basic length-disassembler approach with additional features. Our approach is unaware of the full instruction encoding scheme of x86 or x86-64 platforms: by the usage of 4.2 GiB precompiled ELF (Executable and Linking Format) files and its corresponding ground truth assembly structure obtained by [1], we build up a decision tree of byte instructions. Each path of the tree represents the decoding process of a byte sequence to its correspond- ing instruction length. We use the opcode and mnemonic frequencies to assist the disassembling process and to differentiate between code and non-code byte sequences. The overall goal of approxis is not to reach the accuracy of profes- sional disassemblers, but to outreach the capabilities of a simple length disas- sembler. We evaluate our approach in different fields of application. First, we show the promising disassembling accuracy of approxis compared to objdump, a widely distributed and often used linear disassembler. Second, our approach is able to distinguish between code and data. Third, we demonstrate the capabilities to identify interleaved segments of code within large sets of raw binary data. Our current implementation introduces the possibility to determine the architecture of code during the process of disassembling. Finally, we demonstrate the compu- tational performance of approxis by the application on a raw memory image.

160 L. Liebler and H. Baier It is important to outline the conditions and the operational field of approxis, as our approach should not be considered in the well known domains of binary analysis. Thus, even if the final evaluation of approxis could seem to be incomplete to the reader, we argue that the extensive introduction of our app- roach in the field of memory forensics is important to understand the following design decisions. Additionally, it is somewhat negligible and deceptive to com- pare our approach to other disassemblers. However, our current implementation of approxis is designed for processing large portions of raw memory dumps, so a straight comparison with other disassemblers is not always valid. The remainder of this paper is organized as follows: In Sect. 2 we give an overview of related work. We introduce key features of existing research and describe instances of different disassemblers. In Sect. 3 we define central require- ments which should be fulfilled by approxis. In Sect. 4 we briefly introduce the x86 decoding scheme and the challenges of disassembling. We also introduce the results of analyzing our ground truth assemblies obtained by [1], which build the foundation for our code detection and approximate disassembling approach. In Sect. 5 we introduce approxis and its functionality. In Sect. 6 we present our assessment and experimental results. Finally, Sect. 7 concludes this paper. 2 Related Work Researches discussed different approaches for the application of cryptographic hash functions on memory fragments. Existing work addresses the problem of identifying known code by hashing normalized portions of code in memory. A short survey of existing approaches was given by [10]. In [8] offsets of vari- able code fragments were used to normalize and hash executables on a page level. A database of hash templates was created which consists of hash values and its corresponding offsets. These hash templates are applied on the physical address space. The comparison between each template and each page lead to a complexity of O(n ∗ m) for a comparison of n templates against m memory pages. The authors of [10] extended the approach and tried to improve the naive all-against-all comparison introduced by [8]. Therefore, they applied the hashes on virtual memory pages and used structures in memory to identify a process. By identifying a process, the lookup of a corresponding hash template could be performed efficiently. Before creating the hash values, the introduced approaches convert a present executable from disk to its state in memory and normalize it. The conversion of disk stored image files to a virtual loaded module was accom- plished with the help of a virtual Windows PE Loader [10]. The identification of variable offsets by imitating the loading process of an executable seems legit. A normalization based on previously disassembling a present sequence of bytes in memory was not mentioned by the authors. Recent research of linear disassemblers has shown the significant underes- timation of linear disassembly and the dualism in the stance on disassembly in literature [1]. A more exotic form are the so called length-disassemblers,

Approxis: Approximate Disassembly 161 which could be understood as a limited subset of linear disassemblers. A length- disassembler only extracts the lengths of an instruction. Beside the classical linear and recursive disassemblers, the authors of [7] introduced an experimen- tal approach of fast and approximate disassembly. The approach is based on the statistically examination of the most frequent occurred mnemonics. A set of extracted sequences of mnemonics have been used to create a lookup table of predominant bigrams. With the help of this table, a fuzzy 32 bit decoding scheme was proposed, which showed decent results. As already introduced, approximate matching algorithms can be used to detect similarities among objects, but also to detect embedded objects or frag- ment of objects [3,6]. Investigators can use it to differ between non-relevant and relevant fragments in large sets of suspicious data. In the course of memory foren- sics this approach would obviously struggle with volatile instruction operands and updated byte-sequences. Current approximate matching techniques con- stantly evolve, e.g. by the integration of better lookup strategies like Cuckoo Filters [5]. The problem of identifying code structures in large sets of binary data could be misleadingly compared with the problem of identifying interleaved data within code sections of a single executable [9]. The major goals of our approach are the fast identification and the approximate disassembly of code fragments. 3 Requirements of Approximate Disassembling In this section we introduce and explain four essential requirements for our research: lightweight, robustness, speed and versatility. These requirements should be understood as superior and long term goals in the context of applying approx- imate matching to the field of memory forensics. They have to be respected in this research and beyond this work. To be able to better describe the fundamen- tal requirements, we first introduce the central goals of this publication. As the application of approximate matching algorithms to portions of memory seems unfeasible due to a unpredictable representation of code in memory, we suggest a process of normalization after approximate disassembling portions of code in large sets of raw and mixed data. As this work addresses the step of identifying and disassembling code in data, we define four major goals: 1. Detect sequences of code in a vast amount of different shaped raw data. 2. Extract sequences of instruction-related bytes with little overhead. 3. Make a statement about the confidence of the code detection process. 4. Determine additional information, like the architecture of the code. These practical goals describe the motivation of this work, where the follow- ing requirements describe the bounding conditions to achieve those goals. The defined requirements are discussed by recalling some central properties of the introduced competing approaches and by considering the mentioned goals. The first requirement lightweight aims to reduce the stack of dependencies of the target system with a focus on the instruction set and the loader traces. In

162 L. Liebler and H. Baier contrast to existing approaches, we propose a normalization based on previously disassembling code in different states of an executable. We consider this approach significant more lightweight than imitating loader traces with the help of a self- constructed virtual loader. A disassembler is therefore less interleaved to record the changes of a memory loader to an image file. Previous work to detect known fragments of code (e.g., the approach intro- duced by [10]) relies on the correct identification of a running process. This offers new degrees of bypassing and obfuscation to the malware author, e.g., by unlinking Virtual Address Descriptor (VAD) nodes using Direct Kernel Object Manipulation [4]. Our second requirement robustness means to identify a code fragment without process structures and being thus more robust against obfus- cation compared to competing approaches. Our third requirement is speed, which is a central requirement adopted from the field of approximate matching. In our current stage of research the detection and extraction of code from a vast amount of data has to be done with good computational performance. As we are interested in an approximate disassem- bler, we trade computational performance more important than accuracy of the disassembled code. However, the degree of disassembling should enable further normalization or the reduction of code representation. Most of the introduced systems in Sect. 2 are limited to x86 systems. A more versatile approach is desirable, which is not dependent on an a-priori knowledge of the architecture of the target system. The requirement versatility means that the disassembler works reliably for different target architectures. 4 Background and Fundamentals In this section we introduce the basic fundamentals of our approach for the intro- duction of approxis. We briefly introduce the target x86 system. Afterwards, we introduce the set of ground truth assembly files in a detailed way. 4.1 Disassembling We first give a short introduction to the x86 encoding scheme and the fundamen- tals of disassembling. Disassemblers are used to transform machine code into a human readable representation. In the field of binary analysis and reverse engi- neering the demands and requirements of a disassembler engine are clearly iden- tified. With the x86 instruction set these tools have to deal with variable-length and unaligned instruction encodings. Additional, executables sections could be interleaved by code and data sequences. As the authors of [9] already described, this system design trades simplicity for brevity and speed. Summarized, the process of disassembly in general is undecidable [1,9]. As could be seen in Fig. 1 the x86 instructions are defined by sequences of mandatory and non-mandatory bytes. The Reg field of the ModR/M byte is sometimes used as an additional opcode extension field. Prefix bytes could additionally change the overall instruction length. For further details we refer to the Intel Instruction manual1. 1 https://software.intel.com/en-us/articles/intel-sdm.

Approxis: Approximate Disassembly 163 Bits: Mod Reg R/M Scale Index Base Bytes: 76 543 210 76 543 210 Prefix Opcode ModR/M SIB Displacement Immediate 0-4 0,1,2,4,8 1-3 0-1 0-1 0,1,2,4,8 Fig. 1. x86 machine instruction format The core of this research is to approximate disassemble a vast amount of unknown data. This desire clearly stays in conflict with the goal of classical dis- assembler engines, where computational performance is often understood as a secondary goal. We ignore recursive traversal, as this would implicate an imprac- tical layer of computational overhead. The development and the maintenance process of disassemblers is somewhat cumbersome and tedious. Even the lookup tables of a simple length-disassembler have to be maintained. 4.2 Mnemonic Frequency Analysis We analyzed the opcode and mnemonic distribution of a set of ELF binaries, namely a dataset containing 521 different binaries obtained by [1]. As we focus on the acquisition of byte sequences which rely to code only, we extracted the .text section of each binary file. It should be mentioned that the following dis- tribution analysis is nothing new [2,7]. However, existing distribution analysis of mnemonics often rely on malware, which could be biased. We used the ground truth of assemblies to determine the distribution of mnemonics and extracted the bigrams of mnemonics (see Table 1). We splitted the set of assemblies by its architecture and determined the total amount of unigrams and bigrams. The col- umn of distinct values describes the set of all occurring mnemonics. The columns max, mean and min describe the assignment of the total amount of instructions to each distinct unigram or bigram. For example, the most frequently occurred mnemonic in the case of 32 bit binaries represents 33.25% of all instructions. Table 1. Overview of unigram and bigram mnemonic counts. 32 bit (200 files) 64 bit (321 files) Total Distinct Max Mean Total Distinct Max Mean Unigrams 35.232k 322 11.714k 1531 61.441k 436 21.627k 1859 Bigrams 35.232k 11632 5.889k 17 61.441k 16059 10.360k 28 The frequency of occurrence of all bigrams are extracted, the probability p of each bigram is saved as logarithmic odds (logit). We further denote the absolute values of logits as λ (see Eq. 1). Similar to [7] we want to avoid computational underflow by multiplication of probabilities. λ= ln 1 p p (1) −

164 L. Liebler and H. Baier 4.3 Byte Tree Analysis The former subsection revisits the frequencies of most frequently occurred mnemonics. In a next step we analyze the byte frequencies on a instruction base. We have to deal with a vast amount of overlapping byte sequences and non-relevant operand information. To refine our demands, the overall goal of approxis is not do establish a high-accuracy disassembler, but to identify instruction offsets and a predominant mnemonic. We extract all bytes of an instruction and insert them in a database structured as tree. Each node of the tree represents a byte and stores a reference to all its corresponding children, the subsequent instruction bytes (see Fig. 2). Input instructions: root push 41 55 64 48 41 push 41 55 mov lea sub push mov 48 89 f3 sub 48 81 ec mov 55 lea 48 8d push mov 64 48 8b 48 89 81 8d mov mov sub lea 8b f3 ec mov mov sub Fig. 2. Oversimplified bytetree example after inserting several instructions. As an example we inspect the byte sequence 488d and its subsequent bytes after inserting our ground truth into the tree. In listing 1 we can see the com- plete output of a single node. We should mention that the amount of the child nodes was shortened for a better representation . We also save auxiliary infor- mation like the amount of counted bytes for a current node , the counts of all corresponding mnemonics and the counts of different occurring instruction lengths . Each node maintains different formats and could possibly lead to redundant information. This structure represents an intermediate state needed for the following steps of data analysis, post processing and tree reduction. After inserting the whole ground truth into the tree we perform an additional step of reduction. Every node which represents a single length and a single mnemonic was transformed to a leaf node. So we cropped all subsequent child nodes of the current node, which doesn’t affect the instruction mnemonic. The reduced shape of the tree is highlighted black in Fig. 2. The impact of reduction could be seen in Table 2.

Approxis: Approximate Disassembly 165 Table 2. Comparison of original and reduced bytetree. Platform Input bytes Original tree Reduced tree Nodes Height Size Nodes Height Size 64 bit 253.535.572 12.773.078 15 445M 87.224 10 7.5M 32 bit 123.221.439 5.871.232 15 206M 35.211 9 3.0M 5 Approach The observation of the preceding section lead the deduction of our approach, which is based on the introduced bytetree and mnemonic frequency analysis. 5.1 Disassembling We argue that length-disassemblers could be assumed to be very fast and lightweight. Though, even a simple length-disassembler needs to respect a lot of basic operations and needs to be maintained for different target architectures. The disassembler library distorm2 is based on a trie structure and conceptional similar to our approach. It outperforms other disassemblers with its instruction lookup complexity of O(1). However, the engine still respects instruction sets on a bit granularity and performs a detailed decoding. As we trade computational speed more important than accuracy, approxis will stay on a byte granular- ity level. We consult the previously gained learnings of the mnemonic analysis to improve our process of length disassembling. It should be clear and fair to mention that existing disassemblers aren’t designed for our field of application. Processing a large amount of raw data is out of the scope of classical disas- semblers. As existing length-disassembler engines reduce the amount of needed decoding mechanisms to a minimum, we introduce an approach to resolve a corresponding mnemonic without respecting any provided opcode maps. Hence, comparing the computational speed of approxis with other disassemblers seems less meaningful. Bytetree Disassembling. To address the introduced requirement lightweight (see Sect. 3), approxis does not depend on the integration of a specific disas- sembler engine. The process of disassembling is mainly realized with the already introduced bytetree. We implemented our first prototype of approxis in the language C and used a reduced bytetree to generate cascades of switch state- ments. These statements are used to sequentially process the input instructions and to perform the translation into a corresponding length and mnemonic. The information of the bytetree nodes have been reduced to a minimum core. We only store the amount of counted visited bytes per node and the lengths. Nodes with more than one mnemonic are reduced to a single representative, which is the predominant and most counted mnemonic of the specific node. 2 https://github.com/gdabah/distorm.

166 L. Liebler and H. Baier The performance of the bytetree was evaluated by a set of 1318 64 bit bina- ries. The disassemblies obtained by the bytetree have been compared to the disassemblies obtained by objdump. Determining the correct offsets is impor- tant to build a solid foundation for further normalization. Thus, it is important to measure the amount of correctly disassembled instruction offsets compared to the set of true instruction offsets. We disassembled all binaries of an Ubuntu LTS 16.04 x86 64 and extracted the .text sections. The determined instruction offsets by objdump build our ground truth of relevant offsets θrl. We measured the performance of our bytetree disassembler by verifying all retrieved offsets θrt against our set of relevant offsets. An overview of fairly good performance is shown in Table 3 (row bt-dis). We denote the performance in values of precision and recall, where precision = |{θrl} ∩ {θrt}| and recall = |{θrl} ∩ {θrt }| . |{θrt}| |{θrl}| Table 3. Precision and recall of approxis. Approach Precision Recall Max Min Mean (geo./ari.) Max Min Mean (geo./ari.) bt-dis 100% 84.40% 99.50% 99.51% 100% 92.40% 99.80% 99.80% bta-dis 100% 91.49% 99.76% 99.76% 100% 93.62% 99.84% 99.84% We examined the binary with the lowest precision (i.e., 84.40%), namely xvminitoppm, which converts a XV thumbnail picture to PPM. Extracting a bunch of false positives underlines our assumption: even with a reliable vast amount of ground truth files, the integration of all instructions is impossible. In case of xvminitoppm a lot of overlong Multi Media Extension (MMX) instructions are implemented, which are not present in the bytetree. Assisted Length Disassembling. Disassembling a unknown binary, with unknown instruction bytes could lead to ambiguous decision paths within the bytetree. Namely, an unknown sequence of input bytes would lead to an exit of the tree structure at a non-leaf node, with multiple remaining lengths and mnemonics. An example in Fig. 3 could not be clearly disassembled with the tree from Fig. 2. To detect those outliers and to extend approxis with other features, we integrate our results from Sect. 4. In detail, we use the logarithmic odds of mnemonic bigrams to assist the process of disassembling and to identify reasonable instruction lengths, which could not be resolved by the bytetree itself. As the authors of [7] proposed a disassembler based on a set of logarithmic odds only, we argue that the descent performance of this approach is not sufficient. As the process of bytetree based disassembling is straightforward, the inte- gration of the absolute logit value λ has not yet been described. We consider

Approxis: Approximate Disassembly 167 λ as a value of confidence if two disassembled and subsequent instructions are plausible or not. So it is more likely that a sequence of instructions is in fact meaningful as long as λ remains small. In contrast, a high value of λ illustrates two subsequent instructions, which are not common at all. We limit the range of the absolute logit λ, where 0 ≤ λ ≤ 100. This value of confidence could be used differently to cope with the goals and requirements in Sect. 3. We first focus on assisting our process of disassembling by resolving plausible instruction lengths. Summarized, we use λ to determine the most plausible offset of a byte sequence, which is not known by our bytetree. The following steps describe the process of assisted disassembling in detail: 1. We use a table of confidence values λi to evaluate the transition between two instruction sequences denoted by its mnemonic. If a lookup of a subse- quent mnemonic pair fails, the action gets penalized with an exorbitant high value. Every retrieved λi has to be under a selected threshold τ . We repeat the disassembling with all stored length values of a current node until an offset fulfills the threshold. If none of the length values returns a λi under the threshold τ , we select the most common length of the current node. 2. All byte sequences with an unknown byte at offset zero, i.e. a byte which is not present in the first level of the bytetree, are penalized by the system. As bytes, which are not present on the first level of the bytetree after processing a fairly large amount of ground truth files, are expected to be not common. 3. A simple running length counter keeps track of subsequently repeating confidence values, as these indicate a significant lack of variance, often occur- ring in large fragments of zero byte sequences or random padding sequences. These non-relevant byte sequences are additionally penalized. Figure 3 illustrates the process of offset determination. We repeated the pro- cess of disassembling the set of 1318 64 bit ELF binaries with assisted length- disassembling. The obtained results in Table 3 (row bta-dis) show a significant improvement in the case of precision. λi = 7 λi+1 = 3 λi+2 = 5 λi+3 = 4 41 55 64 e0 ff 48 89 e0 48 ff e0 cc λi+3 = 17 Fig. 3. Selecting certain offsets with a predefined threshold τ = 16. 5.2 Code and Architecture Detection Beside supporting the process of determining unknown instruction offsets during disassembling, we use the value of confidence to realize two goals: detect code sequences in data and discriminate the architecture of code.

168 L. Liebler and H. Baier Code Detection. The current implementation of approxis could differ between code and non-code fragments in unknown sequences of bytes. As shown in the previous subsection, the value of confidence λi is determined for two subsequent instructions to enhance the disassembling process. We use a sliding window approach to consider those values over sequences of subsequent instruc- tions. More formally, we define a windowed confidence value ωx in Eq. 2 as the average of all λi within a sliding window, with a predefined size n at offset x. Penalized values overwrite a local value λi and thus influence ωx. The value of ω should be interpreted as a value of confidence over time. A rising value ω under- lines the presence of large data fragments. A short rising peak of λ indicates the presence of short and interleaved data. A mid-ranged value of ω indicates the loose presence of instructions or the presence of non-common instructions. ωx = n+x λi (2) i=x n Architecture Detection. We created a bytetree and a lookup table of λi for each architecture of our ground truth. Thus, switching the mode of operation could be realized by simply changing the references of the used bytetree and lookup-table. Mid-ranged values of ω could indicate uncommon sequences of instructions, which we will show later. Large sections of mid-range ω values could also indicate the presence of alternative architectures. We will demonstrate that these variances are significant for different architectures. Sections of code are normally within a range from 1 (high confidence) to 17 (low confidence). 6 Assessment and Experimental Results In this section we evaluate approxis in different fields of application. These assessments focus on the detection of code in different areas of application. Code Detection: The following evaluation addresses our defined requirement of robustness (see Sect. 3). To evaluate the code detection performance in the field of binary analysis, we first examined a randomly selected ELF binary. The result in Fig. 4 illustrates the capabilities of approxis to differentiate code from data. Figure 4a shows the initial reduction of confidence by the header. Figure 4b shows that the .text section is clearly distinguishable and introduced by the .plt section, which is not filled with common sequences of instructions. 102 a) b) ωi 101 1.2 100 101 102 103 104 105 0.4 0.6 0.8 1 ·104 .plt .text offset (bytes) .text .data Fig. 4. approxis applied on zip (64 bit); value of ωi with cutoff set to 100;

Approxis: Approximate Disassembly 169 We extracted from a set of 792 ELF binaries the file offsets of different sections with the help of objdump. The offsets θ of the sections .plt, .text and .data define points of transition between code and data in each file. To evaluate the code detection performance we inspected the average local value of confidence λi for κ preceding and κ subsequent instructions at an offset θ. A transition τd from code to data or τc from data to code at offset θ is recognized by approxis, if the average local confidence differs by a threshold δ (see formula 3). In the case of transitions between .plt and .text we lowered the threshold from δ = 30 to δ = 5. The ratio of all correctly registered transitions is shown in Table 4. ⎧ if θ λi − θ+κ λi >δ ⎪⎨1, i=θ−κ i=θ τc = τd = ⎪⎩0, n n (3) otherwise Table 4. Ratio of correctly detected transitions. Arch # files # transition Detected x86-64 400 1200 99 % x86 392 1176 92 % Architecture Detection. The following evaluation addresses our defined requirement of versatility (see Sect. 3). To illustrate the detection process of approxis for code fragments of different types, an image with random bytes was generated. Within the random byte sequences we inserted several non- overlapping binaries at predefined offsets. In detail, we inserted a 32 bit (i.e., ELF 64-bit LSB, dynam. linked, stripped) and a 64 bit (i.e., ELF 32-bit LSB, dynam. linked, stripped) version of four different binaries: wget, curl, info and cut. As introduced in Sect. 5, approxis currently relies on two different bytetrees and mnemonic lookup-tables. By applying both versions on our pathological image, we visualize the changing values of confidence (see Fig. 5a, b). Similar to the analysis of data and code transitions, we examined the archi- tecture discrimination with the help of 400 randomly selected ELF binaries for each architecture. We extracted the .text section of each binary and disassem- bled them with approxis in 64 bit and 32 bit mode. We determined the average of all ωx for the whole .text section of each binary, denoted as ω¯. The distribu- tion of ω¯ for each binary is illustrated in Fig. 6 and outlines the capabilities of approxis to discriminate a present architecture. Computational Performance. The following evaluation addresses our defined requirement of speed (see Sect. 3). The execution time of approxis was tested on a machine with an Intel(R) Core(TM) i5-3570K CPU @ 3.40 GHz with 16 GiB DDR3 RAM (1333 MHz) and 6 MiB L3 cache. The implementation was done in C and compiled with optimization set to -O3. As we focus on a possible

170 L. Liebler and H. Baier approxis-32 approxis-64 ωx Fig. 5. Comparison of code detection for x86 and x86-64 binaries. 300 # 32bit binaries # 64bit binaries # 64bit binaries # 32bit binaries 200 20 40 60 80 0 10 20 30 100 ω¯ of approxis-32 ω¯ of approxis-64 0 0 Fig. 6. Architecture detection of approxis with a selected bin size of one. integration in existing approximate matching techniques, we only measured the computation time of the disassembling process and ignored the loading process to memory. It should be mentioned that the current prototype doesn’t focus on performance optimization or parallelization. We created three images with a size of 2 GiB each to evaluate the runtime performance. As we already mentioned in Sect. 5.1, the comparison of approxis with other disassemblers is somewhat misleading. As approxis outreaches the capabilities of length-disassemblers, but is not able to completely decode x86 instructions, the comparison of those disas- semblers should not be understood as a comparison of competing approaches. We applied each disassembler in different modes and optimized our implementation of the distorm engine by removing unnecessary printouts and buffers. Table 5 outlines that the execution time of approxis relies on the processed input. Table 5. Execution time of approxis and distorm with different input data. Execution time Description Approxis Distorm Disassembler 32 64 32 64 Mode 29.084 s 21.936 s 1 m 20.770 s 1 m 7.772 s Concatenated set of 64 bit binaries from /usr/bin 27.859 s 31.918 s 1 m 43.999 s 1 m 43.046 s Raw memory dump acquired with LiMEa 1 m 15.521 s 1 m 44.990 s 1 m 58.278 s 1 m 56.192 s Random sequences of bytes generated with /dev/urandom a https://github.com/504ensicslabs/lime

Approxis: Approximate Disassembly 171 7 Conclusion In this paper, we demonstrated a first approach to detect, discriminate and approximate disassemble code fragments within vast amount of data. In contrast to previous work, approxis revisits the analysis of raw memory with less pre- requisites and dependencies. Our approach is a first step to fill the gap between state of the art high level memory examination (e.g., by the usage of volatility) and methods of data reduction similar to those in disk forensics. Our results show the capabilities of approxis to differentiate between code and data during the process of disassembling. By maintaining a value of confidence throughout the process of disassembling, we can reliably distinguish between different archi- tectures and switch the used bytetree to obtain a better degree of accuracy. The current implementation shows also a good computational speed. A next step should be the extraction of features, which are used in a context of approximate matching. Possible methods of subversion (e.g. anti-disassembling) should be considered. A process of exact and inexact matching of code is eligible to consider metamorphic structures and to damp variances in detected code. The approach could be transferred to other domains (e.g. embedded systems). Acknowledgement. This work was supported by the German Federal Ministry of Education and Research (BMBF) as well as by the Hessen State Ministry for Higher Education, Research and the Arts (HMWK) within CRISP (crisp-da.de). References 1. Andriesse, D., Chen, X., van der Veen, V., Slowinska, A., Bos, H.: An in-depth analysis of disassembly on full-scale x86/x64 binaries. In: USENIX Security Sym- posium (2016) 2. Bilar, D.: Statistical structures: fingerprinting malware for classification and anal- ysis. In: Proceedings of Black Hat Federal 2006 (2006) 3. Breitinger, F., Baier, H.: Similarity preserving hashing: eligible properties and a new algorithm MRSH-v2. In: Rogers, M., Seigfried-Spellar, K.C. (eds.) ICDF2C 2012. LNICST, vol. 114, pp. 167–182. Springer, Heidelberg (2013). https://doi. org/10.1007/978-3-642-39891-9 11 4. Dolan-Gavitt, B.: The VAD tree: a process-eye view of physical memory. Digit. Invest. 4, 62–64 (2007) 5. Gupta, V., Breitinger, F.: How cuckoo filter can improve existing approximate matching techniques. In: James, J.I., Breitinger, F. (eds.) ICDF2C 2015. LNICST, vol. 157, pp. 39–52. Springer, Cham (2015). https://doi.org/10.1007/978-3-319- 25512-5 4 6. Roussev, V., Richard, G.G., Marziale, L.: Multi-resolution similarity hashing. Digit. Invest. 4, 105–113 (2007) 7. Radhakrishnan, D.: Approximate disassembly. Master’s Projects. 155 (2010). http://scholarworks.sjsu.edu/etd projects/155/ 8. Walters, A., Matheny, B., White, D.: Using hashing to improve volatile memory forensic analysis. In: American Acadaemy of Forensic Sciences Annual Meeting (2008)

172 L. Liebler and H. Baier 9. Wartell, R., Zhou, Y., Hamlen, K.W., Kantarcioglu, M., Thuraisingham, B.: Differ- entiating code from data in x86 binaries. In: Gunopulos, D., Hofmann, T., Malerba, D., Vazirgiannis, M. (eds.) ECML PKDD 2011. LNCS (LNAI), vol. 6913, pp. 522– 536. Springer, Heidelberg (2011). https://doi.org/10.1007/978-3-642-23808-6 34 10. White, A., Schatz, B., Foo, E.: Integrity verification of user space code. Digit. Invest. 10, S59–S68 (2013)

Digital Forensics Tools Testing and Validation

Memory Forensics and the Macintosh OS X Operating System Charles B. Leopard(&), Neil C. Rowe, and Michael R. McCarrin U.S. Naval Postgraduate School, Monterey, CA 93940, USA [email protected], {ncrowe,mrmccarr}@nps.edu Abstract. Memory acquisition is essential to defeat anti-forensic operating system features and investigate clever cyberattacks that leave little or no evi- dence on physical storage media. The forensic community has developed tools to acquire physical memory from Apple’s Macintosh computers, but they have not much been tested. This work in progress tested three major OS X memory-acquisition tools. Although all tools tested could capture system memory in most cases, the open-source tool OSXPmem bettered its proprietary counterparts in reliability and support for memory configurations and versions of the OS X operating system. Keywords: Digital forensics Á Acquisition Á Main memory Á Apple Á Macintosh OSX Á Testing Á MacQuisition Á OSXPMem Á RECON Á Reserved area 1 Introduction Recent Macintosh OS X operating systems incorporate many recent anti-forensic features, most notably cloud storage and encryption. Users can fully encrypt many things including whole operating system volumes, making it impossible to recover forensic evidence in a reasonable time frame without passwords. Because of this, forensics on the main memory of such systems is increasingly valuable. Memory forensics can recover encryption keys, network packets, injected code, hidden pro- cesses and communications from volatile memory. While there are many memory-acquisition tools and analysis programs for Win- dows operating systems, there are only a few for Macintosh systems. Ligh et al. (2014) provides a survey of information pertaining to Macintosh OS X memory forensics. A resource is the Rekall Memory Forensic Framework which began as a branch within the Volatility Project (Volatility, 2015) and became a stand-alone project in December 2013 (Rekall, 2015). Since main-memory capture is challenging, it is helpful to compare these tools to see what differences they have. 2 Methodology This work tested three tools: BlackBag Technologies MacQuisition, Version 2014R1; OSXPMem, Version RC3; and Sumuri Forensics RECON, Version 1.0.11 (Leopard, 2015). The systems were first tested with OS X Mavericks (10.9.5), and then after © ICST Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 2018 P. Matoušek and M. Schmiedecker (Eds.): ICDF2C 2017, LNICST 216, pp. 175–180, 2018. https://doi.org/10.1007/978-3-319-73697-6_13

176 C. B. Leopard et al. upgrading to Yosemite 10.10.1 and 10.10.2. Each tool was directed to write a memory capture to an external USB 3 hard drive (7200RPM). In total 450 captures were performed (50 machines, 3 operating systems, and 3 forensic tools). We evaluated the success rate with respect to (1) the ability of the tools to write a physical-memory capture without crashing the computer system; (2) how obtrusive the tool was (what its memory footprint was and how long it took to run); and (3) its ability to produce a capture from which standard forensic artifacts could be recovered using two memory-analysis tools, the Volatility Framework and the Rekall Memory Forensic Framework. The Rekall plugins used were arp, ifconfig, lsof, mount, net- stat, psaux, and route, and the Volatility plugins used were mac_arp, mac_bash, mac-ifconfig, mac_lsof, mac-mount, mac_netstat, mac_psaux, and mac_route. We were particularly interested in differences between the memory snapshots obtained since they could indicate functional differences or coverage gaps of the tools. The Passware Password Recovery Kit Forensic Version 13.1 was used to the confirm that encryption keys for FileVault2 were located within the OS X memory captures and could be used to decrypt the volume. To do this, FileVault2 was enabled on a MacBook Pro and a Mac Pro computer running Mavericks as well as on a MacBook Pro and a Mac Pro computer running Yosemite. Memory captures were done with MacQuisition, OSXPMem, and RECON on both the MacBook Pro and Mac Pro computers running Mavericks. RECON failed to capture physical memory from the Mac Pro computers. OSXPMem was used to capture memory from the Mac Pro and MacBook Pro running Yosemite. MacQuisition does not support Yosemite. The rate at which memory changes affects the memory dumps acquired by tools. To analyze this we created a virtual machine using VMware Fusion Professional version 7.1.1, and used VMware to take a series of snapshots. The virtual machine ran Mav- ericks and was configured to use two processor cores and 8 GiB of memory. The host machine was a MacBook Pro (Retina, 15-inch, Mid 2014) with a 2.8 GHz Intel i7 processor and 16 GiB of 1600 MHz DDR3 memory. Our procedure was: (1) log into the VM and take a snapshot every fifteen minutes; (2) use the Volatility plugin to decompress the snapshots; (3) create MD5 hashes for every 4 KiB block using MD5Deep; (4) compare the MD5 hashes with the original hashes and note differences; (5) and repeat three times. We compared memory captured by each of our tools against the VM Snapshot that completed at a time closest to when each capture completed. We then compared the memory captures taken with the tools. To control for potential variations due to VMware’s environment, we tested the tools on a physical Mac Mini (late 2014) with a 2.6 GHz Intel i7 processor, and 8 GiB of 1600 MHz DDR3 memory, running Mavericks. The memory captures were taken over a period of 30 min. 3 Results Memory-acquisition speeds were within 7% for the three tools. Physical memory sizes were 67.45 MiB for MacQuisition, 0.944 MiB for OSXPmem, and 206.7 MiB for RECON, and shared memory and private memory sizes were proportional. OSXPmem had the advantage that it is a command-line tool without a graphical user interface.

Memory Forensics and the Macintosh OS X Operating System 177 We observed several crashes caused by tools. The machines that crashed were not the same nor did any one machine crash more than once. After a crash, a second acquisition attempt was often successful after the machines restarted. The exception was when RECON was used to acquire memory from the Mac Pros with 64 GiB of RAM; all the machines crashed and additional attempts also failed. Valuable forensic data is often permanently lost in a crash, so crash danger is important. Nonetheless, our experiments confirmed that if a memory capture was completed without a crash, then the capture contained every forensic artifact found by the other tools on any run. The Passware Password Recovery Kit located the encryption keys in all of the memory captures and successfully decrypted the FileVault2 volumes. The OS X user’s login password was located within all the memory captures using the hex editor iBored by searching for the term “longname” which we found frequently near a user’s pass- word. The password remained in the same block of memory during the thirty-minute period on all captures. In another experiment, VM snapshots were taken over a period on a VM with Mac OS version Mavericks installed. A Python script counted the 4 KiB blocks whose hash values changed from the original snapshot. Results showed that on average only 5.33% of the blocks had changed after 30 min when running default processes. Memory captures were considerably larger than the allocated physical memory due to the presence of reserved areas. The datasheet for 4th Generation Intel Core Processor Address Map describes reserved areas below 4 GiB that do not belong to the DRAM. A similar structure was observed in the virtual machines. The vmem files containing the memory in the VM snapshots were converted to raw images. Each vmem file as well as each tool memory capture was 9 GiB in size, though the VM configuration allocated 8 GiB to physical memory. (Stuttgen and Cohen, 2015) discuss how physical memory addresses are used for communication with devices (video cards, PCI cards, and flash memory) on the motherboard with memory-mapped I/O. The 1 GiB block ranges observed between 3 GiB and 4 GiB appear to be reserved for this. The chipset routes memory access around these reserved regions so that all RAM is used. This increases the size of memory captures. All three tools captured the same range of null values observed in the first half of the memory graphs. The MacQuisition device log reported “bad addresses” were padded with zeroes beginning at block 786432 and ending at block 1048575. Each block contained 4096 bytes resulting in approximately 1 GiB of null characters. We inspected the block range in all three tool memory captures with a hex editor and confirmed that all the tools padded the same block range with zeroes. Comparisons were done of the tool memory captures and the VM memory snap- shots taken at 1 min after logging in to system, as well as the results of each tool memory capture compared to each other. Overall, we saw similar regions of non-null matches in all comparisons. However, the tool memory captures showed that most of the null characters observed in the VM snapshots were overwritten with data when the acquisition tools themselves acquired the memory. This would suggest as the memory-capture tools run, blocks of memory containing null characters get changed while other blocks remain mostly unchanged. Since these regions are large and outside the memory space used by the tools, it is unlikely that the tools themselves are

178 C. B. Leopard et al. changing the data directly. Rather, we conclude that some other mechanism of the operating system is writing to unused space in memory during the acquisition process. Figure 1 shows example 4 KiB block matches between the tool-acquired memory captures and the VM snapshot SV1 (initiated at time = 1 min). The three plots show MacQuisition, OSXPmem, and RECON. Red blocks represent matches to the initial memory state which do not contain null (zero) characters; grey blocks represent blocks that match but contain null characters; and the white blocks represent blocks that have changed and do not match. The top of the diagram represents the beginning of memory, and each row represents 1024 blocks from left to right in 4 KiB block increments, so each horizontal slice represents 4 MiB of memory. Fig. 1. Comparison of MacQuisition, OSXPmem, and RECON (left to right) on an analogous memory state. (Color figure online) The OSXPmem data shows a reserved area that appears to agree with the output of the MacQuisition captures, again beginning at approximately the 2 GiB and continuing to 4 GiB. A range of blocks located just before the 6 GiB mark changed between OM2.5 and OM30. The edge of the red area in the figure on the right has shifted and the region of matching blocks is less. The RECON data agree with other tools about the

Memory Forensics and the Macintosh OS X Operating System 179 location of reserved regions. The graphs also showed that a range of blocks, located just before the 6 GiB mark, changed between the memory capture at T2.5 and the capture at T30. The edge of the red areas between the figures was similar to before. Data showed that the matching blocks without null characters (red) change over time by a relatively small percentage. These results were supported by the VM snap- shots. It is clear that certain regions of memory are consistently captured while other regions are always in flux. Tests showed that slightly more than the first GiB of the memory capture always matches the VM snapshot. Many null values occur between the third and fourth GiB of memory which appears to be a reserved area. Two more significant blocks of null characters follow while the remaining memory appears to have changed during the acquisition. Our tests showed that the tools represented the non-match regions (white areas) differently. This suggests not only that the tools are introducing considerable change to the memory space during the acquisition process, but also that each is changing the space in a unique way, so the changes from different tools do not match each other. The memory-acquisition tools were also tested in non-virtual environment. The Mac Mini was configured with 8 GiB of physical memory, and each tool acquired a 9.74 GiB raw file. All three tools captured the same range of null values in the first half of the capture. This reserved area appears to be larger than in the VM memory images. Analysis with a hex editor determined that the reserved region began at 2.17 GiB and continued until 4 GiB. Data also showed that the block matches that contain non-null characters begin at approximately 30% of the total captured material, but remain rel- atively stable, declining by less than 10% over a 30 min period (Fig. 2). The match percent was less than what observed in the virtual environment. Fig. 2. Match Percentage Comparison over Time (“Column 1” = RECON). 4 Conclusions MacQuisition, RECON, and OSXPmem were all successful in capturing memory from OS X Mavericks on Macintosh computers. They captured valuable artifacts such as FileVault2 encryption keys and volatile system data. Nonetheless, (Ligh et al., 2015)

180 C. B. Leopard et al. acknowledges the risk of memory-acquisition tools causing system crashes as we observed since these can be sensitive to the OS X version or the installed hardware on the system. The tool may access a reserved region or interfere with a system-critical function. Our results showed that size of the memory capture was constant over the tools. Memory dumps were larger than the amount of physical memory (17.99 GiB versus 16 GiB for MacBook Pro was typical) due to regions reserved for firmware, ROM, and other PCI resources. Comparison of the VM snapshots taken over thirty minutes showed that with only the default processes, memory changed only slightly. Volatility and Rekall revealed many valuable forensic artifacts remaining such as encryption keys and volatile system data. Our evidence further suggested that the tools are acquiring the blocks of memory that are not changing between captures. Though there were significant regions of memory that did not match between the tool-acquired dumps and the VM snapshots, these regions corresponded with memory blocks that contained nulls in the baseline. Our analysis of forensic artifacts using the Volatility and Rekall frameworks failed to detect any situations in which the non-matching regions corresponded to a loss of forensic evidence, since the regions or memory appear to have contained nulls before the memory acquisition. The experiments with a non-virtual environment showed the tools successfully captured memory from a Mac Mini running Mavericks. We observed the memory captures from all three of the tools appeared similar as far as the blocks that matched and did not match as well for the blocks containing null characters. The results also agree with the results of our tests in the virtual environment in that the regions of memory that match between comparisons did not change much over time. Future work will examine in more detail the exact changes in files over time and the discrepancies between different tools. Discrepancies suggest, without having to analyze the operating system, where volatile memory stores key operating-system parameters and links. Future work will also investigate the effects of simultaneously running various kinds of software on the operating-system memory images. Acknowledgements. The views expressed are those of the authors and do not represent the U.S. Government. References Intel Corporation: Desktop 4th Generation Intel Core Processor Family, Desktop Intel Pentium Processor Family, and Desktop Intel Celeron Processor Family (2012). www.intel.com/content/ dam/www/public/us/en/documents/datasheets/4th-gen-core-family-desktop-vol-2-datasheet.pdf. Accessed 25 May 2015 Leopard, C.: Memory forensics and the Macintosh OS X operating system. M.S. thesis, U.S. Naval Postgraduate School, June 2015 Ligh, M., Case, A., Levy, J., Walters, A.: Art of Memory Forensics. Wiley, Indianapolis (2014) Rekall Team: Rekall Memory Forensic Framework: About the Rekall Memory Forensic Framework (2015). www.rekall-forensic.com/about.html. Accessed 13 March 2015 Stuttgen, J., Cohen, M.: Anti-forensic resilient memory acquisition. Digital Invest. 10, S105– S115 (2013) Volatility foundation: the volatility foundation – open source memory forensics (2015). www. volatilityfoundation.org/#!about/cmf3. Accessed 13 March 2015

Sketch-Based Modeling and Immersive Display Techniques for Indoor Crime Scene Presentation Pu Ren1,2, Mingquan Zhou1,2, Jin Liu3, Yachun Fan1,2, Wenshuo Zhao4, and Wuyang Shui1,2(&) 1 College of Information Science and Technology, Beijing Normal University, Beijing, China [email protected] 2 Engineering Research Center for Virtual Reality Applications, MOE, Beijing, China 3 Institute of Forensic Science, Ministry of Public Security, Beijing, China 4 General Office, Ministry of Public Security, Beijing, China Abstract. The reconstruction of crime scene plays an important role in digital forensic application. Although the 3D scanning technique is popular in general scene reconstruction, it has great limitation in the practice use of crime scene presentation. This article integrates computer graphics, sketch-based modeling and virtual reality (VR) techniques to develop a low-cost and rapid 3D crime scene presentation approach, which can be used by investigators to analyze and simulate the criminal process. First, we constructed a collection of 3D models for indoor crime scenes using various popular techniques, including laser scanning, image-based modeling and software-modeling. Second, to quickly obtain an object of interest from the 3D model database that is consistent with the geo- metric structure of the real object, a sketch-based retrieval method was proposed. Finally, a rapid modeling system that integrates our database and retrieval algorithm was developed to quickly build a digital crime scene. For practical use, an interactive real-time virtual roaming application was developed in Unity 3D and a low-cost VR head-mounted display (HMD). Practical cases have been implemented to demonstrate the feasibility and availability of our method. Keywords: Forensic science Á Indoor crime scene presentation 3D model database Á Sketch-based retrieval Á Rapid modeling Immersive display 1 Introduction In case of criminal incidents, the first phase of inspection and investigation is to rapidly record a complete, objective crime scene representation without erroneous information [1]. In comparison to traditional methods, i.e., verbal descriptions, hand-drawn sketches, photos, videos, etc., the use of 3D crime scene presentation is more intuitive and effective [2, 3]. Although 2D photos, videos and spherical photographs have been used in the courtroom, there are challenges in using these resources to describe and present the crime © ICST Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 2018 P. Matoušek and M. Schmiedecker (Eds.): ICDF2C 2017, LNICST 216, pp. 181–194, 2018. https://doi.org/10.1007/978-3-319-73697-6_14

182 P. Ren et al. scene because these resources only provide information from a given view [4, 5]. 3D presentation enables investigators to virtually experience the crime scene, measure the distances between different objects and simulate the criminal activity. A powerful and effective way of presenting a 3D crime scene was proposed in this context. In recent studies of forensic investigation, the use of a terrestrial laser scanner (TLS) or RGB-D camera has become a popular technique for the acquisition of 3D models of indoor crime scenes and evidence. The time-of-flight laser scanner, structure-light scanner and triangulation-based scanner have been used to acquire both the large-scale geometric information of crime scenes and the small-scale geometric information of evidence and victims [1, 3, 4, 6, 7]. These noninvasive scanners can be used to accurately generate a digital model after registration of range images and mesh processing. However, these devices are always expensive and the generation of digital models from unorganized point clouds is always based on manual and expert proce- dures. It is difficult to widely promote the application of this technique in local police stations. To address this problem, another type of modeling method is to produce a realistic 3D digital model from a series of images, the procedures for which comprise camera calibration, dense point-cloud computation, surface reconstruction and post-processing [8–11]. The quality of a reconstructed model depends largely upon the algorithm used to calculate feature correspondence and camera calibration. Further- more, it is time consuming and expensive to use these optical device based methods. Considering investigators would like to quickly represent the spatial information of crime scenes, the use of professional software, for example AutoCAD, 3Ds Max, SketchUp, etc., is the most common, intensive and powerful technique for 3D crime scene representation [12–15]. However, one potential problem of this technique is that investigators have no professional training or experience in producing 3D models using software. In addition, this work is tedious and time consuming, because hundreds of 3D models should be generated for a crime scene. We have observed that in traditional practical crime investigations, policemen are often tasked with recording the indoor layout in hand-drawn sketches. Inspired by this observation and existing literature, this article presents an effective way to build a digital indoor crime scene to record the spatial relationships of objects for crime analysis and presentation. Additionally, rather than relying on sketches of the layout and objects, investigators can directly obtain a 3D scene using our system and explore this virtual scene anywhere and at any time. 2 Materials and Methods 2.1 A Specialized 3D Model Collection The high quality and large number of 3D models in the collection improved the pre- sentation of the 3D crime scene. By collecting more categories and a larger number of models in each category, one can retrieve a larger number of appropriate objects. In this study, we used existing laser-scanning, image-based modeling and software-modeling techniques to generate 3D models. We have constructed a 3D model database including crime-related models and common models in indoor scenes.

Sketch-Based Modeling and Immersive Display Techniques 183 Some objects that appear in a crime scene are unique and cannot be replaced by the existing models in the database. Thus, we used laser-scanning and image-based modeling techniques to capture real data of critical evidence. We used a high-precision hand-held laser scanner HandySCAN 700 (Creaform Company, Canada) to reconstruct 3D models of objects. The benefit of this laser scanner is that it automatically produces complete single mesh models, without the procedure of manual range-image regis- tration in other scanners (e.g., Vivid 910 laser scanner). Figure 1 shows some examples of 3D models captured by laser scanner. In addition to some crime tools there are two shoes and soles (usually very important evidence) in this figure. The main benefit of this technique is that it acquires high-quality 3D models with more details. However, the high cost of the device prohibits its widespread use. Fig. 1. 3D models capture by laser scanner. (Crime-fighting tools and shoe soles.) The structure-from-motion (SFM) technique is used as a substitute in cases in which the laser scanner cannot be used. Inputting a set of photos of the object, a powerful and free tool called VisualSFM [16, 17] was used to generate a dense 3D point cloud with color. Figure 2 shows some examples of 3D models acquired by the SFM technique. Fig. 2. 3D models reconstructed by SFM technique. Left: a chair with clothes on it. Middle: a mass of clothes. Right: a plush toy. (Color figure online) To construct a mesh model from point clouds, the open-source software Meshlab was used to realize surface reconstruction and post-processing [18]. In Meshlab, the normal vector at every point was estimated and the Poisson surface reconstruction

184 P. Ren et al. algorithm was used to generate a mesh model. This technique is easier to use than 3D scanning since it is convenient to acquire multiple photos for evidence. To extend the number and categories of 3D models, we collected 3D models from online public-domain galleries, such as the Google 3D Warehouse, which offers thou- sands of models online [12], and the public database from literature [19]. As a sup- plement, some models were created by professional designers using geometric modeling software. Figure 3 shows some examples of 3D models created using commercial software (SketchUp, 3Ds Max). Figure 3(a) shows 3D models of furniture. Moreover, the victim’s posture plays a significant role in crime investigation. Thus, multiple types of human models with various postures are available in our database to ensure that the most similar one to the real situation would be found (Fig. 3(b)). In summary, we offered a total of 2,564 models and 18 categories in our collection, including windows, doors, home appliances, furniture, human bodies, and criminal tools. Table 1 lists the main types of models from different sources in our database. The decisive evidence refers to some material evidence which play a decisive role in the real investigation. Fig. 3. A collection of 3D models in the crime scene. (a) Furniture models with various shapes. (b) Human models with various postures.

Sketch-Based Modeling and Immersive Display Techniques 185 Table 1. 3D model database. Source Online Open Software Laser Image-based Total libraries literature modeling scanning modeling 2,161 Indoor models 1,123 659 361 0 18 393 0 135 12 6 10 Murder related 240 0 3 5 2 2,564 Decisive evidence 0 Total 2.2 Method I. Sketch-based indoor scene modeling It is a challenge to rapidly obtain the appropriate model from large collections of 3D models since public collections are often insufficiently annotated [20]. To address this problem, the content-based retrieval technique is a powerful and effective tool. The general idea of the sketch-based method is that the user retrieves the desired model through the input of a hand drawing. In this study, our sketch-based retrieval was divided into two stages: offline index and online query. To save time in a real-time query, we perform the computation offline as much as possible. Figure 4 shows the framework of our algorithm and Fig. 5 shows one of the retrieval results. The input sketch is shown on the upper left, and the first couch model is the most similar model in the database. The key steps of our algorithm are described below. Fig. 4. The framework of our sketch-based retrieval algorithm. Fig. 5. Retrieval results using sketch-based technique. The left figure shows an input of hand drawing by user. Right figure shows the first nine most similar models. Step 1: Line-drawing calculation. The essence of 3D model retrieval is to evaluate the similarity between hand-drawn sketches and models. Towards this end, 3D information should be first projected into 2D images. 2D line drawings are extracted from 102

186 P. Ren et al. viewpoints of geodesic geometry for each model in the database, reflecting the visual information as much as possible. Different from most of the previous line-drawing extraction algorithms, which were only available for homogeneously distributed dense meshes, we proposed a depth map-based difference-of-Gaussian (DoG) method to extract lines, including the boundaries and creases formed by differences in depth. The information in the depth buffer is used to generate depth images with different Gaussian parameters, called D1 and D2, and the line drawing is generated by calculating the inverse of binary image, i.e., the Gaussian difference of D1 and D2. To overcome the saw tooth noise problem, the Bezier curve approximation is used to perform the line stylization and obtain a smooth contour line [22]. Step 2: Feature extraction. We used a spatial, high-dimensional local feature- description algorithm to extract features. As a type of short-time Fourier transform, Gabor transform is sensitive to the edges of an image. It can provide good selection for frequency and orientation. In addition, the Gabor filter is similar to the mammalian visual system in the expression of frequency and orientation. It is suitable for sketch retrieval requests. Thus, we use an algorithm called the Space Pyramid of Gabor Local Feature Extraction and obtain better results [20]. Next, we define a set of Gabor filters giði ¼ 1; 2; . . .; kÞ to calculate the basic transform of the feature region, and the information on the spatial distribution is obtained in the space pyramid of the image. For each gi and image I, a convolution computation is employed to obtain a response image Ri: Ri ¼ kidftðgi à dftðIÞÞk ð1Þ where * denotes point-wise multiplication, and the function dft() and idft() respectively denote the discrete Fourier transform and the inverse discrete Fourier transform. A grid-sampling method is used for feature-point sampling. For a local shape feature, we divide the region into n  n cells Crc, in which r and c respectively denote the row and column coordinates. The descriptor in the i direction is a feature vector of size n  n. Fðr; c; iÞ ¼ 1 X Riðx; yÞ ð2Þ N ðx;yÞ2Crc where N denotes the sample number for which Riðx; yÞ 6¼ 0 in the i direction. The local feature is a k  n  n dimensional vector. Step 3: Sorting by similarity. We employed TF-IDF [21] to calculate the similarities of feature vectors among various models. In an ideal situation, the first-place model is the desired model, and then we import it into the crime scene. As the retrieval algorithm is not the focus of this work, readers can find more complete algorithm details in our other work [22].

Sketch-Based Modeling and Immersive Display Techniques 187 II. System interface Our system was developed on the basis of open-source software SweetHome3D licensed under the GNU General Public License [23]. We developed the sketch-based algorithm in Microsoft Visual Studio in C++ and exported to a Dynamic-link library (dll) file. This dll file was imported as a plugin on a new user interface implementing sketch-based function. Our proposed 3D crime scene representation system contains five modules (see Fig. 6): (a) the user draw a sketch of the desired from any viewpoint at the left-top area, and the retrieval results are displayed on the bottom, sorted according to similarity; (b) a 2D plan view that referring to the ichnography, can be loaded into this module as a base map where the layout of the indoor scene and the selected model can be transformed to the designated location (translation, rotation and scale); (c) a 3D display view where the 3D model scene corresponding to the 2D plan view is displayed and the user can observe the scene from any view and roam the scene as a virtual character; (d) a model classification and viewing tree in which a collection of 3D models is classified according to the given classification scheme and every model can be selected and viewed; and (e) a scene management interface where the param- eters and statues of every model can be edited. Fig. 6. Interface of our system. (a) Sketch retrieval interface. (b) 2D plan view. (c) 3D display view. (d) Model classification and viewing tree. (e) Scene management interface. The major advantage of our system is that simple 2D sketches can be rapidly transformed into a complex 3D crime scene. In the first stage, users need to draw a sketch on the sketch-retrieval interface to obtain the desired objects from the database directly. Second, the retrieved models are placed on the 2D plane view and the cor- responding 3D scene is simultaneously rendered on the 3D display view. The user can either view the 3D scene from any directions or roam in it anywhere and at any time. In the scene-management module, users can adjust the parameters and status of the chosen

188 P. Ren et al. model, including visibility, texture, object position and size. Another notable feature of our system is that it is easy to measure the distance between two objects (Fig. 7). In the 3D scene shown in (a), the distance between the body and the murder weapon can be easily measured by connecting them with a line as shown in (b). Finally, the 3D crime-scene representation can be exported as a standard .obj files. Fig. 7. The distance measuring function of the system. III. Immersive display As a supplement to the virtual roaming function provided by our system, a helmet-mounted display (HMD) device, such as HTC Vive, can be used to increase the immersive VR effect. This device has a high resolution of pixels, resulting in a reso- lution of pixels for each eye. HTC Vive provides a pair of handheld controllers and positioning-system tracking display, which allow the user to move within a certain scope and interact with the virtual scene using the handle [4]. These advantages are very suitable for the virtual representation of crime scenes. Utilizing the encapsulated SDK in the cross-platform game engine Unity3D (Unity Technologies, San Francisco, USA), we developed a VR roaming system for crime scenes. The 3D model scene built with our proposed sketch-based indoor-scene system can be imported into Unity3D and real-time interactive virtual-experience systems are developed using Microsoft Visual Studio C#. In comparison to the traditional PC screen, the immersive display offers a larger viewing volume and more realistic experience. With the headset and handle, the investigator can enter the crime scene in digital space, observe 3D models of physical evidence, and analyze the case from a more intuitive angle. 3 Illustrative Example To demonstrate the availability and effectiveness of our system, we quickly present an example of how to create an acceptable 3D crime scene for presentation from series of 2D sketches. We took a criminal case happened fifteen years ago as an example;

Sketch-Based Modeling and Immersive Display Techniques 189 specifically, three adults and one child were killed in an apartment (Fig. 8). The only remaining visual documents for this case are several low-resolution photos and a hand-drawn floor plan of the crime scene. Using our system, we can rapidly reconstruct this indoor scene and develop a roaming system in VR space. Fig. 8. The floor plan of the crime scene in our example. Although very few visual records of this case are available, the floor plan is a crucial piece of physical evidence for crime-scene reconstruction. By importing the hand-drawn floor plan into our system as a base map, we obtained the measurements and layout information of 3D models (Fig. 9a). Then, the user dragged the mouse to draw 2D shapes of walls on the 2D plan view according to the tracing lines of the imported base map, and the 3D scene was rendered in the 3D display view in real time (Fig. 9b). To enable the accurate representation of the 3D crime scene, the user scaled each shape according to the real measurement values, i.e., user defined the length, height and width of the indoor scene. The main contribution of our approach is the sketch retrieval function in this system. Figure 9c shows an example of retrieving the sofa. The retrieved model was imported into the 2D plan view and placed at the designated location, according to the base map. All the textures of imported models can be exchanged according to the real scenario (Fig. 9d). These steps were repeated until all objects were imported and transformed to the correct locations. Figure 10 shows the 3D scene of this crime that was constructed using our system, which consisted of a total of 58 digital models and was rebuilt in a total of 13 min. The top two screenshots are bird’s eye view and the bottom two are roaming perspective.

190 P. Ren et al. Fig. 9. Sketch-based modeling for the indoor crime scene. (a) Importing the hand-drawn floor plan as a base map. (b) Reconstruct the walls. (c) Retrieving 3D models by sketches. (d) Changing the textures. Fig. 10. The creation of 3D indoor crime scene using our system.

Sketch-Based Modeling and Immersive Display Techniques 191 To virtually experience this crime scene in an immersive display, the created crime scene can be exported as a standard .obj file, and an interactive virtual roaming system was developed in Unity3D, enabling investigators to experience the crime scene from a fixed viewpoint or different views to examine more details of the evidence of interest. Figure 11 shows the immersive roaming effect using HTC Vive. In this application, the user can intuitively simulate and analysis the shooting and walking routes of the criminal in the virtual space. Fig. 11. Interactive crime scene experience in the immersive display using HTC Vive. Left: photo of the experiencer. Right: real-time screenshot. 4 Discussion In comparison to traditional recording approaches, e.g., 2D hand-drawn sketches, photos, videos, 3D digital scenes and animations have been used to enhance clarity and understanding in crime-scene investigation [2, 3, 7, 12, 14]. Although the laser- scanning technique provides life-like and accurate 3D models of crime scenes, it has limitations for widely promotion. For one hand, the devices are expensive. For another hand, it is still a great challenge to convert dense triangle meshes (more than hundreds of thousands of triangle meshes) into a simplified model to meet the requirement of real-time virtual experience. Another limitation is that many crime scenes cannot be entered after the criminal incident. In this situation, investigators need to model the scene manually. Clair et al. introduced the application of the easy-to-use modeling software SketchUp (version 8) to generate 3D indoor crime-scene models [12]. It was an extremely time-consuming process to generate every model. To solve this problem, Howard et al. constructed a collection of 3D models and generated the non-critical areas of digital crime scenes using the existing models [14]. One of the contributions of our work is utilizing multiple techniques to construct a large collection of 3D models for indoor scene. The 3D models with complex structures and more details, e.g., guns, knives, shoe soles, etc., were generated by laser-scanning or image-based modeling techniques. To enable real-time rendering of this model in Unity 3D, the open-source Meshlab software was used to convert this 3D model to a simplified model and texture.

192 P. Ren et al. Another contribution of our work is the sketch-based model retrieval. Because of the large number of models in the collection, investigators have become more com- fortable and it has become easier to generate a crime scene by our method. However, it is also a challenge for investigator to rapidly obtain the desired model from datasets. Compared with the traditional text-based retrieval methods, the 2D hand-drawn sketch-based approach has much more potential in our application since few annota- tions are available for each 3D model. In this paper, we propose a sketch-based approach to obtain a suitable model with geometric structure similar to that of the real object from the database. To achieve real-time retrieval, we have extracted and archived the feature lines of every model in advance. Because of this main part of our work, crime scenes can be rebuilt quickly using policemen’s hand-drawn sketches rather than those of professional designers. To better provide a crime-scene model, a multi-participant, large-screen stereo- scopic projector system [14], an immersive display VR headset [4], and the augmented-reality technique have been used in previous studies [24]. In our article, we provided a general system covering the functions of rebuilding an indoor crime scene and rendering it in 3D space. To realize immersive display, the rebuilt scene model was imported into Unity 3D to develop a VR roaming system in HTC Vive. There are still some limitations of our approach. We have successfully extended the crime scene model database, but both the number of category in the database and the number of models in each category are insufficient for crime-scene presentation. We will continue to generate multiple kinds of models to build an extensive crime-scene model database. A system allowing the user to retrieve multiple 3D models at the same time is also helpful in practice. 5 Conclusion Based on the 3D model collection, a sketch-retrieval based modeling system was developed. Because of the TF-IDF algorithm, our method achieves high retrieval accuracy and time efficiency. Using our approach, police investigators can rapidly record the spatial relationships of objects while constructing a digital model of the indoor crime scene. In comparison to laser-scanning and software-modeling tech- niques, the main advantage of our method is that it is low cost and rapid, making it very suitable for criminal investigation. In terms of digital forensics and educational training applications, the immersive-display we developed has broad prospects because of the VR interactive experience in the crime scene. Acknowledgement. The authors would like to thank the anonymous reviewers. Special thanks to all the members of SweetHome3D project. This work is supported by the National Natural Science Foundation of China (No. 61402042), the open subject of the key laboratory of traces of science and technology of Ministry of Public Security (No. 2014FMKFKT04) and the National Key Technology Research and Development Program of China (No. 2012BAH33F04).

Sketch-Based Modeling and Immersive Display Techniques 193 References 1. Sansoni, G., Cattaneo, C., Trebeschi, M., Gibelli, D., Poppa, P., Porta, D., et al.: Scene-of-crime analysis by a 3-dimensional optical digitizer: a useful perspective for forensic science. Am. J. Forensic Med. Pathol. 32, 280–286 (2011) 2. Ma, M., Zheng, H., Lallie, H.: Virtual reality and 3D animation in forensic visualization. J. Forensic Sci. 55, 1227–1231 (2010) 3. Hołowko, E., Januszkiewicz, K., Bolewicki, P., Sitnik, R., Michoński, J.: Application of multi-resolution 3D techniques in crime scene documentation with bloodstain pattern analysis. Forensic Sci. Int. 267, 218–227 (2016) 4. Ebert, L.C., Nguyen, T.T., Breitbeck, R., Braun, M., Thali, M.J., Ross, S.: The forensic holodeck: an immersive display for forensic crime scene reconstructions. Forensic Sci. Med. Pathol. 10, 623–626 (2014) 5. Tung, N.D., Barr, J., Sheppard, D.J., Elliot, D.A., Tottey, L.S., Walsh, K.A.: Spherical photography and virtual tours for presenting crime scenes and forensic evidence in New Zealand courtrooms. J. Forensic Sci. 60, 753–758 (2015) 6. González-Jorge, H., Zancajo, S., González-Aguilera, D., Arias, P.: Application of Kinect gaming sensor in forensic science. J. Forensic Sci. 60, 206–211 (2015) 7. Buck, U., Naether, S., Räss, B., Jackowski, C., Thali, M.J.: Accident or homicide–virtual crime scene reconstruction using 3D methods. Forensic Sci. Int. 225, 75–84 (2013) 8. Gibson, S., Howard, T.: Interactive reconstruction of virtual environments from pho- tographs, with application to scene-of-crime analysis. In: ACM Symposium on Virtual Reality Software and Technology, pp. 41–48 (2000) 9. Se, S., Jasiobedzki, P.: Instant scene modeler for crime scene reconstruction. In: 2005 IEEE Computer Society Conference on Computer Vision and Pattern Recognition Workshops, CVPR 2005, pp. 123–128. IEEE (2005) 10. Leipner, A., Baumeister, R., Thali, M.J., Braun, M., Dobler, E., Ebert, L.C.: Multi-camera system for 3D forensic documentation. Forensic Sci. Int. 261, 123–128 (2016) 11. Bostanci, E.: 3D reconstruction of crime scenes and design considerations for an interactive investigation tool. Computer Science, pp. 896–900 (2015) 12. Clair, E.S., Maloney, A., Schade, A.: An introduction to building 3D crime scene models using SketchUp. J. Assoc. Crime Scene Reconstr. 18, 29–47 (2012) 13. Maksymowicz, K., Tunikowski, W., Kościuk, J.: Crime event 3D reconstruction based on incomplete or fragmentary evidence material–case report. Forensic Sci. Int. 242, e6–e11 (2014) 14. Howard, T.L., Murta, A.D., Gibson, S.: Virtual environments for scene of crime reconstruction and analysis. In: Electronic Imaging: International Society for Optics and Photonics, pp. 41–48 (2000) 15. Bevel, T., Gardner, R.M.: Bloodstain Pattern Analysis with an Introduction to Crime Scene Reconstruction. CRC Press, Boca Raton (2008) 16. Wu, C.: Towards linear-time incremental structure from motion. In: 2013 International Conference on 3D Vision-3DV 2013, pp. 127–134. IEEE (2013) 17. Jancosek, M., Pajdla, T.: Multi-view reconstruction preserving weakly-supported surfaces. In: 2011 IEEE Conference on Computer Vision and Pattern Recognition (CVPR), pp. 3121– 3128. IEEE (2011) 18. Cignoni, P., Callieri, M., Corsini, M., Dellepiane, M., Ganovelli, F., Ranzuglia, G.: MeshLab: an open-source mesh processing tool, pp. 129–136. Eurographics Association (2008)

194 P. Ren et al. 19. Fisher, M., Ritchie, D., Savva, M., Funkhouser, T., Hanrahan, P.: Example-based synthesis of 3D object arrangements. ACM Trans. Graph. 31, 135 (2012) 20. Eitz, M., Richter, R., Boubekeur, T., Hildebrand, K., Alexa, M.: Sketch-based shape retrieval. ACM Trans. Graph. 31, 31:1–31:10 (2012) 21. Zobel, J., Moffat, A.: Inverted files for text search engines. ACM Comput. Surv. 38, 1–56 (2006). Article no. 6 22. Qian, L., Fan, Y., Zhou, M., Luan, H., Ren, P.: Manifold ranking for sketch-based 3D model retrieval. In: Pan, Z., Cheok, A.D., Müller, W., Zhang, M. (eds.) Transactions on Edutainment XIII. LNCS, vol. 10092, pp. 149–164. Springer, Heidelberg (2017). https://doi. org/10.1007/978-3-662-54395-5_14 23. http://www.sweethome3d.com/ 24. Gee, A.P., Escamilla-Ambrosio, P.J., Webb, M., Mayol-Cuevas, W., Calway, A.: Augmented crime scenes: virtual annotation of physical environments for forensic investigation. In: Proceedings of the 2nd ACM Workshop on Multimedia in Forensics, Security and Intelligence, pp. 105–110. ACM (2010)

An Overview of the Usage of Default Passwords Brandon Knieriem, Xiaolu Zhang, Philip Levine, Frank Breitinger(B), and Ibrahim Baggili Cyber Forensics Research and Education Group (UNHcFREG), Tagliatela College of Engineering, University of New Haven, West Haven, CT 06516, USA {bknie1,plevi1}@unh.newhaven.edu, {XZhang,FBreitinger,IBaggili}@newhaven.edu Abstract. The recent Mirai botnet attack demonstrated the danger of using default passwords and showed it is still a major problem. In this study we investigated several common applications and their password policies. Specifically, we analyzed if these applications: (1) have default passwords or (2) allow the user to set a weak password (i.e., they do not properly enforce a password policy). Our study shows that default pass- words are still a significant problem: 61% of applications inspected ini- tially used a default or blank password. When changing the password, 58% allowed a blank password, 35% allowed a weak password of 1 character. Keywords: Default passwords · Applications · Usage · Security 1 Introduction In October 2016, a large section of the Internet came under attack. This attack was perpetuated by approximately 100,000 Internet of Things (IoT) appliances, refrigerators, and microwaves which were compromised and formed the Mirai botnet. Targets of this attack included Twitter, reddit and The New York Times all of which shut down for hours. The Mirai botnet was created by abusing default credentials in IoT devices [7,14]. Besides devices, there are also applica- tions permitting users access to critical central resources such as Database Man- agement Systems (DBMS), Web Server Applications, and Content Management Systems (CMS). For instance, in July 2014 hackers attacked HealthCare.gov [18]. Fifteen days later HealthCare.gov released a statement that only the test servers were hacked and no personal information was compromised. The attack occurred because the manufacturer’s default password on the server had not been changed. Days later, despite reporting on this vulnerability, the default password had still not been updated [2]. These findings motivated us to perform two short surveys with the goal to start a discussion in the field about the usage of develop passwords: The first was to examine applications such as DBMS, Web Server Applications, and CMSs that enable a default password during initial configuration. Results show the c ICST Institute for Computer Sciences, Social Informatics and Telecommunications Engineering 2018 P. Matouˇsek and M. Schmiedecker (Eds.): ICDF2C 2017, LNICST 216, pp. 195–203, 2018. https://doi.org/10.1007/978-3-319-73697-6_15

196 B. Knieriem et al. most applications have default credentials. The second survey was conducted on developers to understand the use of default passwords. The results indicate that many services are designed with default passwords to bypass authentication to provide immediate, temporary access for quick, convenient initial set up of infrastructure and should only be used during this installation phase. Remark: The extended version of this article named ‘An Overview of the Usage of Default Passwords (extended version)’ can be accessed through digital com- mons1. 2 Literature Review “Passwords are an ubiquitous and critical component of many security systems” [19]. Therefore, it is important to create secure passwords that are difficult to compromise. For instance, according to [9], a strong password policy requires a minimum number of characters, different types of characters, and specify how frequently users should change their passwords. More recently, National Insti- tutes of Standards and Technology (NIST) Digital Authentication Guidelines have suggestions for improving security and reduce common issues [6]. These suggestions can be broken down into several main categories: hashing passwords, increasing user friendliness, enforcing an 8-character minimum, and banning common passwords. It suggests avoiding password rules, password hints, security questions, and never forcing arbitrary password changes [22]. These suggestions are a step in the right direction for new password policy, though despite being nearly a year old, have yet to be implemented by many application developers. 2.1 Breaches Exploiting Default User Credentials Although guidelines and warnings regarding default passwords exist, there are still many incidents involving default credentials. According to [4], “very few open source vendor advisories have mentioned default passwords, whereas they appear with some regularity in closed source advisories, even in the top 10 [vul- nerabilities] as recently as 2005”. A newer study named the Verizon Data Breach Report examined 621 cor- porate breaches. “The analysis found that 78% of initial intrusions into corpo- rate networks were elementary. Many attackers use a phishing attack, convincing employees to give up credentials, or brute force attack, taking advantage of weak or default passwords on remote services to gain initial access to the network” [20]. Unfortunately, the report did not mention, out of 78% how many consti- tuted weak passwords or default passwords. Notwithstanding, some of the recent breaches that were attributed to the misuse of default passwords. Utah Depart- ment of Health] suffered a breach of 780 k Medicaid patient health records [12] in addition to compromising more than 255,000 social security numbers [17]. Attackers achieved complete access to the system using a default password. 1 http://digitalcommons.newhaven.edu.

An Overview of the Usage of Default Passwords 197 A Bank of Montreal’s ATM was hacked by two 14 year old children; they used the machine’s default password [11]. Emergency Alert System (EAS)] equipment used to broadcast warnings was hacked by exploiting default passwords. After the breach, the hackers sent out an alert warning the public of a ‘zombie attack.’ [11]. Electronic Highway Billboards were attacked in June 2014. The hacker changed the signs to display their Twitter/hacker handle for all the highway drivers to see. This was an act of mischief reported by [8]. A recent WordPress incident demonstrated that the usage of a default user- name can result in a tremendous security risk. In case of WordPress, the default username is always ‘admin’. Hackers used that knowledge and used a botnet to brute force 90,000 IP addresses hosting different software [1]. Unfortunately, the report did not release how successful this attack was. 2.2 Taking Advantage of Default Passwords - Tools, Scripts and Malware Attackers, often taking an opportunistic approach, realized the potential in abus- ing default passwords to access a system. Thus, there are several tools, scripts, and malware that can be used for this purpose. Work [16] states “the most common password lists found using Internet search engines were default pass- word lists. These lists contain passwords used by hardware manufacturers as the default security setting”. In a recent article, [3] mentioned several tools that focus on exploiting default passwords. For instance, Cisco OCS Perl Script scans Cisco devices on a network by inputting ‘cisco’ into the password form. Metas- ploit includes multiple modules used for network default password scanning. On the other hand, several worms exist that use default passwords to prop- agate. According to [13], the ‘Voyager Alpha Force’ worm was used to demon- strate a vulnerability on Microsoft’s SQL Server with an administrator blank password using the default port: 1433. Similarly, MySQL required no password at the time of installation. A worm named “MySpooler” infected 8000 hosts at a rate of 100 hosts per hour [10]. In 2005, an anonymous developer disclosed a proof-of-concept worm that targeted Oracle databases using default usernames and passwords [23]. A particularly malicious worm implementation uses blend- ing viruses; which are viruses that run a daily Internet scan for vulnerabilities. One of the main functions of them are to find well known default passwords [5]. Work [15] triggered malnets; a combination of malware and bots initiated malware attacks on routers. A similar experiment was also performed by [24]. Regarding wireless malware propagation: 16.7% of routers were set to be config- ured with default settings. Only 10% of these routers used default passwords or did not have passwords set. 3 Applications Analysis To analyze the impact of default passwords we examined database management systems, Web server applications, and content management systems. We decided