Interestingly enough, the same holds true in the digital world. When malware infects a system, there is usually some means by which it arrives on the system, such as a browser “drive-by” infection, via a network share, USB thumb drive, or an e-mail attachment. When an intruder accesses a system, there is some artifact such as a network connection or activity on the target system and the target system will contain some information about the system from which the intruder originated. Some of this information may be extremely volatile, meaning that it only remains visible to the operating system (and hence, an analyst) for a short period of time. However, remnants of that artifact may persist for a considerable amount of time.

So how does this apply to Registry analysis? When a user, even an intruder who has gained access to the system, interacts with the system, and particularly with the Windows Explorer user interface (aka the “shell”), some rather persistent artifacts are created. If a malicious user logs into the system and plugs in a USB thumb drive, there is an exchange of information that occurs, and some of those artifacts persist in the Registry (the same is true when connecting to devices via Bluetooth). If the malicious user then launches applications, there will be additional artifacts created. When a user connects their system to a wireless access point (WAP), information about the WAP persists on the system. I was told by another analyst several years ago that he’d been involved in an investigation where a former employee was thought to have provided sensitive data to a competitor and then accepted employment with the competitor. An examination of the system revealed that while the employee was traveling, he’d connected his corporate laptop to WiFi at a Starbucks near the competitor’s building and then to the WiFi in the competitor’s offices about an hour later. A combination of the WiFi access point names and a geolocation lookup of the medium access control (MAC) addresses of the access points, along with date and time stamps, revealed important clues about the employee’s activities.

Analysts need to keep Locard’s exchange principle in mind during an examination because it can not only tell them that there are artifacts, but can also point them to where those artifacts may be located. Knowing likely sources of artifacts significantly reduces the time it takes to conduct an investigation; instead of combing through all of the data, the examiner can target those specific areas to quickly determine whether they will be fruitful or not. This sort of data collection and triage can greatly assist incident response activities as well as increase the throughput of investigations, as a whole, without sacrificing quality or completeness.

The offshoot of this is that the mutex is very often random (although sometimes not so random) and always unique. This became an excellent indicator of a malware infection; in fact, Kris Harms (at the time an analyst with Mandiant, who later became an analyst with Cylance) discussed during a presentation the use of the Microsoft SysInternals tool handle.exe to list all the mutexes available in memory for all of the running processes on the system and then sorting the output by the unique mutexes. Kris demonstrated that a quick look at those mutexes that only occurred once or infrequently across processes very often resulted in rapid and accurate detection of malware, even if the mutex name itself had been changed.

Demonstrating Kris’ use of handle.exe is outside the scope of this book, but it does serve as an example of how the concept of least frequency of occurrence (LFO) can be used, not only for malware but also for intrusions, and therefore can also be very important to our analysis.

The point of LFO is that during the lifetime of a system, malware infections and intrusions constitute what occurs least frequently on that system. Operating system and application updates are extremely “noisy,” generating a great deal of file system (file creations, modifications, and deletions) and Registry (keys being created, values updated, etc.) activity, and occurring fairly frequently. Windows XP, by default, will create a System Restore Point every 24 h (as well as under other conditions) and will also launch its Disk Defragmenter utility every three calendar days to perform a limited defrag. Windows XP also generates or updates Prefetch files whenever an application is launched. Beginning with Windows Vista, the operating systems began maintaining Volume Shadow Copies (as opposed to the Windows XP System Restore Points) in order to provide a recovery mechanism. When a user installs software from Apple (such as QuickTime, iTunes, etc.), a Scheduled Task is created on the system to look for updates to those applications once a week, and the user can choose to install those updates, creating and modifying files within the file system. Microsoft releases operating system and application updates monthly, and sometimes does so “out of band,” or out of the regular update release schedule. What this means is that there is a lot of normal file system and Registry activity that occurs on a system, but in contrast, when malware infects a system, a few files (and maybe Registry keys/values) are created, and there may also be some network connections as the malware communicates off of the system. When an intruder accesses a system via Remote Desktop due to an easily guessed password, there may be several Event Log records generated (we will discuss how to determine the audit configuration on a system in detail in chapter Analyzing the System Hives), some Registry keys created or modified, and depending upon the actions they take, maybe some files created, modified, or deleted on that system. Again, with the exception of turning the compromised system into a repository for pirated movies or music files, a malware infection or intrusion will very often constitute the least frequent activity on the system. In fact, many intrusions go undetected for long periods of time, as the intruder will use very simple techniques to minimize as much as possible the artifacts left on a system. This can also be true for other types of issues, such as viewing illegal images. A file (or a few files) is added to the system, the files are viewed (as we’ll see in chapter Case Studies: User Hives, some Registry keys will be updated), and then the files may be shared or deleted. All in all, adding, viewing, and deleting these files really do not constitute a considerable amount of activity, particularly when compared to operating system and application updates.

