Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 7 Nov 2016 08:23:09 -0900
From: Royce Williams <royce@...ho.org>
To: john-dev <john-dev@...ts.openwall.com>
Subject: Re: USB-FPGA development

On Mon, Nov 7, 2016 at 7:57 AM, atom <atom@...hcat.net> wrote:
> 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.

Intriguing! :)

> 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.

+1. FWIW for others until there's a better fix, I worked around this
by using the EZ-USB SDK tools to reflash the default firmware:

# cd ./ztex/default/usb-fpga-1.15y
# ./prog-1.15y.sh
Firmware to EEPROM upload time: 2155 ms
Writing configuration data.

... and then power-cycling the board.

> 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.

I only had this problem with one my devices, and it has persistently
been the same device.

> 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

That's similar to my performance.

Royce

> On Wed, Oct 12, 2016 at 7:13 PM, <apingis@...nwall.net> wrote:

>> descrypt-ztex format is ready. I've created pull request at
>> bleeding-jumbo:
>> https://github.com/magnumripper/JohnTheRipper/pull/2307

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