When we change
registry information in an existing APPV package we usually do so manually in
the Sequencer, Ave or TMEdit then save the new
version.
Afterwards we try to document that changed registry information and often
forget some crucial information, making resequencing of the application later
on harder than it should be.
During the development of an internal APPV workflow application we have created
around Tweakappv, TMEdit
and AVE, we also wanted to document what has been done in each applications
REGISTRY.DAT after the APPV file is saved in a new version automatically.
The new and
the old Registry.DAT file could be extracted automatically by 7zip command line
version with this command: 7-Zip>7z.exe
x "filaname.appv" "registry.dat" –y
(just ignore archive errors, the registryfile will
work non the less=)
But
understanding the DAT files is not very easy.
By coincidence I found a tool a clever guy have made in C# and published for
free called “Registry
Comparator (GUI)”. It can be downloaded from that site once you registered
an account there.
We are
going to modify the source code so it will just pipe out the changes directly
to our documentation log file with a commandline J
Here is his own words:
Introduction
In order to
see how some software manipulate the Windows Registry, I needed a tool that
could take two hive files, load them, and then compare them to show the
differences between the two. I did find some code on the net that would compare
files but not two registry hives in a nice graphical way. So I thought of
coding one myself in C#. (Registry Hives are binary files, I don't mean here
the .reg text based files made by regedit.exe.)
Background
Windows
stores the Registry in binary files. The format of this Registry hive is not
publicly available. The way data is stored in the Registry is simple. It begins
with a Registry header of size 4096 bytes. It then starts off with Logical Data
blocks - aka Cells. Based on the type of Logical Data blocks, it will have a
list of pointers (called offsets = file offset from 4096th byte). These
pointers point to another logical cell which has more information or data in
them. Broadly speaking, there are two types of cells:
·
Node
Key Cell
·
Value
Key Cell
Node keys -
as the name suggests - are nodes of a tree. It's like the directory in the
Windows file system. A directory can have in it more directories and files.
This node cell has four important pieces of information.
·
Number
of Subkeys in this Node (or Key)
·
Pointer
to a Cell that stores the address of these Subkeys.
·
Number
of Value Key Cells in this node.
·
Pointer
to a Cell that stores addresses of Value Keys.
A value key
cell stores data. Value keys behave like files which have different types of
formats and information. Values keys are broadly categorized into having text
based information or binary information.
HIVE starts
off with the ROOT node at (4096+32) address. Information is read by reading
this first Node Key type cell. The subkey node
information provides us link to the sub keys present in this node. We have to
iterate through all the nodes to read the entire Registry hive. We also read
the Value Keys as we iterate deeper into levels.
I have got
some very good information (and coding help too) from these articles:
http://www.codeproject.com/Articles/24415/How-to-read-dump-compare-registry-hives
http://www.sentinelchicken.com/data/TheWindowsNTRegistryFileFormat.pdf
We then
read these node information into a WinForms TreeNode and then plot them in a TreeView.
Once we
have two hives loaded in two separate TreeViews, we
then compare them using a simple iteration method. We assign color to TreeNodes based on the
search status: Green is an unchanged reg key type,
red is a key that was deleted (or not present) in the second file, blue is a
key that was added into the second file (not present in the first), and pink
means a Value Key that was changed in its data.
Hope this
information will help you as much as it did for us.
No comments:
Post a Comment