I encrypted a folder and forgot to save the password.

I remember how long I made the password (40 characters)

I know the last two characters (40)

I don't know the first 38 characters but I do know what they might be (a-z, A-Z, / and \)

I've come accross this thread that might help but I am having trouble modifying it to my specific problem.

Edit: 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. This does not mean there is a word with 8 characters but that there will not be a word with more than 8 characters.

Three of those words are [Dark, Sun, Orange].

There are no repeating words. Except possibly for the word "Dark".(I am not sure if I used it once or twice in the password).

All the words are separated with either / or \. The slashes alternate. So if / was used then the next slash will be \. The slashes are used only to separate the words. So if a slash was used the next character will not be a slash.

The password only has 4 possible starts

Dark/Sun\ or Dark\Sun/ or /Dark\Sun/ or \Dark/Sun/

The password only has 2 possible ends

/Orange\40 or \Orange/40

This leaves brute forcing either 21 or 20 characters depending on the possible start

  • Sorry, bob. You will not be able to recover this password using the method suggested in the thread you linked to.
    – hft
    Commented Jun 11, 2019 at 2:23
  • Are the 38 unknown characters a random selection from [a-z, A-Z, /,\ ], or was it made up of words found in a dictionary (or modified words)?
    – Johnny
    Commented Jun 11, 2019 at 18:03
  • @Johnny The 38 unknown characters are words. For example three of those words are [Orange, Dark, Sun] Each starting with a capital letter and separated with either [/or\].
    – bob100
    Commented Jun 12, 2019 at 7:54
  • Well that's very important information! Update your question with all the information you have about the password — e.g., will the words have a minimum or maximum length, etc
    – Johnny
    Commented Jun 12, 2019 at 13:11
  • Ha. Yep, that is a very important update.
    – hft
    Commented Jun 12, 2019 at 16:09

1 Answer 1


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:

  1. Four (4) possible starts
  2. Two (2) possible ends
  3. Approximately (10000)**3.23 = 8,317,637,711,027 possible infixes
  4. 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 
  • It's a fine answer, but you can't really arrive at any sort of reasonable time guess unless you can give a better answer for the password guess/second. This varies by many orders of magnitude depending on how the software was written, and how large of a cracking rig you have. Commented Jun 12, 2019 at 17:49
  • In the latter case of a passwords comprised of words, I've explicitly stated my assumption about how many passwords can be tried per second (100000). This is, of course only an assumption and will be different if, say, the OP has access to a million AWS instances or something. In the former case of 38 characters chosen from (26+26+2) possibilities, the number of combinations is so large that any reasonable choice for the number of attempts per second (regardless of whether or not the OP has access to all the computers and rigs in the world) still results in astronomical cracking times.
    – hft
    Commented Jun 12, 2019 at 18:26
  • I've updated the answer to state that total time scales as the linear inverse of attempt time (given fixed number of combinations to try).
    – hft
    Commented Jun 12, 2019 at 18:30
  • My comment about passwords/second was more aimed at your number, which might be ridiculously high, or ridiculously low. For comparison, the rc5 project at distributed.net gets around 20 million passwords/second on a high end Athlon X2, Since this is roughly 200 times faster, that brings the break time down to just 1 year. The algorithm used isn't specified, but encryption algorithms have somewhat similar processing requirements. It could also be much to high if a strengthening techniques like iteratively hashing the password with the previous hash, done 100,000 times. Commented Jun 12, 2019 at 19:27
  • So the point is more that you don't need "all the computing power in the world", but you do need a good estimate about how much computing power you have, and what the computing power will produce. Commented Jun 12, 2019 at 19:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .