How can I get status from hashcat for using other program?
#1
Question 
Hi,

I trying to get status from oclHashcat-lite like speed, percentage and more to do GUI, I have been search and looking for answer like read .restore but it not good answer. Tried to use:
Code:
[DllImport("user32.dll")]
public static extern IntPtr PostMessage(IntPtr hWnd, IntPtr Msg, IntPtr wParam, IntPtr lParam);
to pass 's' character to program but not good as well.
Is any here can help me? I have been spent 2 days to try to do this thing Sad
#2
its not recommended to read status via the stdout console. better read the .restore file (and reread it to update). the binary structure is documented in the wiki
#3
Thank you for reply, but in my question, I want as way can read status like Speed. It can't read from binary struct file.
#4
Yes, the struct description is here: http://hashcat.net/wiki/doku.php?id=oclh...store-file but there is no speed information included within the struct (since speed may vary quickly and does *not* affect the restore process).

A good start for you would be to have a look here and see what other hashcat GUI projects do/have done: https://hashcat.net/hashcat-gui/ (where open source code is available etc).
#5
Thank you philsmd, I read it and didn't see speed information in hashcat GUI project.
My purpose is create GUI for my customer, who I rent VGA to do hashcat and transfer speed and processting task information to my cloud. Have any solution?
#6
Ok, I understand.
If you look at the output of ./*hashcat -h you see some parameters that may help you, e.g.:
--status Enable automatic update of the status-screen
--status-timer=NUM Seconds between status-screen update
etc etc...

Maybe you can regularly parse this output (when it arrives) and use that info instead of sending the "s" character directly.

But maybe there are even better methods to get this info and I am not aware of.
#7
(05-13-2013, 01:47 PM)philsmd Wrote: Ok, I understand.
If you look at the output of ./*hashcat -h you see some parameters that may help you, e.g.:
--status Enable automatic update of the status-screen
--status-timer=NUM Seconds between status-screen update
etc etc...

Maybe you can regularly parse this output (when it arrives) and use that info instead of sending the "s" character directly.

But maybe there are even better methods to get this info and I am not aware of.

Thank you, but it still read status via the stdout console, I'm looking for other solution. I'm stuck for it 2 days Sad.
#8
I agree w/ atom and you that stdout/stderr reading isn't a good choice in general and should be avoided whenever possible but I think that w/o a full API access to *hashcats functionalities, this is the only way to go for now.

Since it is very easy to validate and parse the "status output" of *hashcat this isn't as evil as one may think.
Of course there will be some edge cases and you must validate the values/strings you get, but by validating each of this fields you should be able to get whatever you need.

If you really think this isn't doable, then please make a list of disadvantages of this stdout/stderr reading (beside the stdout "noise" argument) and a suggestion how a better solution should look like and how it should be implemented by @atom.

I think atom may be willing to accept a feature request for adding some "API queries" e.g. via custom SIGNALS etc which trigger a write to a file whenever a signal is catched etc etc. IFF atom thinks this is of use also to other users and IFF the suggested format is struct(ured) well.

I think some suggestions are always welcome.

Furthermore, I may not be the right person who has enough knowledge if *hashcat may not have other means to get some speed etc info (which are/can be written to some other files etc).

BTW: I don't think that one can generally argue that reading a file is much better than reading from a pipe, it only depends what the format of the "output" is and if it is somehow standard (and doesn't include "noise")... For instance, the stdout may include cracked passwords, instead .restore doesn't include that for sure (but it also misses e.g. speed), but the pot file does etc etc.
#9
the speed can be calculated by the change between the current position and the time difference. api might be an idea, but lower prio