In order to have something meaningful to test hashcat with, I went onto my forum and using phpmyadmin, exported the usernames & password hashes to separate files. I have the first 200 hashes and usernames in separate files. I've thrown a variety of options at it and expected to at least reveal low-hanging fruit but haven't turned up any plains.
I'm roughly following/borrowing (*.[rule|dic]) from here:
http://www.adeptus-mechanicus.com/codex/...ateasy.php
../hashcat-cli32.bin -a0 -r linkedin2012.rule -e smfMembers-top200.salt -m121 -o results.txt -n8 --remove smfMembers-top200.hash linked.dic
Nothing after 10 minutes (this time).
../hashcat-cli32.bin -a3 -1 ?l?u?d?s -m121 -e smfMembers-top200.salt -n8 --remove smfMembers-top200.hash ?1?1?1?1?1?1?1?1
Nothing after some other amount of time.
All of that's got me wondering if I have the hashes in the right format. They're essentially 40 Alphanumeric chars w/ no ":" separating the hash from the salt. Is this the right format for what I'm trying to show?
Anything obvious that I'm not doing right?
First, if you want to use -e, don't use --remove. If I remember well it's not yet fixed in this version of Hashcat. Here's a couple of things to try but I am not sure if they can really cause a problem:
- I think that you need spaces at a couple of places like -a 0, -m 121 and -n 8.
- Just to be safe, make sure that the user names in the salt file are all lowercased.
- It was unclear in your post but the hash file should only have the hashes which are 40 characters long, 1 per line.
(06-15-2013, 02:43 AM)mastercracker Wrote: [ -> ]First, if you want to use -e, don't use --remove. If I remember well it's not yet fixed in this version of Hashcat. Here's a couple of things to try but I am not sure if they can really cause a problem:
- I think that you need spaces at a couple of places like -a 0, -m 121 and -n 8.
- Just to be safe, make sure that the user names in the salt file are all lowercased.
- It was unclear in your post but the hash file should only have the hashes which are 40 characters long, 1 per line.
Thanks for the reply. What exactly is incompatible between -e & --remove?
As for spaces, I get meaningful output that indicates that those options are accepted the way they are.
I'll doublecheck the usernames. The first few are lower, but I'm not sure all of them are (as usernames on the forum aren't all lower.)
The format of my hash file is 40 chars per line.
Just brainstorming here, but one way I could check is to add my password to the dictionary file. I'd at least see SOME progress or know immediately if I'm doing it wrong.
I need to learn rules, and how to work on combining forum-specific terminology w/ standard password logic. I guess I've just given myself a homework assignment.
Quote:Thanks for the reply. What exactly is incompatible between -e & --remove?
It was creating a race condition where one file (I don't remember which one) will grow until filling your whole hard drive.
This -e and --remove discussion seems to be kind of offtopic here, but anyway, there was a "non-ideal behaviour" I would say that was very well documented
https://hashcat.net/trac/ticket/153 and
https://hashcat.net/forum/thread-2329.html and was fixed. The problem: by using external salts each hash could be combined w/ each possible salt, this grows exponentially fast and could end up in a very large file. The solution was: not write the salt to disk at all, but only the hashes.
Back to SMF:
I can reproduce this "problem" on cpu hashcat. If you have doubts about the format as always see here:
http://hashcat.net/wiki/doku.php?id=example_hashes
It could be that external salt + SMF was not really supported so far or it is just simply broken.
Could you please open a trac ticket for this problem here:
https://hashcat.net/trac/ (if possible w/ a testcase and explain what exaclty *is* working and what *not*, e.g. w/o -e it is, w/ -e not etc) and one of the devs will have a look at it soon. Thx
UPDATE: I was able to reproduce it, opened a trac ticket for you (
https://hashcat.net/trac/ticket/163 ) and it seems that it works w/ cpu hashcat 0.46 dev version now... Bad news: you need to wait for next release.
Wow! A lot has happened while I was away. Thanks for doing the legwork. I'm glad I bothered asking a question.
Thanks again.
Do not use -e unless you know exactly what you're doing. SMF has its own hash mode for good reasons.
My post-count and the content of the original post should indicate I'm in no danger of knowing "exactly what <i'm> doing" anytime soon.
Regardless, when I issue this command:
../hashcat-cli32.bin -a0 -m121 -o results.txt -n2 --remove smfMembers-top200.hash linked.dic
I get:
...
Skipping line: 014f1ef02d52b27ae68670b119097d2309eb0d21 (line length exception)
No hashes loaded
whereas, the -e <filename.salt> seems to give the type output I'd expect sans actual results (cracked passwords).
Ok. After re-reading philsmd's post where he points me to a link if I have doubts about the format of my hash, I see
"121 SMF >= v1.1 ecf076ce9d6ed3624a9332112b1cd67b236fdd11:17782686 "
My hashes don't look like this. There is no :<numbers> at the end. I guess I need good data first. Now to figure out how to GET the data in that format.
After the colon ( : ) is the salt! If you have the salt in a separate file, the only things you could do is either combine each hash w/ every salt or use -e.... BUT: the -e option w/ SMF hashes was *not* supported so far... this feature is *new* in cpu hashcat 0.46! See trac ticket above ^.
So either wait for the release or stick to option 1 (combine each hash w/ each salt yourself).