Linux uses a logical directory tree to organize files into different folders.

Content Folder Changes

Continuing to move through the directory structure that was displayed by Xplorer360, the next folder in line that needed examination was the Content folder. There are many folders and subfolders throughout this top-level directory. The best way to proceed was to determine which folders contained files that had been altered by the game play. The only way to do this was to navigate through each folder and determine the changes, if any, which had occurred.

Viewing the information that is located within the Content folder revealed that there are four immediate subfolders. Each of these subfolders contains an additional layer of subfolders that may or may not contain associated files. Each of the folders had to be expanded and examined to determine any changes made. The initial review detailed that the second folder did not contain any files; therefore, further review was not needed. Figures 10.31 and 10.32 detail this information.

The third folder located under the Content folder contained one file for examination. This file was exported from the drive image using the features of Xplorer360, and then the file was imported into EnCase for examination. Reviewing the file revealed that it was a CON file, conforming to the format detailed in earlier chapters. The console security certificate was present, as to be expected with a CON file. Reviewing the data within the file revealed some interesting information. One of the first data entries that was of interest had a plain text entry referring to account information. It appeared as though there were calls to 32-bit and 64-bit entries for PNG files. The entire file was reviewed, and there were several PNG files that were located within the file; each was carved from the file and saved. There were references to an account, and there appeared to be two calls to 32-bit and 64-bit PNG files. Continued examination of the data within the file revealed that there were two PNG files that were one of the Gamertag icons created for the console—a 32-bit and 64-bit image. Figures 10.33 through 10.35 show this data.

Continued examination of this file revealed more plain text information, which appeared to be configuration information for the gamer's dashboard and other information. In short, this file appears to be a configuration file for the specific gamer, similar to a customized desktop of a multiuser PC. Figures 10.36 through 10.39 provide some screenshots of the data.

The fourth subfolder within the Content folder has two folders within it. Each folder contains files that need to be examined. The first folder contained a file that was not altered during the course of the game play. Figure 10.40 provides a screenshot.

The second subfolder here, the one titled “425307D5,” contained several files that needed to be examined. Although the file names provide some indication of the file's purpose, an examination still needs to be conducted. The files within this subfolder are the save game points that were generated during game play. Figure 10.41 shows the files as they represented in Xplorer360.

The files listed in Figure 10.41 were extracted from the drive image and imported into EnCase. The first of these files that was examined was the autosave.fxs file. This file contained several embedded PNGs that were icons used within the game to indicated game progression. Figure 10.42 provides a sample one of these icon files.

The details of the autosave file header show that the file is a CON file with the console security certificate. Additional information that is listed in plain text is the name of the character that was used, which was “templar,” along with the stage within the game that the game was saved. Figure 10.43 shows the EnCase view of this data. Each of the save game files follows this format.

The final section of the Content folder that requires examination is the very first subfolder, titled with all zeros. This folder contains several subfolders, each of which has a file within it. Initially, there were only nine folders located within this directory. Over the course of the game play, two additional folders were added. The first nine folders that were present are listed here in Figure 10.44, and the new folders are listed in Figure 10.45.

A review of the folders and the subsequent files revealed that two new folders were created and that one of the folders had an additional file added to it. The first folder that showed a change was labeled “FFFE07DF.” Within this folder, there were two files; one had a date that correlated to the game play. This new file was titled “InGameAccessTimes.” This file continues to comply with the format in other files that have been examined and is a CON file. The header of the file is the magic byte “CON” and the console security certificate is utilized once again. There were two embedded PNG files that were carved out. Figure 10.46 provides a snapshot of the files, Figure 10.47 provides a snapshot of the file header, and Figures 10.48 and 10.49 are the carved PNGs.

The last file for examination is located within the folder named “425307D5.” The file is reported as being 79 MB in size. The file was extracted from the image, imported into EnCase, and examined. Examination of this file revealed that it is the video trailer that was downloaded through the XBOX Live service that was available. Reviewing the information in EnCase provided many plain text strings that verify that this is a video file. The file header on this file reveals that it has the “magic” header of LIVE, so it would follow the details laid out in Chapter 6, “XBOX 360–Specific File Types.” Figure 10.50 shows the details revealed in hex view.

