|
Message-ID: <664819dae17b9daad04e5cc3ebb7c46b@smtp.hushmail.com> Date: Tue, 29 Jan 2013 07:48:12 +0100 From: magnum <john.magnum@...hmail.com> To: john-users@...ts.openwall.com Subject: Re: can't get jtr to ID this On 29 Jan, 2013, at 2:21 , Solar Designer <solar@...nwall.com> wrote: > On Mon, Jan 28, 2013 at 06:58:06PM -0500, tanoury wrote: >> Here's the hccap (greasedjtr.hccap) converted to john format: >> http://home.comcast.net/~A_Tanoury/greasedjtr.hccap >> >> Here's the password: >> http://home.comcast.net/~A_Tanoury/password.txt > > 63 chars? Is this a stress-test for the tools? Thank you for it! > Dhiru - please get these sample files onto our wiki. :-) Great, I have requested such a test vector! I will include it in all versions. >> I'm using john-1.7.9-jumbo-7-Linux-x86-64 and it has worked fine. Here's >> my command line that has worked fine with other WPA passwords: >> ./john --wordlist=password.txt -fo=wpapsk greasedjtr.hccap > > It works for your password here, with all of: wpapsk, wpapsk-opencl, and > wpapsk-cuda. I tested with bleeding-jumbo. Maybe there was some issue > we've fixed since 1.7.9-jumbo-7. It was unfortunately by design: Jumbo-7 had a totally uncalled for limitation of 15 characters in all versions of wpapsk. I dropped that limitation for the revised (split kernel) opencl format and later also in then in CPU/CUDA versions. Latest code in unstable has a password length limit of 63 (which is the IRL limit) and a max ESSID length of 32 or so (which should be the IRL limit but there are contradicting evidence - anyway that is pretty long and I recall it currently is limited by SHA-1 block size vs. optimizations). > ... I've just tested unstable-jumbo as well. wpapsk and wpapsk-cuda > resulted in: > > Loaded 1 password hash (WPA-PSK PBKDF2-HMAC-SHA-1 [32/64]) > *** buffer overflow detected ***: ./john terminated > ======= Backtrace: ========= > /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f9e023a1007] > [...] > > (similar in both cases). However, wpapsk-opencl cracked the password > just fine. > > Maybe there's some bug we happened to fix between unstable-jumbo and > bleeding-jumbo, or maybe it's just somehow hidden in the latter. Either > way, we need to fix it in unstable-jumbo as well, because that's likely > what we'll base the next -jumbo release on. (bleeding-jumbo is about > preparations for an even later release.) > > magnum - can you take a look, please? Sure, this will be fixed ASAP in unstable. magnum
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.