Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

I want to manually get the NT hash from the registry (without any tool). Let's say just for the administrator. I know that it must be stored in the SAM area of the registry somewhere so I tried to extract it from there. I found the location HKLM\SAM\SAM\Domains\Account\Users\000001F4 (1F4=500=Admin) and there the value "V" with some binary content. The only useful documentation for the V binary is this link: but that info is very old and I'm not sure if that is still correct with current Windows 7 and Windows 8. Also, if I extract the NT hash like described there, it doesn't match what I get if I set the password to "123" (I would expect 3dbde697d71690a769204beb12283678, but got 1509c04cb2a3e20eba3fde1ac5f8589f). So the question again: How to manually extract the NT hash from the registry?

share|improve this question

closed as off-topic by TildalWave, Adi, Rory Alsop Jul 9 '13 at 7:06

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to break the security of a specific system for you are off-topic unless they demonstrate an understanding of the concepts involved and clearly identify a specific problem." – TildalWave, Adi
If this question can be reworded to fit the rules in the help center, please edit the question.

I don't know the internals of how Windows stores the hashes, but a difference in the hash could be accounted for by a salt – LamonteCristo Jul 7 '13 at 11:53
Hi @makerofthings7, best answer so far. Let me know if I should edit the post somehow. Yes, if Windows is now using a salt, that would explain everything. Are you sure about that? It would be new to me that Windows now uses salting. Any source for that? Since what version? And which salt is being used? The username, SID or something completely different? I think Windows is NOT using salting at all (for several reasons), but convince me if you have any reliable source for that. – http Jul 7 '13 at 17:12
An API will be needed to read the hash if the one you located is wrong or incomplete. The premise of this question is that regedit & file browsing tools built into the OS are sufficient to view the hash. That may not be the case, and the value may be stored in binary using a non documented API that is restricted to a specific calling process. Your question seems to think linux-like where you can browse to a ./etc/passwd file. That's not necessarily the case with Windows OSs... but I don't know for sure. – LamonteCristo Jul 7 '13 at 17:57
@http You need to challenge your assumptions or else you will dismiss the correct answer because it does not match what you expected. – schroeder Jul 8 '13 at 15:13
Simple answer http: you are not asking a security question. The question you have asked is basic windows OS functionality. It has been perfectly well answered in any case. – Rory Alsop Jul 11 '13 at 10:49

2 Answers 2

How to extract the hashes from the registry without 3rd party tools

This is the bare-bones answer to the question posed by the OP:

reg.exe save HKLM\SAM MySam
reg.exe save HKLM\SYSTEM MySys

In these files are the local user hashes (not AD). From here, a simple hex script can be written to pull out the individual hashes.

The next question is: are you happy with the just hashes, or do you want to reverse engineer them to the plaintext versions? That question is not asked, so I will assume that it is not desired.


This post explains how to script ways to extract hashes.

share|improve this answer
I'm interested in this "simple hex script". Well, I don't even need a script, just a description what to get from where exactly. Yes, just the hashes. Only Admin one is sufficient. – http Jul 8 '13 at 21:39
@http Then you need to radically alter your question. – schroeder Jul 8 '13 at 23:54
I think the question is really clear. I don't know how to improve it. Let me know if you can. I asked how to get the hash. No idea why I should radically alter it. – http Jul 11 '13 at 2:18
I just saw your link ("This post") in the edit. That post there is very helpful. It says that SysKey is generating a bootkey that is generated from other values stored in the Class attribute of some other keys etc. I haven't read/understood/verified everything yet. Why don't you give that as an answer? I thought we are not allowed to post a simple link as an answer and all answers have to get copied here. Such an answer would answer my original question. – http Jul 11 '13 at 2:41
I finished reading the "This post" and see that the calculation of the 16-byte boot key is missing. Would that be a new question? – http Jul 11 '13 at 2:54

The hashes are stored in the Windows SAM file. This file is located on your system (depending on your installation paths) at X:\Windows\System32\config but is not accessible while the operating system is booted up. These values are also stored in the registry at HKEY_LOCAL_MACHINE\SAM, but again this area of the registry is also not accessible while the operating system is booted.

There are known ways (and tools) to reverse engineer the hashes to retrieve the passwords and vice-versa, but I am not going to help you with that because...

Questions asking us to break the security of a specific system for you are off-topic unless they demonstrate an understanding of the concepts involved and clearly identify a specific problem.


Since you have physical access, one of the most effective methods is to boot the computer into a different operating system. If you are comfortable using Linux then this means you can simply boot to a Linux live CD that is capable of reading NTFS drives, mount the Windows partition, and copy the SAM file to external media. Work on that copy by looking at “SAM\Domain\Account\Users”. The rest is up to you.

On a sidenote I would like to warn you about playing with such system areas if you are using Encrypted File System (EFS) on anything released after Windows XP/2003. If you change something in the wrong place there (like resetting passwords or modifying other hashes), it might cause the operating system to lose its EFS keys which introduces a whole new bunch of problems which you don't even want to think about. That's why you'll only want to work with a copy of the SAM file.


Just found your previous question "How to brute-force NT hash to password?" and I'm starting to understand why you keep asking for the "exact hash location" and "hash identification".

Therefore, a little reminder: security.SE is not here to help you hack or crack anything. Please check the rules instead of looping the question in the comments area. Thanks.

share|improve this answer
@http Please read what I wrote: not accessible while the operating system is booted. You will have to use another OS (Windows, Linux) to access the data from the non-booted windows install you want to analyze. Besides that, I think that marking the locations "X:\Windows\System32\config" and "HKEY_LOCAL_MACHINE\SAM" in bold is enough indication where to look? To make sure you get it: even if you would be able to run regedit as SYSTEM, your OS is booted and the related areas not accessible while the operating system is booted so you will not be able to see the hidden and locked data. – e-sushi Jul 6 '13 at 22:25
@http I can't help you as long as you ignore what I write... I never stated you need "wizard" software to help you find the hash locations; I said you need another "OS". Since you keep repeating your "no tool" mantra over and over again, let me remind you that no one can read disk-data with the naked eye. You will need a hex-editor to see the relevant raw bytes. But no special "password crackers" or "hash fetchers" needed. As for the repeated location question, I'll quote my EDIT: "SAM\Domain\Account\Users". You want to do it manually? Use separate OS + HexEdit and get your hands dirty. – e-sushi Jul 7 '13 at 14:42
@http Please note that after I post this comment, I won't be replying here anymore to avoid a discussion loop. Besides that, I think time has come to point you to "Please avoid extended discussions in comments.", "Can I get data analysed here? Can I challenge people to decode something? No. Such questions are not helpful." and… Have a nice day. – e-sushi Jul 7 '13 at 17:37
@http Let's assume that e-sushi is correct. That means that the relevant hashes are loaded into memory at bootup and the sources are locked. That means that to get what you are looking for, you need to look in the memory, or be outside of the OS to read the hashes and salts. Look at the source code of the tools you know. Where do they look? – schroeder Jul 8 '13 at 15:22
@http Please avoid extended discussions in comments. Security.SE is not a “forum”. Besides, your question was put on hold as “off-topic” two days ago. From my perspective — for a good reason… – e-sushi Jul 11 '13 at 13:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.