gmane.comp.security.openwall.john.user

Re: Solaris Assembler Multiply Fix

Solar Designer — 2010-09-02T03:03:19

Thank you!

Using this approach for up to MUL_512() feels risky, though.  That's a
stress test for the assembler.  Perhaps there's another way that would
not involve multiplying by a number this large.

I'll try to find time to look into this a bit later, although I have
other (non-JtR) things to focus on first...

Thanks again,

Alexander

SHA-3 Contest

Rich Rumble — 2010-09-02T02:52:59

Bruce Schneier, and probably other SHA-3 competitors, but more
specifically Bruce, is looking for people with FPGA and ASIC skillz.
I figure someone on the list may know someone who knows someone
with such a skill set and or interest. You can read more about it here:
http://www.schneier.com/blog/archives/2010/09/wanted_skein_ha.html

I'm just putting this out there (cleared with Solar first) to see if anyone
can help. If so contact Mr Schneier or other entrants you may favor,
and offer your help to them directly, I've posted this on my own volition.
Pass along the link if you know anyone, thanks!
-rich

Re: Noob question: how to feed 10 alphanum char min&max incremental to aircrack when "MaxLen = 10 exceeds the compile-time limit of 8"

2010-09-02T01:14:53

I experimented with different data structures to hold the hashes to find
the most efficient one. I'm not sure how JTR stores multiple hashes. I
don't have the detailed numbers as this was a while ago, but here is what
I found in general:

* unsorted std::vector (slow)
* binary_search on a sorted std::vector (much faster)
* std::unordered_set (fastest on large sets (10k to 1m hashes), but
slightly slower than binary_search when dealing with dozens or hundreds of
hashes). It was the overall winner. In C, I think you would call this an
in memory hash table.


Not sure this would be of interest to you, but if you can use C++ the
boost library has portable code that determines this number automatically.

const unsigned int t = boost::thread::hardware_concurrency();

This will return the number of "hardware threads" (that may be CPUs, CPU
cores, pretend cores (HT), etc.) and if it can't determine the number, it
returns 0 so you can drop-back to only one thread if needed. Not that I've
ever had to do that, but you

Re: Noob question: how to feed 10 alphanum char min&max incremental to aircrack when "MaxLen = 10 exceeds the compile-time limit of 8"

Solar Designer — 2010-09-02T00:50:51

Oh, then your time was not bad.  I just did some math, and it appears
that JtR would complete a similar run in about 50 minutes (that's on one
CPU core).  There got to be room for improvement here.


Well, 3.5x to 5.5x faster by using all four cores.  So far, this is best
done by running 8 instances of JtR manually (it should be 8 for a Core i7
with HT enabled even though the CPU is quad-core), but I'll need to be
improving the code to make this simpler yet efficient.

Alexander

Re: Noob question: how to feed 10 alphanum char min&max incremental to aircrack when "MaxLen = 10 exceeds the compile-time limit of 8"

2010-09-02T00:03:01



Ah yes, not a good fit currently.




Yes, I omitted that. The time (67m6.326s) was on roughly 30,000 NT
(unsalted md4 unicode) hashes from the KoreLogic Defcon contest.

wc -l nt_clean.txt
30820 nt_clean.txt




That's one NT hash and SSE2, right? That should be fast.




SSE again it seems. Good numbers for a CPU based application. I doubt
you'll get much faster than that on a current CPU with that has type.



Thanks for the numbers,

Brad

Re: Noob question: how to feed 10 alphanum char min&max incremental to aircrack when "MaxLen = 10 exceeds the compile-time limit of 8"

Solar Designer — 2010-09-01T23:39:03

I think Joshua's point was that I made it so difficult to do simple/dumb
things (e.g., shoot oneself in the foot, which sometimes even makes
sense) that coding a separate program would be easier than figuring out
how to modify params.h to go beyond length 8 with incremental mode or
how to modify the DumbForce example in john.conf to specify the desired
lengths range and charset.  I fully agree with this criticism - I got to
make doing this sort of things a lot simpler, maybe by introducing a
builtin dumb cracking mode into the very next development version.  I am
going to consider doing this when I switch back to JtR development from
many other tasks and projects that I switched to after the contest...

[...]

Yeah, it should be possible to do a lot faster than that, although you
haven't mentioned the number of NTLM hashes being cracked (with a truly
large number, the hash table lookups and collisions would be taking
significant time).


For a single NTLM hash and using a variation of DumbForce with:

minl

Re: Noob question: how to feed 10 alphanum char min&max incremental to aircrack when "MaxLen = 10 exceeds the compile-time limit of 8"

Solar Designer — 2010-09-01T22:57:21

At 20M candidates per second, which is realistic for NTLM hashes on a
single modern CPU core, exhaustively searching the all-digit password
space up to length 16 would take 17.6 years.

For WPA-PSK, it would take several orders of magnitude longer.

Alexander

Re: Fw: Noob question: how to feed 10 alphanum char min&max incremental to aircrack when "MaxLen = 10 exceeds the compile-time limit of 8"

