hashcat Forum

Full Version: Install Oclhashcat 0.25 w/multiple HD 5970's Linux
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I am looking for asssistance to get some installation steps documented formyself and other ATI HD5970 users with multiple ATI GPU's runing under Linux. I have succesfuly installed ATI STREAM SDK_V2.3, ATI Catalyst 10-12 all on Ubuntu 10.04-64 bit. My main reason for the transition to Linux was for full support of the HD5970 and the annoying dongle required on each 5970 under the Windows environment.

I have reviewed the following useful links on the forum; but none of the
go into detail on enabling multi-ATI GPU support under linux.

all right, first of all. it is 100% known to work on linux. also multiple hd5970's Smile so its just an installation problem somehow. ubuntu 10.04 might be a problem. some users reported 2nd gpu does not work but also other users reported it works. its hard to say. i use ubuntu 10.10 and it defenitly works. but first start with installing cat 11.1. it is not important but it is a start. then check out this:

http://developer.amd.com/gpu/AMDAPPSDK/a..._Notes.pdf

the important section in the document is 2.2.4 which says to set LD_LIBRARY_PATH which is one of the most important things to do. after you perform this step, you should verify it. do "ldd oclHashcat64.bin" and check out if the path is the correct one. it should say something like:

libOpenCL.so => /root/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libOpenCL.so (0x00007fca0e6b4000)

check out that the path is the correct one to the unpacked SDK v2.3. not something in /usr/local/...

also important is section 2.2.5 talking about the ICD registration. but if oclHashcat already found 1 GPU on your system you have already passed this step.

now check out this post:

http://devforums.amd.com/devforum/messag...did=139928

it helped me a lot in the beginning. there is a diffrence of how you access your computer. is it local or remote via ssh? if its from local X, its more easy.

lets add some more things:

1. make sure you do: export DISPLAY=:0
2. after oclHashcat found all gpu, make sure your left mask is big enough
3. play with -n values. 8,40,80,160,800 are known to work good. sometimes its faster if you use lower numbers
4. if it still does not work come to our IRC channel.



any news here?
(02-15-2011, 03:58 PM)atom Wrote: [ -> ]any news here?

Hello Atom,

Things are finally looking much better. I appreciate all of your assistance. The main issue was with the export =0: Can you elaborate on the following warning message:

WARNING: words in dict_right < 1024. Can't gain full performance

We are testing the programs abilities on md5-salted hashes as you can see. There is only 1 salt and a list of 5 md5 hashes.

When will version 0.26 be ready? Also is a speed of 5515.8M/s seem accurate to you? See output below.

./oclHashcat64.bin -m 2 --increment -n 800 --gpu-loops 1024 -o output.txt --salt-file=salt.txt hashes.txt -1 ?l?u?d?s ?1?1?1?1 ?1?1?1?1?1?1?1?1

oclHashcat v0.25 starting...

Digests: 2 entries, 2 unique
Salts: 1 entries, 1 unique
Bitmaps: 8 bits, 256 entries, 0x000000ff mask, 1024 bytes
Platform: ATI compatible platform found
Device #1: Cypress, 512MB, 0Mhz, 20MCU
Device #2: Cypress, 512MB, 0Mhz, 20MCU
Device #3: Cypress, 512MB, 0Mhz, 20MCU
Device #4: Cypress, 512MB, 0Mhz, 20MCU
Device #1: Kernel ./kernels/4098/m0002.Cypress.64.kernel
Device #2: Kernel ./kernels/4098/m0002.Cypress.64.kernel
Device #3: Kernel ./kernels/4098/m0002.Cypress.64.kernel
Device #4: Kernel ./kernels/4098/m0002.Cypress.64.kernel
WARNING: words in dict_right < 1024. Can't gain full performance
[s]tatus [p]ause [r]esume [h]elp [q]uit => s
Status....: Running
Mode.Left.: Mask '?1?1?1?1' (81450625)
Mode.Right: Mask '?1?1' (9025)
Speed.GPU*: 5515.8M/s
looks good, however if you want to compare performance with other cracker use sha1 since sha1 can not be reversed.
Ok Atom,

What about the error message?
WARNING: words in dict_right < 1024. Can't gain full performance

In my example above using the --increment will determine the password bu applying the -1 ?lu?u?d?s attack as such(salt+1charachters),(salt+2 charachter) etc etc all the way to a key space of up to 12 charachters. Please confirm.
yes, you can ignore the warning. but no, it will not from 1-12. it search from
5-12 because your mask is ?1?1?1?1 ?1?1?1?1?1?1?1?1. read http://ob-security.info to get more information about --increment
Hello Atom,

I understand how the increment is functioning with the explanation provided at the above link. As a seperate question I received a meesage saying "too many possible combinations" when I was attempting to process the following.
/.oclhascatbin.64 -m 2 -o output.txt hash.txt --salt-file=salt.txt --increment -1 ?l?u?d?s ?1?1?1?1 ?1?1?1?1?1?1?1?1?1?1?1? (Attack on salted md5's) 1 salt - 5 hashes.

The program obviously has built a default check and is advising not to run the hash based on # of years it would take. However as GPU processing is increaed and ATI hopefully fixes the issue with trying to install more the four individual 5970's in a single machine(8 cores); one may attempt to try to attack a keyspace of that length if we can get x8 5970's recognized under Linux.

Lastly when I processed the attack on the system removing the -n 320 --gpuloops=1024 parameters I was able to acheive rough 4.5B c/s. When I was running the attack with the no -n/gpuloops option the speed was around 1.3B c/s. The last modification was to reduce the -n 320 to -n 80 and I was around 5.5B c/s. So what I am asking is that is there a way to some how integrate by default the performance increase offered by the -n/gpuloops command in the next release so that the inclusion/removal of those two parameters is transparent to the user? I know you are working on a new release.
Bruteforcing higher than 8 characters on all charset is possible only for huge clusters of gpus.
If you have a cluster of 93 5970's, somehow interconnected, it'll still take you ~26 days of uninterrupted work. Dont forget the electricity usage for such a cluster.
In short - dont even think of going above 8 characters on all charset.
that is absolutly correct. the brute-force idea was ok in the past where hashes were ciphers and therefore limited somehow. for example DES which is limited to 8 chars or its children like LM which is limited to 7 chars or DEScrypt which is limited to 7 bit charset. real hashes (not ciphers) like md5 or sha1 so not have this limitation. that is why all hashcat utils focuses wordlist based attacks like hybrid, combination, fingerprint, permutation, table-attack or rule-based.