Title (Ebook - Computer) Hacking The Windows Registry.pdf ✅

22 MARCH 1996 Visual Basic Programmer’s Journal HACKING THE REGISTRY http://www.windx.com USER also maps to a subkey). Keys beneath the root are referenced by building a string key by concatenating each node together, separated by backslashes. Each key also contains data stored in values: a key may have no values, a de- fault value, or any number of named val- ues in addition to the default. The data in the values may be in a variety of forms, though text and binary data types are by far the most common. While key names and value names are never localized, text data often is. Using the Windows 95 RegEdit utility shows you a much compacted view of the regis- try including the root keys, several subkeys, a default (text) value, and a named (binary) value (see Figure 2). Note that Windows NT has a similar but slightly different structure: it omits HKEY_ CURRENT_CONFIG and substitutes a some- what analogous HKEY_PERFORMANCE_ DATA for HKEY_DYN_ DATA. SPELUNKING THE REGISTRY A variety of common components can be found in the registry, especially if they have anything to do with OLE. Here are some examples so you’ll know what you’re look- ing at when you go spelunking with RegEdit. Creatable OLE classes, provided by OLE servers, must be in the registry. Each class is registered separately in the HKEY_CLASSES_ROOT\CLSID key under its CLSID and must, at minimum, have enough information for the OLE system to locate and start the server. For example, Access registers the Application object with the key name on the left and the default value on the right: {B54DCF20-5F9C-101B- Microsoft Access Database AF4E 00AA003F0F07} InprocHandler32 ole32.dll LocalServer32 C:\MSOFFICE\ACCESS\MSACCESS.EXE ProgID Access.Application.7 BY KEITH PLEAS ately: some of them are particular to the new Windows shell (first delivered on Windows 95 but currently in beta on Win- dows NT), some work only with NT (also known as “Microsoft’s real operating sys- tem”), and some will work for everybody. So, grab your tools (primarily a copy of RegEdit) and prepare for an exciting round of hacking the registry. The registration database, commonly called the registry, contains a substantial amount of data about the computer and users. It includes computer data such as hardware, the OS, and installed applica- tions, and user information such as their desk- top settings and customization prefer- ences. The registry stores data in a hierar- chically structured tree. Each node in the tree is called a key. Each key can contain additional keys called subkeys (see Figure 1). Keys are composed of printable char- acters and cannot include backslashes (\) or wildcard characters (* or ?). Sev- eral predefined keys, represented with uppercase words separated by under- scores, can be accessed using numeric constants. These keys are always “open,” so it’s not necessary to use the RegOpen... functions on them. It’s important to note that the root key for machine information HKEY_LOCAL_MACHINE (HKEY_CLASSES_ ROOT and HKEY_CURRENT_CONFIG map to subkeys) and the root key for user infor- mation is HKEY_USERS (HKEY_CURRENT_ It’s a jungle out there, but with some guidance, an intrepid developer can unlock the secrets of the Win32 Registry. f USER, Kernel, and GDI are the heart, brain, and eyes of Windows, the reg- Iistry would be the memory—both long and short term. OK, maybe this meta- phor is a bit weak, but the point should be obvious: the registry is a critical compo- nent of a well-functioning system and you’re not going to get very far without it. The registry is lightly documented and not well understood. Programming it can be similar to the old neurological tech- nique of zapping part of the cerebral cortex with an electrode and see- ing what happens: the patient may remember a baseball game or expe- rience a war-related flashback. In Windows, you may enable a cool new feature or ren- der your system unbootable. But it’s the thrill of the hunt that makes it so exciting. After a brief introduction to get our ter- minology straight, I’ll skip the fundamen- tals of the registry—MSDN would be an ideal place to find this information—and leap into advanced aspects. Along the way I’ll note a variety of thing you can take advantage of immedi- Keith Pleas is an independent developer, author, and trainer. He is the author of the forthcoming book, Visual Basic Tips & Tricks, from Addison-Wesley. He can be reached on Compu-Serve at 71333,3014 (from the Internet: [email protected]). Hacking the Windows Registry ©1991–1996 Fawcette Technical Publications Click & Retrieve Source CODE!

