This article touches upon how Windows 95 keeps track of file sharing. It is not meant to be an all-inclusive dissertation on every possible detail of the registry and how it relates to file sharing. While it is fairly detailed and complex in parts, it is based solely on material found in various Resource Kits, reference books, and my own personal observation. Therefore, you should use this information at your own risk.

TThere are two types of file sharing systems that Windows uses. The fist is simple and is the "stock" sharing method-password level sharing. The second is slightly more complex and requires the computer to be on a Windows Domain with a PDC (Primary Domain Controller) capable of validating users. Very few people use the second method.

Both types of sharing systems utilize the registry, and solely the registry, to keep track of shares and permissions. [Refresher: the registry is a relational database, an integral part of Windows that keeps track of configuration settings, preferences, and customizations]. Password-level sharing uses a single part of the registry to keep track of network share names, share passwords, and associated security permissions. User level sharing utilizes the same part of the registry, but includes a pointer to a separate part of the registry. This second part of the registry keeps track of each user or group, as listed and validated by the PDC, and their associated permissions to the share. This second key is there so that each user can have permissions specifically set for him.

Password Level Sharing

Password Level Sharing is stored in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Network\LanMan\. Each key (subfolder in the registry editor) in this location is the name of a file share. For instance, if my machine name was "Enigma" and I shared a directory using the name "Transfer," there would be a key here called "Transfer." This is a good place for you to pause reading and open up RegEdit for yourself. Create a share and examine the values within this key. The obvious value is "Path" which is associated to the local path to the share. (In the above example, connecting across the network to \\enigma\transfer would go to the local path "c:\etc\transfer" (or wherever the directory resides). "Remark" is just as easy to see. It is the free-form text you enter as a comment for the share. "Parm1enc" and "Parm2enc" are binary fields. They encode the share write and read passwords, respectively. They are variable-length and not null terminated. The sharing passwords are encoded using a very simple rotating XOR algorithm. "Type" tells Windows what kind of resource this item is. 0x00 is a file and 0x01 is a printer. Flags are a combination of the following values:

0000000001 (0x001)	Read Flag
0000000010 (0x002)	Write Flag
0000010000 (0x00F)	Unknown
0010000000 (0x080)	Unknown. Typically set in user-level sharing.
0100000000 (0x100)	Unknown. ALWAYS set.
1000000000 (0x200)	System-Share. Rarely seen, but PREVENTS the "sharing hand" icon from overlaying on top of this item's icon!

In examining this part of the registry, you may note several share keys that do not appear in Network Neighborhood, especially if you have print sharing turned on and a local printer shared to the network. Often there are shares called "Admin$" and "Printer$" that point to your Windows\System directory. It turns out that no password-level shares that end in a $ appear in Network Neighborhood. To access these shares, you must know them beforehand and type them directly (e.g. go to the Start Menu, select "Run," and then type \\computername\sharename).

Some of these secret shares do not even show up in the Network Watcher application and do not have the "sharing hand" icon overlaid on top of their standard folders. This is especially true if you have a local printer shared and someone across the network is setting up their system to use it-their system automatically copies the drivers out of your \windows\system directory. I do not know an official name for these shares. I have not even found a documented reference of their existence (typical Microsoft). I have dubbed them "System-Shares" and refer to them as such.

Password Level Sharing Password Encryption

After less than an hour of work with a pencil, paper, and hex calculator, I was able to determine Microsoft's password encryption algorithm-my first ever attempt at cryptoanalysis; Bruce Schneier would be proud. He would also by dumbfounded by Microsoft's ineptitude. Again.

The passwords are all upper case and therefore case insensitive. During encryption/decryption the string's terminating null is not encrypted. It is also not stored in the registry. The encryption is performed by using a simple XOR with an 8-bit rotating key. The first character in the password is XOR'ed with a key of 0x35 (00110101). The bits of this key are rotated right by one position to 0xD8(10011010) and XOR'ed with the second character of the password. This rotr() and XOR'ing is continued for each character in the password.

User Level Sharing

This type of sharing is slightly more complex. The above mentioned registry key is correct. "Path," "Remark," and "Type" are exactly the same. "Parm1enc" and "Parm2enc" are empty (zero-length binary values) and ignored, even if they are present. "Flags" is set to 0x193, although it seems to be ignored for all practical purposes. Toggling the 0x200 System-Share flag works with user level sharing, as well!

A second key is placed in the HKEY_LOCAL_MACHINE\Security\Access hierarchy. The local path (as specified above in "Path") is appended to this key and sharing data is stored here. For instance, if E:\Documents\Sekrit is shared, a key is inserted into the registry at "HKEY_LOCAL_MACHINE\Security\Access\E:\Documents\Sekrit." Apparently a colon is a valid character for registry keys. Within this key any number of values are stored-one set for each user or group that has access to this resource. Each value's name is the network name of a user or group, including domain. The associated value is a set of bit-level flags used to determine that user or group's access. For instance, a user named "Tesla" in the domain "Inventors" would be "Inventors\Tesla." The group "Administrators" in the domain "Inventors" would be "Inventors\Administrators," but would have a special flag set (see below) to let the computer know that this is a group instead of a single person. "Everyone" (or "The World") is just a single asterisk ("*") without any back-slashes or other characters.

The value associated with this name is a bit field, composed of OR-ing together any of the following constants:

0x0000	Read Access
0x0200	Write Access
0x0400	Create Access
0x1000	Delete Access
0x2000	Change Access
0x4000	User can change access control
0x8000	List Files
0x0080	The string in the name field is not a user, but a domain group

For instance:

0x8180	Means that everyone can list and read files here Inventors\Tesla
0xFF00	The guy logged in as Tesla can do anything Inventors\Famous
0xB780	Everyone part of the "Famous" group can do anything but change access control

Registry Fun Thwarted

You may have noticed that the Windows user interface does not allow you to share certain things-one example being a mapped network drive (a share from another computer). You can rest assured that after adding custom entries into the registry, that should allow this, Windows still somehow prevents these mapped drives from being shared. Imagine how confusing things would be if you could share a share. Imagine a long chain of shares. Imagine the "feedback" and overflows that would occur if two shares pointed directly at each other! Maybe it is good that this isn't (yet) possible.

Conclusion

As stated previously, this information works only on Windows 95. Use it at your own risk--tweaking with the registry is always a dangerous endeavor if you do not know what you are doing. Little research has been done with NT Server or Workstation. This data is probably stored in a similar fashion, but with Registry security active.

Files

I am placing two programs (with Visual C++ source code) onto public servers for interested parties to tinker with.

	Setup Trojan (18K) -- A tiny program called Setup.EXE which adds a full read/write hidden System-Share to the victim's C:\ drive. Takes less than a second to run and will then call a REAL setup.exe. Includes VC++ source code.
	Share View (310k) -- allows you to see ALL shares on your system, whether hidden, System-Share or normal. Displays read/write information and plaintext decoded passwords. Allows you to toggle the System-Share bit of any existing share. Includes VC++ source code.

Back to the main page.