Poll: Do you find Hashtopus interesting?
You do not have permission to vote in this poll.
Yes, I would use it
94.62%
88 94.62%
No, it's a shitty idea
5.38%
5 5.38%
Total 93 vote(s) 100%
* You voted for this item. [Show Results]

Hashtopus - distributed solution
Hello,

curlyboi, got a question for you.

I have two hashing rigs, running on Ubuntu 14.04 LTS. Rig #1 has 4x Gigabyte R9 280x GPUs, Rig #2 has 4x MSI Twinfrozr III 7950 GPUs.

I use latest version of oclHashcat + Hashtopus.

Hashtopus works great as it should, but I have a problem with "Measuring keyspace..." part when adding new tasks.

Normally, when I start oclHashcat directly without Hashtopus it happens only one time, during first use of that specific dictionary. I assume the result of dictionary stats generation is written on disc and used for next tasks to avoid repeating.

For large dictionaries it takes substantial amount of time to complete, even 30 minutes.

I noticed that every Hashtopus client tries to generate dictionary stats by itself, however when I connect only 1 agent and it finishes "Measuring keyspace" the second agent assigned to task doesn't do that again and starts hashing at sight without generating dictionary stats.

The problem is that when I add another task with the same dictionary, Hashtopus clients generate directory stats again which is a time waste.

Imagine that I have dictionary that is processed within 2 hours, but between each task I have to wait 30 minutes before the hashing starts for dictionary generation of the same file, which is a time and resources waste.

Is there a way to avoid repeated keyspace measurements by Hashtopus?
Good point. I will try to fix this but there is a risk. What if i add a state "keyspace measuring", and an agent performing this will crash? Then the task will frozen in that state. Sure, i could add some timeout but how much time is too much here? we are talking hours
I seem to have an issue with Hybrid Attacks when prepending the mask.

My job as follows works fine:
-a 6 -m 1000 #HL# example.txt ?a?a

However the following causes the clients to hand at measure keyspace:
-a 6 -m 1000 #HL# ?a?a example.txt

As per the documentation of oclhashcat should the input not be valid?
https://hashcat.net/wiki/doku.php?id=hybrid_attack
(06-30-2015, 12:38 PM)curlyboi Wrote: Good point. I will try to fix this but there is a risk. What if i add a state "keyspace measuring", and an agent performing this will crash? Then the task will frozen in that state. Sure, i could add some timeout but how much time is too much here? we are talking hours

I think the benefits are much greater than potential risk. All I would have to do is paying attention during first use of this specific dictionary, checking if everything went OK.

My gain is avoiding repeating such task hundreds of time for the same dictionary across hundreds of future tasks.

I think you could even skip timeout part, just wait until it finishes and maybe you could just add the choice of using such feature in config file so everybody can choose whether they like repeated keyspace masurements or not.

It would be very helpful curlyboi, at least for me.
(06-30-2015, 02:41 PM)skillskills Wrote: I seem to have an issue with Hybrid Attacks when prepending the mask.

My job as follows works fine:
-a 6 -m 1000 #HL# example.txt ?a?a

However the following causes the clients to hand at measure keyspace:
-a 6 -m 1000 #HL# ?a?a example.txt

As per the documentation of oclhashcat should the input not be valid?
https://hashcat.net/wiki/doku.php?id=hybrid_attack
You have to use -a 7 for the second example.
You have to use -a 7 for the second example.

Thanks!

If I want to update hashtopus can I simply copy the new release on top of the old one? Or does the DB need to be updated as well?
(07-03-2015, 01:44 PM)skillskills Wrote:
(07-01-2015, 02:02 PM)mastercracker Wrote:
You have to use -a 7 for the second example.

Thanks!

If I want to update hashtopus can I simply copy the new release on top of the old one? Or does the DB need to be updated as well?

It depends. Sometimes there are changes in the DB, sometimes they are not. You can find this out in github.
Got a crash:

Code:
Описание:
 Stopped working

