[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF37FbXr3fjT--ZACjK9skyo7cmMA-462rK5K1NUn6GWdLWe5Q@mail.gmail.com>
Date: Mon, 7 Nov 2016 17:57:17 +0100
From: atom <atom@...hcat.net>
To: john-dev@...ts.openwall.com
Subject: Re: USB-FPGA development
This is nice work Denis, my gratulation! I'd love to see you adding a patch
for hashcat, too. Maybe I can help you other algorithms as well.
Anyway, I had some problem getting this to work. There's two problems of
which I know at least one how to solve.
1. I have three boards, but they all had some custom firmware installed,
one that wasn't "USB-FPGA Module 1.15y (default)". The following line in
ztex_scan.c will fail:
else if (!strncmp("USB-FPGA Module 1.15y (default)", dev->product_string,
31)) {
The user will end up with an error "no valid ZTEX devices found" and JtR
will quit. I've recompiled ZTEX_DEBUG with ZTEX_DEBUG=1, then it will print
the current firmware name on the board. I used that name to replace string
in the comparison above, then it worked. I think you need to find a
different solution to that, if not simply ignore the firmware running and
simply overwrite it.
2. There seems to be some timing issue somewhere when it comes to uploading
the bitstream. JtR prints the following error:
SN XXXXXXXXXX: uploading bitstreams.. ok
SN XXXXXXXXXX: device_list_check_bitstreams(): no bitstream or wrong type
Since I have multiple devices and if just one of them did not run into that
error on start, then JtR will start cracking. After some time (while JtR
cracks), JtR will try to upload the bitstream again to the other (failed)
devices. This sometimes works, but sometimes it does not. This will repeat
until all devices are initialized.
Here's some result after running for 2 days on a single hash:
0g 2:17:04:07 7.35% (ETA: 2016-12-11 22:04) 0g/s 2081Mp/s 2081Mc/s 2081MC/s
aaa;o7}r..ae\;o7}r
That's around 693MH/s
- Jens
On Wed, Oct 12, 2016 at 7:13 PM, <apingis@...nwall.net> wrote:
> Hi,
>
> descrypt-ztex format is ready. I've created pull request at bleeding-jumbo:
> https://github.com/magnumripper/JohnTheRipper/pull/2307
>
> Running test on 3 boards for the 2nd day.
>
> It works however there are still issues.
> 1. Mask implementation details.
> 1.1. In mask mode, it has to reconstruct a plaintext candidate out of
> template key and mask data. For that, it creates an array
> 'mask_int_cand.int_cand' - 4 bytes for every possible candidate. Then
> formats use the array for lookups.
> The problem is that the array uses too much resources - with mask
> "?w?a?a?a?a" it uses 310 MBytes of RAM and ~2 sec. of CPU time for
> initialization. I was unable to check with mask such as "?w?b?b?b?b"
> because ?b doesn't seem to work correctly with 7-bit format, but I can
> calculate it would use up to 4 Gbytes of RAM and would cause substantial
> delay on program startup.
> descrypt-ztex format uses divisions to reconstruct plaintext candidates,
> doesn't use 'mask_int_cand.int_cand' array. With on-device comparator that
> filters out overwhelming majority of computation results, reconstruction of
> plaintext candidates becomes rarily used function (called several times per
> second). Also I can't exclude cases where Ztex devices are connected to
> cost-optimized host system, in such cases host system might have no enough
> RAM.
> So it would be great to skip allocation and initialization of
> 'mask_int_cand.int_cand' array if format doesn't use that.
>
> 2. Self-test.
> 2.1. For test array, I've generated several hashes with same salt and
> partial binaries. That is, on-device comparator is loaded with first 35
> bits of hashes and they are the same, resulting in false positives. That
> cause self-test to fail. If that hashes are used for creation of password
> file then it works as expected, false positives successfully ruled out with
> cmp_exact() including the case where several false positives occur in one
> crypt_all() call.
> 2.2. "Warning: salt() returned misaligned pointer" self-test message.
> Format has 2-byte salt and I've set salt alignment to 2 bytes - is that
> correct or I should set salt_align to ARCH_WORD? Salt on host system is
> rarily accessed.
> 2.3. I've implemented a warning when mask is too short and that results in
> performance degradation because USB 2.0 link has no enough bandwith. The
> warning appears during self-test and it looks confusing. How can format
> know when self-test is running, to suppress the warning? Is it planned to
> add usage of mask in self-test?
>
> 3. FMT_REMOVE. How does format know when some binary was removed? If
> that's possible I'd prefer to keep comparator configuration until it
> actually changes - skipping unnecessary transfers to device would improve
> performance in case where only one salt is being audited. So far FMT_REMOVE
> is not implemented.
>
>
> Denis
>
--
atom
Content of type "text/html" skipped
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.
