Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Apr 2006 07:23:31 +0400
From: Solar Designer <>
Subject: SYSKEY

Dear Rembrandt,

On Thu, Apr 06, 2006 at 04:28:48AM +0200, wrote:
> If you would have take a look at bkhive you would have noticed that, if
> you also have the system-file where the SYSKEY is normaly stored in, you
> don?t have to crack SYSKEY from a SAM from a modern Windows.
> The encryption key is stored in this system-File so it gets decrypted
> imedietly. So if John would be able to do this it could also be able to
> convert the SAM like pwdump does.

I understand this.  I never implied otherwise.

I also remember this feature request of yours from a few months ago -
but as you're well aware, I did not bother to implement it.

The only thing I said now is that to have a SAM file off a modern
Windows system processed, one would at least have to grab the SYSKEY as
well - to allow for the instant decryption. (*)  I also said that for
Jay it would be a lot of complexity for no gain - things were already
too complicated for him, so why have him grab two files and pass them
through an extra program when he can just use pwdump2 instead?

(*) For others reading this discussion - this "instant decryption" does
_not_ produce plaintext passwords.  It merely produces unencrypted
hashes which may then be passed for (non-instant) cracking to John as

> The bkhive-Source is totaly messed up, yes. But if you manage to compile
> it it realy works even a plain and good C-Version would be better.
> So SAMs are not that hard to handle because MS provides you the key for
> the SYSKEY-Encryption too.

That's right.  But we can't expect Jay to compile bkhive and so on, and,
more importantly, he does not need to do that.  So the "SAM file approach"
was wrong for him.

> LothCrack does not get sold outside america anymore because fucked up
> crapto-Laws.

As far as I know, LC5, the last incarnation of L0phtCrack, is no longer
sold at all, including within North America, and this has nothing to do
with crypto laws (although that was used as the excuse initially).  It's
Symantec's business decision to kill this fine product of @stake, a
company they've acquired.  Apparently, they did the same to other @stake

> So I don`t wonder why so much people start to use John

Yes, John should gain some users as a result of this.

> even for SAM-Files.

That's also true - although it appears that most people who try to use
John on raw SAM files simply don't know that there are easier approaches
(the pwdump* tools).

Dennis has just provided a valid reason for processing SAM files
directly (accessing a Windows partition off another OS), but I doubt
that he's a past LC5 user.

> But LC provides also a "real" Bruteforce against the SYSKEY-Encryption
> (without knowing the key).

I was not aware of that.  Are you sure?  Got some reference to back this
up with?

I was surprised enough that I Googled for this and found some claims to
the opposite:

This is a copy of the official LC5 FAQ.  It says:

| Q. Does LC 5 decrypt passwords from a Windows 2000 SAM file that uses
| Syskey encryption?
| A. No, LC does not support this.

| NTFSDOS is useful free utility for booting your system from a floppy to
| gain read-only access to your hard disk's files.  This can be useful
| for accessing a SAM file (although SYSKEY-protected SAMs will not be
| auditable in LC5).

> But adding the bkhive and pwdump "feautures"
> would be a big step ahead (at least for guys who also have to maintain
> Windows-CLients).

I agree.  But I am unsure about adding such system-specific features
into the main John source tree.

(bkhive is not _that_ system-specific - it makes sense to run it on
non-Windows; but pwdump is.)

I am considering making a "Pro" version of John, distributed primarily
as pre-built native packages for specific popular systems (Windows,
Linux, maybe Solaris, maybe Mac OS X) where such features could be
included.  The same goes about adding a GUI.  This version, if ever made
and maintained, would likely be non-free or not completely free (at
least not in the GNU sense).  I would actually pay money for development
and maintenance of the GUI - I wouldn't want to spend my very own time
on that.

Alexander Peslyak <solar at>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598 - bringing security into open computing environments

Was I helpful?  Please give your feedback here:

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