[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/session.php on line 580: sizeof(): Parameter must be an array or an object that implements Countable
[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/session.php on line 636: sizeof(): Parameter must be an array or an object that implements Countable
3.14.by forum • creative new approaches
Page 1 of 1

creative new approaches

Posted: Wed Oct 08, 2008 3:21 pm
by kiando
Here are some new and old attacktypes that I was thinking about:
- combining two dictionaries and using hybrid methods:

Code: Select all

mutate(wordlist_A[] & wordlist_B[])
the mutate function has hybrid effect such as:
+ Uppercase first char / uppercase all chars
+ reverse word A / word B
+ insert numbers 0-99? between words
+ double word A / B / both
+ do not hash if outcoming key < 8 chars
...

be creative

edit: I am not sure how well a dictionary attack fits GPU accelerated code....

Re: creative new approaches

Posted: Thu Oct 09, 2008 2:49 am
by BarsMonster
Dictionary would slow down GPU core by 1-20%

Re: creative new approaches

Posted: Thu Oct 09, 2008 2:46 pm
by kiando
Are you thinking about an implementation of dictionary stuff in any version of BarsWF?

Re: creative new approaches

Posted: Thu Oct 09, 2008 4:41 pm
by BarsMonster
Yes I do, but I wonder how it can be done in distributed version...

Re: creative new approaches

Posted: Thu Oct 09, 2008 11:55 pm
by hardfalcon
You could split up the dictionary in multiple parts, one for each GPU...
Would the dictionary be loaded into VRAM or into normal RAM?

Re: creative new approaches

Posted: Fri Oct 10, 2008 5:16 am
by BarsMonster
hardfalcon wrote:You could split up the dictionary in multiple parts, one for each GPU...
Would the dictionary be loaded into VRAM or into normal RAM?
To normal RAM first, then copied to VRAM.
If your GPU does 1'000'000'000 keys per second that would require ~10Gb/sec transfer from memory->vcard, which is impossible right now (PCI-E 16x limitations, not even talking about how CPU would prepare these 10 Gb/sec of data).

Re: creative new approaches

Posted: Mon Oct 20, 2008 4:34 pm
by kiando
Another thing that I was thinking about is limiting the keyspace:

If we suppose that each plaintext is more likely to contain each char (that it is composed of) only 1 or 2 times and we had an algorithm that checks these keys of plaintext first that could save a lot of time.

e.g. take a look at these plaintexts:

Code: Select all

plaintext123
BarsMonster
*firestorm*
oksusrgbwkq
19857192523
power444user
h#sr35!r3stx
greenhorn
A plaintext eighter has a limited charset (because of double chars) or it has limited double chars.
So you will need two attack types:
1. check with small charsets (especially frequent chars, such as vowels and "123")
2. if the key allready contains two instances of "A", eleminate "A" from the charset in use. the rest is brute force