With all the abilities Hashes.org provides to generate hash algorithms, there are unlimited ways of making things go smoothly or horribly wrong. For this reason, I will list some general examples and some edge cases.
Hashes.org supports a bunch of known algorithms, e.g. well-known ones like MD5, SHA1, etc. (a full list is available at the site). These algorithms all can be used as “simple” algorithms for hashes.
In most cases, the simple list algorithms provide everything you need but, there are hashes which might be nested or modified in some way. Let’s look at an example of a nested hash algorithm:
This looks like a standard MD5 hash, right? If you are lucky enough you might find a plain for this hash (The plain is itself an MD5 hash). So the found plain text would look like:
This is not the plain we are looking for and it’s very unlikely that you even get this far. In most cases, you will just try to crack this hash with MD5 and maybe you will resign after some time as you were unable to find it.
With MDXfind we can easily try a lot of algorithms at the same time and we would discover that this hash resolves as an MD5SHA1x01 hash:
As Hashes.org also supports combining basic algorithms, it’s pretty easy to submit this found correctly. We can submit this found by specifying “MD5SHA1” as the algorithm type.
We can take combining algorithms a step further by specifying more than two nested algorithms. Maybe someone has hashes with the algorithm MD5MD5SHA1. On Hashes.org you can specify the algorithm string with a length up to 300 chars which supports an extended variety of usable algorithms.
When you combine algorithms, you always supply algorithms from right to left starting with the plain. So if we have the example:
This would mean the plain is hashed with SHA1 first, resulting in a SHA1 hash. The resulting SHA1 hash then goes through SHA256 and the last step the SHA256 hash is put through MD5. So the final result of this example algorithm would be a 32hex hash. You can imagine the algorithm written like:
In some cases just applying hash algorithms, one after the other might not be flexible enough to build a particular hash algorithm. Let’s take an example where we have two hashes put together before the final hashing algorithm:
In this case we need the brackets, otherwise, it’s not clear in which order the hash algorithms should be applied. The first SHA1 and MD5 are just put together before being hashed with the second MD5.
Let’s imagine we have someone just hashing a password N number of times with a certain algorithm. We now have to write an algorithm applied 100 times:
MD5MD5MD5MD5 … (tired of typing) … MD5
This is not very user-friendly to enter. So there is an easier solution, you can supply an algorithm and multiply how many times the algorithm is applied:
The iteration count is bound to the hash algorithm and is applied first (before combinations).
In the example above the SHA1 is applied 10 times and after those 10 times, the result is hashed with MD5 one single time.
On occasion, we find hashes that are reversed. This means the hash
is, in fact, an MD5
So, Hashes.org allows you to reverse hashes. The above example would then just have the algorithm
This does not necessarily have to be the last operation. In combinations of algorithms you can apply reversing in between algorithms and multiple places within the algorithm string:
Hashes.org always hashes to lowercase on hex hashes. If you have an algorithm which requires the hash to be uppercase inside the combination like:
MD5(“hashes.org”) -> 88e54e471cd6971e426f2a9e047ea9f1
To uppercase -> 88E54E471CD6971E426F2A9E047EA9F1
MD5 again -> e81af6cd8ef6fb1ebfa41ae18e5d5344
The final hash algorithm can now be represented with the “UC” option of Hashes.org
UC is not allowed at the end and the beginning of the algorithm.
Some hash generation routines modify the hash by shifting characters of the resulting hash by N number of positions.
MD5(“hashes.org”) -> 88e54e471cd6971e426f2a9e047ea9f1
For example, shift the hash by 4 positions:
88e54e471cd6971e426f2a9e047ea9f1 -> 4e471cd6971e426f2a9e047ea9f188e5
Hashes.org allows you to use ROTn to give a number (N) between 1 and length-1 to rotate a hash. N chars are then cut from the left and appended on the right.
ROT4MD5(“hashes.org”) -> 4e471cd6971e426f2a9e047ea9f188e5
If you have for example the following hash:
It looks like an MD5, but you will not be able to crack it as MD5, because it’s a SHA1 with the last 8 chars cut off:
SHA1(“hashes.org”) -> 2e6af2e7867840f858f3c2bb535ede10a3494c07
On Hashes.org you can use CUTn-m to specify where to cut the hash to create a substring of the hash given. N gives the start position (starting with 0) and M the length to cut.
CUT0-32SHA1(“hashes.org”) -> 2e6af2e7867840f858f3c2bb535ede10
CUT is not allowed to be applied to the plain directly. Two CUTs after each other are not allowed.
The difference between MYSQL5TOT and MYSQL5 is the MYSQL5 hash is given in lowercase and without the * character, MYSQL5TOT returns it in the default format with uppercase hex chars and prepended *:
MYSQL5(“hashes.org”) -> ed774bd2024eeac679886d504c6b5047e1e17c96
MYSQL5TOT(“hashes.org”) -> *ED774BD2024EEAC679886D504C6B5047E1E17C96
Is listed as basic algorithm even if it’s not really a hash algorithm but, it can be used just like all the other hashes. It’s also possible to apply it multiple times if required.
Outer loops can be difficult when combined with some other algorithms. We will start with a basic example:
This simply applies MD5SHA1 to the plain 50 times. Imaging this algorithm written out, it would be a string of 350 characters.
Brackets are important
Let’s compare two algorithms now, which look pretty similar, but differ in an important way:
So, the first algorithm takes the plain, hashes it 15 times with WRLNTLM (Whirlpool and NTLM), then for 20 times with MYSQL3MD5. This results in:
The second algorithm does 15 times only NTLM, then applies Whirlpool once before it’s also hashed 20 times with MYSQL3MD5. The result, therefore, looks different then: