Sparsebundle support for DMG

[magnumripper]

@kholia @mledford we have a user in desperate need for sparsebundle. See http://www.openwall.com/lists/john-users/2014/02/21/1

Do we know what is missing? Is this a lot of work?

[magnumripper]

Some info in #359 and another cc: @alienjizz

[kholia]

@mledford added sparsebundle support in commit 6262fd43157a182d6b98f489e2910e76c5f00c74, right?

What are we missing here? Which OS X version is this? Can we get some dummy sparsebundle samples?

[magnumripper]

6262fd4 added sparseimage support, not sparsebundle. I think they are slightly different. @alienjizz seemed to get really close in #359.

[magnumripper]

Samples: https://github.com/alienjizz/UDIF

Also, quoting @alienjizz "As a matter of fact I believe the samples you have up at https://github.com/kholia/VileFault/tree/master/tests are the same as a .sparsebundle created by Disk Utility. (the first four files)"

[magnumripper]

@gat3way did you by any chance fix sparsebundle support in Hashkill lately?

[gat3way]

Hello,

Not yet...unfortunately, not much time.

On Fri, Feb 21, 2014 at 10:03 AM, magnum notifications@github.com wrote:

@gat3way https://github.com/gat3way did you by any chance fix sparsebundle support in Hashkill lately?

Reply to this email directly or view it on GitHubhttps://github.com/magnumripper/JohnTheRipper/issues/511#issuecomment-35706610 .

[mledford]

I'm pretty swamped at the moment. However, I'll look over everything today and see what it might take to get it done and let you know.

[mledford]

@magnumripper I think I have a good grasp on getting sparsebundle support going. I don't think it will be overly difficult to implement—hopefully. Let me try and set aside some time to work on it. I'll keep you updated.

[magnumripper]

Awesome, thanks!

[jeff-keller]

@mledford you'd be my hero if you can get this working. I've got 17+ years of photos on that drive that I need back. Happy to donate to the cause if it helps crack open that sparsebundle.

Thanks- Jeff

[alienjax]

As mentioned in https://github.com/magnumripper/JohnTheRipper/issues/359 the solution is very simple, until this issue is fixed you can always do it manually!

You need to join the token file (inside the package) with the first band (inside the bands folder within the package) and open the resulting file with a hex editor and enter 7E2200 starting at byte 0x3C, then process it with dmg2john.

[jeff-keller]

Ohh, thanks - will try this when I get home!

On 02/21/2014 12:34, alienjizz wrote:

As mentioned in #359 [1] the solution is very simple, until this issue is fixed you can always do it manually!

You need to join the token file (inside the package) with the first band (inside the bands folder within the package) and open the resulting file with a hex editor and enter 7E2200 starting at byte 0x3C, then process it with dmg2john.

Reply to this email directly or view it on GitHub [2].

---

Jeff Keller Senior Writer, dpreview.com

Links:

[1] https://github.com/magnumripper/JohnTheRipper/issues/359 [2] https://github.com/magnumripper/JohnTheRipper/issues/511#issuecomment-35770643

[mledford]

@magnumripper @jeff-keller I just finished implementing the functionality and testing it. I have to break away from the computer for a little bit. As soon as I can I will commit it.

[mledford]

@magnumripper @jeff-keller Pull request for sparseimage support in #513.

[jeff-keller]

You are a wonderful human being. @magnumripper do I download again and recompile?

[mledford]

@jeff-keller If you want to download it right now you can head over to my fork and download from the sparsebundle-support branch found here. https://github.com/mledford/JohnTheRipper/tree/sparsebundle-support

Or you can wait for @magnumripper to look over the patch and merge it into the main repository.

I wish you luck!

[jeff-keller]

@mledford I think I'll wait. I barely know what I'm doing as it is :)

[magnumripper]

Stay put, I'll merge it asap

[magnumripper]

Merged now, will start testing with various images.

[magnumripper]

Works like a champ. Hopefully it will work with a 550 GB drive too. I recall we made some fixes a while ago for that.

@jeff-keller note that if you can run this on some machine(s) with high-end OpenCL GPU (and using --format:dmg-opencl), it will be a lot faster.

Excellent work @mledford!

[mledford]

@magnumripper My pleasure!

[jeff-keller]

@magnumripper I've got a late-2013 iMac with 3.5Ghz Core i7 and GTX780M graphics. What options should I put in for that?

And just to confirm, I still need to run dmg2john, right?

Thanks!

[magnumripper]

OK here's what you should do:

1. edit Makefile line 36, uncomment OMPFLAGS = -fopenmp
2. make -s clean && make -sj8 macosx-x86-64-native-opencl

Then try it out with ../run/john --test --format=dmg-opencl and see if Apple failed to screw up this time. It works fine on my MBPR with GT650M so it will most likely work fine on your gear.