2010-09-01T22:52:03

I'm not sure any other CPU based program would be significantly faster
than JTR. Here is how quickly my program enumerates 6 - 10 (numbers only)
on a six core AMD box (each number gets a core to itself, so in this case,
5 cores were used) there is no SSE math or anything else fancy going on,
just threads and brute-force space enumeration:

$ time ./16crack nt --numbers --no-mangle < nt_clean.txt > results.txt
Finished Brute 6: 1234567890
Finished Brute 7: 1234567890
Finished Brute 8: 1234567890
Finished Brute 9: 1234567890
Finished Brute 10: 1234567890

real    67m6.326s
user    74m27.730s
sys     0m0.060s

I've never tried doing this with JTR, so I don't know how it would
compare. It may do better than this (I would expect it to as it's much
more mature), but I would not expect it to perform worse (at least not by
a lot) on the same hashes and the same hardware.

Brad

Re: Fw: Noob question: how to feed 10 alphanum char min&max incremental to aircrack when "MaxLen = 10 exceeds the compile-time limit of 8"

Joshua J. Drake — 2010-09-01T21:36:17

No offense to Solar or any other john contributors, but you might be
better off implementing your own generator program. It won't exactly
be elegant, but it will likely do the job (exhaustive brute force). Be
sure to periodically save state then you can recover in the case of
failure. 

Another option might be to use the markov model work done with john.
It may help you guess quicker.

Good luck,

Solaris Assembler Multiply Fix

Alain Espinosa — 2010-09-01T21:45:01

Hi. I have a small time and convert the assembler multiply into sum as
Solar do. The patch is apply on top the jumbo distribution. I make a
rapid test in linux and mac and works well.

saludos,
alain

Re: Noob question: how to feed 10 alphanum char min&max incremental to aircrack when "MaxLen = 10 exceeds the compile-time limit of 8"

Solar Designer — 2010-09-01T21:53:36

[...]

No, it does not seem reasonable.  aircrack-ng will only be able to test
a relatively small number of candidate passwords per second, so you'd
only search a very small fraction of the "10-only and alphanum" keyspace
during your lifetime.  Incremental mode's smart ordering of candidate
passwords is of some help to improve your chances of a successful crack,
though - from "negligible" to "almost negligible".

(For fast-to-compute password hashes - e.g., Windows passwords - this
would be very different.)

If you must, this old posting referenced by Rich has the complete set of
params.h settings for you to use:

http://www.openwall.com/lists/john-users/2007/07/04/6

The very first set of settings ("for lengths up to 10") will be it.
Then you put something hopefully-relevant into your john.pot (see one
example with all.gz in the above posting) and generate a new .chr file:

john --make-charset=alnum10.chr --external=filter_alnum

Finally, you add an incremental mode section that will use alnum10.chr.

Howev

Fw: Noob question: how to feed 10 alphanum char min&max incremental to aircrack when "MaxLen = 10 exceeds the compile-time limit of 8"

Mr Ex — 2010-09-01T21:18:07

Thanks for the reply.

It does need to be 10 alnum as the passphrase won't just be digits (and I'd be 
using Mac OSX). So its not possible to just do 10-10 alphanum chars on JtR as 
far as anyone knows? Given that I don't want 9, 8, 7 or less alnum chars nor 11+ 
alnum chars *just 10*, seems quite a reasonable, not too overly time-consuming 
crack to want to feed through from John, I'd be surprised if its not possible.

I take what you're saying in terms of generating a custom .chr file and have 
re-read http://www.openwall.com/john/doc/EXAMPLES.shtml but isn't that method 
merely a way of filtering, i.e. it won't actually make John do a min 10 / max 
10, or am I just not understanding it right?

-EX



----- Forwarded Message ----
From: Rich Rumble <richrumble-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
To: john-users-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8< at >public.gmane.org
Sent: Wed, 1 September, 2010 15:35:49
Subject: Re: [john-users] Noob question: how to feed 10 alphanum char min&max 
incremental to aircrack when

Re: Noob question: how to feed 10 alphanum char min&max incremental to aircrack when "MaxLen = 10 exceeds the compile-time limit of 8"

Rich Rumble — 2010-09-01T18:54:30

Never tried, and depending on the hash it would vary, but something fast
like NTLM would likely take weeks.Depending on how I generated the
CHR file, I'm not sure if there is a "tri-graph" that would help JtR guess the
more likely digits, but I have used it to find long char only passwords that
were 12 chars in a few days.I'll let this run (1-16) as long as I can and see
if I can get you a number for at least the NT hash on a 2.33Ghz. I've certainly
cracked passes over 8 with it plenty of times. All digit pass's are not that
common in my experience so I've never thought of having a rainbow table
for them, esp when JtR goes through 1-8 so quickly.

Re: Noob question: how to feed 10 alphanum char min&max incremental to aircrack when "MaxLen = 10 exceeds the compile-time limit of 8"

Brad Tilley — 2010-09-01T18:31:37