Сигнатура проблемы:
 Имя события проблемы: CLR20r3
 Сигнатура проблемы 01: hashtopus.exe
 Сигнатура проблемы 02: 0.0.0.0
 Сигнатура проблемы 03: 55cda209
 Сигнатура проблемы 04: mscorlib
 Сигнатура проблемы 05: 2.0.0.0
 Сигнатура проблемы 06: 53a12268
 Сигнатура проблемы 07: 361f
 Сигнатура проблемы 08: 34
 Сигнатура проблемы 09: System.ArgumentException
 Версия ОС: 6.1.7601.2.1.0.256.1
 Код языка: 1049

Ознакомьтесь с заявлением о конфиденциальности в Интернете:
 http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0419

Если заявление о конфиденциальности в Интернете недоступно, ознакомьтесь с его локальным вариантом:
 C:\Windows\system32\ru-RU\erofflps.txt

UPD:

Constantly crashing after restart, so I suppose it is related to my task:


.jpg   scneenshot.JPG (Size: 29.33 KB / Downloads: 10)

Code:
-a 1 #HL# -j "$-" libru_t10_transkey libru_t10_transkey

However same task runs OK by manually:

Code:
F:\temp\hashtopus>hashcat\oclHashcat32.exe --force -a 1 -m 2611 -p☺ hashlists\17 -j "$-" files\libru_t10_transkey files\libru_t10_transkey
oclHashcat v1.36 starting...

Device #1: Cayman, 2048MB, 880Mhz, 24MCU

Hashes: 1232 hashes; 1232 unique digests, 1231 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Applicable Optimizers:
* Zero-Byte
* Precompute-Init
* Precompute-Merkle-Demgard
* Early-Skip
* Not-Iterated
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: Kernel F:\temp\hashtopus\hashcat/kernels/4098/m02610_a1.Cayman_1800.5_1800.5 (VM)_1429981600.kernel (386212 bytes)
Device #1: Kernel F:\temp\hashtopus\hashcat/kernels/4098/markov_le_v4.Cayman_1800.5_1800.5 (VM)_1429981600.kernel (82316 bytes)

Generated dictionary stats for files\libru_t10_transkey: 7535987 bytes, 774627 words, 599952488356 keyspace

[s]tatus [p]ause [r]esume [b]ypass [q]uit =>


Session.Name...: oclHashcat
Status.........: Aborted
Input.Left.....: File (files\libru_t10_transkey)
Input.Right....: File (files\libru_t10_transkey)
Hash.Target....: File (hashlists\17)
Hash.Type......: vBulletin < v3.8.5
Time.Started...: Sat Aug 22 17:23:44 2015 (1 sec)
Time.Estimated.: Tue Oct 13 09:35:24 2015 (51 days, 16 hours)
Speed.GPU.#1...:   679.5 MH/s
Recovered......: 0/1232 (0.00%) Digests, 0/1231 (0.00%) Salts
Progress.......: 301979904/738541513166236 (0.00%)
Rejected.......: 0/301979904 (0.00%)
Restore.Point..: 0/774566 (0.00%)
HWMon.GPU.#1...:  0% Util, 69c Temp, 100% Fan
(08-22-2015, 12:16 PM)dikiy Wrote: Constantly crashing after restart, so I suppose it is related to my task:

Code:
-a 1 #HL# -j "$-" libru_t10_transkey libru_t10_transkey

However same task runs OK by manually:

Do you get to the point where oclHashcat is executed or does it crash before that?
(08-22-2015, 01:56 PM)curlyboi Wrote:
(08-22-2015, 12:16 PM)dikiy Wrote: Constantly crashing after restart, so I suppose it is related to my task:

Do you get to the point where oclHashcat is executed or does it crash before that?

No, exact `hashtopus debug`output is on scneenshot.
Tried to run this task on other computer, it also "Stopped working" in same manner and dump was created (I can't attach it to message and will email to you if you wish)