And yes, you run dmg2john to get a "hash file" that you give to john.

[mledford]

@magnumripper This is a bit off topic but I noticed that there is a python version of dmg2john but it hasn't been updated with any of the new functionality from the previous commit or this commit. I'm not saying that I will do it :) but are those to be kept up to date as well? Or is the C version primarily what is used?

[kholia]

@mledford I have been super lazy lately. I have been hiding, hoping that someone will come along and update dmg2john.py.

[jeff-keller]

Okay, we're getting somewhere now. but first, I followed the instructions from @magnumripper and got these results:

on make: clang: warning: argument unused during compilation: '-fopenmp'

on run: -bash: ./run/john: No such file or directory

If I don't uncomment it, it compiles (with a few warnings) and I think I was able to extract the hash using dmg2john.

When I do the test mentioned above, I get this:

Jeffs-iMac:run jakeller$ ./john --test --format=dmg-opencl Device 1: GeForce GTX 780M Local worksize (LWS) 64, Global worksize (GWS) 9216 Benchmarking: dmg-opencl, Apple DMG [PBKDF2-SHA1 3DES/AES OpenCL]... Warning: salt() returned misaligned pointer DONE Raw: 17066 c/s real, 24576 c/s virtual

Am I getting somewhere?

Thanks, Jeff

[jeff-keller]

Oh and this is what I try to do when running it:

Jeffs-iMac:magnumripper-JohnTheRipper jakeller$ ./run/john --format:dmg-opencl --wordlist=wordlists/all.lst hash Device 1: GeForce GTX 780M Local worksize (LWS) 64, Global worksize (GWS) 9216 Loaded 1 password hash (dmg-opencl, Apple DMG [PBKDF2-SHA1 3DES/AES OpenCL]) Warning: salt() returned misaligned pointer Press 'q' or Ctrl-C to abort, almost any other key for status

It never seems to get anywhere :(

[jeff-keller]

if I leave it alone for a while this pops up: GPU hang occurred, msgtracer returned -1 Abort trap: 6

[mledford]

@jeff-keller Try compiling using the following...

$ make -s clean && make macosx-x86-sse2-opencl

$ ../run/john --test --format=dmg-opencl

[jeff-keller]

@mledford thanks for that, no errors this time when testing:

jeffs-imac:magnumripper-JohnTheRipper jakeller$ ./run/john --test --format=dmg-opencl Device 1: GeForce GTX 780M Local worksize (LWS) 64, Global worksize (GWS) 9216 Benchmarking: dmg-opencl, Apple DMG [PBKDF2-SHA1 3DES/AES OpenCL]... DONE Raw: 15233 c/s real, 21186 c/s virtual

[jeff-keller]

Still getting the GPU hang error when I run it on anything but a tiny wordlist.

edited to add: on a small wordlist (password.lst from the big package) it works. if you have --rules in there it does not. if I do the all.lst wordlist it just hangs.

[mledford]

@jeff-keller I'm afraid I'm about to be not very useful. I'm not knowledgable enough in the workings of john and its configuration. But, maybe while waiting to hear from others going somewhere is better than going nowhere. So maybe you should compile without OpenCL for now and see how that goes.

$ make -s clean && make macosx-x86-64

Find out how many cores your machine has and replace the X after fork with that number.

$ ./run/john --fork=X --format:dmg --wordlist=wordlists/all.lst hash

[magnumripper]

Sorry I've been busy. The GPU hang can most likely be fixed by lowering GWS. You can do that by prepending each run with "GWS=xxxx", eg:

$ GWS=8192 ./john -form:dmg-opencl hashfile

(first '$' being the prompt).

Like @mledford says you can use --fork since your compiler apparently doesn't want to build OMP. But this is only applicable for --format:dmg, not --format=dmg-opencl - if you try to fork several processes using same GPU card it will probably not end up well.

Once you find a GWS that doesn't hang your GPU, you can run one OpenCL session (without fork) in one console window, and one CPU session (using --fork=7 if you have 8 cores) in another console window. Obviously using different attacks, eg. different wordlists.

[magnumripper]

@mledford the Python version is for people to use without building anything, just for producing a file to pass on to someone else. So eventually it needs to be in sync with the C version.

[magnumripper]

@jeff-keller my laptop GPU seem to like a GWS as low as 256 for this hash. You have some more power so maybe 512 will work as well. When you press space for a status line, if it doesn't react in 10 seconds, ctrl-c twice to cancel, halve the number and re-try.

[magnumripper]

Followup: @jeff-keller was kind enough to reveal the password to me so I could verify what the decrypted blocks looked like. They are almost entirely made of zeros and the alternate block is a partition map. As long as I don't hear any report of a false negative, I will assume the current code and "known plain" tests are just fine. Good stuff.

Though it would have been much better publicity if we actually cracked his password before he found it :laughing: