Add Wide Character Support to Table Attack Engine
#1
Bug 
I've noticed a trend in multilingual users who are creating passwords based on English words, but with their native IME. For example, one of the passwords in the LinkedIn dump is 'سحاهىء', which is a nonsense word in Arabic that was created by hitting the keys for s, p, h, i, n, x (sphinx) on their keyboard while using the Arabic IME.

I have some Korean friends who attest to creating passwords the same way, by typing Hangul letters for English words. Some attest to doing the opposite, where they will write a word in Korean but while using the English IME, so that the word is just an odd string of letters.

Because of this trend I think it is worthwhile to create tables for this kind of pattern. I have already created such a table for Arabic; however, because the current table attack engine does not have wide character support, this table does not work with the current implementation.

If wide character support were added to the table attack engine, the community could create tables for every possible language supported by e.g. Windows IME and fully exploit this new pattern.
#2
Can confirm the same thing for people in Ukraine using cyrillic <-> latin flipping of the keyboard layout.

Hm. I see an expansion area for the keyboard walks from d3ad0ne on the horizon?
http://ob-security.info/?p=475
#3
Yeah, I see 'зфыыцщкв' (password) in the LinkedIn dump as well.
#4
Well thought out epixoip!
I can confirm this too, hundreds if not thousands use this method when choosing their passwords (I live in an Arabian country), in fact I, myself, used to write my name in "masked" in English, which was something like "uf]hglg;". Good enough password for an 8-year-old kid.

I revised your Arabic table, it was missing some characters and also some characters were wrongly formatted (might be my text editor only).
I ended up with two tables:
1- arabic_revised_simple.table, this one is it, it should get any English word hiding behind a nonsense-Arabic-word as long as it's in your dictionary, e.g:
Code:
malik = ةشمهن
OR
12e4b5b39b6230240cd6eace258b564b:اشساؤشف
اشساؤشف = HashCat
2- arabic_revised.table, this one is a bit more complicated, it has all Arabic characters including Shift+ArabicChar (Not very common, I think).
Both attached, remove .txt.

If this got applied to all other languages it would rape foreign hashes brutely, no doubt.


Attached Files
.txt   arabic_tables.rar.txt (Size: 694 bytes / Downloads: 58)
#5
Excellent Guys. Added support to hashcat beta. Please test.
#6
atom thanks for rolling out this change so damn quickly. Malik, thanks for updating my Arabic table. It's far better to have a native speaker create the tables Smile

You guys rock, great job on this.

Anyone want to make Cyrillic tables next? Big Grin



EDIT: Actually Malik, it looks like the tables you attached are in the old table format. atom had to make a major change to the table format in order to support wide characters. Can you download hashcat-0.41b5 and make the appropriate changes to tables/arabic.keyboard.utf8.table?
#7
@epixoip:: No, I'm not a native Arabic speaker, I just happen to know a LOT about Arabic =)

I'm quite sure I followed the new tables' format, where anything on the right side could be a replacement, E.g:
Code:
1=one
c=see
c=cee
u=you
u=4u
And so on...


@atom:: I was playing with the new tables yesterday and I noticed this.
Sometimes when a character appears continuously twice in a word, that is in your dictionary (E.g: nassim). There SHOULD be at least two replacements in the table, otherwise it will die with an error (... has stopped working).
For example: "nassim" is in my dict, my table is:
Code:
s=1
s=2
That's fine but once I remove "s=2"... doesn't work.
I not sure if that's the exact problem, but I'm sure there's something wrong there.
#8
you're right, you did follow the new format. sorry!