|
Message-ID: <553996BF.7080005@openwall.com> Date: Fri, 24 Apr 2015 04:05:03 +0300 From: Alexander Cherepanov <ch3root@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: Advice on proposal: John the Ripper jumbo robustness On 2015-04-23 17:45, Kai Zhao wrote: >> Let's see where the next bottleneck is. > > I have tried 3 days to find the next bottleneck. There are two ways I have > tried, both the two ways speed up a little which is about dozens of > exec/sec: > > 1. Remove the useless source code to make the size of john smaller > > 2. Remove the useless functions in john.c You were doing it based on the results of profiling? Where john spends most time now? It was expected that we get to something harder after eliminating several easy bottlenecks. It just means that we exhausted this approach and have to switch to the next one:-) > Finally, I found that the key of fuzz the valid() function is this line: > > ldr_load_pw_file(&database, current->data); > > We init the john by registering fmts, reading configs, and so on, after the > init done, we run the ldr_load_pw_file() function which will valid the hash. > It takes some time from the start of john to the function > ldr_load_pw_file(). > And we repeat it in every case, thus it wastes a lot of time. > > I think it is a better way that we init only once and use fork to copy the > progress to child. The child only needs to run the ldr_load_pw_file(). > > AFL has come up this idea with 'The fork server', more details below: > > http://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html > > I think we should custom AFL to init only once. Do you agree with this idea? Yes, that's the next step. But we don't need to customize AFL for this. A week ago, in version 1.69b, afl have got support for deferred initialization in LLVM mode. Please try it. -- 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.