Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 08 Mar 2011 21:01:26 +0100
From: magnum <>
Subject: Re: --utf8 option, proof of concept

On 03/07/2011 11:47 PM, jfoug wrote:
> Can you provide some 'sample' data.  By that, I mean wordlist(s), input
> file(s) and a list of what is in each file, which can be used to test these
> methods?

Attached are hash files with NT and md5(unicode(p)) as well as a 
dictionary file. All of them are in utf-8 (but the hashes are made from 
UTF-16LE). The hash files are prepared so you can immediately crack all 
hashes in single mode, or use the wordlist.

All are from the 100 words of the greek wordlist sample.

One of the NT hashes does not get cracked, as it is from a 32 bytes long 
plaintext (16 greek characters). That is expected as the PLAINTEXT_SIZE 
is only 27.

In the utf-8 patched I posted yesterday, I had mistakenly halved the 
PLAINTEXT_LENGTH in rawMD5unicode_fmt.c. This should be reverted to 53. 
The thing is, 53 bytes of UTF-8 can be anything between 13 and 53 
*characters* but PLAINTEXT_LENGTH is in *bytes* so it should of course 
not be altered. Tricky business, this.

After fixing that, raw-md5-unicode cracks all 100 of them.

You can benchmark by running --incremental with and without --utf8 (no 
hashes will get cracked either way) for a minute or something.


View attachment "utf16-rawmd5-hashes.txt" of type "text/plain" (5962 bytes)

View attachment "unicode-nt-hashes.txt" of type "text/plain" (6262 bytes)

View attachment "test-dic.utf8.txt" of type "text/plain" (1671 bytes)

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.