Hashtopolis Forum

Full Version: Server skips cracked hash after client HC error
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hello, again.
Got another problem.
Client version: python 0.4.0
Server version: 0.10.0
Hashcat version: 5.0.0+81 (beta)
Hash-type: 5300 (IKE PSK MD5)

hashcat gives me some errors such as:
Quote:nvmlDeviceGetCurrPcieLinkWidth(): Not Supported
nvmlDeviceGetClockInfo(): Not Supported
nvmlDeviceGetTemperatureThreshold(): Not Supported
nvmlDeviceGetUtilizationRates(): Not Supported

Therefore, hashtopolis deactivates agent and agent cant upload cracked hash. It fails with an error: "Agent is marked inactive!"

If I change "Cracker errors" parameter in agent setup to "Keep agent running,...", I can get two results:
1. Client uploads cracked hash and server accepts it (on one PC).
2. Client uploads cracked hash and server skips it (on another PC).

I think that such errors are not critical for the cracking process and can be ignored or valued as warnings.
And I can't imagine why the server skips cracked hashes. There is no SQL query with update of hash table. The server selects cracked hash only.

Thank you

P.S. Got two bugs.
If you change Agent binary current version parameter in server config, but keep hashtopolis.zip with an old version, client will enter to endless update loop.
If you install Python to a path with spaces (for example, "c:\Program Files\Python37"), agent will fail to run after update with "File not found" error.
Depending on the hardware, OS and driver installed there are sometimes such "uncritical" errors on the agent. Unfortunately, Hashtopolis cannot distinguish between such errors and more fatal ones where Hashcat exists afterwards, because Hashcat is printing all of them to stderr. So setting the agent to ignore these errors is indeed the correct workaround.

I cannot follow exactly what you mean with the skipping of the cracked hashes, can you please explain what happened there?

Regarding the two bugs:
1. This is indeed true, but the server is not designed to automatically determine the version number from the binary. So if you update manually, you need to keep in mind to change the number on the server as well. But with the new release of 0.10.0 there is this automatic update feature where you can retrieve easily a new agent version and in this case the version number also gets adjusted correctly.
2. That's a good point. I didn't thought at this case, as I assumed that when people have python installed on their windows computer they would add it to the PATH variable and simply call with 'python' without the full path. I'll try to find a fix for this on the client.
Quote:I cannot follow exactly what you mean with the skipping of the cracked hashes, can you please explain what happened there?

Client 1 debug output (I think it's normal way)
Quote:[2018-11-17 23:59:32,765] [ERROR] HC error: nvmlDeviceGetUtilizationRates(): Not Supported
[2018-11-17 23:59:32,765] [DEBUG] {'action': 'clientError', 'token': '<token>', 'taskId': 1, 'chunkId': 2, 'message': 'nvmlDeviceGetUtilizationRates(): Not Supported'}
[2018-11-17 23:59:32,810] [DEBUG] http://<serverIp>:<serverPort> "POST /api/server.php HTTP/1.1" 200 45
[2018-11-17 23:59:32,811] [DEBUG] b'{"action":"clientError","response":"SUCCESS"}'
[2018-11-17 23:59:35,443] [DEBUG] STATUS 6 SPEED 1500 1000 EXEC_RUNTIME 0.113728 CURKU 0 PROGRESS 1 1 RECHASH 1 1 RECSALT 1 1 TEMP 26 REJECTED 0 UTIL -1
[2018-11-17 23:59:36,444] [DEBUG] Sending 1 cracks...
[2018-11-17 23:59:36,444] [DEBUG] {'action': 'sendProgress', 'token': '<token>', 'chunkId': 2, 'keyspaceProgress': 0, 'relativeProgress': 10000, 'speed': 1500, 'state': 5, 'cracks': [['e957a6a0f53ce06a56e4d82e96bc925ffa3cf7b79f6500b667edad5a1d7bad4619efa734f75cca9c4222fbb169f71d4240aced349eb7126f35cf94772b4af373ddf9b3f1ab3a9ff8cd2705417dca7e36dd9026bd0d472459cea7ad245ce57e4bf7d36efdea2a782978c6161eae98f01eac1ee05578f8e524a0d7748c5a1ec2de:647c051436ee84b39a514fd5f2da24fd3bdbb245ef3ed05cb362c58916bbb2cb93a93e3ec33da27404b82125cfd354c0114a3d10dfca26fab139f91046f2ad996f6091ac7a729305272696ac1769991b81a30826e24cee586f3f383b5e035820e17d9715db433ac75f204f20153a12cf7ee4fa7d11b2823e424c26cb513eb26b:fb3678377967e4db:708993a01df48348:00000001000000010000009801010004030000240101000080010005800200028003000180040002800b0001000c000400007080030000240201000080010005800200018003000180040002800b0001000c000400007080030000240301000080010001800200028003000180040002800b0001000c000400007080000000240401000080010001800200018003000180040002800b0001000c000400007080:01110000c0a83965:19004c6aa04dba354599f0d6afbc866970d751e4:6074841c25c83a0c1abfa348fee2d133399595f2:19a3428d90eb5045363a58dc33f51941', 'hashcat', '68617368636174', '0']], 'gpuTemp': [26], 'gpuUtil': [-1]}
[2018-11-17 23:59:36,581] [DEBUG] http://<serverIp>:<serverPort> "POST /api/server.php HTTP/1.1" 200 80
[2018-11-17 23:59:36,581] [DEBUG] b'{"action":"sendProgress","response":"SUCCESS","cracked":1,"skipped":0,"zaps":[]}'
[2018-11-17 23:59:36,582] [INFO ] Progress:100.00% Speed:   1.50kH/s Cracks: 1 Accepted: 1 Skips: 0 Zaps: 0
[2018-11-17 23:59:37,582] [INFO ] finished chunk

Client 2 debug output:
Quote:[2018-11-18 12:00:13,567] [ERROR] HC error: nvmlDeviceGetTemperatureThreshold(): Not Supported
[2018-11-18 12:00:13,567] [DEBUG] {'action': 'clientError', 'token': '<token>', 'taskId': 2, 'chunkId': 8, 'message': 'nvmlDeviceGetTemperatureThreshold(): Not Supported'}
[2018-11-18 12:00:13,621] [DEBUG] http://<serverIp>:<serverPort> "POST /api/server.php HTTP/1.1" 200 45
[2018-11-18 12:00:13,622] [DEBUG] b'{"action":"clientError","response":"SUCCESS"}'
[2018-11-18 12:00:16,112] [DEBUG] STATUS 6 SPEED 1213 1000 EXEC_RUNTIME 0.153118 CURKU 0 PROGRESS 1 1 RECHASH 1 1 RECSALT 1 1 TEMP 34 REJECTED 0 UTIL -1
[2018-11-18 12:00:17,113] [DEBUG] Sending 1 cracks...
[2018-11-18 12:00:17,113] [DEBUG] {'action': 'sendProgress', 'token': '<token>', 'chunkId': 8, 'keyspaceProgress': 0, 'relativeProgress': 10000, 'speed': 1213, 'state': 5, 'cracks': [['e957a6a0f53ce06a56e4d82e96bc925ffa3cf7b79f6500b667edad5a1d7bad4619efa734f75cca9c4222fbb169f71d4240aced349eb7126f35cf94772b4af373ddf9b3f1ab3a9ff8cd2705417dca7e36dd9026bd0d472459cea7ad245ce57e4bf7d36efdea2a782978c6161eae98f01eac1ee05578f8e524a0d7748c5a1ec2de:647c051436ee84b39a514fd5f2da24fd3bdbb245ef3ed05cb362c58916bbb2cb93a93e3ec33da27404b82125cfd354c0114a3d10dfca26fab139f91046f2ad996f6091ac7a729305272696ac1769991b81a30826e24cee586f3f383b5e035820e17d9715db433ac75f204f20153a12cf7ee4fa7d11b2823e424c26cb513eb26b:fb3678377967e4db:708993a01df48348:00000001000000010000009801010004030000240101000080010005800200028003000180040002800b0001000c000400007080030000240201000080010005800200018003000180040002800b0001000c000400007080030000240301000080010001800200028003000180040002800b0001000c000400007080000000240401000080010001800200018003000180040002800b0001000c000400007080:01110000c0a83965:19004c6aa04dba354599f0d6afbc866970d751e4:6074841c25c83a0c1abfa348fee2d133399595f2:19a3428d90eb5045363a58dc33f51941', 'hashcat', '68617368636174', '0']], 'gpuTemp': [34], 'gpuUtil': [-1]}
[2018-11-18 12:00:17,353] [DEBUG] http://<serverIp>:<serverPort> "POST /api/server.php HTTP/1.1" 200 80
[2018-11-18 12:00:17,353] [DEBUG] b'{"action":"sendProgress","response":"SUCCESS","cracked":0,"skipped":1,"zaps":[]}'
[2018-11-18 12:00:17,354] [INFO ] Progress:100.00% Speed:   1.21kH/s Cracks: 1 Accepted: 0 Skips: 1 Zaps: 0
[2018-11-18 12:00:18,354] [INFO ] finished chunk

Clients use different servers and do not know about each other.
Interesting... Do both servers have the same version?
Sure. Both servers were installed with clean database. Both clients have the same version.
Hmm, that seems really strange. So does it always happen on the same server or is it basically just randomly if the crack gets accepted or not when running this task?

If it always happens on the second server, there must be something wrong with configuration. Can you look into the table `Hash` and check that the full hash is contained in the column `hash`. As well check that for the hashlist the `isSalted` flag is not set.
I've checked them. The hash is full, and isSalted param is false
This is getting weird..

Can you turn on TRACE logging on the server config, then reproduce the skipped case and upload the log here (remove tokens and url), to see if the cracked hash submission also arrives fully at the server and maybe to see why it skips it.
I've found the problem: input and output (cracked) hashes are different. Hashcat forms output cracked hash from some internal structure and inserts dividers according hardcoded size, not the input one. For example:
from input
Quote:e957a6a0f53ce06a56e4d82e96bc925ffa3cf7b79f6500b667edad5a1d7bad4619efa734f75cca9c4222fbb169f71d4240aced349eb7126f35cf94772b4af373ddf9b3f1ab3a9ff8cd2705417dca7e36dd9026bd0d472459cea7ad245ce57e4b:f7d36efdea2a782978c6161eae98f01eac1ee05578f8e524a0d7748c5a1ec2de647c051436ee84b39a514fd5f2da24fd3bdbb245ef3ed05cb362c58916bbb2cb93a93e3ec33da27404b82125cfd354c0114a3d10dfca26fab139f91046f2ad996f6091ac7a729305272696ac1769991b81a30826e24cee586f3f383b5e035820e17d9715db433ac75f204f20153a12cf7ee4fa7d11b2823e424c26cb513eb26b:fb3678377967e4db:708993a01df48348:00000001000000010000009801010004030000240101000080010005800200028003000180040002800b0001000c000400007080030000240201000080010005800200018003000180040002800b0001000c000400007080030000240301000080010001800200028003000180040002800b0001000c000400007080000000240401000080010001800200018003000180040002800b0001000c000400007080:01110000c0a83965:19004c6aa04dba354599f0d6afbc866970d751e4:6074841c25c83a0c1abfa348fee2d133399595f2:19a3428d90eb5045363a58dc33f51941

it makes
Quote:e957a6a0f53ce06a56e4d82e96bc925ffa3cf7b79f6500b667edad5a1d7bad4619efa734f75cca9c4222fbb169f71d4240aced349eb7126f35cf94772b4af373ddf9b3f1ab3a9ff8cd2705417dca7e36dd9026bd0d472459cea7ad245ce57e4bf7d36efdea2a782978c6161eae98f01eac1ee05578f8e524a0d7748c5a1ec2de:647c051436ee84b39a514fd5f2da24fd3bdbb245ef3ed05cb362c58916bbb2cb93a93e3ec33da27404b82125cfd354c0114a3d10dfca26fab139f91046f2ad996f6091ac7a729305272696ac1769991b81a30826e24cee586f3f383b5e035820e17d9715db433ac75f204f20153a12cf7ee4fa7d11b2823e424c26cb513eb26b:fb3678377967e4db:708993a01df48348:00000001000000010000009801010004030000240101000080010005800200028003000180040002800b0001000c000400007080030000240201000080010005800200018003000180040002800b0001000c000400007080030000240301000080010001800200028003000180040002800b0001000c000400007080000000240401000080010001800200018003000180040002800b0001000c000400007080:01110000c0a83965:19004c6aa04dba354599f0d6afbc866970d751e4:6074841c25c83a0c1abfa348fee2d133399595f2:19a3428d90eb5045363a58dc33f51941

P.S.: It's just an example, not a real hash.
Interesting, I'll take a look at the source code of hashcat for this parser.

EDIT: Indeed, it seems that hashcat has the lengths for the parts hard-coded. I'll take care about fixing this and contact the hashcat developers.
EDIT2: I created a PR to fix this issue: https://github.com/hashcat/hashcat/pull/1803
Pages: 1 2