Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 27 Feb 2018 16:35:22 -0500
From: Ian Boyd <>
Subject: Re: dmg file with lost password

HI Alexander, 

Thanks for the “out of date” information about building JtR from source, I abandoned my attempts once I found Johnny. :)

>> 2. Using Johnny, and trying to figure out how to crack one password for my .dmg file. This program makes it easier to work with, but are there any helpful tips on who to use to crack one file?
>> 	When I think I scan the file properly i get a "Warning: invalid UTF-8 seen reading??? and the computer stalls at 57% 
> It's hard to help you with this without knowing exactly how you used
> Johnny and what else it outputs besides that warning and the 57%.
> As Claudio correctly pointed out, you should have started by using
> dmg2john.  You can probably do this from Johnny itself, using the dialog
> shown on this screenshot:
> I guess you need to choose dmg in the "Choose file format" drop-down.
> Please confirm that you did this (or if not, do it) and please also show
> us the full output from JtR (copy-paste from a Johnny window).
I believe I did get Johnny to work using the dmgsjohn. file and chose the dmg for the file format in the drop down.
The program has currently been running for a total time of 2:17:48:33 and has worked through Single rule, Wordlist rule, and has been working on incremental rule for some time. But it’s my understanding that incremental typically takes the longest time. Is this correct?
Can this process take a long time?

> In our off-list discussion, I wrote that "In our experience with
> forgotten passwords to .dmg files, failure is more likely than success"
> and you asked "Why are dmg files usually unsuccessful to crack?"  I'll
> answer here: Apple has made the "key derivation" step (deriving an
> internal encryption key from a user-entered password/passphrase)
> purposefully computationally expensive (slow).  This is an industry
> standard thing to do, and Apple did it right (although in more recent
> years even more expensive key derivation methods have been designed).
> Without specialized hardware (ASICs, which some three-letter agencies
> probably have, but we don't), JtR is only able to test a few thousand to
> maybe 10 thousand candidate passwords per second per GPU, against a dmg
> file generated/protected on a recent version of OS X.  (For ancient
> versions, speeds may be 100 times higher.)  This means that a user might
> realistically test, say, a billion of candidate passwords before giving
> up (this might be a day on the latest high-end GPU, or a few months on a
> laptop/desktop CPU - but exact times may vary greatly).  And that's just
> not enough to crack a semi-strong password/passphrase unless quite some
> information about what it can vs. cannot be like is known (can be
> recalled and input to the program).  Of course, the weakest passwords
> (such as those within the top few million of common passwords) can be
> cracked anyway, but when people ask for help it's unusual for their
> forgotten password/phrase to be a common one (although this happens).
Thanks for this information, I have a better understanding of why this process takes so long. It helps a lot.

You have been really helpful in this process and I really appreciate all this information and guidance. 

All the best, 

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