(Ebook - Computer) Hacking The Windows Registry, Hacking and IT E-Book Dump Release, pobierz pdf

[ Pobierz całość w formacie PDF ]
HACKING THE REGISTRY
Click & Retrieve
Source
CODE!
Hacking the
Windows Registry
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
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.
It’s a jungle out
there, but with some
guidance, an intrepid
developer can unlock
the secrets of the
Win32 Registry.
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-
f USER, Kernel, and GDI are the heart,
brain, and eyes of Windows, the reg-
istry would be the memory—both
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:
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_
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: 71333.3014@compu-serve.com).
{B54DCF20-5F9C-101B- Microsoft Access Database
AF4E 00AA003F0F07}
InprocHandler32 ole32.dll
LocalServer32 C:\MSOFFICE\ACCESS\MSACCESS.EXE
ProgID Access.Application.7
22
MARCH 1996
Visual Basic Programmer’s Journal
©1991–1996 Fawcette Technical Publications
http://www.windx.com
HACKING THE REGISTRY
{27395F85-0C0C-101B-A3C9-08002B2F49FB}
1.0
Microsoft PictureClip Control
0
win32 C:\WINDOWS\SYSTEM\PICCLP32.OCX
FLAGS
2
HELPDIR
C:\VB4
Note that the type library itself can be stored as a separate
file on disk (typically with a TLB or OLB extension) or attached
as a resource to a DLL or EXE. Because OLE controls are in fact
DLLs, their type libraries are most often stored with the
control itself.
The HELPDIR key is notable because it points to the fully
qualified location for the accompanying WinHelp file containing
additional programming documentation about the control. This
location can obviously vary by installation and is typically deter-
mined when the control is first installed: if the WinHelp file is moved
the link can obviously be broken.
Licenses, such as those used by OLE controls, are also
commonly stored in the registry. They can be found under the
HKEY_CLASSES_ROOT\Licenses key, where you’ll also find
the warning that “Copying the keys may be a violation of
established copyrights.” No kidding. Anyway, each license is
stored under its own GUID. This example from my registry
database has both design and run keys (with the key values
changed, naturally):
{B54DCF20-5F9C-101B-AF4E-00AA003F0F07}
Retail
abcdefghijklmnopqrstuvwxyzabcdefghij
Related Entries in the Registry.
Expanded (Win95)
registry keys depict how root keys map to major subkeys
for current user, classes, and current configuration.
Runtime
abcdefghijklmnopqrstuvwxyzabcdefghij
F
IGURE
1
VB4 itself uses this technique: when it’s installed it merges the
contents of one of the three REG files (for Standard, Professional,
and Enterprise editions) into the registry.
Finally, the registry contains information about
remoted OLE
servers
in both their local and remote configurations. Like the other
OLE object described here, this VB4-created OLE Automation
server registers a Clerk class under its own GUID in the
HKEY_CLASSES_ROOT\CLSID key. Of course, VB4 handles all the
registration automatically and it’s typically not necessary to modify
these entries directly.
Running the Remote Automation Connection Manager (RacMgr32)
utility included with VB4 Enterprise Edition adds additional keys for
a remote machine name, RPC protocol, and RPC authentication
level. When run locally, this particular class is registered as:
OLE controls, being specialized in-process OLE servers, must
be in the registry. If an OLE control is referenced by an application
but is not in the registry, it can autoregister itself if the system can
locate it by searching along the normal DLL search path.
OLE controls are registered as classes and can also be found
in the HKEY_CLASSES_ROOT\CLSID key by referencing their
CLSID. For example, the PicClip control that ships with VB4 has
the following registry entries:
{27395F85-0C0C-101B-A3C9-08002B2F49FB}
PicClip Control
Control
InprocServer32
C:\WINDOWS\SYSTEM\PICCLP32.OCX
Insertable
MiscStatus
ProgIDPicClip.PictureClip
ToolboxBitmap32
{8435CD47-D6BE-11CE-A842-00AA00688747}
_AuthenticationLevel
2
_NetworkAddress
NT
C:\WINDOWS\SYSTEM\PICCLP32.OCX, 1
_ProtocolSequence
ncacn_ip_tcp
TypeLib
{27395F85-0C0C-101B-A3C9-08002B2F49FB}
InprocHandler32
OLE32.DLL
Version
1.0
LocalServer32
D:\PROJ\MSJ\CAR RENTAL\RENTAL OBJECTS.EXE
ProgID
RentalObjects.Clerk
The Control key is used when dialog boxes like the OLE Insert
Object dialog or VB4’s Custom Controls dialog is displayed with
the Controls box checked. InprocServer32 contains the fully
qualified path to the control.
ProgID contains the so-called “friendly” name, which can also be
found in a separate key under HKEY_CLASSES_ROOT: this separate
key contains a pointer back to the CLSID where all the information for
the control is maintained. The Insertable key behaves similarly to the
Control key, though it may be duplicated under the ProgID key for
backward compatibility with OLE 1.0 servers.
The type library for
a control is indicated in the TypeLib key.
Type libraries are stored separately in the registry under their
own GUIDs in the HKEY_CLASSES_ROOT\TypeLib key. The
entries for the PicClip control’s type library are:
TypeLib
{8435CD4E-D6EB-11CE-A842-00AA00688747}
When the class is remote, RacMgr32 changes the registration
entries to:
{8435CD47-D6BE-11CE-A842-00AA00688747}
_LocalServer32
D:\PROJ\MSJ\CAR RENTAL\RENTAL OBJECTS.EXE
AuthenticationLevel
2
InprocHandler32
OLE32.DLL
InprocServer32
C:\WINDOWS\SYSTEM\autprx32.dll
NetworkAddress
NT
ProgID
RentalObjects.Clerk
ProtocolSequence
ncacn_ip_tcp
TypeLib
{8435CD4E-D6EB-11CE-A842-00AA00688747}
Visual Basic Programmer’s Journal
MARCH 1996
23
http://www.windx.com
©1991–1996 Fawcette Technical Publications
HACKING THE REGISTRY
Text Value
Keys
Subkeys
Binary Value
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).
F
IGURE
2
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:
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
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
24
MARCH 1996
Visual Basic Programmer’s Journal
©1991–1996 Fawcette Technical Publications
http://www.windx.com
HACKING THE REGISTRY
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\<program name>
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.
F
IGURE
3
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.
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.
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
C
ONTINUED
ON
PAGE
30.
http://www.windx.com
©1991–1996 Fawcette Technical Publications
Visual Basic Programmer’s Journal
MARCH 1996
25
HACKING THE REGISTRY
Adding the Test VB Finder to the Find Menu in Explorer.
The registry structure for dynamically added Find items illustrates
how simple it is to add items to the menu. A modified Find Menu in the new shell’s Explorer show an entry added by MSN as
well as two custom entries described here. It’s just as easy to add an entry for something like Yahoo for finding files on the Internet.
F
IGURE
4
C
ONTINUED
FROM
PAGE
26.
• Invalid ProgID key.
• Missing OLE key.
• Wrong value for OLE key.
• Missing file.
• Empty subkey.
• Conflicting local/remote keys.
• Improper InprocServer registration.
• Server isn’t AUTPRX16.DLL/AUTPRX32.DLL.
• Differing server paths.
• Missing InprocServer key.
This shows the contents of a trivial REG file using the old format:
REGEDIT
HKEY_CLASSES_ROOT\.txt = txtfile
And, this shows this new format (with a named value):
REGEDIT4
[HKEY_CLASSES_ROOT\.txt]
@="txtfile"
"Content Type"="text/plain"
RegClean also gives you the option of creating a pending change
file or just letting it rip and make the changes for you (guess
which one I chose).
If you distribute a REG file with your application, be aware
that Setup Toolkit has somewhat limited support for this. You
can add a REG file with the Add Files button and the Setup
Toolkit will register those keys on the user’s machine. However,
you are limited to embedding relative paths and there’s no
automated support for uninstalling the REG file entries.
If you’ve been following along on your machine, your registry
might be getting a little wonky. It’s not uncommon for your
registry to get whacked: hacking around manually just tends to
accelerate this process. Eventually, you’re going to want to use
the little-known RegClean utility (16- and 32-bit) that ships with
VB4 and is located in the \Tools\PSS subdirectory. It can
correct a number of these problems in your registry:
EXTENDING THE NEW SHELL
If you’ve selected New from the File menu within the Windows
95 Explorer, after what seems like an inordinate delay you’ve
seen a cascading menu (see Figure 3).
The shell is searching through the registry looking for valid
file extensions (those beginning with “.”) that have a subkey of
ShellNew. Each time it finds one, it reads the value in the
extension’s key to determine the ProgID, looks up the ProgID,
and adds the value of that key to the menu.
For example, to add the TXT item to the menu shown in
Figure 3, I added the ShellNew key to the CLSID key for “.txt”
files:
• Mismatched GUID in TypeLib.
• Missing TypeLib GUID.
• Missing CLSID for ProgID.
• Useless NumMethods or BaseInterface keys.
HKEY_CLASSES_ROOT\.txt = txtfile
ShellNew
CONTINUED
ON
PAGE
34.
26
MARCH 1996
Visual Basic Programmer’s Journal
©1991–1996 Fawcette Technical Publications
http://www.windx.com
[ Pobierz całość w formacie PDF ]

Tematy