24 MARCH 1996 Visual Basic Programmer’s Journal HACKING THE REGISTRY http://www.windx.com Text Value Binary Value Subkeys Keys Notice how the LocalServer32 key gets renamed (actually, keys cannot be renamed, so it is destroyed and re-created) and an additional InprocServer32 key is created. This new key points to the remote automation proxy on the local machine, initiating a conversation with the AutMgr utility running on the remote machine. Of course, you’ll never want to touch these registration entries directly. In addition to using RacMgr32, we can also call the RacReg OLE Automation server in code to examine and change server settings. To do so add a reference to the RacReg32.DLL, create a RacReg.RegClass object, and use the GetAutoServerSettings func- tion and SetAutoServerSettings method. Unfortunately, the documentation for these functions is a little obscure: it’s only found in the ReadMe file that ships with VB4. But it’s pretty obvious how the RacReg32 server reads/writes the registry settings shown in this function prototype: object.SetAutoServerSettings (Remote, [ProgID], [CLSID], _ [ServerName], [Protocol], [Authentication]) A side benefit of using the RacReg.RegClass object is that Microsoft’s VB group promises that your code will be upwardly compatible with future versions of VB, which will support true Networked OLE: they’ll do the work of encapsulating the changes so that you don’t have to change your code. USING REGISTRY FUNCTIONS The Win32 API provides a function group of 26 APIs, many of them with both “A” (ANSI) and “W” (Wide, or Unicode) ver- sions, for working with the registry. Five of the 26 APIs are provided for backward compatibility only and shouldn’t be used (the corresponding ...Ex functions, which support named values and access to keys other than HKEY_CLASSES_ROOT, should be used instead). Rather than torture you with a complete list of the APIs, I’ll point you to a couple of useful samples that highlight their implementation such as the RegTool sample that ships on the VB4 disc. The RegTool sample is buried down in the \Tools\ Dataex32\Source\Regtool subdirectory and has a reusable class with routines for creating, updating, and deleting keys. Unfortu- nately, while it can read both string and numeric (dword) data, it can only write strings. A much better example can be found in the file REGVB4.ZIP in the Magazine Library of the VBPJ Forum on CompuServe. Written by Don Bradner, VBPJ Forum Section Leader of the “32-Bit Bucket,” REGVB4 is a handy VB4 version of RegEdit that has well-commented source code for reading and writing both string and numeric values. Several of the registry functions deserve a bit more com- ment. While we do not yet have built-in support for a distributed registry (where part or all of your registry is stored on another machine), the RegConnectRegistry function can be used pro- grammatically to connect to remote registries and get/set val- ues from their registries. They can connect only through the root keys (HKEY_LOCAL_MACHINE and HKEY_USERS), but be- cause of the subkey mappings to HKEY_CURRENT_ USER, HKEY_CLASSES_ROOT, and HKEY_CURRENT_CONFIG this isn’t a major limitation. There are also a few differences between the Win95 and WinNT implementations of the registry functions. Of course, Win95 knows nothing about security, so Get/SetKeySecurity aren’t implemented Keys to the Windows Registry. The hierarchical structure of the registry consists of keys and subkeys. The associated values for each key can be named (text) or a non-string data type (binary). FIGURE 2 ©1991–1996 Fawcette Technical Publications
Visual Basic Programmer’s Journal MARCH 1996 25 HACKING THE REGISTRY http://www.windx.com on that platform. Also, while Win95 does implement QueryInfoKey, it doesn’t track the last write time, so don’t be surprised when the FILETIME structure comes up empty. Another thing to watch out for, particularly if you develop under Win95, is that RegDeleteKey on that platform deletes key and descendants, whereas on NT it can only delete keys that have no subkeys. Because of its architecture, Win95 has very limited support for kernel synchronization objects, and thus RegNotifyChangeKeyValue is not supported at all. Win95 also doesn’t implement RegRestoreKey, which can be worked around tediously by writing code to re-create the keys or, much easier, by using a REGEDIT4 file. Interestingly, RegQueryMultipleValues is only implemented on Win95 (though its primary value appears to be as a coding shortcut). Finally, if you must store Unicode data in the Win95 registry you must store it as REG_BINARY, because Win95 is an ANSI system. It’s also worth pointing out that VB4 includes built-in func- tions for working with the registry, though they only work with information from a specific location in the registry: HKEY_CURRENT_USERS\Software\VB and VBA Program _ Settings\ I’ve seen a number of people experience problems with the built-in VB functions.GetSetting and GetAllSettings are functions, but SaveSetting and DeleteSetting are statements and thus don’t use parentheses. While SaveSetting and DeleteSetting were origi- nally specified as functions, later they became statements. IMPORT DATA INTO THE REGISTRY It’s common to use registration (REG) files for importing data into the registry. REG files have two formats: REGEDIT and REGEDIT4. REGEDIT4 was introduced to deal with named values. RegEdit can run from the command line, but in this configuration, it will not be able to load REGEDIT4 files. If you’re working on NT, you should use the RegIni utility from the NT Resource Kit. Adding the TXT File Type to the Explorer. This view of the New menu in the Win95 explorer is fairly typical, except that by using the registry, I added the TXT file type to the menu. Selecting it launches Notepad, the file associated with TXT files. FIGURE 3 CONTINUED ON PAGE 30. http://www.windx.com ©1991–1996 Fawcette Technical Publications Visual Basic Programmer’s Journal MARCH 1996 25 ©1991–1996 Fawcette Technical Publications