Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Sep 2011 08:30:24 -0500
From: "jfoug" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: RE: False positives on zip (aes256)

Actually, this might not be a bad command line option.  An option that
causes john to find passwords, but not remove them from it's running list.
I will add this to the wish list as something to look at in the future.

If we do put out format types which find passwords, but also have a tendency
for false positives, and we have no real way to 'fix' the format, then this
type option would allow john to keep trying different passwords on the hash,
'never' fully cracking and removing it.

I bet, if you restart john, however, this hash will not be loaded.  Since
the hash does get written to the john.pot file, when you restart john on
different data, if you do not hand edit the .pot file to remove any found
lines for this hash, it will NOT get loaded.

Jim.

>-----Original Message-----
>From: estenole lists [mailto:estenole.lists@...il.com]
>Sent: Friday, September 02, 2011 6:38 AM
>To: john-users@...ts.openwall.com
>Subject: Re: [john-users] False positives on zip (aes256)
>
>Hello,
>
>seems like the problem was on ldr_remove_hash(crk_db, salt, pw) inside
>crk_process_guess .-)))
>
>
>static int crk_process_guess(struct db_salt *salt, struct db_password
>*pw,
>        int index)
>{
>        int dupe;
>        char *key;
>
>        dupe = !memcmp(&crk_timestamps[index], &status.crypts,
>sizeof(int64));
>        crk_timestamps[index] = status.crypts;
>
>        key = crk_methods.get_key(index);
>
>        log_guess(crk_db->options->flags & DB_LOGIN ? pw->login : "?",
>                dupe ? NULL : pw->source, key,
>crk_db->options->field_sep_char);
>
>        crk_db->guess_count++;
>        status.guess_count++;
>
>        if (crk_guesses && !dupe) {
>                strnfcpy(crk_guesses->ptr, key,
>crk_params.plaintext_length);
>                crk_guesses->ptr += crk_params.plaintext_length;
>                crk_guesses->count++;
>        }
>
>        /*ldr_remove_hash(crk_db, salt, pw);*/
>
>        if (!crk_db->salts)
>                return 1;
>
>        crk_init_salt();
>
>        return 0;
>}
>
>
>Thank you
>
>
>2011/9/2 estenole lists <estenole.lists@...il.com>
>
>>
>> Hello,
>>
>> ive tried it without suceess, it stops on the first key it finds. Ive
>been
>> makeing some tests
>> and seems like i should modify the function crk_process_gues called
>from
>> cracker.c. My C
>> knowledge is limited, but that function make some changes that affect
>the
>> rest of the bufferered
>> keys os any other value.
>>
>>
>>  if (crk_methods.cmp_exact(pw->source, index)) {
>>                                 if (crk_process_guess(salt, pw,
>index))
>>                                    ->     return 1;
>>                                 else
>>                                         break;
>>                         }
>>
>>                 } while ((pw = pw->next));
>>
>>
>> Ive tried some modifications, but after crk_process_gues the program
>exits.
>> I tried to modify some
>> calls before but i ended on a Segmen segfault errors.
>>
>> Ill let you know if im able to get it working.
>>
>> Thank you !
>>
>>
>>
>>
>> 2011/9/1 jfoug <jfoug@....net>
>>
>>> You will have to 'change' the zip format source file to  do this.
>Change
>>> the
>>> cmp_exact to this (NOTE I have not tested, just coding in the email)
>>>
>>> static int cmp_exact(char *source, int index)
>>> {
>>>        static int cnt=0;
>>>        if (++cnt < 13) // we have to 'pass' the self tests.
>>>                return has_been_cracked[index];
>>>        cnt = 20; // to make sure we do not 'wrap' cnt past the end of
>a
>>> 2^31 number to a negative number
>>>        if (has_been_cracked[index]) {
>>>                fprintf(stderr, "\nPossible pass:  %s   Hash=%s\n\n",
>>> saved_key[index], source);
>>>                log_event("++ Possible pass:   [%s]",
>saved_key[index]);
>>>        }
>>>      return 0;
>>> }
>>>
>>> Then you can see them show up on the screen output, and also in the
>>> john.log
>>> file.  These can then be tested after the run.
>>>
>>> NOTE, this method will cause john to NEVER find the password.  It
>simply
>>> informs you in output that a possible password was seen.  The right
>one
>>> will
>>> be output, along with any false positives.
>>>
>>> Jim.
>>>
>>> >From: estenole lists [mailto:estenole.lists@...il.com]
>>> >
>>> >Hello all,
>>> >
>>> >im using the latest John the Ripper
>>> >1.7.8-jumbo-5<http://www.openwall.com/john/g/john-1.7.8-jumbo-
>5.tar.gz>
>>> >version
>>> >for trying to get the key of a zip encrypted
>>> >with aes256 bit. I allready know that actuallty false positives are
>>> >common
>>> >at this time.
>>> >
>>> >THe problem is tha when processing the wordlist john stops as soon
>as a
>>> >key
>>> >is found, but at the moment
>>> >none on them works, what i want to achieve is to force john to try
>with
>>> >the
>>> >full wordlist while printing
>>> >the keys found so i can try them when finished. Could find any
>option or
>>> >configuration to do so, do you
>>> >know id theres such a possiblity ?
>>> >
>>> >Thank you
>>>
>>>
>>

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.