Hello everyone, I have issues with a 7zip hash being recognized. The 7zip archive is made by Cobian backup tool.
I have tried extracting the hash using hashcat and the john tool. Both methods worked and the extracted 7z hashes are identical. I have tried it in The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) and win 10.
When I try to load the hash for password crunching I get an error that the hash can not be loaded (due to a length issue?)
The hash is in a .txt file and looks like this $7z1$18$0$16$[xxxx], 238 characters in total. Hashcat reads the file as it shows the hash in the .txt file in the error message.
The hash is formatted in a single row. Am I an idiot? Can Cobian have changed the encryption? I can access the archive separately and see the file structure, yet access to the files requires a password.
Thanks
command & screenshot?
example 7z hash (pass:hashcat)
$7z$0$19$0$salt$8$f6196259a7326e3f0000000000000000$185065650$112$98$f3bc2a88062c419a25acd40c0c2d75421cf23263f69c51b13f9b1aada41a8a09f9adeae45d67c60b56aad338f20c0dcc5eb811c7a61128ee0746f922cdb9c59096869f341c7a9cb1ac7bb7d771f546b82cf4e6f11a5ecd4b61751e4d8de66dd6e2dfb5b7d1022d2211e2d66ea1703f96
Here is the result of the cracking attempt with a random mask:
Code:
hashcat -a 3 -m 11600 321.hash ?l?l?l?l?l?l?l?l?l
hashcat (v6.2.6) starting
OpenCL API (OpenCL 3.0 PoCL 3.0+debian Linux, None+Asserts, RELOC, LLVM 13.0.1, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
============================================================================================================================================
* Device #1: pthread-AMD Ryzen 9 3900X 12-Core Processor, 31062/62188 MB (8192 MB allocatable), 24MCU
This hash-mode is known to emit multiple valid candidates for the same hash.
Use --keep-guessing to continue attack after finding the first crack.
Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256
Hashfile '321.hash' on line 1 ($7$1$1...416231c8d30778412$100$5d00004000): Signature unmatched
No hashes loaded.
Started: Wed Jan 4 17:28:08 2023
Stopped: Wed Jan 4 17:28:08 2023
The 7z archive/files are not encrypted in any way, just password protected. I can also try running hashcat on my Dell R420 - ubuntu 20.4 - ,but it will take some time setting up the machine and I doubt this will solve the issue
I could post the hash, but from what I know, posting complete hashes is not allowed.
(01-04-2023, 05:50 PM)cola Wrote: [ -> ]Here is the result of the cracking attempt with a random mask:
Code:
hashcat -a 3 -m 11600 321.hash ?l?l?l?l?l?l?l?l?l
hashcat (v6.2.6) starting
OpenCL API (OpenCL 3.0 PoCL 3.0+debian Linux, None+Asserts, RELOC, LLVM 13.0.1, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
============================================================================================================================================
* Device #1: pthread-AMD Ryzen 9 3900X 12-Core Processor, 31062/62188 MB (8192 MB allocatable), 24MCU
This hash-mode is known to emit multiple valid candidates for the same hash.
Use --keep-guessing to continue attack after finding the first crack.
Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256
Hashfile '321.hash' on line 1 ($7$1$1...416231c8d30778412$100$5d00004000): Signature unmatched
No hashes loaded.
Started: Wed Jan 4 17:28:08 2023
Stopped: Wed Jan 4 17:28:08 2023
The 7z archive/files are not encrypted in any way, just password protected. I can also try running hashcat on my Dell R420 - ubuntu 20.4 - ,but it will take some time setting up the machine and I doubt this will solve the issue
I could post the hash, but from what I know, posting complete hashes is not allowed.
You can see by the header that your 7z version is different and probably not supported by hashcat
Well this is bad news... Is there anything else that I can try?
john gives a similar error. I had no idea Cobian 7z archives are so hard to crack.
(01-04-2023, 11:57 PM)cola Wrote: [ -> ]john gives a similar error. I had no idea Cobian 7z archives are so hard to crack.
This means that Cobain has his own proprietary 7z encryption algorithm
But shouldn't this tie the archive to Cobian itself, and make impossible to use other software to open it? I made a test today and winrar opens the password protected 7z cobian backups with no issues if I use the correct pass. This shouldn't work if the encryption key was generated by a different algorithm.
Sorry if my questions seem silly, I am quite new at this.
Bump. Any other ideas? The backups are not extremely important, but recovering the pass would help a lot.