hashcat
advanced password recovery

hashcat supports displaying information in machine-readable output for a number of modes.

Some machine-readable output includes a commented-out header with information such as the hashcat version.

One line per device, six colon-separated fields:

[device-id]:[hash-mode]:[core-clock in MHz]:[memory-clock in MHz]:[exec-runtime in milliseconds]:[hashes per second]

The lines beginning with # form a header, with one line per enabled option plus the version.

$ hashcat -b -m 0 --machine-readable

# version: v8.0.0
# option: --backend-devices-virthost=1
# option: --optimized-kernel-enable
1:0:2817:1258:90.42:47932721276
2:0:600:3000:85.51:1468731093
Started: Sat Sep 26 09:03:11 2026
Stopped: Sat Sep 26 09:03:18 2026

Reading the first line: device 1, hash-mode 0, running at 2817 MHz core and 1258 MHz memory, a kernel that took 90.42 ms, and 47.9 GH/s.

When the work goes through an assimilation bridge rather than a backend device, hashcat prints a single line instead of one per device, with the device id, the core clock and the memory clock all reported as 0.

The code that implements runtime machine-readable output is in terminal.c

Some fields are variable in width depending on the number of devices used.

Example of a run in progress:

STATUS  3       SPEED   11620683163     1000    EXEC_RUNTIME    452.773035      CURKU   0       PROGRESS        26190392852480  630249409724609375      RECHASH01       RECSALT 0       1       TEMP    64      REJECTED        0

Example of a completed run that was very fast and only engaged one GPU out of six:

STATUS  5       SPEED   186419656       1000    0       1000    0       1000    0       1000    0       1000    0      1000     EXEC_RUNTIME    0.094336        0.000000        0.000000        0.000000        0.000000        0.000000       CURKU    0       PROGRESS        857375  857375  RECHASH 0       1       RECSALT 0       1       TEMP    64      66     67       61      68      64      REJECTED        0

Example of an attack that was terminated by selecting 'q' to quit:

STATUS  8       SPEED   11674779143     1000    EXEC_RUNTIME    455.360562      CURKU   5242880 PROGRESS        41447409582080  630249409724609375      RECHASH 0       1       RECSALT 0       1       TEMP    63      REJECTED        0

The fields are as follows:

• STATUS: Exit status of the job. Statuses are defined in status.c (near the top). Common exit statuses are:
  • 3 (running)
  • 5 (exhausted)
  • 6 (cracked)
  • 7 (aborted)
  • 8 (quit)
• SPEED: hashes (per unit of time), and unit of time (in milliseconds) (per device)
• EXEC_RUNTIME: execution runtime in seconds
• CURKU: the restore point. It counts in the full keyspace, so --skip does not move it.
• PROGRESS: two values, the candidates tried and the total. Both are measured against the range you asked for, so --skip and --limit are already accounted for. A monitoring tool must not add --skip to the first value, which older ones did because the field used to count differently.
• CURKU and PROGRESS both report 0 while --encrypt-with-pubkey is in use, because position reveals which candidates were reached.
• RECHASH: Number of recovered hashes.
• RECSALT: Number of recovered salts.
• TEMP: Temperatures in Celsius (per device)
• REJECTED: Number of rejected candidate passwords.

To get regular machine-readable progress, use --status-timer [seconds].

For most machine-readable output, you will also want to use --quiet.

[device-id]:[hashes per second]

$ hashcat -m 0 -a 3 target.hashlist -d 1 --quiet --speed-only --machine-readable ?a?a?a?a?a?a?a?a
1:3273837251