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 23:42:59 +0300
From: Elijah SmarTeam <smarteam.support@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: USB-FPGA development

Slight off-topic - how do you power those 1.15y? From site I'm getting too
wide selection of "4.5 to 16v 5.5/2.1/positive center" (
http://wiki.ztex.de/doku.php?id=en:ztex_boards:ztex_fpga_boards:power_supply_selection).
But what about amps? As I have only one of those - don't want to burn it :)
Maybe some well-known replacement option exist for power supply unit? (from
some routers or other consumer grade devices)

On 7 November 2016 at 20:23, Royce Williams <royce@...ho.org> wrote:

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

[ CONTENT OF TYPE text/html SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

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