Continued troubleshooting API issues

[vbabson]

After having managed to get the API connectivity working I am unable to perform certain actions.

I am able to successfully query hashlists, tasks, and other multiple objects in the system, but I cannot determine how to create a simple hashlists.

Using the example JSON from the User API PDF:

Code:

{
"section": "hashlist",
"request": "createHashlist",
"name": "API Hashlist",
"isSalted": false,
"isSecret": true,
"isHexSalt": false,
"separator": ":",
"format": 0,
"hashtypeId": 3200,
"accessGroupId": 1,
"data": "JDJ5JDEyJDcwMElMNlZ4TGwyLkEvS2NISmJEYmVKMGFhcWVxYUdrcHhlc0FFZC5jWFBQUU4vWjNVN1c2",
"useBrain": false,
"brainFeatures": 0,
"accessKey": "mykey"
}

I initially get:

Code:

The response is:{"section":"hashlist","request":"createHashlist","response":"ERROR","message":"Hashcat brain cannot be used if not enabled in config!"}

So I comment out the usebrain=false line, then I get:

Code:

The response is:{"section":"hashlist","request":"createHashlist","response":"ERROR","message":"Invalid query!"}

How can I determine the exact error or proper API calls?

Thanks,

--Vic

[s3in!c]

Which Hashtopolis version exactly are you running?
I tried reproducing the issue on a 0.11.0 installation, but for me it works.

Just to be sure, did you set the false flag correctly? For example:

Code:

"useBrain":false

is the correct variant, but if you write

Code:

"useBrain":"false"

it will not work.

[vbabson]

Thanks for the response.

I actually tried using false without quotes.

Turns out I have to use 0 in my python script.

I think I am moving along now.

Thank you for the response!

[vbabson]

When I push a brute force attack:

Code:

data62 = {
"section": "task",
"request": "createTask",
"name": "API_Task_BF",
"hashlistId": 1,
"attackCmd": "#HL# -a 3 ?l?l?l?l?l?l",
"chunksize": 600,
"statusTimer": 5,
"benchmarkType": "runtime",
"color": "4D4D4D",
"isCpuOnly": 0,
"isSmall": 1,
"skip": 0,
"crackerVersionId": 1,
"files": [],
"priority": 99,
"isPrince": 0,
"accessKey": "REDACTED"

Everything works as expected.

When I push a dictionary attack (with or without the rules) I get;

Code:

Keyspace got accepted!
Benchmark task...
Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "hashtopolis.zip/__main__.py", line 338, in <module>
  File "hashtopolis.zip/__main__.py", line 217, in loop
  File "hashtopolis.zip/htpclient/hashcat_cracker.py", line 390, in run_benchmark
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa2 in position 45: invalid start byte

My API calls aren't the issue as if I create the task in the web interface I get the same error.

Code:

data61 = {
"section": "task",
"request": "createTask",
"name": "API_Task_PW_List",
"hashlistId": 1,
"attackCmd": "#HL# -a 0 -r best64.rule example.dict",
"chunksize": 600,
"statusTimer": 5,
"benchmarkType": "runtime",
"color": "5D5D5D",
"isCpuOnly": 0,
"isSmall": 0,
"skip": 0,
"crackerVersionId": 1,
"files": [2,3],
"priority": 100,
"isPrince": 0,
"accessKey": "REDACTED"
}

My files appear to be encoded correctly:

Code:

/opt/client/files# file -i *
api_test_inline2.txt: text/plain; charset=us-ascii
best64.rule:          text/plain; charset=us-ascii
example.dict:         text/plain; charset=us-ascii
vic.dict:             text/plain; charset=us-ascii
vic.txt:              text/plain; charset=us-ascii

Forgot to mention that if I run this task with benchmarkpeed I get:

Code:

Error during speed benchmark, return code: 255
Got task with id: 23
Benchmark task...
No hashes loaded.

So I switched over to benchmark: runtime and receive the error above.  But only if trying to use files/lists.  Brute Force works fine with benchmark:runtime.


Any ideas?

[s3in!c]

Turn on the debug flag on the client with adding --debug and search for the command it issues for the speed benchmarking (prepended with CALL.
Take this command and try to run it in the appropriate cracker directory (crackers/<id>/) and see what hashcat reports.

It might be that there is a BOM somewhere which hashcat does not like. At least with calling hashcat directly you should get a more useful error message.

[vbabson]

Here is the debug output from the client:

Got cracker binary type hashcat
{'action': 'getChunk', 'token': 'fQ4cjQiAgH', 'taskId': 24}
http://52.15.120.70:80 "POST /api/server.php HTTP/1.1" 200 63
b'{"action":"getChunk","response":"SUCCESS","status":"benchmark"}'
Benchmark task...
CALL: ./hashcat64.bin --machine-readable --quiet --runtime=30 --restore-disable --potfile-disable --session=hashtopolis -p " " ../../hashlists/1 -a 0 ../../files/example.dict --hash-type=9400 -o ../../hashlists/1.out
started benchmark
{'action': 'clientError', 'token': 'REDACTED', 'taskId': 24, 'chunkId': None, 'message': 'nvmlDeviceGetFanSpeed(): Not Supported'}
http://REDACTED "POST /api/server.php HTTP/1.1" 200 45
b'{"action":"clientError","response":"SUCCESS"}'
{'action': 'clientError', 'token': 'REDACTED', 'taskId': 24, 'chunkId': None, 'message': 'No hashes loaded.'}
http://REDACTED "POST /api/server.php HTTP/1.1" 200 45
b'{"action":"clientError","response":"SUCCESS"}'
Traceback (most recent call last):
File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "hashtopolis.zip/__main__.py", line 338, in <module>
File "hashtopolis.zip/__main__.py", line 217, in loop
File "hashtopolis.zip/htpclient/hashcat_cracker.py", line 390, in run_benchmark
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa2 in position 45: invalid start byte


I also noticed something weird in the database. I browsed over to the hash table and noticed that hashes I uploaded through the web interface look like this:

oldoffice$0*0e62d7b435b9a5a02edbccdec499fb...


While ones pushed through the API (both in python and powershell) look like this:

¡÷âqí´Ó½´×o5ën÷‡µnºßÝㇶó§4߶ùi­ݾ}...


I'm wondering if some weird encoding is the culprit.

[s3in!c]

Is it possible that you didn't encode them with base64 when sending them with the API?