Any way to get more restore points for 7z mask attack?

[Replicon]

I have a 7z file I'm trying to restore a password for. I'll try a few things, including a mask attack for shorter keyspaces (7-8 lowercase chars should be within the realm of feasibility.).

My 6 year old machine's GPU is not that great, so I'll have to do it in the cloud (can probably do it in a day with a couple of machines).

To save money, I'll want to use preemptible instances, which are a fraction of the price per hour, which is a bargain if you can engineer around the fact that they can shut down on you at any time.

As such... I want to minimize the amount of wasted work, and based on my 7z mask experiments so far, it looks like restore points are entirely too few and far between.

So, my question is two-fold:

1) How can I maximize my restore points and minimize the amount of work that's wasted if the instances are preempted?

So far, the only thing I've tried that seems to work is to artificially break up the key space into chunks that should take a reasonable amount of time.

Like, instead of '?l?l?l?d' I could have a mask file that looks like (heh this does not like the code tag):

?l?l?l0
?l?l?l1
...
?l?l?l8
?l?l?l9

This seems to at least checkpoint after each mask is exhausted (sorta... if I kill it with a ctrl-C instead of a checkpoint quit, it looks like it doesn't finish writing the restore for the previously-completed run even several seconds into the next one).

2) How do restore points work in general, and what are the numbers showing up in progress?

If I run with '?l?l?l', I see:

Code:

Progress.........: 5408/17576 (30.77%)
...
Restore.Point....: 0/676 (0.00%)

To me, that intuitively says, "there are 676 total checkpoints in this run, or one every 17576 / 676 = 26 hashes". That's clearly not how it works, because "one every 26" would be ridiculously often (and probably make the thing i/o bound haha), but then... what does that 676 even mean, if there are basically zero restore points in that run?

[Centurio]

Hi,

I can not answer your qestion about the checkpoints. Maybe with faster GPU the restore points are rechached earlier. If I try with 2x 2080ti on BTC wallet, it can take 5 minutes until the checkpoint is reached. In my eyes this is quiet ok.

If you want, I can give it a try on my machine and let you know. You will not have to buy cloud GPU and you can estimate the cracktime more precise. What are you using the -m 11600

Kind regards
centurio

[Replicon]

Hi,

I can not answer your qestion about the checkpoints. Maybe with faster GPU the restore points are rechached earlier. If I try with 2x 2080ti on BTC wallet, it can take 5 minutes until the checkpoint is reached. In my eyes this is quiet ok.

If you want, I can give it a try on my machine and let you know. You will not have to buy cloud GPU and you can estimate the cracktime more precise. What are you using the -m 11600

Kind regards
centurio

Hi there!

Yes, 11600 is what I'm using. From what I'm reading, 7z is just generally significantly slower to crack than most other things, due to the algorithm requiring many iterations... which is generally a good thing, if you're not on the cracking side of it haha. If you run the benchmarks, you can see the ratio between md5 and 7z - it's quite pronounced.

So, I'm thinking, hashcat doesn't take algorithm into account when it determines how and where to lay out the restore points, and if md5 and some others run ~60,000 times faster than 7z, and it takes 5 minutes between checkpoints for that, the 7z checkpoints are just... hopelessly far out... but it might be better behaved with larger key spaces... I know I've seen some kind of restore point at some stage... I just don't understand it yet.

If you want, please do give it an estimation run. I'm curious to see the results.

I'll reply again shortly with some of my own numbers, both for benchmark, and for actual real cracking (which seems to be orders of magnitude slower than the benchmark, possibly because benchmark assumes more parallelization from larger keyspaces or something... again, don't know the deets yet). I also want to test with multiple different cloud GPUs, to get the best cost ratio... I bet you twice as expensive isn't twice as fast.

[Replicon]

Well, I did some benchmarking...

I compared my local machine to a couple of cloud instances. I basically started with the base image that the FaceSwap folks provide, because I'm lazy and it already had the nVidia drivers installed.  

Then I installed nvidia-cuda-toolkit and hashcat, and saved it as my actual image to use.

I tried running it with Tesla P100, and with Tesla K80. Interestingly, the K80 was a nonstarter, as it complained about outdated CUDA capability, and ended up performing as poorly as my local machine.

Interestingly, the ratio between "benchmark 11600" and "actual real-world 11600" seems to be ~30 consistently across the board... maybe there's something I can do to bridge that gap that I'm not yet aware of...

Unless I find a massive boost in bang-for-the-buck with the higher end stuff, even short passwords are fairly intractable/costly to deal with.

[Replicon]

Heh just for fun... we can see what's tractable and what's not, beyond which only wordlists/hybrid would be practical.

.... but anyway, let's avoid getting too much into the weeds - would still love to know about how to get more frequent restore points... maybe when using wordlists, it's more reasonable?

EDIT: yep, looks like with wordlists, it's actually hitting restore points at good frequency (at least, if I run with example.dict).