Where data is stored

The iPhone has a standard directory structure in which various files are stored (refer to Appendix C for a full listing of the folders and files recovered from an iPhone). Because it does not contain an external storage slot, all data are stored internally on the device (as opposed to other mobile devices that contain external SD cards or emulated SD cards). To display the iPhone's hierarchy, a jailbroken phone is remotely connected through Wi-Fi, using the same techniques as described in Chapter 5 – Imaging a Jail-broken Device. From a Macintosh computer, the phone is connected through SSH in order to navigate through the file system. Immediately upon logging in to the device, the “ls” command is used to list the directory contents.

3GS-40:/ root# ls -l

total 58

lrwxr-xr-x 1 root admin 23 Sep 17 12:11 Applications -> /var/stash/Applications/

drwxrwxr-x 2 root admin 68 May 31 2010 Developer/

drwxrwxr-x 14 root admin 680 Sep 17 12:11 Library/

drwxr-xr-x 3 root wheel 102 Jul 30 2010 System/

lrwxr-xr-x 1 root admin 11 Mar 4 10:20 User -> /var/mobile/

drwxr-xr-x 2 root wheel 2108 Sep 28 11:28 bin/

drwxr-xr-x 2 root wheel 68 Oct 28 2006 boot/

drwxrwxr-t 2 root admin 68 May 19 2010 cores/

dr-xr-xr-x 3 root wheel 1555 Mar 4 10:20 dev/

lrwxr-xr-x 1 root wheel 12 Sep 17 12:11 etc -> private/etc//

drwxr-xr-x 2 root wheel 68 Oct 28 2006 lib/

drwxr-xr-x 2 root wheel 68 Oct 28 2006 mnt/

drwxr-xr-x 4 root wheel 136 Feb 25 11:57 private/

-rw-r--r-- 1 root admin  15290 Sep 16 17:43 restore.log

drwxr-xr-x 2 root wheel 1326 Sep 17 12:11 sbin/

lrwxr-xr-x 1 root wheel 16 Sep 17 12:11 tmp -> private/var/tmp//

drwxr-xr-x 6 root wheel 306 Sep 17 12:12 usr/

lrwxr-xr-x 1 root wheel 12 Sep 17 12:12 var -> private/var//

Most of the data that an examiner would be interested in is stored in the “private/var/mobile/” path (on an iPhone disk image, the “mobile” folder will be at the root of the mounted image); however, valuable forensic evidence can also be found in other locations. Within the Mobile directory, there are three subfolders: Applications, Library, and Media. Any downloaded apps will be stored in the Applications folder in a format similar to that shown in Figure 3.1. Each downloaded application has an application identifier, which becomes the folder name and is the same across all devices, as shown in Figure 3.1.

The contents of each application folder are generally the same among all apps. Some standard folders and files include the following:

A Documents folder containing relevant files for that particular app, such as plists, text documents, or images;

A Library folder containing Cached data, Cookies, Preferences, and if applicable, WebKit data. “Preferences” is where user login data is commonly stored if that is required for the application being used;

The application bundle, which can be extracted to view individual files containing code and other files on which the application is dependent;

A “tmp” folder, which is empty in most cases.

In the following listing, the contents of the Yahoo! iPhone application are displayed, with some file names (such as logos and icons) removed for simplicity. This structure represents a standard application directory. Looking at the top-level directories, one can see the Documents, Library, and tmp folders, as well as the Yahoo!app folder outlined above. The “iTunes Artwork” and “iTunesMetadata.plist” files are standard files found in all downloads installed through the iTunes App Store. The actual application bundle can be extracted to view more details on the development of that particular application. In this example, the “Info.plist” may contain application version numbers, release dates, or perhaps user login data. Depending on the application, varying configuration files will be found. This is a popular area to look for stored application data.

[email protected]:~/Desktop/iPhoneapp-mount/mobile/Applications$ tree FA06A4AA-0EC9-4E0C-B947-9CAA16698F19/

