Skip to content
This repository has been archived by the owner on Aug 19, 2023. It is now read-only.

Request for better handling of hashcat errors #368

Open
GrepItAll opened this issue Nov 13, 2017 · 3 comments
Open

Request for better handling of hashcat errors #368

GrepItAll opened this issue Nov 13, 2017 · 3 comments

Comments

@GrepItAll
Copy link
Contributor

GrepItAll commented Nov 13, 2017

The check for whether or not a hashcat job has completed seems to me to boil down to this code:

def isBusy? @results = `ps awwux | grep -i Hashcat | egrep -v "(grep|sudo|resque|^$)"` true if @results.length > 1 end

This is in helpers/status.rb

I would like to request that the hashcat job status checking be made more robust. Hashcat can crash from time to time and Hashview should be able to handle this somewhat. I had a job where Hashcat crashed with a segfault 24 hours into a roughly 2 day job. I got an email from Hashview telling me the job had completed. I knew that the job wasn't due to complete for another day, so I checked the syslog and confirmed that hashcat crashed. I have reported that crash separately to the Hashcat devs.

Hashview should not in my opinion just use the check that I copied above. If the Hashcat job does not complete with either an Exhausted or Cracked status, then something has probably gone wrong and Hashview should reflect this.

No idea what the best way of implementing that check is currently though, so apologies for that!

Keep up the good work :)

@i128
Copy link
Contributor

i128 commented Nov 21, 2017

Ha yeah the above was a bit of code from our legacy implementation, and a bit of a hack. There are other ways we could report on this, for example if job.status == running, etc.

It would be good to record the return values from hashcat (if possible) and use that to trigger a status a failed or completed chunk.

@GrepItAll
Copy link
Contributor Author

So I've had a look at the hashcat status codes and the codes that are returnable are the following (from hashcat/docs/status_codes.txt):

-2 = gpu-watchdog alarm
-1 = error
 0 = OK/cracked
 1 = exhausted
 2 = aborted
 3 = aborted by checkpoint
 4 = aborted by runtime

Internally, the list of statuses is slightly different/larger (from hashcat/src/status.c):

static const char *ST_0000 = "Initializing";
static const char *ST_0001 = "Autotuning";
static const char *ST_0002 = "Selftest";
static const char *ST_0003 = "Running";
static const char *ST_0004 = "Paused";
static const char *ST_0005 = "Exhausted";
static const char *ST_0006 = "Cracked";
static const char *ST_0007 = "Aborted";
static const char *ST_0008 = "Quit";
static const char *ST_0009 = "Bypass";
static const char *ST_0010 = "Aborted (Checkpoint)";
static const char *ST_0011 = "Aborted (Runtime)";
static const char *ST_0012 = "Running (Checkpoint Quit requested)";
static const char *ST_9999 = "Unknown! Bug!";

@i128
Copy link
Contributor

i128 commented Feb 21, 2018

So we've fixed the 'isbusy' function in v0.7.4, but still no support yet for exit codes.

@i128 i128 added the bug label Feb 21, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants