hashcat in VM

[strcmp]

Hi.

First post here.
New w/ hashcat.
I googled now for +2 hours ... no joy.

Basic question ... does hashcat 5.1.0 work properly in VM (VirtualBox - host W10) and make use of GPU?

Host:
NVIDIA GeForce RTX 2080
Intel Core i9-9900K

I tried quite a lot of cuda and nvidia drivers - no success.

I get ...

Code:

hashcat (v5.1.0-1497-g8932c71a) starting...

cuInit(): no CUDA-capable device is detected

clGetPlatformIDs(): CL_PLATFORM_NOT_FOUND_KHR

ATTENTION! No OpenCL-compatible or CUDA-compatible platform found.

You are probably missing the OpenCL or CUDA runtime installation.

* AMD GPUs on Linux require this driver:
  "RadeonOpenCompute (ROCm)" Software Platform (1.6.180 or later)
* Intel CPUs require this runtime:
  "OpenCL Runtime for Intel Core and Intel Xeon Processors" (16.1.1 or later)
* Intel GPUs on Linux require this driver:
  "OpenCL 2.0 GPU Driver Package for Linux" (2.0 or later)
* NVIDIA GPUs require this runtime and/or driver (both):
  "NVIDIA Driver" (418.56 or later)
  "CUDA Toolkit" (10.1 or later)
...

[philsmd]

the GPU is probably not exposed to the VM.

only few virtualization software support PCI passthrough and even with those are some restrictions (for instance what if the host also wants to get hold of that GPU, it for instance needs this "resource"... therefore sometimes you would need to have at least several GPUs)... but of course with the correct software and enough/correct hardware it is possible, because also some "cloud" providers give you access to a "dedicated server" with V100 GPUs or similar.
It's just very complicated and maybe even ineffective, because the bare metal would probably be better and faster (and without the additional point of failure).

so the main question is, why do you need a virtual machine ?

[strcmp]

Thanks a lot for your quick response.
The VM was for testing purpose only.
Just wondering if this wouöd work.
I need the host W10 constantly, hence a VM on top would pemit use of both machines in //.

[philsmd]

but why do you not simply use hashcat on W10 then ? hashcat works under windows 10 perfectly fine (same as on linux or macOS etc)

[strcmp]

I had preference for the VM due remote access possibility.
That's more difficult to console access to W10.
But you are right - I'll try the native x86 version (and let you know) ...

[strcmp]

Ok ... works great. Thanks a lot !!!
RTX 2080 seems to be recognized.

However I have another issue, but this is off-topic for this thread.
I get ...

Code:

Minimum password length supported by kernel: 24
Maximum password length supported by kernel: 24

... with -m14100 and a 16 Bytes mask.

[philsmd]

triple des is a cipher which encrypts blocks (8 bytes = 64 bits, our hashcat salt = plaintext and hash = ciphertext in hex) and a key lengh of 24 bytes (3 times 8 bytes).. see https://en.wikipedia.org/wiki/Triple_DES (Keying option 1, all 3 keys are independent)

if you have an alternative where some of those keys are related, you need to somehow feed hashcat with the correct 24 bytes (pipe, dict attack etc)

[strcmp]

My situation is keying option 2, where k1=k3.
Hence 128 (effective 112 bits).
The key is 16 Bytes

So hashcat is not suitable for this, right?

[philsmd]

option 1 is basically the most flexible one that can accomodate for all other modes (the user can just pass the correct password candidates according to keying options).

The main other problem is how to set the last 8 bytes equal to the first 8 bytes in your particular case... but this is NOT even the worst problem, because you are trying to brute-force it with basically 112 bits (2 * 56 bits, which would be 14 bytes, instead of the full 8*2=16 bytes, due to some security properties it's actually known to have only 80 bits of security, see https://en.wikipedia.org/wiki/Triple_DES), which is even in case of a meet-in-the middle quite difficult/infeasible to brute-force in a reasonable amount of time.... you probably need to know more about the (weakness of the) keys to make it feasible and pass the candidates e.g. with an external generetor over pipe where you set K1=K3.
I wouldn't say it's a problem of hashcat (even though one could argue why there is not a dedicated mode for each and every keying option, that's a fair and valid point), but just a problem of complexity and infeasibility (because of too many possible keys/password candidates, at least if you have no further knowledge about some of the bytes or some non-random generation process).

[strcmp]

Thanks for the extensive explanations. I knew about the 80 bit effective key for my situation (K1=K3). Indeed, I'm presently looking for a weakness/hints/scheme in the key, being aware that brute-force won't help.

Good to know that hashcat can cope with K1=K3. That was what I wasn't really sure of.