hashcat Forum

Hello Everyone,

I've encountered a Problem while updating to oclHashcat-1.33. At first the Error "clCreateBuffer() -61" showed up everytime I tried to start cracking on some Hashes (tried it with the oclExample0.sh). After some Googling I stumbled accross the Command


Now I am able to run Hashcat fine, except when I am trying to use the tuned performance Profile.

The following Job runs fine


But when I try to increase the Performance Profile to 3, I get the above mentioned Error


I don't know if its worth mentioning but I have an old HD5850 that I use to toy around with oclHashcat

As always thanks in advance for any Help or Suggestions

clCreateBuffer() -61 basically means "Out of Memory". That means your GPU memory. The number of hashes (plus the fact that they are salted) affects the required memory plus the wordload profile affects the required memory. So it's perfectly normal to run into this error, sooner or later.

@atom

Thank you for your reply and the Clearification of the Error Message but I've done some more tests and the Results don't seem to Point in that Direction although I am not sure in which Direction the Results point anyway :-\

Let me Explain what I did:

I testet a Single vBulletin hash with oclHashcat 1.33 which returns the clCreateBuffer() -61 Error.


Then I testet the same Hash with oclHahscat 1.31 and everything works fine. So I am a bit out of Ideas here :-\


Thanks in Advance!

EDIT

When I try the full Hashlist with oclHashcat-1.31 it also works fine :-\ Could it be that my Graphicscard is getting to old for newer Versions of Hashcat?

The new version probably handles the salts a bit different and hence needs more vram. Split up your hashlist and try again.

@undeath

As I said in the above Post, I have tried this with a single Hash and the Error happens there as well, so I don't think its a matter of how big the Hashfile is because I don't believe that a single Hash + Salt need 1GB of vram :-)

EDIT: At least I don't think that it matters in this Case how big the Hashfile ist :-)

Oh, I'm sorry I didn't read your post properly. Running a mask attack on a single hash should definitely not exhaust your vram.

It's as i said, the wordload profile affects the required memory, too. In your above example you used -w 3 with 1.33 and -w 2 with 1.31. That makes no sense unless you test 1.33 with -w 2 as well

(03-05-2015, 12:56 PM)atom Wrote: [ -> ]It's as i said, the wordload profile affects the required memory, too. In your above example you used -w 3 with 1.33 and -w 2 with 1.31. That makes no sense unless you test 1.33 with -w 2 as well

Sorry atom, I didn't notice the wrong Workload Profile. I've done it with -w 3 now and it works with the Full Hashlist under 1.31.


Sorry to keep nagging on about this :-\ I get the Explenation you provided - at least for the full Hashlist. If you look at the Results I got when trying a single Hash the Workload Profile is the same. I just can't quite grasp that a Single Hash with Workload Profile 3 under 1.31 would work and under 1.33 it would need more then 1GB vram. Or didn't I get the full Picture here :-\ As I was saying, sorry for nagging on about this...

I took my oldest card I have, a hd5770, and I tried to reproduce the problem. That card has only 256mb of GPU ram.

Quote:root@sf:~/xy/oclHashcat-1.33# ./oclHashcat64.bin -a 3 -m 2711 -w 3 -o hashes_out.txt --username --remove hashes_w_u.txt ?l?l?l?a?a?a?a --status -d 2
oclHashcat v1.33 starting...

Device #1: skipped by user
Device #2: Juniper, 256MB, 1000Mhz, 10MCU

Hashes: 1 hashes; 1 unique digests, 1 unique salts
Bitmaps: 8 bits, 256 entries, 0x000000ff mask, 1024 bytes
Applicable Optimizers:
* Zero-Byte
* Precompute-Init
* Early-Skip
* Not-Iterated
* Single-Hash
* Single-Salt
* Brute-Force
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: Kernel ./kernels/4098/m02710_a3.Juniper_1573.4_1573.4.kernel (566680 bytes)
Device #1: Kernel ./kernels/4098/markov_le_v4.Juniper_1573.4_1573.4.kernel (71776 bytes)


ERROR: clCreateBuffer() -61

Now this is oclHashcat v1.34 beta which fixed the problem Actually I have no idea what exactly caused the problem but v1.34 fixed many bugs. I think we accidentially fixed the problem you described as well. If you wish to test v1.34 send me an email

Quote:root@sf:~/oclHashcat-1.34# ./oclHashcat64.bin -a 3 -m 2711 -w 3 -o hashes_out.txt --username --remove hashes_w_u.txt ?l?l?l?a?a?a?a --status -d 2
oclHashcat v1.34 starting...

Device #1: skipped by user
Device #2: Juniper, 256MB, 1000Mhz, 10MCU

Hashes: 1 hashes; 1 unique digests, 1 unique salts
Bitmaps: 8 bits, 256 entries, 0x000000ff mask, 1024 bytes
Applicable Optimizers:
* Zero-Byte
* Precompute-Init
* Early-Skip
* Not-Iterated
* Single-Hash
* Single-Salt
* Brute-Force
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: Kernel ./kernels/4098/m02710_a3.Juniper_1573.4_1573.4.kernel (567384 bytes)
Device #1: Kernel ./kernels/4098/markov_le_v4.Juniper_1573.4_1573.4.kernel (71772 bytes)


Session.Name...: oclHashcat
Status.........: Running
Input.Mode.....: Mask (?l?l?l?a?a?a?a) [7]
Hash.Target....: 98f3c91a605e29e80e9623cc66caff6b:162005066561457267521833088306
Hash.Type......: vBulletin > v3.8.5
Time.Started...: Sun Mar 8 11:55:37 2015 (9 secs)
Time.Estimated.: Sun Mar 8 12:36:29 2015 (40 mins, 42 secs)
Speed.GPU.#1...: 606.6 MH/s
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 5704253440/1431576185000 (0.40%)
Skipped........: 0/5704253440 (0.00%)
Rejected.......: 0/5704253440 (0.00%)
Restore.Point..: 0/81450625 (0.00%)
HWMon.GPU.#1...: 99% Util, 53c Temp, 51% Fan