FA06A4AA-0EC9-4E0C-B947-9CAA16698F19/

├── Documents

│ ├── last_location.txt

│ └── OKURLCache

│ ├── Dictionary.plist

│ ├── E8117953-62EF-454C-8FC6-6EE60E8FCA31

│ ├── EC699560-327D-45DE-8B6C-4D5544095B99

│ └── F2A80C4D-5859-4C2F-A9DB-BCD1527B6BCE

├── iTunesArtwork

├── iTunesMetadata.plist

├── Library

│ ├── Caches

│ ├── Cookies

│ │ └── Cookies.plist

│ ├── Preferences

│ │ ├── com.apple.PeoplePicker.plist -> /private/var/mobile/Library/Preferences/com.apple.PeoplePicker.plist

│ │ └── com.yahoo.frontpage.plist

│ └── WebKit

│ ├── Databases [error opening dir]

│ └── LocalStorage

│ └── http_m.mg.mail.yahoo.com_0.localstorage

├── tmp

└── Yahoo!.app

 ├── blueprint.xsd

 ├── bpResourcesVoice.bundle

 │ └── Info.plist

 ├── CodeResources -> _CodeSignature/CodeResources

 ├── _CodeSignature

 │ └── CodeResources

 ├── config.xml

 ├── config.xsd

 ├── Default.png

 ├── de.lproj

 ├── en.lproj

 ├── Entitlements.plist

 ├── es.lproj

 ├── fr.lproj

 ├── Icon.png

 ├── Info.plist

 ├── it.lproj

 ├── oneKit

 ├── PkgInfo

 ├── pt.lproj

 ├── ResourceRules.plist

 ├── SC_Info

 ├── Settings.bundle

 │ ├── en.lproj

 │ │ └── Root.strings

 │ └── Root.plist

 ├── SettingsGenericSelectionView.nib

 ├── SettingsGenericTextView.nib

 ├── SettingsView.nib

 ├── Sounds

 ├── Yahoo!

 └── zh_tw.lproj

Outside of the downloaded applications, the more common data is typically stored in either the “Library” or “Media” folder within specific subfolders. For example, text messages are stored under Library > SMS, in a file named “sms.db.” The iPhone file system is structured in an intuitive manner for most of the data.

There are, however, other files on the root of the device which have required a bit more research to understand the data within them. One example of this involves GPS location information stored on the device. Many different applications often ask the user if they wish to enable GPS for that particular app, including the on-board camera and video camera. For this reason, GPS data can often be found for pictures or videos that were taken from the device. When iOS 4.0 was released, changes were made to part of the iPhone's file system layout. One of the major transformations involved a file called “consolidated.db.” This database contains a wide array of GPS data and includes latitude and longitude coordinates, time stamps, cell tower locations, and Wi-Fi/Bluetooth connections from that device. There is only one instance of this file and it is not stored within an individual application folder, despite the fact that this database may contain information about individual applications. More details on recovering GPS data from consolidated.db and other locations can be found in Chapter 6.

Android Directory Structures

A broad understanding of the Android directory structure is very helpful in the forensic analysis of a device. To perform this analysis, five important root level directories were copied from the HTC Incredible and then displayed with the tree command on the local workstation. Following the hierarchical layout, an explanation of many directories is provided.

Line 1: At the top is the root directory, which creates the structure and mount points for the other file systems explored previously.

Line 2: As previously discussed, the HTC Incredible created an “/app-cache” directory of type tmpfs. You can see the browser cache structure. Presumably, over time, other apps may leverage this directory.

Lines 6–8: Android devices from the start had a dedicated “/cache” directory that originally appeared to be unused. However, this is certainly not the case and the “/cache” partition should be imaged for full analysis. Files including Gmail attachment previews, Browser DRM, some downloads (Market and other), as well as Over The Air (OTA) updates from the wireless carriers can be found here.

Line 9: The root level “/data” directory has a number of important subdirectories covered next. Note that some phones (such as the HTC Incredible) have a dedicated partition for the “/data/data” subdirectory.

