Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list] 
Message-ID: <CABtNtWGr=aQ4Ee7vSzurMFH=WAGXoctNaRRpRocyesvQiofVYQ@mail.gmail.com>
Date: Fri, 26 Jun 2015 10:49:39 +0800
From: Kai Zhao <loverszhao@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: more robustness

I created a patch to implement the --fuzz option, and it was not finished.
The patch is attached.

The core method is formats.c::fuzz_test()

void fuzz_test(struct fmt_main *format)
{
  ...
  current = format->params.tests;
  while (1) {
    if (!fcp) {
      fcp = create_fuzz_cases(format->params.label, current->ciphertext);
      fcp_copy = fcp;
  }

  current->ciphertext = fcp->ctext;
  current->fields[0] = "?";
  current->fields[1] = current->ciphertext;
  ciphertext = format->methods.prepare(current->fields, format);
  if (ciphertext)
    format->methods.valid(ciphertext, format);

  fcp = fcp->next;
  if (!fcp) {
    free_fuzz_cases(fcp_copy);
    if (!(++current)->ciphertext)
      break;
  }
}

The fuzz_test() only test the prepare() and valid() functions.
The fuzz_test() is borrowed from loader.c::ldr_split_line(), but fuzz_test()
is much simple.

Is there anything wrong with this patch?

There are something to be done for --fuzz option, I will do the follow
things
if the logic of this patch is all right.

1. Add more fuzzing methods
2. Support formats whose ciphertext is very long such as LUKS
3. Add the split() after valid()


Thanks,

Kai

Content of type "text/html" skipped

Download attachment "0001-Implement-fuzz-option.patch" of type "application/octet-stream" (6634 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.