What this often means to our analysis is that during intrusions or malware infections, we wouldn’t usually be looking for large numbers of files being added to the system, or of massive numbers of Registry keys or values being created, or regular or significant spikes in activity of any kind. Most often, spikes in file system and Registry activity will indicate an operating system or application software update (or much to the chagrin of the analyst, a system administrator running antivirus application scans) not a malware infection or system intrusion.

Consider user searches; with Windows XP, the terms that a user searched for via the shell were maintained in subkeys beneath the “ACMru” Registry key in the user’s NTUSER.DAT hive file. With Windows Vista, the search terms were saved to an XML file, and then with Windows 7, the terms were saved beneath a key named “WordWheelQuery.” With Windows 8, user search terms were saved in the Registry and associated with “Search Charm” in the user interface, and apparently, with Windows 8.1, those terms are again saved in a file.

There are other significant changes between versions of Windows. With Windows XP and 2003, system events were recorded in the Event Logs, files with the “.evt” extension in the Windowssystem32config folder. As of Windows Vista, the logs were referred to as Windows Event Logs and had a “.evtx” extension, a new location, and an entirely different binary format, requiring a completely different set of tools to parse them. Oh, and even more events were (and still are) being recorded by default.

There are many more such differences between the versions of Windows, and we’ll go into many of those differences in this book as they apply directly to the Registry for each version.

For example, I was examining a system about a year ago which had been found to be infected with a particular variant of a remote access Trojan (RAT). This particular RAT variant is usually installed as a Windows service, allowing the intruder to access the system with privileges greater than that of the system administrator. Further, this particular bit of malware is most often assumed to be installed via a “spearphishing” e-mail, in which the user is enticed to click on a link or malicious document, resulting in the installation of the RAT. In this particular case, Registry artifacts revealed that the RAT had been installed as a result of someone with physical access to the system plugging a USB thumb drive into the system (it was mounted as the E: volume) and launching an installer application. When the user’s employer requested that they turn in the system for examination, the user attempted to remove the RAT…in fact, artifacts in the Registry revealed that the last key in focus in the Registry Editor before it was closed by the user was the key alphabetically following the name with which the RAT was installed. Additional information was extracted from the hibernation file through the use of the Volatility Framework, but the preponderance of artifacts extracted from the Registry clearly indicated that the RAT was installed and running on the system with the full knowledge (and involvement) of the user.

As I’m writing this section of the book, I’m working (as part of my day job) on an examination in which an intruder had access to an infrastructure via domain administrator credentials and Terminal Services. I’d tried to backtrack the intruder’s connections as they hopped from system to system, but they had a penchant for clearing the Windows Event Logs on some (albeit not all) systems. Even though I could not see all of the data that I wanted to, there was more than enough data in the Registry to tell me when they were logged into the system and active (days and times), as well as other systems to which they connected. Even without the Windows Event Log records, I was able to build a time-based map of the intruder’s activities, showing what time of day they were active, files and resources they’d accessed, etc. I was also able to illustrate their connection to a file transfer protocol server.

Data available in the Registry can be very revealing on a number of fronts. Although the intruder had cleared the Windows Event Log and we were not able to see where they were when they logged into the system we were examining, but we could see when they were active on the system (which we could then correlate with other sources, such as domain controller and VPN logs), what they’d done, and other systems they’d connected to through the use of the Terminal Services Client as well as via Microsoft networking. All of this data remained even following the intruder’s “antiforensics” steps.

