hashcat Forum

Full Version: How can i Brute-force attack with 32 charset
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I'm try to decrypt a 7z file which encrypted with 32 charset.
How can i make it?

i have try the command:
-m 11600 -a 3 -1 ?l?u?d file.txt ?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1 -o output.txt

But it can not be run.

Any solution?
please do the math.

How feasible is this ?

How many combinations exists and how large is the keyspace ?

Is this really a clever attack and is this even possible ?

What type of password is this ?

Are you sure about a 32-character long random password ?

The answer in general would be that this type of attack (even when/if it would be allowed by hashcat) wouldn't be feasible and you wouldn't be able to run over all the password candidates within a lifetime (and in this case it's even much worse because of the slow 7z algorithm, but in general brute-forcing a 32-character random password with that huge of a keyspace wouldn't be possible within thousands of years even with the best hardware).
(05-14-2021, 09:39 AM)philsmd Wrote: [ -> ]please do the math.

How feasible is this ?

How many combinations exists and how large is the keyspace ?

Is this really a clever attack and is this even possible ?

What type of password is this ?

Are you sure about a 32-character long random password ?

The answer in general would be that this type of attack (even when/if it would be allowed by hashcat) wouldn't be feasible and you wouldn't be able to run over all the password candidates within a lifetime (and in this case it's even much worse because of the slow 7z algorithm, but in general brute-forcing a 32-character random password with that huge of a keyspace wouldn't be possible within thousands of years even with the best hardware).

Thank you.
Are you sure about a 32-character long random password ? Yes, Qlocker.
I know that a huge number of the combinations.

Just try to find a way to recovery all file.
so according to some news sources, this is a ransomware that encrypts the users files with 7-Zip using a 32-ASCII-character long random password:
https://www.bleepingcomputer.com/news/se.../#cid18995

that's of course very bad, because this is infeasible to just brute-force it within a lifetime (it's waaaaay too long and random)... unless there is some weakness in the ransomware itself (e.g. predictable / weak passwords or some leak of parts of the password.... but this is very unlikely)... my guess is that it's best to see if somebody is able to help you (some forensic or anti-virus company that has some other solution, but brute-forcing it with the above length and randomness makes it impossible to do within dozens/hundreds/thousands of years without a weakness).

update: what is this https://www.youtube.com/watch?v=aq_cIdY_ksQ&t=533s is this true or a fake report ? (it says that you must not have restarted your device, otherwise this method doesn't work. so DONT reboot)
some other advice, just wait

for some ransomware, security experts revealed the main key for decrypting after a short period of time after the ransomware goes "into the wild"

10 seconds google, here is a short list from avast (older ransomware)
https://www.avast.com/de-de/ransomware-decryption-tools
so be patient if your data isnt that vital

EDIT:
harr the idea with the logfile is "straight beautiful" Big Grin
Oh I had another look at these news articles and description of the problem and it seems that :
it's not enough to look at a log file (7z.log or similar)... you instead need to catch the malware while it's still encrypting and the 7z.log needs to be created by YOU (i.e. a command can be run to log the "ps" output.... the list of running processes under linux with all the command line arguments. The -p[PASSWORD_HERE] is of course then also within the command line).

This is just a clarification / correction (I don't want that wrong claims/facts are mentioned above by me, I didn't know that the log file was NOT automatically created and that you must also catch qlocker while still encrypting your (only small) files. It's using this "small files" approach for ensuring to do more damage in a small amount of time, instead of encrypting large movie files or similar).

Some further links:
https://www.qnap.com/en/security-news/20...e-qnap-nas
https://www.qnap.com/en/how-to/faq/artic...iles-by-7z
https://security.stackexchange.com/questions/248696/
https://www.bleepingcomputer.com/news/se...p-utility/
https://sourceforge.net/p/sevenzip/suppo...uests/389/
https://sourceforge.net/p/sevenzip/discu...c08f09aa8/
https://www.bleepingcomputer.com/news/se...overy-app/
https://np.reddit.com/r/qnap/comments/mx..._testdisk/
https://forum.qnap.com/viewtopic.php?f=4...95#p788526
https://forum.qnap.com/viewtopic.php?f=4...55#p788798
https://forum.qnap.com/viewtopic.php?f=4...50#p788325


It seems the photorec / testdisk method to recover files is working good for a lot of affected users (you just need to do it the correct way and not use the disk heavily... i.e. read-only and not mess around with the disk itself... just copy everything before i.e. special backup of the whole disk 1:1, bit by bit copy).
This of course is only needed if you don't have the password. This only works because the malware just use -sdel parameter of 7z and did not override the underlying data (like shred or similar).

Good luck recovering the files ! It seems doable because of these weaknesses/problems of the encryption.