Index: trunk/doc/devel/README
===================================================================
--- trunk/doc/devel/README	(revision 164)
+++ trunk/doc/devel/README	(revision 164)
@@ -0,0 +1,4 @@
+Developer's documentation previously stored here has been removed from the
+main software distribution trunk.  It is still available in the Subversion
+repository, however, and may be obtained here:
+  http://code.google.com/p/reglookup/source/browse/
Index: trunk/doc/devel/TODO
===================================================================
--- trunk/doc/devel/TODO	(revision 163)
+++ 	(revision )
@@ -1,47 +1,0 @@
-$Id$
-
-If you are interested in contributing to this project, here's a few
-things you could look into:
-
- - Currently there is no way on the command line to search for exotic 
-   paths/types.  For instance, if reglookup encounters an unknown VK
-   type, it just prints it out in Hex.  However, if you wanted to search
-   specifically for that type, there is no way to do it.  Similarly, it
-   isn't possible to specify certain binary or weird characters in
-   paths.  Reglookup should take the user path and unquote each path
-   component using the \xQQ syntax prior to searching.
-
- - It might be nice to have a way to filter results by security 
-   descriptor information.  Maybe by MTIME as well.
-
- - Testing, testing, and more testing.  reglookup needs to be more
-   heavily tested on all recent Windows platforms.  A regression test
-   suite would be nice too.  Some thoughts on this include a script
-   which randomly fuzzes an existing registry file, and tries to detect
-   crashes of reglookup when parsing it.  Another test script might
-   randomly truncate an existing registry file, which will help improve
-   reglookup's parsing on fragmentary files.
-
- - Build system.  I do not wish to use automake/autoconf in this
-   project.  I have also now decided that make is painful to use for
-   everything.  I'd like to switch to a suite of shell scripts driven by
-   minimal make rules.  If you got any ideas on this, shoot them my way.
-
- - Unicode support still needs improvement.  While parsing strings seems
-   to be decent, UTF-8 output would be nice.
-
- - Develop and solidify regfi API.  Regfi should be better documented and 
-   eventually needs a set of higher-language wrappers, starting with Python
-   and possibly moving on to Perl as well.
-
- - Documentation.  The security descriptor output format needs to be
-   documented.  Also, function contracts should be added to the
-   lower-level functions of regfi.c.
-
- - The smb_deps.h and smb_deps.c content is almost eliminated.  Just need
-   to integrate parts that are being kept into regfi or other modules.
-
- - Consider switching from libiconv to Joachim Metz's libuna for
-   increased portability and easier builds.
-
- - Grep through the source for 'XXX', and you'll find more.
Index: trunk/doc/devel/references.txt
===================================================================
--- trunk/doc/devel/references.txt	(revision 163)
+++ 	(revision )
@@ -1,30 +1,0 @@
-- The Windows NT Registry File Format
-  (A work in progress to support this tool.)
-  http://sentinelchicken.com/research/registry_format/
-
-- Recovering Deleted Data From the Windows Registry
-  (The research that is implemented as a PoC in reglookup-recover.)
-  http://sentinelchicken.com/research/registry_recovery/
-
-- Petter Nordahl-Hagen.  Windows NT registry file format description.
-  (The file 'winntreg.txt' included in this distribution is derived from this.)
-  http://home.eunet.no/~pnordahl/ntpasswd/WinReg.txt
-
-- Some useful information on how Windows reads from and writes to registry
-  hives:
-  http://www.microsoft.com/technet/archive/winntas/tips/winntmag/inreg.mspx
-
-- Registry key, value, and depth limits:
-  http://msdn2.microsoft.com/en-us/library/ms724872.aspx
-
-- Misc references for windows registry permissions and ownership:
-  http://msdn2.microsoft.com/en-gb/library/ms724878.aspx
-  http://technet2.microsoft.com/WindowsServer/en/library/86cf2457-4f17-43f8-a2ab-7f4e2e5659091033.mspx?mfr=true
-  http://msdn2.microsoft.com/en-gb/library/aa374892.aspx
-
-- ACL/ACE flags information
-  http://support.microsoft.com/kb/220167
-  http://msdn2.microsoft.com/en-us/library/aa772242.aspx
-
-- Info on SAM hive, syskey, and hash extraction (with tools bkhive and samdump2):
-  http://www.studenti.unina.it/~ncuomo/syskey/
Index: trunk/doc/devel/winntreg.txt
===================================================================
--- trunk/doc/devel/winntreg.txt	(revision 163)
+++ 	(revision )
@@ -1,272 +1,0 @@
-The windows NT registry has 2 different blocks, where one can occur many
-times...
-
-the "regf"-Block
-================
- 
-"regf" is obviosly the abbreviation for "Registry file". "regf" is the
-signature of the header-block which is always 4kb in size, although only
-the first 64 bytes seem to be used and a checksum is calculated over
-the first 0x200 bytes only!
-
-Offset            Size      Contents
-0x00000000      D-Word      ID: ASCII-"regf" = 0x66676572
-0x00000004      D-Word      ???? //see struct REGF
-0x00000008      D-Word      ???? Always the same value as at 0x00000004
-0x0000000C      Q-Word      last modify date in WinNT date-format
-0x00000014      D-Word      1
-0x00000018      D-Word      3
-0x0000001C      D-Word      0
-0x00000020      D-Word      1
-0x00000024      D-Word      Offset of 1st key record
-0x00000028      D-Word      Size of the data-blocks (Filesize-4kb)
-0x0000002C      D-Word      1
-0x000001FC      D-Word      Sum of all D-Words from 0x00000000 to
-                            0x000001FB  //XOR of all words. Nigel
-
-I have analyzed more registry files (from multiple machines running
-NT 4.0 german version) and could not find an explanation for the values
-marked with ???? the rest of the first 4kb page is not important...
-
-the "hbin"-Block
-================
-I dont know what "hbin" stands for, but this block is always a multiple
-of 4kb in size.
-
-Inside these hbin-blocks the different records are placed. The memory-
-management looks like a C-compiler heap management to me...
-
-hbin-Header
-===========
-Offset      Size      Contents
-0x0000      D-Word      ID: ASCII-"hbin" = 0x6E696268
-0x0004      D-Word      Offset from the 1st hbin-Block
-0x0008      D-Word      Offset to the next hbin-Block
-0x001C      D-Word      Block-size
-
-The values in 0x0008 and 0x001C should be the same, so I dont know
-if they are correct or swapped...
-
-From offset 0x0020 inside a hbin-block data is stored with the following
-format:
-
-Offset      Size      Contents
-0x0000      D-Word      Data-block size    //this size must be a
-multiple of 8. Nigel
-0x0004      ????      Data
- 
-If the size field is negative (bit 31 set), the corresponding block
-is free and has a size of -blocksize!
-
-That does not seem to be true. All block lengths seem to be negative! 
-(Richard Sharpe) 
-
-The data is stored as one record per block. Block size is a multiple
-of 4 and the last block reaches the next hbin-block, leaving no room.
-
-(That also seems incorrect, in that the block size if a multiple of 8.
-That is, the block, including the 4 byte header, is always a multiple of
-8 bytes. Richard Sharpe.)
-
-Records in the hbin-blocks
-==========================
-
-nk-Record
-
-      The nk-record can be treated as a kombination of tree-record and
-      key-record of the win 95 registry.
-
-lf-Record
-
-      The lf-record is the counterpart to the RGKN-record (the
-      hash-function)
-
-vk-Record
-
-      The vk-record consists information to a single value.
-
-sk-Record
-
-      sk (? Security Key ?) is the ACL of the registry.
-
-Value-Lists
-
-      The value-lists contain information about which values are inside a
-      sub-key and dont have a header.
-
-Datas
-
-      The datas of the registry are (like the value-list) stored without a
-      header.
-
-All offset-values are relative to the first hbin-block and point to the
-block-size field of the record-entry. to get the file offset, you have to add
-the header size (4kb) and the size field (4 bytes)...
-
-the nk-Record
-=============
-Offset      Size      Contents
-0x0000      Word      ID: ASCII-"nk" = 0x6B6E
-0x0002      Word      for the root-key: 0x2C, otherwise 0x20  //key symbolic links 0x10. Nigel
-0x0004      Q-Word      write-date/time in windows nt notation
-0x000C      D-Word      UNKNOWN // added by TDM
-0x0010      D-Word      Offset of Owner/Parent key
-0x0014      D-Word      number of sub-Keys
-0x0018      D-Word      UNKNOWN // added by TDM
-0x001C      D-Word      Offset of the sub-key lf-Records
-0x0020      D-Word      UNKNOWN // added by TDM
-0x0024      D-Word      number of values
-0x0028      D-Word      Offset of the Value-List
-0x002C      D-Word      Offset of the sk-Record
-
-0x0030      D-Word      Offset of the Class-Name //see NK structure for the use of these fields. Nigel
-0x0044      D-Word      Unused (data-trash)  //some kind of run time index. Does not appear to be important. Nigel
-0x0048      Word      name-length
-0x004A      Word      class-name length
-0x004C      ????      key-name
-
-the Value-List
-==============
-Offset      Size      Contents
-0x0000      D-Word      Offset 1st Value
-0x0004      D-Word      Offset 2nd Value
-0x????      D-Word      Offset nth Value
-
-To determine the number of values, you have to look at the owner-nk-record!
-
-Der vk-Record
-=============
-Offset      Size      Contents
-0x0000      Word      ID: ASCII-"vk" = 0x6B76
-0x0002      Word      name length
-0x0004      D-Word      length of the data   //if top bit is set when offset contains data. Nigel
-0x0008      D-Word      Offset of Data
-0x000C      D-Word      Type of value
-0x0010      Word      Flag
-0x0012      Word      Unused (data-trash)
-0x0014      ????      Name
-
-If bit 0 of the flag-word is set, a name is present, otherwise the value has no name (=default)
-
-If the data-size is lower 5, the data-offset value is used to store the data itself!
-
-The data-types
-==============
-Wert      Beteutung
-0x0001      RegSZ:             character string (in UNICODE!)
-0x0002      ExpandSZ:   string with "%var%" expanding (UNICODE!)
-0x0003      RegBin:           raw-binary value
-0x0004      RegDWord:   Dword
-0x0007      RegMultiSZ:      multiple strings, seperated with 0
-                  (UNICODE!)
-
-The "lf"/"lh"/"ri"-record (hash list header)
-===============
-Offset      Size      Contents
-0x0000      Word      ID: ASCII-"lf" = 0x666C  (or "lh" or "ri")
-0x0002      Word      number of keys
-0x0004      ????      Hash-Records
-
-Hash-Record
-===========
-Offset      Size      Contents
-0x0000      D-Word      Offset of corresponding "nk"-Record
-0x0004      D-Word      ASCII: the first 4 characters of the key-name, padded with 0-s. Case sensitive! 
-			(the hash value may be computed differently for the various header types 
-			 "lf"/"lh"/"ri"/etc)
-Keep in mind, that the value at 0x0004 is used for checking the data-consistency! If you change the 
-key-name you have to change the hash-value too!
-
-//These hashrecords must be sorted low to high within the lf record. Nigel.
-
-The "sk"-block
-==============
-(due to the complexity of the SAM-info, not clear jet)
-(This is just a self-relative security descriptor in the data. R Sharpe.) 
-
-
-Offset      Size      Contents
-0x0000      Word      ID: ASCII-"sk" = 0x6B73
-0x0002      Word      Unused
-0x0004      D-Word      Offset of previous "sk"-Record
-0x0008      D-Word      Offset of next "sk"-Record
-0x000C      D-Word      usage-counter
-0x0010      D-Word      Size of "sk"-record in bytes
-????                                             //standard self
-relative security desciptor. Nigel
-????  ????      Security and auditing settings...
-????
-
-The usage counter counts the number of references to this
-"sk"-record. You can use one "sk"-record for the entire registry!
-
-Windows nt date/time format
-===========================
-The time-format is a 64-bit integer which is incremented every
-0,0000001 seconds by 1 (I dont know how accurate it really is!)
-It starts with 0 at the 1st of january 1601 0:00! All values are
-stored in GMT time! The time-zone is important to get the real
-time!
-
-Common values for win95 and win-nt
-==================================
-Offset values marking an "end of list", are either 0 or -1 (0xFFFFFFFF).
-If a value has no name (length=0, flag(bit 0)=0), it is treated as the
-"Default" entry...
-If a value has no data (length=0), it is displayed as empty.
-
-simplyfied win-3.?? registry:
-=============================
-
-+-----------+
-| next rec. |---+                      +----->+------------+
-| first sub |   |                      |      | Usage cnt. |
-| name      |   |  +-->+------------+  |      | length     |
-| value     |   |  |   | next rec.  |  |      | text       |------->+-------+
-+-----------+   |  |   | name rec.  |--+      +------------+        | xxxxx |
-   +------------+  |   | value rec. |-------->+------------+        +-------+
-   v               |   +------------+         | Usage cnt. |
-+-----------+      |                          | length     |
-| next rec. |      |                          | text       |------->+-------+
-| first sub |------+                          +------------+        | xxxxx |
-| name      |                                                       +-------+
-| value     |
-+-----------+    
-
-Greatly simplyfied structure of the nt-registry:
-================================================
-   
-+---------------------------------------------------------------+
-|                                                               |
-v                                                               |
-+---------+     +---------->+-----------+  +----->+---------+   |
-| "nk"    |     |           | lf-rec.   |  |      | nk-rec. |   |
-| ID      |     |           | # of keys |  |      | parent  |---+
-| Date    |     |           | 1st key   |--+      | ....    |
-| parent  |     |           +-----------+         +---------+
-| suk-keys|-----+
-| values  |--------------------->+----------+
-| SK-rec. |---------------+      | 1. value |--> +----------+
-| class   |--+            |      +----------+    | vk-rec.  |
-+---------+  |            |                      | ....     |
-             v            |                      | data     |--> +-------+
-      +------------+      |                      +----------+    | xxxxx |
-      | Class name |      |                                      +-------+
-      +------------+      |
-                          v
-          +---------+    +---------+
-   +----->| next sk |--->| Next sk |--+
-   |  +---| prev sk |<---| prev sk |  |
-   |  |   | ....    |    | ...     |  |
-   |  |   +---------+    +---------+  |
-   |  |                    ^          |
-   |  |                    |          |
-   |  +--------------------+          |
-   +----------------------------------+
-
----------------------------------------------------------------------------
-
-Hope this helps....  (Although it was *fun* for me to uncover this things,
-                  it took me several sleepless nights ;)
-
-            B.D.
