Windows Registry

The windows registry is a hierarchical database, which you can describe as a central repository for configuration data or a configuration database. A hierarchical database has characteristics that make it ideally suited to storing configuration data. The Registry contains information that Windows continually references during operation, such as profiles for each user, the applications installed on the computer and the types of documents that each can create, property sheet settings for folders and application icons, what hardware exists on the system, and the ports that are being used. The Windows Registry maintains a great deal of configuration information about the system, maintaining settings for various functionality within the system (ie, may be enabled or disabled). In addition, the Registry maintains historical information about user activity; in order to provide the user with a “better” overall experience, details about applications installed and accessed, as well as window positions and sizes, are maintained in a manner similar to a log file.

          Lih Wern Wong (2006) indicates the Windows Registry contains lots of information that are of potential evidential value or helpful in aiding forensic examiners on other aspects of forensic analysis. Windows store configuration data in registry. As we already told that it is a central repository for configuration data that is stored in a hierarchical manner. System, users, applications and hardware in Windows make use of the registry to store their configuration and it is constantly accessed for reference during their operation. The registry is introduced to replace most text-based configuration files used in Windows 3.x and MS-DOS, such as .ini files, autoexec.bat and config.sys.

          Bunting Steve (2007) also indicates Due to the vast amount of information stored in Windows registry; the registry can be an excellent source for potential evidential data. In instance, windows registry contains information on user accounts, typed URLs, network shared, and Run command history. Aspects discussed in this study are based solely on Windows registry. All of this information can be extremely valuable for a forensic examiner, particularly when attempting to establish a timeline of system and/or user activity. A wide range of cases would benefit greatly from information derived from the Registry, if the analyst were aware of the information and how to best exploit it for the purposes of their examination. Available research in Windows registry forensic focuses on identification of keys that are relevant for forensic examiners and possibilities for data hiding. Windows registry contains lots of information that are of potential evidential value or helpful in aiding forensic examiners on other aspects of forensic analysis. Since registry hive files can have hundreds of thousands of entries, forensic investigators need to familiarize themselves with the registry to know where to look for evidence.

A Birth of the Windows Registry

            In the beginning, there was no concepts of  Registry in OS of Microsoft. The operating system had its own set of configuration files; the most famous of these files are config.sys and autoexec.bat, which control hardware and operating system settings. At first blush, this approach may seem reasonable. After all, applications’ settings are generally private, and they don’t usually affect other programs. Most components of MS-DOS itself weren’t configurable anyway, so there was little need (or demand) for a better configuration mechanism. If the configuration data for a single application was lost or corrupted, restoring it was reasonably simple and could be done without affecting anything else on the computer.

          Windows 3.0 improved on the MS-DOS approach by introducing the idea of a single,system wide set of operating-system preference and settings data. In addition to DOS’configuration files, Windows 3.0 itself added four initialization files ( progman.ini,control.ini, win.ini, and system.ini ) that contained information about the system’shardware configuration, device drivers, and application settings. These files quicklybecame known as INI files, after their extension. Microsoft chose a simple, human-readable ASCII format for INI files; not only didthis ease the task of writing programs to use these files, but it also made it possible forend users to inspect and change their contents. One of the important featuresMicrosoft wanted to deliver in Windows 3.0 was Macintosh-like customization; userswanted to be able to set their own colour schemes, fonts, desktop backgrounds, and soon. By default, the Windows File Manager included a file mapping so that double clickingan INI file would open it in the Notepad text editor.

          In addition to storing Windows’ settings in INI files, Microsoft provided a set of API routines (often called the private profile API ) that gave programmers a way to create their own initialization files. The theory was that application programmers could use INI files to store private settings that were specific to their applications. Settings that could be useful to several applications–for example, lists of which fonts were installed on a computer–lived in the system’s INI files, while application-specific settings were in the application’s private INI files. Application programmers enthusiastically embraced this idea, and before long most applications used INI files for their private settings. However, INI files weren’t perfect; in fact, they suffered from some fairly serious weaknesses.

          INI files were editable, users felt free to edit them. This flexibility did make it easy for users to customize their environments or make necessary changes; it also made it much easier for a user to break a single application, an entire service (such as printing or file sharing), or Windows itself by making an accidental or ill-informed change to an INI file.

          INI files provided a one-time link between a program and its settings; they weren’t dynamic enough to reflect changes in the machine’s configuration or environment. For example, many presentation graphics programs built a list of available fonts during their installation process. If you later added—or, worse, remove—fonts, the presentation package might or might not notice the changes, meaning either that you couldn’t use newly installed fonts or the package could crash while trying to use fonts the application thought were still available. This lack of flexibility was partly due to the fact that Windows didn’t have any way to be notified when something on the computer was changed; without these alerts, there was no way to tell when INI file data needed to be updated.

          Microsoft didn’t provide any explicit guidelines as to where INI files should be stored or what should go in them; in the absence of these rules, application programmers felt free to put INI files in various locations. Some used the Windows directory itself, while others stored their INI files in the same directory as the application or in some other seemingly logical location. To compound the problem, some applications put their private data directly into win.ini, while others kept their own private copies of such things as font lists and printer settings that were explicitly supposed to be shared between applications.

          INI files had to be smaller than 64 KB in length; in addition, the Windows profile API calls blissfully ignores all but the first instance of settings with the same name within one section of the file. An even more serious limit was that INI files were inseparably bound to the original PC concept of “one user, one machine”; there was no way to easily move settings around so that users who needed to use different computers could keep their preferred settings.

