[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Apr 2006 12:11:04 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: SYSKEY, John "Pro"
Rembrandt,
Your postings start to sound more and more like rants rather than
suggestions, constructive criticism, etc. This is up to you as long as
we're on topic and the postings are informative to other john-users
subscribers, but you could want to stop for a moment and think whether
this is really the impression you want to make.
On Thu, Apr 06, 2006 at 07:22:45AM +0200, rembrandt@...erlin.de wrote:
> I can`t find anything about LC crackign Syskey anymore even I remember
> that I did it because I tried it out....
> I relay run a bruteforce against Syskey even I got a warning that it`s
> maybe useless at all....
Well, for now I'll assume that you don't remember correctly.
> Was LC6 ever released? (Or a Beta?!)
Not that I'm aware of. I think 5.04 or so was the latest. I didn't
keep track of L0phtCrack development, but I had a look at it again when
I was about to release John the Ripper 1.7 - just so that I could do
some comparison of their performance at LM hashes and answer questions
on that.
> > I agree. But I am unsure about adding such system-specific features
> > into the main John source tree.
The very next sentence in the message you're responding to was:
> > (bkhive is not _that_ system-specific - it makes sense to run it on
> > non-Windows; but pwdump is.)
So by the "system-specific features" I was referring primarily to
pwdump-like functionality - which you had also mentioned.
> Btw: Unshadow isn`t portable too! It wont work on OSs wich do not have a
> shadow-system.... So "portable" is just a point of view...
Actually, as both of us are aware, both unshadow and bkhive can be run
on OSes other than those from which the password or SAM files are taken.
Yes, they're similar in this respect.
> (even the code IS portable but you didn`t ported it (I don?t see it at the
> binary-archives for DOS)).
I'm not sure what you mean. There is "unshadow" in the official DOS
build of John 1.7.0.1.
> Why shouldn`t there be un "unsyskey" for Sam-Files?
I am not saying there shouldn't be one. I am unsure whether there
should be one. One of the reasons for this uncertainty is that such
"unsyskey" is likely to require further maintenance by someone who
"does" Windows - as file formats change.
This is somewhat similar to "unafs" (which also processes binary files
of software which I don't use myself), but worse.
> The example with the mounted Windows-Partition wasn`t that bad....
It was not bad at all.
> > 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.
>
> Free is free like a BSD and nothing else...
Well, under that definition, John is already not free - because it is
GPL'ed.
> Going closed-src is not a solution in my oppinion.
I am unsure whether the "Pro" (a marketing word) flavor of John, if one
is ever made, would be open or closed source yet. In fact, I don't
think this matters much to the target users of this flavor (they don't
need the source code) or to others (they don't need this flavor).
One thing I am certain of is that this would not have any negative
effect on the existing John the Ripper project, which would continue
to evolve. The expected effect is positive.
> If you wanna earn money: Just tell that clearly...
Indeed, that's one of the primary objectives - but not the only one.
There are indirect profits and costs associated with free software (in
the GNU or BSD license sense) as well. So I am already earning money
with software such as John and I also have related expenses (primarily
lost profit off other work I am not doing or paying others to do while
I am working on John or writing this message).
I see nothing wrong with earning money if the overall effect this has on
the project is neutral or positive. With this, I expect a positive
effect for both John (the existing Open Source project) and Openwall's
other projects. Openwall, Inc. is already paying for some work on Owl
(all of which is Open Source) out of profits we make off other
activities. If you look at the Owl changelog between 1.1 and 2.0,
you'll notice that it's been 2 years, yet half of the changes were made
in the last 6 months. That's the difference between mostly volunteer
(first 1.5 years) vs. mostly paid (last 6 months) work on Open Source
software - three times faster development (in this case).
Another reason to possibly branch the code is to not pollute the Open
Source portable John with code for features that would only be needed in
"Pro", and to make it easier to develop that "Pro" (yes, this could mean
lower code quality there - it would not need to be as portable or
generic - instead, it would need to be well-tested for particular target
platforms). Similarly, the documentation in "Pro" could be made
specific and not generic (several branches of it could be maintained for
different target OSes - provided that there are not too many).
I would be more comfortable with implementing all sorts of hacks that
people demand in "Pro". An example would be built-in and fully
automated cracking of the case of characters with NTLM hashes as LM ones
are cracked. This goes against the current program structure of John,
so I'd hesitate to add it until/unless I find a way to implement that
elegantly. For "Pro", especially a closed-source one (or with almost
noone caring about the source code, even if it's available), that would
be a non-issue.
> But who the fuck wanna have a GUI if the cmd-line works perfectly?
Some people working for some companies and .gov's do.
> Or do you plan to fill the empty space @stake and LC left?
That would be great for John and for our other projects - and for me
personally - but I'm afraid it's a little bit too late for that. The
"Pro" is not ready; in fact, it is not even certain whether a "Pro"
would be created. Other commercial "crackers" are already starting to
fill this empty space.
Also, John has been and will remain quite different from LC. It's the
cross-platform functionality which many of John users appreciate it for.
> Be truthly and face your goals Solar...
I am being honest about everything being discussed.
> But not thinking about OpenBSD as supported OS makes me kind of sad.
I would share your feeling, except that I realize that there would be no
demand for "Pro" on OpenBSD anyway - and that's not because of licensing
issues.
I will definitely continue supporting OpenBSD in the main branch of John.
> Even I wouldn?t run your product anyway if it gets closed source.
You would likely have no need for the "Pro".
You would be welcome to continue running John off the main branch,
unless your religion prohibits you from that, which would be a pity.
> Fyodor got a GUI for free.. don`t you think you`ll find somebody who codes
> it....?
There have been a few - I can recall two - GUIs for JtR developed by
others.
One was a Visual Basic program (yuck). The other, which was developed
just recently, is also a Windows program requiring the .NET framework.
Both are closed-source and are just wrappers around the command-line
John executable. Neither is of any practical use, in my opinion.
Yes, there's a small but not negligible chance that I could find a
volunteer who would do it well. I would also need to put quite some of
my time into it for the proper integration.
But what for? Didn't you just say that the command-line John works
perfectly? I similarly have absolutely no need for the Nmap GUI, I have
never used it, although I am using Nmap a lot.
The GUI is precisely for those companies and .gov's willing to pay. So
I can pay, too, to deliver a "commercial quality application" that they
expect, even if it's source code is not pretty. ;-) (Now, am I not
being _too_ honest? Hey, my potential customers are reading this list,
too.)
On the other hand, a properly integrated GUI can in fact be of _some_
use even to experienced users of John - but once again, primarily to
those who do this for w$rk. There may be greater interactive control
over running cracking sessions and eventually there would be pie charts
and such - stuff to show to company management, etc.
> If you decide to make John closed source
Noone is talking about winding down the existing John the Ripper, an
Open Source project. On the contrary, I'd expect it to evolve faster.
But I am repeating.
> another idol dies...
Is John the Ripper your idol, or did you make an idol out of myself?..
Either way, I am just a human being, and John the Ripper is just a fun
project, a useful program, etc. Please don't make idols. This results
in your attitude being religious rather than rational.
> If so: That was MY IDEA [tm][r][c][whatever]....
> Isn`t stealing an idea also a crime in the US? ;-))
I am not sure what idea you're referring to. The integration of bkhive?
I almost expected you would at least demand credit for it or something.
You'll have your due credit for "pushing" for this functionality to be
integrated, if I ever do that. As it relates to the idea, it was
obvious that this functionality existed and was of relevance to John.
If you're all for software freedom, then why are you for an equivalent
of software patents? ;-)
Similarly, if you favor BSD license over GPL, then why are you against
closed-source derivative versions? (This is something which BSD permits
and GPL does not - except for copyright holders.)
I feel that you're being illogical here.
> Well... The decission is yours.
And it has not been made yet. I might simply not have the time, even if
I would expect a financial return, although this does make it a little
bit easier to find the time.
P.S. This turned into a lengthy message. I'd appreciate it if your
response, if any, would be shorter. ;-) It would not be productive for
us to spend a lot of our and fellow john-users time on this discussion.
Thanks,
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