Your goals may vary depending upon your employer and the type of work you generally do. If you’re a consultant, your goals may vary from case to case; during one examination, you may have to determine if a system was infected with malware, and if so, the capabilities of that malware (ie, what data did it extract, where was the data sent, was the malware specifically targeted at the organization, etc.). In another examination, you may have to determine if there was sensitive information (ie, personally identifiable information, credit card data, classified data, etc.) stored on the system, while another examination may pertain to violations of corporate acceptable use policies. If you’re a law enforcement officer, you may be faced with a possible issue of fraud, or you may need to demonstrate that a computer owner had knowledge of and viewed contraband images.

Regardless of the type of examination, your goals are where everything starts and ends. For consultants, not answering a customer’s questions can lead to serious issues, such as spending far more time on your “analysis” than your contract allows, or attempting to bill a customer when you haven’t answered their questions. Our analysis goals give us direction and focus and allow us to provide those answers in a timely and efficient manner.

What can sometimes be missed is documentation of the overall analysis process. Before conducting analysis, do you sit down and ensure that you understand the goals of the analysis, or the questions that you’re trying to answer? Whether you’re a consultant working for a customer or an examiner performing work in support of law enforcement, there’s usually some reason why you’re sitting there with a hard drive or an acquired image. What is that reason? Most likely, it’s that someone has questions that need to be answered. So start your analysis plan by documenting the goals that you’re trying to achieve. From there, you can begin framing out your steps going forward and noting where you need to look, and those tasks that you need to achieve. For example, if the goal is to determine the existence of specific e-mails, you’ll likely want to check for .pst/.ost files, or maybe check the Registry and determine which e-mail client was used, determine if web-based e-mail was used, etc.

The analysis plan can lead the analyst directly into documenting the analysis process itself. So why would we do this? What happens if at some point during the analysis process, you get sick or become injured? What happens if the analysis needs to be handed off to someone else? Another very real possibility is what happens if 6 months or a year after you complete your analysis, you have to answer questions about it? I know several analysts to whom this has happened recently. For myself, I’ve worked with customers who’ve come back with questions six or more months after accepting the final report and paying their bill…had I not had clear, concise documentation, I would have had trouble answering their questions in an intelligible manner. We’ve all been busy to the point where we can’t remember what we had for breakfast, let alone the specifics of an examination from 6 months ago. Your case notes and documentation can be extremely important at that point, and it’s best not to have to figure that out after the fact.

Another important aspect of documenting your analysis is that it allows you to go back and look at what you did, and improve the process. Documentation is the basis for improvement, and you can’t improve a process if you don’t have one. Your documentation provides that process. If you didn’t document what you did, it didn’t happen. By listing out the steps you followed in your analysis, you can see which ones were perhaps less fruitful and can be skipped or improved upon the next time, and which ones provided greater value. This also allows for other, less experienced analysts to learn from what you have done, what worked and what didn’t, so that more analysts are able to achieve a similar, greater level of analysis.

The first challenge to Registry analysis is that the Registry itself isn’t all that well understood by responders and analysts. To be honest, I’m not even sure that there’s really anyone who completely understands the Windows Registry! The Registry is a critical, core component of the Windows operating systems and records a considerable amount of information about the system configuration and usage, as well as user activity, particularly when the user is interacting with the system through the Windows Explorer shell. With just the operating system itself, I don’t think that there’s really anyone who completely understands why some keys and values have the paths and contain the structures that they do, or what activities lead to the keys or values being created or modified, let alone the structure of various binary value data. This lack of understanding by the vendor obviates any thorough knowledge and understanding by analysts and leaves the analyst to perform considerable testing to determine and illustrate how various artifacts originated on the system.

While considerable work has been performed and documented in this area, the awareness that this work is possibly incomplete persists. As new versions of the operating system are developed, locations and formats for storing data in the Registry change, as well, and some keys or values may be added, moved, modified, or simply removed. Very little is known and documented about what actions cause various keys to be modified; while some testing has been done for a very small number of keys, new questions are being posed all the time that would, quite honestly, require access to the source code to the operating system in order to completely answer. Being closed source the way Windows is, having complete access to the source code isn’t likely to happen anytime soon.

Several years ago, Cory Altheide (whom I used to work with, and is now a responder for Google) and I conducted some research into tracking the use of USB devices across Windows systems. After we were done, we published our findings, confident that we’d figured out a way to determine when a USB device was last connected to a system. More recently, Rob Lee (of SANS fame) conducted additional testing and determined that what Cory and I had determined was really the first time that the device had been connected during the current (or most recent) boot session, meaning that if the system was running for several days and the USB device connected and disconnected several times, the best we could hope to show (with just the data we’d found) was when the device had first been connected during that boot session. Additional information is available in Windows Vista and Windows 7, but there simply is no comprehensive listing of actions, by a user or within the operating system, that would affect particular Registry keys.

