full-disclosure - Re: Patator - new multi-purpose brute-forcing tool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu, 23 Feb 2012 08:42:08 -0600
From: Grandma Eubanks <tborland1@...il.com>
To: van Hauser <vh@....org>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Patator - new multi-purpose brute-forcing tool

That could be. I've done testing with Python with multi-threads and
multi-processing and have gotten a couple hundred more over HTTP than I
have on managing threads (not to mention how much easier it was). However,
this also needed to handle much more data and parse the responses for
validation before continuing, as you said not over network login (I assume
lan here). So perhaps that was my issue with the multi-threaded.

http://code.google.com/p/http-brute

The speed also was an issue. At that speed the amount of threads were not
able to complete at points in time, causing them to be repeated. But when I
spanned cores it no longer became an issue. But as you said, this could've
been just how I was managing the threads.

On Thu, Feb 23, 2012 at 8:18 AM, van Hauser <vh@....org> wrote:

> Hi folks,
>
> as the programmer of hydra, some comments on this ...
>
> On 23.02.2012 06:52, Grandma Eubanks wrote:
> > Multiprocessing is quiet a bit faster than utilizing threads (this
> > should be obvious as threads are GIL locked, while multi-processing can
> > be spread amongst cores with the kernel's scheduler).
>
> yes, multiprocessing is faster than threads, and threads used
> intelligently are faster than forking - but ... for network login
> hacking that is not the bottleneck and its not where optimization helps
> anything.
>
> the secret of being fast is how you balance the connections to the
> network services and skipping parts of the protocols which are not
> essential.
>
> thats why hydra is the fastest one out there (own biased testing ;-)
> http://thc.org/thc-hydra/network_password_cracker_comparison.html )
> although it uses forking. go figure.
> hydra got more stable and faster when I rewrote the balancing engine in
> v7, the v7.2 is now the fastest and is very stable.
>
> (why forking? because when it was written the goal was to be able to run
> on any platform, even on esoteric platforms like ultrix 4, MVS
> openedition etc. - and it did. In today's monocultures that a less
> useful feature, I agree)
>
> On Feb 22, 2012 6:43 AM, "lanjelot" <lanjelot@...il.com> wrote:
> > To put it bluntly, I just got tired of using Medusa, Hydra, ncrack,
> > metasploit auxiliary modules, nmap NSE scripts and the like because:
> >  - they either do not work or are not reliable (got me false
> >    negatives several times in the past)
> >  - they are slow (not multi-threaded or not testing multiple or
> >    not testing multiple passwords within the same TCP connection)
>
> have you read the code of the named tools?
> hydra does multiple password attempts in the connection if the protocol
> supports it - the competitors do so too I'd guess, medusa and ncrack use
> threading or parallel socketing - and rgw false negatives/positives ...
> you will have them too, because its always interpretation of results.
>
> post some speed comparison and show that your tool is ruling :-)
> competition makes the tools better.
>
> Greets,
> van Hauser
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/