The First Entry of Registry In Windows 3.1

            Windows 3.1 added several new features that improved inter application integration and ease of use. Chief among them were two new technologies, Object Linking and Embedding (OLE) and drag and drop. Both features required an up-to-date, correct database of program locations and capabilities. For example, object embedding could only work if the source and destination applications had some way to communicate exactly what type of data was being embedded, and the File Manager required access to a database of mappings to associate files with the applications that created them. To provide this information, Windows 3.1 included the first Windows registration database, which quickly became known as the Registry. This Registry offered solutions to several of the problems posed by INI files: Instead of segregating data into separate INI files, both system and application-specific configuration data could be stored in the Registry. In the original Windows 3.1 implementation, all Registry data was stored in a single file named reg.dat. Keeping system and application settings in one place reduced both the number and complexity of INI files; in addition, having a one-stop system for storing preferences and setting data made it possible to better share information such as font lists between different applications.

INI files were plain text, so it was easy to edit them. This was both a blessing and a curse; users could make changes when necessary, but they were often prone to making unnecessary or instability-causing changes. The data in reg.dat was stored using an undocumented binary format, and the only way users could edit it was with the Windows 3.1 Registry editor. Windows 3.1 also introduced the first version of the Registry access API, thus making it possible for programmers to read and write Registry data directly from their programs.

          The structure of INI files was haphazard at best: sections could appear in any order within the file, and values could appear anywhere in the section. There was no good way to  group related settings, especially when they might appear in different files! However, the Windows 3.1 Registry still wasn’t perfect. It supported only a single hierarchy for storing all system and application settings, and the reg.dat file was still subject to the 64-KB size limitation that hampered INI files. In addition, Windows 3.1 itself didn’t improve on the problem of synchronizing the Registry’s contents with the state of software, fonts, and other items actually loaded on the computer, so there was no guarantee that the Registry, the INI files, and the actual software loaded on the computer would stay in synch. Finally, the Windows 3.1 Registry didn’t offer any solution to the problem of allowing users’ settings to move with them to different computers on a network, or even allowing more than one user to keep settings on a single machine. Despite these shortcomings, the Windows 3.1 Registry introduced several features that carried over to its successors. First and foremost is the concept of the Registry’s hierarchy, which looks much like the structure of a Windows directory tree. In a file system, the topmost item is a root directory, which can contain any number of files and folders. Each folder can in turn contain nested subfolders or files, and you can uniquely identify any object on the disk by constructing a full pathname that points to  it; for example, c:\users\paul\proposal.doc and c:\program\files\eudora\attach\proposal.doc are different files, even though they share the same name. The topmost item in the Registry’s structure (corresponding to a root directory in a file system) is a root key . All other keys in the Registry are children of one of the root keys (although Windows 3.1 supported only one root key, named HKEY_CLASSES_ROOT). Each key can contain either values (the Registry equivalent of a data file) or nested subkeys , equivalent to nested folders. Just as with files and folders, you can uniquely identify a Registry key by building a full path to it. In addition to providing a hierarchy for keys, the Windows 3.1 Registry introduced the idea that keys have names and values. The key’s name (for example, Disable Server Thread) can be combined with the full path to the key to identify it (as in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print\DisableServerThread). The value of the key holds whatever data belongs to the key; the actual contents vary from key to key.