Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 12 Jul 2015 18:15:54 +0300
From: Alexander Cherepanov <ch3root@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: more robustness

On 2015-07-12 14:46, Kai Zhao wrote:
>> And I'd test further format methods as well, perhaps those the loader
>> would use.  So don't proceed to crypt_all(), but do test everything
>> leading up to it.
>
> To mimic the real cracking process, I tried to change the loader.c to reuse
> for fuzzing. The last three commits reuse loader.c for fuzzing.
>
> https://github.com/loverszhaokai/JohnTheRipper/commit/c4a3fc5c177d5a4181ca5cb3d2b72de95ab8818e
> https://github.com/loverszhaokai/JohnTheRipper/commit/6300f5fae0713e740169250877a67ab9380ce71a
> https://github.com/loverszhaokai/JohnTheRipper/commit/f8a6f01a12e47cb9d951a7733fa0a69af1bd6204

After these commits, your fuzzer just calls ldr_load_pw_line() and all 
details of calling valid(), split() etc. are hidden inside it, right?

Then it's possible to simplify the fuzzer a bit. It has an inverted 
structure right now with functions for specific fuzzing methods 
generating only one case at a time, written without loops and forced to 
store their state in static variables. It seems easier to make them 
generate all cases during one call, have loops inside of them and call 
ldr_load_pw_line() in the deepest loops.

What do you (and others) think?

-- 
Alexander Cherepanov

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.