Line 10: The “/data/anr” directory contains stack traces (debugging) from the system and is generally not accessible to the shell user. However, some of the adb debug commands appear to read this data.

Line 11: The “/data/app” directory contains the .apk files from the Android Market.

Line 12: The “/data/app-private” directory stores protected apps from the Android Market.

Line 13: More recent versions of Android have a secure cloud backup API that developers can integrate into their apps. The “/data/backup” directory is used to queue and manage these backups. However, thus far meaningful data has not been recovered from directory.

Line 14: The “/data/btips” (Texas Instrument's Bluetooth Protocol Stack) directory stores the log files if the associated app (com.ti.btips) crashes.

Line 15: The “/data/davlik-cache” directory contains the Davlik VM's cached dex files used to run apps.

Line 16: The “/data/data directory” contains the application specific data, easily the most important area to focus on in an investigation.

Lines 17–23: One app was kept in the directory hierarchy for demonstration purposes. The directory is named according to the package name and often clearly identifies the developer (Facebook in this case).

Line 24: For HHGTTG fans (famous advice to intergalactic travelers from the classic novel The Hitchhiker's Guide to the Galaxy: DON'T PANIC), there's a great directory named “/data/dontpanic,” which is simply a place to store some error log files from the system. Again, a great benefit of an open system is the ability to examine code. Short of that, we would have simply had to guess the purpose or perform significant testing. From the AOSP:

Line 25: The “/data/local” directory is important as it allows shell (the user account nonrooted phones run adbd as) read/write access. When an app is installed, it is first copied to “/data/local.” Also, some forensic techniques rely on this directory to upload important files, typically binaries.

Line 26: The “/data/lost+found” directory shows up in several places in YAFFS2 file systems. Again, a quick search (try “grep -R lost+found ∗.c” from the YAFFS2 source directory we downloaded) will explain that any files or directories found that do not have a path to the root directory will be placed in this folder.

Lines 27–35: The “/data/misc” directory contains files related to Bluetooth, dhcp, vpn, Wi-Fi, and more. One important file to point out is “/data/misc/wifi/wpa_supplicant.conf” that contains a list of Wi-Fi.com networks to which the device got connected. If the wireless access point required a password, it is stored in plain text in the file (have fun pen testers). Here's a partial listing:

Line 36: The “/data/property” directory contains various system properties such as time zone, country, and language.

Line 37: Beyond the subdirectories you can see /data/system contains several key files. First, the accounts.db contains a list of accounts that require authentication and provides the name, type, password (encrypted), and authentication tokens (among other data). There are also two very important files related to the pass code or PIN for the device. The files are gesture.key and password.key and contain an encoded/encrypted hex value for the pass code.

Line 43: When a process crashes, a special tombstone file can be created. The file is ASCII and thus readable. More information can be found online such as one informative post on Crazydaks.com (Debugging in Android, n.d.).

Line 44: The “/mnt” directory is where the system mounts various file systems, including the SD card, the eMMC, and others.

Line 45: The “/mnt/asec” directory contains the unencrypted apps that are stored on the SD card. When Android introduced the ability to store apps on the SD card, they encrypted the contents for security reasons. However, when the system is up and running and unencrypted access to the files is necessary, they are decrypted and mounted in “/mnt/asec.”

Line 46: The “/mnt/emmc” contains the FAT32 file system that resides on the NAND flash for some devices. Lines 47 through 55 are several examples of eMMC subdirectories.

Line 51: The “/mnt/emmc/DCIM directory,” album thumbnails are stored here.

Line 52: The “/mnt/emmc/DCIM/100MEDIA” directory contains any pictures or videos taken by the HTC Incredible.

Line 53: The “/mnt/emmc/LOST.DIR” directories are found on FAT32 partitions and may contain files or fragments that the file system lost track of (similar to YAFFS2 lost+found directory). This directory should be examined.

Line 56: If a physical SD card is present, it is mounted at “/mnt/sdcard.”

Line 66: As with the eMMC, the “/mnt/sdcard/dcim” directory would store pictures and videos from the device. On the HTC Incredible, they are stored in “/mnt/emmc/DCIM,” so they are not present on the physical SD card.

Lines 67–68: The “/mnt/sdcard/download” and “/mnt/sdcard/Downloads” directories contain files downloaded by the browser, e-mail clients, and others.

Line 72: As mentioned previously, the “/mnt/sdcard/secure/asec” directory is encrypted and is where apps that reside on the SD card (instead of the NAND flash) store data.

Line 75: The “/system/app” directory contains .apk app files for apps that are provided with the system. This includes apps bundled by Google/Android, the manufacturer (HTC in this case), and the wireless carrier (Verizon in this case). In the case of the HTC Incredible, the directory contains a significant 152 .apk files. It's important to know this location in case app analysis is required for a case (which means you need access to the apk file). The .apk files present on the reference HTC Incredible were:

Lines 76 and 117: The “/system/bin” and “/system/xbin” directories contain the Android binary files used on the system. Forensic analysts and security engineers (and most definitely Android researchers) can find many useful and undocumented commands by experimenting with files in these directories.

Lines 77–80: The “/system/customize” directories contain carrier-specific customizations for the phone, notably UI.

Line 81: The “/system/etc” directory is where Android stores the typical Linux/Unix configuration (/etc) directory. It contains numerous configuration files worthy of examination—too many to discuss in this book—but can vary from device to device.

There are far more directories and files to explore but the above overview provides a good starting point.

36.3.14 find (find file)

The find command searches recursively through a directory structure to find files that match certain criteria. It uses a pathname from where to start seaching; this is the first argument given after find. The name of the file is specified after the –name argument and if the userwants the files found printed to the standard output the –print is specified at the end. Sample session 36.34 gives an example of finding a file called fred. f, starting from the current directory.

Sample session 36.35 shows a search of the file passwd, starting from the top-level directory.

The wild-card character can be used in the name but this must be inserted in inverted commas (” “). Sample session 36.36 gives an example of search for all C files starting with the/usr/staff/bill directory.

Other extensions can be used such as –a time which defines the time of last access. The argument following –atime is the number of days since it has been accessed. Sample session 36.37 gives an example of searching for all .o files that have not been used within 10 days.

Directory Structure

UNIX-like systems tend to share a common directory structure that helps in the transition between different operating systems. This is based off of a base root directory referred to simply as “/”. Underneath this root in a hierarchy are a series of common subdirectories which each holds a certain type of files. Underneath those, of course, are a myriad of additional subdirectories. This is how that structure looks like in most UNIX-like systems:

/—Root directory

bin—Critical binary files

dev—Hardware devices

etc—Configuration files and some applications

lib—Library files

opt—Some applications

public—Public shared files

root—Home directory for “root” user

sbin—System binary files

tmp—Temporary files

user or home—User home directories

fairclothj—Each named user has their own home directory

fairclothk—Each named user has their own home directory

fairclothm—Each named user has their own home directory

faircloths—Each named user has their own home directory

usr—Some applications

var—Variable files that change frequently

These directories change a little bit depending on which UNIX-like system is being used, but are generally pretty consistent. In many cases, you will find application configuration files in “/etc” or “/opt”. Log files can often be found in “/var” or “/var/log” as well as in application directories. When working with hardware devices, you’ll typically find the references to those devices in “/dev”. Lastly, the home directory for any given user is generally where user-specific settings are stored as well as any personal-use binaries.

5 Performance

Our system reads data encoded in XML or a directory structure as input formats. It is made of 23,000 lines of C++, using high-performance techniques such as template metaprogramming [23] to achieve the required speed. We have used it with an NVidia GeForce3 board on a 2 GHz Pentium and a 3Dlab Wildcat 5110 on a dual 1.7GHz Pentium. To scale to a million items, the computation of layouts should be done in time linear with the number of items. This is the case with some treemaps and scatter plots but not with VisDB for example. Even using the fastest techniques, layout computation takes about 50% of the redisplay time.

Despite the high theoretical performance of the boards, we have not been able to go beyond 6 million quads per second on any of the boards we tried. The theoretical speed of 15 million triangles per second is only achievable for triangle strips, which is of no use for scatter plots and would require expensive computation for treemaps.

Combining software and hardware techniques provides a sustained performance around 2.5 million quads per second. By using texture mapping for animating treemaps, we achieve 10 frames per second for animating across any family of treemap. For scatter plots we have only reached 3 frames per second for animations on 1 million items, and 6 frames per second for dynamic queries. Finding techniques for improving that speed would be useful but the next generation of graphics cards and computers will solve the problem.

Our estimate is that these results correspond to a 20 to 100 time improvement on the available systems.

Web Server File Structure

If you use Linux for your web environment, the directory structure will vary depending on the exact web server, but for our DVWA installation, the directory structure will resemble what is introduced in Figure 5.12.

The shaded directories with white type are the directories on the web server that the web application is allowed to access. All other directories (many more not shown at the root level) are intended to be accessed only by the web server administrator.

If you were curious what the directory structure is for other Linux installations, I would recommend taking a stepwise approach to discovering them. Run a series of cd and ls commands, so you can see the changes from one directory level to the next as shown in Figure 5.13.

You will be executing a path traversal attack (a.k.a. directory traversal) to retrieve resources from the web server that you have no authorization to in the File Inclusion DVWA exercise. Specifically you will retrieve files from the most notable directories on the DVWA web server. This vulnerability also provides a mechanism to upload, install, configure, and execute additional tools on the web server.

The first step in this attack is to realize where in the file system the application is housed. You won’t normally have access to the web server’s file system to run cd and ls commands to fully map out where the application is allowed to operate. You know that you need to break out of the assigned directories, but you just don’t know where exactly you are in the overall file structure. I always liken this to stumbling around a dark room looking for a way out. You know there’s a door somewhere, but you don’t know where it is because of the darkness. Your best bet is to simply walk along the wall until you find the door. If you come to a corner before the door, you just walk along the new wall. Sooner or later you will find the door to escape.

In the context of our path traversal attack, this hunting is done with the up a directory command, which is represented by ../ in the web application world. You can use this dot-dot-slash command as many times as you want once you’ve identified the path traversal vulnerability. It’s not important that you know how many levels deep you are in the directory structure, because when you reach the root directory and attempt to go up a directory, you will stay in root. You could be 3 or 7 or 14 levels deep; as long as you put in 14 or more up commands, you will reach the root directory regardless of where you start. Trying to go up a directory when you’ll at the root directory will simply keep you in the root directory, so error on the side of using too many! You can then drill down into your intended directory that you’d like to pillage as shown in Figure 5.14.

In order for this attack to work as described, ensure that your DVWA is still running with the “low” security level that you configured earlier in the book. Here we are using six instances of ../ when we know that we really only need to use four of the commands to reach the root directory. Once we’ve reached the root directory, we then request the /etc/passwd file. The contents of the passwd file are displayed back to our web application.

We just used the web application to reach into parts of the file system that it was not authorized to do and extract out sensitive information! All from the comfort of our browser interacting with the application like a normal user. The ../ rarely works in its natural format like it does here. There are tons of sanitization routines that attempt to identify and remove path traversal characters from user requests. The battle then becomes understanding how these sanitization routines work and how you can circumvent them to still have your attack exploit this vulnerability. A firm understanding of encoding and regular expressions will serve you well in this battle.

“Mounting” File Systems

A major difference between Windows and Linux file systems has to do with how file structured devices, hard disks, floppy drives, CDROMs, etc., are mapped into the system’s directory or hierarchy structure. The Windows file system makes devices explicitly visible, identifying them with a letter-colon combination, as in “C:.” Linux, on the other hand, emphasizes a unified file system in which physical devices are effectively rendered invisible.

Does Linux use logical directory tree?

What command is most effective at identifying different types of files in Linux?

Is it acceptable to use shell metacharacters when naming files?

What directory under contains the log files and spools for a Linux system?