oalabs / hashdb Goto Github PK

Hello.
hashdb.openanalysis.net is a great service.
But I was wondering that if it supports macOS APIs.
Unfortunately, it does not seems to support them at the moment.
Do you have any plan to support them in the future?

When querying an algorithm using the API, the only attributes provided are algorithm and description (see here).

In order to add proper support for OALabs/hashdb-ida#5, the type (unsigned_int, unsigned_long) is required by the client so that we know which types to use in IDA (ida_bytes.create_dword vs. ida_bytes.create_qword, ...) when fetching the hash_value.

As usual, great stuff! I was wondering if the code to generate the database is available? I would like to plug it with our process for the CIRCL hashlookup database.

SmokeLoader uses a ROL8 hashing as described in rol8_xor_b0d4d06.py, but my understanding is that the XOR key changes frequently.

I'd like to ask if it makes sense to add a generic rol8 for Smoke (without XOR), or just modify this one and remove the current hardcoded XOR key (given we can query HashDB with an XOR already).

The /hunt endpoint currently accepts multiple hashes. My assumption was that passing more hashes to that endpoint, the number of results would decrease, because the DB has more hashes to automatically decide if a given algorithm is better suited for resolution. Instead, it seems that the API returns all possible hashing functions, similar to when I would have tried to hunt for the hashes separately and merge the responses.

Minimal Example:

The body {"hashes": [1676620]} leads to

{
    "hits": [
        {
            "algorithm": "revil_010F",
            "count": 8,
            "hitrate": 8.0
        }
    ]
}

and {"hashes": [219106]} leads to

{
    "hits": [
        {
            "algorithm": "shl1_add",
            "count": 8,
            "hitrate": 8.0
        },
        {
            "algorithm": "revil_010F",
            "count": 6,
            "hitrate": 6.0
        }
    ]
}

But {"hashes": [219106, 1676620]} leads to

{
    "hits": [
        {
            "algorithm": "shl1_add",
            "count": 8,
            "hitrate": 4.0
        },
        {
            "algorithm": "revil_010F",
            "count": 14,
            "hitrate": 7.0
        }
    ]
}

as well. Ideally the last response would be the same as the first.

There might be a good reason /hunt behaves that way. In this case, could we get another endpoint that accepts multiple hashes and behaves as I suggested. Because if not, we would need to make N requests to the /hunt endpoint, one for each hash and intersect the results on the client side.

Context: this came up during developing the HashDB client for Ghidra and in particular, implement automatic REvil API resolution.

When using the /hash/:algorithm/:value endpoint to resolve a hash for example, the value in the field api is returned in lowercase. This imho makes reading the resulting resolved API hashes unnecessarily hard.

https://hashdb.openanalysis.net/hash/crc32/2937175076

{
  "hashes": [
    {
      "hash": 2937175076,
      "string": {
        "string": "RtlFreeHeap",
        "is_api": true,
        "permutation": "api",
        "api": "rtlfreeheap",
        "modules": [
          "ntdll"
        ]
      }
    }
  ]
}

The field string contains the original name including casing, so the data seems to be available in principle. This also effects other endpoint that return structures as the one displayed above btw, /module/:module/:algorithm/:permutation for example.

I haven't looked at the backend code at all, hence I'm asking: Is there a technical reason, the api is lower-cased or can we just change this?

Add driver exports to hashdb API list

Because we have collisions in hash tables a single hash lookup can return multiple hits... this is no good when trying to hunt for a matching algorithm.

Example.
The body {"hashes": [1676620]} leads to

{
    "hits": [
        {
            "algorithm": "revil_010F",
            "count": 8,
            "hitrate": 8.0
        }
    ]
}