The answer/thread you linked to stated (regarding the brute force tool):
Practically, this will bring you absolutely nowhere, unless the .dmg was encrypted with an extremely naive password (like 'admin' or '1234').
Unfortunately, based on your description of the passwords:
I don't know the first 38 characters but I do know what they might be (a-z, A-Z, / and )
it appears that you are not in the situation where the password is naive or trivial.
Rather, you are going to have to try to brute force
(26+26+2)**38 = 677583580243194174785518969776514402284639204793077421485626228736
different possible 38 character prefix combinations.
Even if you were using millions of state-of-the-art processors to perform the brute force attack, it would still take longer than the lifetime of the universe... So, the linked-to brute force attack will not work for you.
The OP has updated the question with much more information about the 38 character prefixes. The additional information greatly increases our knowledge of the potential passwords. In particular:
The 38 unknown characters are words.. .All words begin with a capital letter followed by only lowercase... Minimum length of the words is 3 characters and maximum length is 8. The password only has four possible starts... The password only has two possible ends
OP goes on to state:
This leaves brute forcing either 21 or 20 characters depending on the possible start
The OP's above statement above brute forcing up to 21 characters is (happily) not correct assuming the OP's previous statement "The 38 unknown characters are words" is true.
It is much more difficult to brute force 20 or 21 characters than to brute force sets of words that add up to 20 to 21 characters.
The key point here is the words are not just random strings of characters and this fact greatly decreases the "entropy" of the passwords.
In order to take advantage of this fact we need a word list of potential words OP would have used to construct the passwords. Luckily these word lists exist. If we know that OP would have only used very common words we can probably get away with a list of a few thousand words (maybe less). But, if OP might have used more obscure words, the list will probably be a few tens of thousands of words long.
The fact that the first letter of each words is capital and the rest are lowercase does not increase the entropy at all, since there is no choice being made.
To estimate the entropy and the difficulty of brute-forcing, let's assume that the words were selected from a list of 10000 words. And let's further assume the average length of unknown word is (3+8)/2 = 5.5 characters.
Thus, contributing factors to the entropy are:
- Four (4) possible starts
- Two (2) possible ends
- Approximately (10000)**3.23 = 8,317,637,711,027 possible infixes
- Approximately (2)**3.23 way to choose "/" or "\" to divide the infix words
In step three, I have assumed there are approximately n=3.23 "words" on average in the password infix. This number came from the fact that if there are "n" words in the infix then there are also "n" "\" (or "/") characters and thus (assuming 21 characters rather than 20):
n = 21/(<len(w)> + 1) = 21/(5.5 + 1)
The details of the above-described approximation don't really matter much, but it's useful to try and get an order-of-magnitude approximation. In practice, what one would probably do is write a sub-routine to construct the infix by iterating through all the words in the word list multiple times and concatenating words and "/" or "\" until the infix is 20 or 21 characters and then break/return.
So, in all, the total number of combinations is approximately:
Which is still a large number of potential passwords, but much more manageable than before.
In order to construct a program that brute-forces theses passwords one must "simply" (in practice it will take a bit of work) construct a program that iterates through the four types of choices stated above to choose concrete realizations of the passwords that conform to the conditions.
Assuming you can try something like 100000 passwords a second, this method will still take about 200 years, but it is a great improvement over the previous method.
The greatest contribution to the number of passwords comes from the assumption that the word list is 10000 words long. If there is any way to further reduce this based on your prior knowledge then you made be able to brute force these passwords in a reasonable amount of time. For example, basic english words lists are only about 800 words long. If we can assume basic english instead of 10000 word english then the number of combinations is only:
Which you might potentially brute force in a few hundred hours if you can try 100000 passwords a second.
Per the comments:
The total amount of cracking time clearly depends on the number of attempts you can make in a given amount of time.
I have assumed, based on not much else than the desire to put down some concrete numbers as examples, that in the OP's latter case the number of attempts per second is 100000.
If the number of attempts OP can make is different from this, then the total cracking time will scale accordingly. The scaling of total time with number of attempts per second is linearly with the inverse of attempt time. For example:
total_time_in_days = number_of_combinations/number_of_attempts_per_second/60/60/24