Can you name a few open source tools for offline password cracking?
#1
Hello, I need help big time.
I'm writing a paper and I'm supposed to provide an overview over open source tools for pw cracking. I have to consider word/excel encryption, encrypted .zip files, encrypted windows and linux hard drives and two other formats of my choice. I also have to write which tool is the best for which problem. Do you guys have any suggestions as to which ones are worth writing about? If so, what are the strengths of said tools.
Thanks for reading, have a good day.
Reply
#2
Are we only talking about password for encrypted files or would that also include "cracking" hashed passwords (from compromised DBs etc)?

Some prominent cracking sofware I know of would be Hashcat and Rainbox Tables. Also there's the more classic software such as Cain & Abel (Suite with a lot more feature than just cracking though). For more general cracking of system accounts itself (windows, unix) I think there's also John the ripper. This would involve extracting the password hashes from the system first though, in the case of windows; SAM credentials. You can use popular tools such as Mimikatz and crack the credentials to plaintext via John the ripper.

Not quite sure about cracking 7zip/rar/zip files. But quick google search tells me you can also do this with John The Ripper. See: https://www.youtube.com/watch?v=mE7j-nwDzXE

Edit: Found some more good videos from the same author. Seems like a pretty cool youtube channel: https://www.youtube.com/watch?v=fPHkO6T_g8A
Reply
#3
The only thing you really need to know about password cracking is how a program is supposed to determine whether whatever is being cracked is cracked successfully.

But before that, you also need to know what a hash might refer to, since that's all offline cracking really is.
I don't feel like writing a long writeup when there are hundreds online, so here:
Quote:Encryption is a two-way function; what is encrypted can be decrypted with the proper key. Hashing, however, is a one-way function that scrambles plain text to produce a unique message digest. With a properly designed algorithm, there is no way to reverse the hashing process to reveal the original password.
Taken from https://gcn.com/articles/2013/12/02/hash...ption.aspx

Hashcat and JtR are the easiest to use as reference to understand the process. You might already be familiar with it, but as a refresher...
  • You have a hash.
  • You have a list of passwords that might be the correct piece of data that the hash was generated from.
  • Both the above tools will then run the hashing algorithm against each password in the list.
  • If one of the passwords results in the hash you're trying to crack, then the program assumes that is the 'correct' password and will return that.


Now, you're talking about file encryption or encryption on archives like .7z, .rar, .zip, etc.

Well, here's a couple things to note:
  • Most archive files contain CRC32 hashes of each file inside the archive in the archive's file headers
  • The file headers of archives are typically unencrypted (else how would a program like WinRAR or 7zip even know if the file is an archive or not?)
  • The hash of the password used for encryption is NOT PRESENT anywhere in the file.
So how exactly does a program crack a .rar file, for instance?


You can crack the password of a rar file using John the Ripper, but there's an intermediate step: You first need to run the archive through a tool called rar2john.
So, let's take a look at the source: https://github.com/magnumripper/JohnTheR...rar2john.c

And you'll see from around line 786, the program starts to read the header data and starts extracting important data.
Notably, it's pulling data like file sizes and those CRC32 hashes of files in the archive as well as the IV used for encryption (decryption, rather.)

And when that data is all extracted, JtR can now start running different passwords against the archive. Essentially, what it'll try to do is use each password to decrypt the file using the IV specified in the archive and each password provided in the list. Once decryption ends, it'll check the CRC32 value of a file to see if it decrypted properly or not.

So, even though the hash isn't present, the program can still figure out whether decryption succeeded based on other data present in the file.



Hard drive encryption is different, to a degree. 
But it's not OS dependent. 
I mean, why would it be? The computer would need to decrypt the data at boot-up, before the OS even loads, so that's a pretty neglectful assumption.

A hard drive doesn't just contain files. There's a ton of metadata on that drive that has other information:
  • A table that has a list of partitions on the drive.
  • Tables which store data about files (filenames and physical locations in blocks/sectors on the drive)
Read more here: http://www.mathcs.emory.edu/~cheung/Cour...-disk.html

So, in complete theory, let's assume a hard drive is arranged like this:

0x00000000 -- Drive header
0x00000080 -- Partition table
0x00000100 -- Partition 1
0x00000400 -- Partition 2
0x00000800 -- Partition 3
0x00010000 -- Partition 4
[...]
0xFFFFFFFF -- End of the drive's capacity. (n Partitions.)

Small drive. 4KB.

So when a computer boots up, it starts reading the drive from 0x0 right at the beginning. That header might contain data about where the partition table is, or in other words, 0x80.

So the computer then jumps to 0x80. The partition table will have a list of partitions on the drive, like where they start in terms of block/sector, as well as the file system being used, and which partitions are able to be booted from (typically just one partition, the first partition which contains a series of EFI images that will do all the hard work of loading an OS.)

From the desired bootable partition, it'll read the file table, figure out how to boot the OS installed, and boot.

==========

Now let's add the complexity of encryption:

If implemented properly, the drive's header at 0x0 will now contain some data that the drive is encrypted. 
The computer (at BIOS time) will then prompt the user for a password. If it's correct, the rest of the header will be decrypted containing the partition table and whatnot.

So again, it relies on what the computer can determine from a key given. 
Can it find a certain piece of data after supposed decryption? Then the key is correct. 
If it can't, the key is incorrect.

Now, let's add one more step, just for fun. Consider the following layout.

0x0000 -- Drive header
0x0100 -- Partition Table 1
0x0180 -- Partition Table 2
0x0200 -- Partition 1
[...]

Two tables now.

So we repeat the process for an encrypted drive. Drive header says the drive is encrypted. The computer prompts the user for a password.
The password supplied will decrypt the header, and the header will then point to 0x100, or PT1.

But what if a different password was supplied? Notice the drive header is twice the size...
Instead, the header when decrypted will be different, and the partition table will be listed at a different offset, or 0x180 instead.

And each table will have a different partition it points to that was encrypted with a different encryption key.

It's a little hard to wrap your head around, but the arguably best disk encryption tool VeraCrypt has that functionality, called Hidden Volumes.
You can read their explanation here: https://www.veracrypt.fr/en/VeraCrypt%20...ystem.html



There's no best tool for something, nor is there an all-in-one solution for anything. 

Strengths of tools are also too debatable for what you mean by 'strength.' 
I mean, one program might be faster than another if you have more powerful hardware, but then is it the tool that's stronger, or is it the fact that you have more powerful hardware?
At the end of the day, they all operate in more or less the same way, just trying to figure out if the data is decrypted is the only difference between cracking different things, and the tool doesn't really matter.

But, while you're at it, I'd have a look at hash collisions. It's a more or less untapped part of password cracking, since it's only really relevant if you're using it to spoof a checksum rather than crack an encryption key, but still interesting nonetheless.
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Is releasing hacking tools a bad idea? DeepLogic 2 2,723 07-16-2020, 09:16 PM
Last Post: Vector
  Can ColoCrossing spoof IP header now? feeder986 2 3,275 03-10-2019, 05:25 PM
Last Post: Insider
  how can cracked EMV?chip card . jaycechen 2 5,546 01-20-2019, 11:43 AM
Last Post: Cherry_Linux
  How can I either extend the trial or bypass activation on Windows 10 Enterprise? lunorian 4 4,599 09-27-2018, 02:14 AM
Last Post: cyb3rp0rk