
The Offline NT Password Editor

(c) 1997 Petter Nordahl-Hagen

See COPYING for copyright & credits.
See INSTALL for compile/installation instructions.

Where to get more info:
-----------------------

http://login.eunet.no/~pnordahl/ntpasswd/

What does it do?
----------------

This little program will enable you to view some information and
change user passwords in a Windows NT SAM userdatabase file.
You do not need to know the old passwords.
However, you need to get at the file some way or another yourself.
In addition it contains a simple hex-editor which enables you to
fiddle around with bits&bytes in the file as you wish yourself.

Why?
----

I often forget passwords. Especially on test installations (that
I just _must_ have some stuff out of half a year later..)
On most unix-based boxes you just boot the thingy off some kind
of rescue bootmedia (cd/floppy etc), and simply edit the
password file.
On Windows NT however, as far as I know, there is no way except reinstalling
the userdatabase, losing all users except admin.
(ok, some companies let you pay lotsa $$$$$ for some rescue service..)

How?
----

Currently, this thing only runs under linux, but it may just happen
to compile on other platforms, too.
So, to set a new adminpassword on your NT installation you either:
1) Take the harddrive and mount it on a linux-box
2) Use a linux-bootdisk
   one is available at: http://login.eunet.no/~pnordahl/ntpasswd/
ie. you do it offline, with the NT system down.

Usage:
------

>chntpw version PRE-1 970527, (c) Petter N Hagen
>chntpw: change password of a user in a NT SAM file
>chntpw [OPTIONS] <samfile>
> -h          This message
> -u <user>   Username to change, Administrator is default
> -l          (try to) list all users in SAM file
> -i          Interactive. List users (as -l) then ask for username to  change
> -d          Enter buffer debugger instead (hex editor)
> -t          Trace. Show hexdump of structs/segments. (debug function)
>See readme file on how to extract/read/write the NT's SAM file
>if it's on an NTFS partition!
>Source/binary freely distributable. See readme for details
>(Contains DESlib code (c) Eric Young)
>NOTE: This is a VERY preliminary release! You are on your own!
  
Normal usage is:

> chntp sam
  - open file 'sam' and change administrator account.

The -u option:
Specifies user to change:

> chntp -u jabbathehutt mysam
  - Prompt for password for 'jabbathehutt', if found (otherwise do nothing)
  
The -l option:
  Will list all users it can find in the file. Since the internals
  of the sam file is somewhat undocumentet, it does a lot of guessing,
  and may not find all users, and sometimes it crashes trying
  to follow the internals of the sam file.
  See the source code for more details.
  
The -i option:
  Interactive, first list all users (-l) then ask for
  the name of the user to change. Default is administrator.
  The input is case-insensitive.
  
The -d option:
  This will load the file, and then immediately enter the
  buffer debugger.
  This is a simple hex-editor with only a few commands:
  (enter ? at the . prompt to see this list)
     d [<from>] [<to>] - dump buffer within range (given as offset)
     : <offset> <hexbyte> [<hexbyte> ...] - change bytes
     h <from> <to> <hexbyte> [<hexbyte> ...] - hunt (search) for bytes
     ha <hexbyte> [<hexbyte] - Hunt all (whole buffer)
     p [<offset>] [<rid/sid>] - Change password in V struct at this offset
     s - save & quit
     q - quit (no save)
     instead of <hexbyte> etc. you may give '<string> to enter/search a string

   This is self-explaining for hex-nerds.

   The p command will enter the password change routine
   with the struct starting at the given offset (or current one)
   and you may optionally override the RID autodetection.
   (not smart, but...)

The -t option:
  This is a debug function (extended -l) to show how it traces the chain
  of structs in the file.
  Includes som messages, + hexdump of each struct
  
How does it work:
-----------------

Ehm.. it somewhat works.. but it's a big hack.

A struct, called the V value of a key in the NT registry
was suddenly somewhat documented through the pwdump utility
included in the unix Samba distribution.
This struct contains some info on a user of the NT machine,
along with 2 crypted versions of the password associated
with the account.

One password is the NT console login password,
the other the LANMAN network share password
(which essentially is the first one in uppercase only,
 and no unicode)

This is how NT encrypts the passwords:

The logon cleartext password a user enters is:
1) Converted to unicode
2) A MD4 hash is made out of the unicode string
3) Then the hash is crypted with DES, using the RID (lower
   part of the SID, userid) as the crypt key.
   This is the so called "obfuscation" step, so
   it's not obvious on a hex dump of the file
   that two or more users have the same password.
4) The result of stage 3 (16 bytes) is put into the V struct.

For the LANMAN password:
1) Uppercased (and illegal characters probably removed)
   14 bytes max, if less the remaining bytes are zeroed.
2) A known (constant) string is DES-encrypted
   using 7 first characters of the password as the key.
   Another constant is encrypted using the last 7 chars
   as the key.
   The result of these two crypts are simply appended,
   resulting in a 16 byte string.
3) The same obfuscation DES stage as 3 above.
4) 16 bytes result put into the V struct.

Since the number of possible combinations in the lanman
password is relatively low compared to the other one,
and it's easy to see if it's shorter than 8 chars or not
it's used first in brute-force-crackers.

This program, however, don't care at all what the old
one is, it just overwrites it with the new one.

Ok. So, how do we find and identify the V struct?
Yeah.. that was the hard part.. The files structure
is not documented (as far as I know..)

Shortly, here's what I found out, look in source for all the details:

The file is split up in 4k "pages". The first page is some
kind of fileheader, which I don't care about, so I skip it.

Every page starts with the string "hbin", and the first 32
bytes is some kind of page header, which I just skip, too.
At byte 32 the first "chain" of structs starts.
Each struct has a 32 bit lenght first (stored as a negative number)
the next chains length is found right after the data
in the preceding.
A lenght of 1 (-1 stored) probably indicates end of chain.
The next chain then either starts on the next "page"
or sometimes a new chain starts later out in the current
page. What's between the chains, I cannot say, I just
search for another lenght indicator that fulfills some length criteria.
THIS IS A HACK!

Now, how do we know we have the V struct we seek?
Ehh.. thats also a hack. We don't really know without parsing
a lot of structs elsewhere that defines the registry path and
probably points to the value structs. And I haven't found
out too much about that yet.
So, if a struct is longer than a certain length, we simply
try to match it up as a legal V strutct.
This can somewhat be accomplished since the first part of the V struct
(about 0xCC bytes) contains offsets into the second part.
Offsets that point to the username, comments and password.
If some of these offsets are out of bounds, or the lenghts of
the strings are out of bounds, the program assumes it's not
a legal V struct, and the chain scan continues.

Because of all this "guesswork" it may guess wrong on some files
and choke on it. If so, use the hex editor, and find it yourself.