Out of curiosity, have you ever enumerated the entire space of a 16 char
number only password? If so, how long did that take? I would assume
weeks (at least... although that seems overly optimistic for CPU),
months? Or have you never enumerated the entire space?

10^16 = 10,000,000,000,000,000

Re: Noob question: how to feed 10 alphanum char min&max incremental to aircrack when "MaxLen = 10 exceeds the compile-time limit of 8"

Rich Rumble — 2010-09-01T14:35:49

http://openwall.info/wiki/john/mailing-list-excerpts
http://www.openwall.com/lists/john-users/2007/07/04/6
Specifically... You have to create your own CHR files and recompile.
I have not had success with compiling anything other than digits over 8,
you can DL my digit only build (up to 16 digits) here:
hxxp://xinn.org/jtr__digits/john-digits-16.7z (windows only)
If you don't have 7zip you can find it easily. This build will only
crack digit only
hahses with lengths from 1-16 digit characters long. The build is
against JtR 1.7.6
jumbo rev 5. I'm not sure how to run it against a pcap, but if it's
supported by JtR
or the jumbo patch it should work. I should try again to build an
AlphaNum JtR but
I haven't had the time. You do have to modify the john.conf parameters
to suite your
needs:
  # Incremental modes
  [Incremental:Digits16]
  File = $JOHN/digits16.chr
  MinLen = 1
  MaxLen = 16
  CharCount = 10

Command line:
john-digits-16.exe pass.pwd -i=digits16 -format=nt
I hope that helps some...
-rich

On Wed, Sep

Noob question: how to feed 10 alphanum char min&max incremental to aircrack when "MaxLen = 10 exceeds the compile-time limit of 8"

Mr Ex — 2010-09-01T07:28:22

Hi

I'm a total noob who is trying to run a crack specified to effectively brute 
force 10 characters only and alphanumerical only (against a pcap)... I modified 
the config file; the alpha numerical bit, so that it was minimum 10, maximum 
10, as this just seemed logical from reading the help file, and then

john --stdout --incremental:alnum | aircrack-ng (etc etc...)

but then got...

"MaxLen = 10 exceeds the compile-time limit of 8

There are several good reasons why you probably don't need to raise it:
- many hash types don't support passwords (or password halves) longer than
7 or 8 characters;
- you probably don't have sufficient statistical information to generate a
charset file for lengths beyond 8;
- the limitation applies to incremental mode only."

But for what I want to do, feeding, nothing to do with hashes, 10-only and 
alphanum only seems reasonable..?

Like I say, I have read the documentation but as a novice don't wish to get too 
hopelessly lost so I wondered can anyone help... do I need to

compiled JtR 1.7.6 with the jumbo 7 and the netscreen script v2.01 patches located on the custom-builds page

Robert Harris — 2010-08-31T00:10:19

John-Users,

 

I have compiled JtR 1.7.6 with the jumbo 7 and the netscreen script v2.01
patches for:

Windows

Linux 32-bit

Linux 64-bit

 

These builds are now uploaded to

 

http://openwall.info/wiki/john/custom-builds

 

Enjoy,

 

-Robert B. harris

patch of JtR's netscreen.py script, now version 2.01

Robert Harris — 2010-08-30T22:00:03

Re: A puzzling hash from the past

fijam 7 — 2010-08-28T13:00:39

This is a most informative reply, thank you. My Google-fu must have
been weak that day :)

Regards,
JM

Re: A puzzling hash from the past

Solar Designer — 2010-08-27T14:16:31

Yes: a program setting the password attempted to use an MD5-based crypt
hash, so it provided a salt proper for that hash type, but the system's
libc (or libcrypt) lacked the support, so it produced a DES-based crypt
hash with the invalid salt of "$1" instead.


Different implementations of DES-based crypt(3) process invalid salts
differently.  I don't know how uClibc in particular processes them.
JtR implements one of the possible mappings, but if it's not right for
your target system (for uClibc in this case) then you need to replace
the '$' character with a "correct" one that maps to the same 6-bit
value that uClibc maps the '$' to.

Please refer to these older postings for more detail on the topic:

http://www.openwall.com/lists/john-users/2009/02/28/1
http://www.openwall.com/lists/john-users/2008/10/03/2

Both are linked from:

http://openwall.info/wiki/john/mailing-list-excerpts

* Invalid salts with traditional DES-based crypt(3) (2009/02/28)
    * Invalid salts - more info on the two known mappings (

A puzzling hash from the past

fijam 7 — 2010-08-27T08:18:07

Hello,

I recently analyzed the firmware of a certain discontinued router that
I have and managed to extract a cramfs filesystem. There, I found
/etc/shadow with a strange hash:

user:$1juTFYmn618Y:12086::99999::::

To my understanding, a DES hash should have 13 characters in base64
digits (including the salt). Any ideas why does it start with a '$'?
It appears that the firmware utilized tinylogin 0.80 and uClibc
0.9.26. I had a look at the source but found no clues.

Regards,
JM