The other challenge of Registry analysis is the fact that while the binary structure of the Registry remains the same across versions of Windows (ie, the core binary structure of the Registry is very much the same between Windows 2000 and Windows 7, inclusive), important keys and values change between versions, often very drastically. In many cases, this applies to the base operating system as well as to new and even existing applications. This can make it very difficult for an analyst who figures out and documents some specific Registry keys and values based on a particular version of an application and operating system, only to find those settings null and void when an updated version of the application or the operating system is released.

One example of these changes is how user search terms are maintained within the Registry. With Windows XP, you could find various search terms under a key named “ACMru.” Subkeys beneath this key pertained to particular form fields that a user could submit terms to when performing searches. With Windows Vista, search terms were recorded in a file, but not in the Registry. With Windows 7, search terms are again stored in the Registry, but under an entirely different path, beneath a key named “WordWheelQuery.” These keys are discussed in greater detail in chapter Case Studies: User Hives.

It is not the goal of this chapter or even this book to provide a comprehensive listing of all similar changes that occur between various versions of the Windows operating system; rather, it is enough to understand that these changes can and do occur, and it is incumbent upon analysts to keep up-to-date on analysis techniques and procedures, particularly as they pertain to the Windows Registry.

Devices that have been connected to the system are tracked through the Registry. Information about devices is maintained in the Registry so that the devices are recognized and presented as they were previously when they’re reconnected to the system; as such, this information can be extremely valuable to a forensic analyst when attempting to track the use of an iPod, digital camera, or thumb drive on a system or across several systems.

The Registry also tracks a great deal of information about a user’s activities. This can be very beneficial to a forensic analyst. Let’s say you sit down to play a game of Solitaire on your Windows system, and the first time you run the application, you get the default settings, with respect to how many cards are dealt and how the game is timed and scored. You change most of these settings to something else and then resize and reposition the game window. When you’re done playing, you close the window and shut down the system. The next day, you come back and launch the game again, and all of your settings are still there, having persisted across a log out and reboot. This is due to the fact that the settings are recorded in the Registry, so that the next time you launch the application or game, your most recent and preferred settings are read, and the application window is presented in the location, size, and shape that you left it.

The Registry also tracks a number of other user actions, such as clicking through the Program menu to start an application, as well as keeping track of recently accessed files that are associated with various applications, such as MS Word, Excel, Windows Media Player, etc. The user will generally see these files on the Recent Documents portion of the Program menu, or as part of a drop-down menu specific to the application, as illustrated in Fig. 1.2.

Much of the information tracked in the Registry can be associated with a time value of some sort, and as such, the Registry becomes something of a log file. As will be addressed later in this chapter, all Registry keys maintain a property called their “LastWrite time.” Whenever a Registry key is modified…created, values or subkeys are created or deleted, or a value is modified…the key’s LastWrite time is updated to reflect that change. This value is analogous to a file’s last modification time (although, as of yet, I have been unable to locate an accessible application programming interface, or “API” that allows for the arbitrary modification of LastWrite times, as there is with file MAC times). However, this is not the only place that time stamps are maintained in the Registry. Many values contain time and date information, and often in different formats. In this way, the Registry can be considered in many respects to be a log file.

The main, core system Registry hive files (specifically, SAM, Security, Software, and System) can be found in the Windowssystem32config folder, as illustrated in Fig. 1.3.

The files themselves illustrated in Fig. 1.3 are referred to as “hive” files, as the files contain the binary database structures or “hives.” These are the hive files that maintain configuration information about the system, such as operating system version and settings, local user account information, installed software and components, etc.

On Windows Vista and above systems, there is another hive file in the Windowssystem32config folder named “Components.” While there are a number of keys and values listed in this hive file, as of this writing, I have yet to find anything significant from a forensics or incident response standpoint; however, this may change in the future as more attention is focused on this file.

