Hello,
The attached patch adds decryption of the NT password encryption block used in the SAMR UnicodeChangePassword2 request.
Some notes:
The main goal was to start getting of some basic crypto into the codebase in a uniform manner (where it is abstracted and can be used by multiple dissectors). This patch was really done to demonstrate that the crypto worked properly. Ideally, the same crypto infrastructure can be used for more useful purposes (read NTLMSSP).
The patch includes two new files (crypt-md4.c and crypt-rc4.c) which are required to perform the decryption functionality. I decided to import our own crypto sources (taken from Samba), because I have not been able to find a suitable GPL cross-platform library that provides comparable functionality. The cryptolib library was the only library I found with a GPL compatible license that had the needed functionality. However, upon looking at the code itself, they are actually using Eric Young's crypto functions (the basis of OpenSSL). This puts into question how they can distribute a GPL library that includes code derived from Eric Young's code (with his advertising clause).
The naming convention I am using is "crypt-<algorithm>.c" (and .h). This is independent of whether it is a cryptographic cipher or a cryptographic hash.
I am not certain how to modify the win32 makefiles to include the new files (since I do not have a Win32 environment). The win32 makefile would need to be modified if the patch is committed to CVS.
We only decrypt the NT password change block. The Lan Manager change block is not yet decrypted. I wanted to get this portion accepted into the codebase. If it is accepted, the next step will be to do the Lan Manager block.
A configuration option was added to the SAMR dissector to accept a password. This password is used to decrypt the password block.
Attached is a capture that demonstrates the functionality. In the capture, the user's password was changed from "abcd" to "efgh". By setting the "NT Password" field to "abcd" in SAMR protocol preferences, the block will be properly decrypted (frame 33).
It was suggested by Ronnie Sahlberg to make the 802.11 dissector use the same RC4 source. This has not been done, because the 802.11 dissector simultaneously computes a CRC32 checksum while doing the decryption. While the CRC32 can certainly be separated from the decryption, I don't have any 802.11 captures, and I didn't feel comfortable breaking an otherwise working dissector. If someone sends me a working trace, I can get the 802.11 module to use the new crypt-rc4.c.
There is a known issue where if the user clicks on "New NT Password Encrypted Block", only the Referent ID is highlighed in the hexdump. Ideally, the entire encrypted block should be highlighted. Any ideas as to why this is happening would be greatly appreciated.
I tried to make the changes as clean as possible. Any feedback on style, etc are always appreciated.
Thanks,
Devin Heitmueller
Attachment:
passchange.diff.unified
Description: Binary data
Attachment:
crypt-md4.c
Description: Binary data
Attachment:
crypt-md4.h
Description: Binary data
Attachment:
crypt-rc4.c
Description: Binary data
Attachment:
crypt-rc4.h
Description: Binary data
Attachment:
unicodechangepassword2_abcd_to_efgh.eth
Description: Binary data