hashcat / kwprocessor Goto Github PK

Toggled between using -s and not,
Using -s gives a subset of not using -s and none of the characters are the shifted versions of the lowercase

It seems like the results for kwprocessor on Windows are either truncated or missing completely (truncated to 0). The exact same commands being run on the same system via Bash for Windows (Linux subsystem) show the expected results.

The following screenshot might give a better idea. Exactly the same commands, but the one on top is using Bash on Windows to run kwp, the bottom is using kwp32.exe (same results encountered with kwp64.exe). The first command (2-to-10-max-3) returned ~40,000 rows when running under "linux", but only 511 rows on Windows. The second command (4-to-4-exhaustive) returns 1,780 rows on linux, 0 on Windows.

https://i.imgur.com/emzaexD.png

This occurred both on the 1.0 release (24 Oct, kwprocessor v1.0 - https://github.com/hashcat/kwprocessor/releases), as well as the beta version (kwprocessor-1.00+6.7z 09-Sep-2016 15:33) which was tested per atom's suggestion in the forums (https://hashcat.net/forum/thread-6956-post-37110.html#pid37110)

System: Windows 10 version 1607 and WSL version Ubuntu 14.04.5 LTS

While working on the french 8 bits keymap, I noticed a segfault during my tests. After thinking that I messed up my keymap file (again), I noticed a similar issue with the de.keymap (even on a clean repository).

On the de.keymap I get the following matrix:

(I get a different matrix on my reworked 8bits french keymap so I still might have messed up.)

According to gdb, the segfault is occuring on line 519:
const int c = cs->map[m];

It doesn't seem to be possible to generate all-caps keywalks.

Here is an example:

caps.base:

QAZ

6.route:

6

en.keymap is original file

 $ kwp caps.base en.keymap 6.route

Output is empty, as expected.

$ kwp caps.base en.keymap 6.route  -s1
Qwertyu
Asdfghj
Zxcvbnm
QWERTYU
ASDFGHJ
ZXCVBNM

$ kwp caps.base en.keymap 6.route  -s1 -b0

Output is empty again. It would be nice to see following output here

QWERTYU
ASDFGHJ
ZXCVBNM

I'm using precompiled kwp release 1.00

After running this with numerous configurations, I have been unable to generate a password containing a directional move to the southwest or northeast from any character. All other appropriate and legal directions are shown.

*Running on Void 4.16 rc1, Ubuntu 16.04, Kali 2018.1, Debian 9.4, RHEL 7.3 (all x64)

I was just wondering what the average gen time is for a wordlist based off of 2-to-16-max-4-direction-changes.route with either tiny or full base chars and a English keymap? I had it running for about a week and still no output. I had no issue generating word lists with either base char set for routes up to 2-to-16. How long is it supposed to take to generate a wordlist off of that route?

Posting my command, options and such

./kwp -s -8 -3 -6 -9 -2 -x 2 -o 2.txt base.txt keymaps/en-us.keymap routes/custom_routes.txt

base.txt
q

custom_routes.txt
111111
11111111
1111111111
111111111111

This worked previously with using -0 instead of "-8 -3 -6 -9 -2"

Fantastic tool, thanks for posting!

I know it might be a bit much, but would it be possible to accelerate the creation of keyboard walks with OpenCL? doing it in CPU space takes a long time for large routes.

It is clear from documentation that diagonals are not used by default, but I guess an option to turn "ALL" is a little bit excessive and smth. in-between needed also.

Looking at a standard 104-key keyboard (https://en.wikipedia.org/wiki/Keyboard_layout#/media/File:ANSI_Keyboard_Layout_Diagram_with_Form_Factor.svg) it can be noticed that, if starting for example from letter "s" there is an direct "connection" with diagonal letters "e" and "z" and letters "q" and "c" are a little bit distanced which could lead for direction to less likely be chosen for "walks".

Can we have an option (like -"c" for "connected/continuous") to turn on --keywalk-south-west and --keywalk-north-east but without other two remaining diagonals? Yes it can be achieved with current options set, but I'm here speaking about usability side :)

The builtin routes "2-to-16-max-4-direction-changes.route" and "2-to-32-max-5-direction-changes.route" are to big, and cause a freeze under Linux.

A workaround is to split the routes into smaller pieces. (< 4096 bytes)

split routes/2-to-16-max-4-direction-changes.route -l 810
This creates four files of 3223, 4050, 4050 and 395 bytes.

I've also tested a file with 4095 bytes, which will work.
As soon as a file reaches 4096 bytes, kwp will get stuck.

The most popular keyboard walk out there is some form of 1qaz2wsx3edc4rfv. As written, it doesn't look like kwp can produce keymaps where you look at the columns or rows, e.g. you jump from the end of one column to the beginning of the next.

Hello.
I can't generate character combination like qweasd:

It is very popular keywalk, which presume jumping back to bottom row on keyboard
It means 3 directions (route 212) and some distance between keys more than 1, but nothing:

./kwp -0 -x 6 basechars/tiny.base keymaps/en-us.keymap routes/2-to-10-max-3-direction-changes.route|grep qweasd

command

./kwp -b -0 basechars/full.base keymaps/en-us.keymap routes/4-to-4-exhaustive.route