With Windows 8, we found that there were several new Registry hives files in the Windowssystem32config folder: BBI, BCD, Components, Drivers, and ELAM. Not a great deal of information is available on the purpose of these files, but they can be opened in a Registry viewer application. However, a search on the Microsoft website reveals that “ELAM” stands for “early launch antimalware,” which is intended to protect Windows 8 systems from rootkits. From a reference to ELAM at the Microsoft Dev Center (found online at http://msdn.microsoft.com/en-us/library/windows/desktop/hh848061(v=vs.85).aspx):

My testing system was conducted on a Windows 8.1 laptop, with just MS Office 2013 installed, and little else. As such, I did not have an “ELAM driver” installed.

Information specific to individual users is maintained in the NTUSER.DAT hive file that is located in the user profile. For Windows 2000, XP, and 2003, the user profiles are found in the “Documents and Settings” directory at the root of the system drive, whereas for Vista and above, the user profiles are found in the “Users” directory. There is also another user hive that is merged with the NTUSER.DAT hive file on a live system when a user logs in, allowing for a unified presentation of the information from both hives. This is the USRCLASS.DAT hive, located in the user’s profile, in the Local SettingsApplication DataMicrosoftWindows folder on Windows XP and 2003, and in the AppDataLocalMicrosoftWindows folder on Windows 7 and above. The information maintained in this hive file can vary between operating system versions; some information found in the NTUSER.DAT hive on Windows XP has been moved to the USRCLASS.DAT hive on Windows Vista and above. Many of these differences will be addressed later in this book.

Portions of the Windows Registry visible through the Registry Editor are “volatile,” meaning that they are populated when the system is booted or when a user logs in and do not exist on disk when the system is shut off. This is extremely important for first responders and forensic analysts to understand, as there may be valuable data that does not exist within an acquired image and must be collected while the system is still running.

One example of volatile data is the HKEY_CURRENT_USER hive. When viewed through the Registry Editor, you can clearly see this hive, and after a little exploration, you’ll find that the information in this portion of the Registry pertains specifically to the logged on user. However, when you shut the system down and analyze an acquired image, you won’t find an HKEY_CURRENT_USER hive or any file by that name. That’s because this hive is populated by using the hive for the user that’s logged into the system.

For the currently logged in user, the HKEY_CURRENT_USERSessionInformation key contains a value named ProgramCount that keeps track of the number of programs you have running on your desktop. This is the count you see when you lock your workstation. However, this value doesn’t exist in the user’s NTUSER.DAT file when the system is shut down.

Another example of volatile Registry keys and values is the HKEY_LOCAL_MACHINE/Hardware key and its subkeys. This key stores information regarding the devices connected to the system (CPU, keyboard, mouse, hard drive, etc.) and their assigned resources and is populated when the system boots up.

If you open the Registry Editor and navigate to the HKEY_LOCAL_MACHINESystem hive, you’ll see a key named “CurrentControlSet,” and most likely two others whose names begin with “ControlSet00” and end in a number. The CurrentControlSet doesn’t exist when the system is shut down and is populated at boot time from one of the available ControlSets.

Yet another example of a volatile portion of the Registry is the HKEY_CLASSES_ROOT key. When the system is booted, this key is populated with the contents of the HKEY_LOCAL_MACHINESoftwareClasses key, and when a user logs in, the HKEY_CURRENT_USERSoftwareClasses key contents are added and, according to Microsoft, take precedence of the entries from HKEY_LOCAL_MACHINE entries (found online at https://msdn.microsoft.com/en-us/library/cc144148(VS.85).aspx).

What’s important to keep in mind is that there are portions of the Windows Registry that only exist in memory. Thanks to folks like Aaron Walters and Brendan Dolan-Gavitt (both of Volatility memory analysis fame), this information can be accessed, retrieved, and analyzed; the necessary tools for collecting this data will be discussed later in this book.

On Windows 7 systems (I don’t have an image of Windows Vista system to check for this), there’s a file “System Volume Information” folder named Syscache.hve that follows the same format as Registry hive files, and in fact, you can extract this file from an image and open it in a Registry viewer application. At the time of this writing, there is not a great deal of public information available about this file. There is some information available at the “Windows Registry Knowledge Base” (which can be found online at https://code.google.com/p/winreg-kb/wiki/SysCache), but it largely seems incomplete. This file is likely associated with Volume Shadow Copies in some way.

In short, it’s important that when talking about parts of the Registry, we all have to have a consistent understanding of what it is we’re referring to, so that we can communicate clearly and avoid (as much as possible) confusion and misunderstandings. Fig. 1.4 illustrates the various components of the Registry, specifically keys, subkeys, values, and data. We’ll go into more depth regarding the details of the binary structure of these components.

From the Registry Editor view illustrated in Fig. 1.4, “keys” and “subkeys” are the folders displayed in the left-hand pane of the editor. This is an apt metaphor, in that keys can contain or point to other keys (ie, subkeys) as well as values. Keys also contain very valuable information from a forensic perspective (their LastWrite time) within their binary structure. Values, in the right-hand pane in Fig. 1.4, are much simpler and contain data of a specific type, be it a string value, multiple string values, binary, or DWORD, which is just a 32-bit binary value.

More importantly, we now have a frame of reference for discussing the Registry and Registry analysis throughout the rest of this book, and a common understanding of what a “key” is and what a “value” is, and how they relate to each other. Many times in such discussions, consistent terminology may be reversed or simply not used, and confusion ensues.

As illustrated in Fig. 1.5, the node ID is “6E 6B” (0x6B6E in little endian format), or “nk,” and is followed by the node type of 0x2C, which indicates a root node (0x20 indicates a “normal” key node). Immediately following the node type is the LastWrite time, which is a 64-bit FILETIME object.

Table 1.1 lists the key cell structure details, illustrating the elements of that structure that are of primary interest to forensic analysts.

Table 1.1 should not be considered all-inclusive, as it details those structure elements that are most important to forensic analysts. Again, the size of the structure detailed in Table 1.1 is 80 bytes, and the first 4 bytes of the structure contain the size of the key cell, which includes the key name and any necessary padding. Therefore, the total size of a Registry key is the 80 byte header, the name, and padding; for the key illustrated in Fig. 1.5, that is 96 bytes.

The size value (the first 4 bytes or “DWORD”) is an important aspect of the key structure of which to take notice. When read as an unsigned integer, the size is “4294967200,” and we know that a single key would not usually be expected to be on the order of 4 GB in size. However, when read as a signed integer value, those 4 bytes equal “-96.” Again, the key “header” itself is 80 bytes, and the actual name of the key begins immediately after the key structure. The name of the key illustrated in Fig. 1.5, “$$$PROTO.HIV,” is 12 bytes and there are an additional 4 bytes of padding, rounding out 16 bytes. That makes the total size of the key itself 96 bytes. This is important, as Jolanta (and others) had determined that for normal, allocated Registry keys, the size is a negative value when read as a signed integer value. However, when a key is “deleted,” the size value is made positive. If the key in Fig. 1.5 were deleted, the size would be changed to “60 00 00 00,” or 0x60. This, along with some other checks, is how deleted keys can be located within unallocated space within the hive file.

Table 1.2 provides the relevant value cell structure details. As with the key cell, the first 4 bytes of a value cell (as illustrated in Fig. 1.6) contain the size of the cell.

Notice that while value cells contain some specific information, something that they do not contain is a FILETIME object, nor any other reference to a time stamp of any kind. Again, as with the key cell, not all of the value cell structure elements are listed, and Table 1.2 should not be viewed as all-inclusive. For example, immediately after the “value type” element is a 2-byte element called “Flags,” and as of this writing, I have not been able to locate an available description of this element, nor of its use.

Registry values can point to data of a variety of types. Table 1.3 lists the available Registry value types, along with their names and descriptions. This information is also available from Microsoft website at http://msdn.microsoft.com/en-us/library/ms724884.aspx.

After walking through all of this information on the structure of individual key and value structures, and even though we haven’t really gone into how the keys and values are linked together, it should be evident at this point that each hive file is essentially something of a small file system. There’s a root key that points to other keys (subkeys) and values. Keys can “contain” or point to other keys and values, and values point to data. The links do not go the other way; however, values do not point back to keys nor do values “contain” keys. So in a way, the keys can be considered to be analogous to folders, with only last modification (LastWrite) time stamps, and values can be considered analogous to files. The Registry hive file can have unallocated space, and keys and values that are deleted become part of the unallocated space within the hive file and can be extracted until they are overwritten (much like files within the file system). It’s also possible for value data to contain slack space; if the space allocated for a value data is more than what is actually being used (sound familiar?), then there may be slack space containing data that can be extracted.