[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20171108161834.GA2501@openwall.com>
Date: Wed, 8 Nov 2017 17:18:34 +0100
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Testing ZTEX boards?
On Mon, Nov 06, 2017 at 11:18:20AM +0100, Jeroen wrote:
> I'd like to get a ZTEX board and make sure that it's working properly before
> I buy it, to run some kind of diagnostics. Preferably really simple since
> I'm not experiences with FPGAs, JTAG etc.
>
> According to john documentation and earlier postings, it seems to me that
> the following should work:
>
> - Install libusb-dev.
> - Configure with ZTEX enabled, compile.
> - Hook up the ZTEX device to USB.
> - Run john with a *-ztex format, this will automatically upload the correct
> firmware.
Yes, and the bitstream too.
> - Cracking starts == working board.
>
> Is this correct and does it sound like a good approach?
Yes, that's fine. Like with any hardware, there are possible issues
that would only be discovered after a while, though.
Some of the tests I run use the pw-fake-unix file from:
http://openwall.info/wiki/john/sample-hashes#Sample-password-hash-files
"3107 of Unix crypt(3) hashes (4 flavors, plus bigcrypt for length 9+)
and corresponding plaintext passwords"
You can take portions of it like:
egrep '^([^:]*:){4}[a-z]{4}:' pw-fake-unix > pw-fake-len4
egrep '^([^:]*:){4}[a-z]{6}:' pw-fake-unix > pw-fake-len6
and ensure that commands like:
for n in `seq 1 7`; do rm john.pot; ./john -form=bcrypt-ztex -mask='?l?l?l?l' -verb=1 pw-fake-len4; done
for n in `seq 1 7`; do rm john.pot; ./john -form=descrypt-ztex -mask='?l?l?l?l?l?l' -verb=1 pw-fake-len6; done
consistently give you the same numbers of cracks that similar ones would
on CPU. Actually, all of the passwords in those files should be getting
cracked - 239 and 915, respectively. This takes a few minutes per test.
You can also run these commands on the full pw-fake-unix for longer tests.
To better test communication between host and device (such as to detect
improper cables), try combining mask mode with another mode (using '?w'
inside the mask to refer to the other mode's output), or in the case of
bcrypt you can have all of the candidates generated on host with little
performance impact (since bcrypt is slow enough for that even on FPGA):
for n in `seq 1 7`; do rm john.pot; ./john -form=bcrypt-ztex -inc -min-len=4 -max-len=4 -verb=1 pw-fake-len4; done
doc/README-ZTEX also includes a section called "Troubleshooting ZTEX
board", which currently only mentions testing using Ztex SDK. You can
do that. Personally, before we got anything into JtR, I was testing
these boards with cgminer-3.1.1 built with "./configure --enable-ztex".
(IIRC, newer versions of cgminer dropped this support.)
> If I check ztex/* after compiling I don't see anything that looks like newly
> compiled FPGA code. But again, as an FPGA newbie I might overlook things.
We provide pre-generated bitstream files. We also provide the original
project trees, but it'd take some gigabytes of proprietary software,
some hours of CPU time, and some skills to regenerate the bitstreams -
that's not something we expect end-users to do, and besides it doesn't
work the same way each time (there's some randomness involved).
Alexander
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.
