Extracting and cracking MacOSX SHA512 passwords

Long story short, I love my fiance though she may be somewhat lacking in the technical area. She’s got a work-issue laptop with a built-in “Administrator” account that has locked down parts of the machine we want access to. So how to get in?

A nice post on apple stackexchange here helped me understand how the password encryption works on the backend (it’s SHA512), as well as rip out a pretty plist file with the hashed password data and get it ready for cracking. From there I’ll use my favorite cracker hashcat to break the actual password.

I’ve already been able to create a sudo-able account on this machine (this I finagled some time back when one of the “tech support guys” was helping us out and he made a little mistake). Outside of the scope of this article, but if you don’t have a sudo locally you might be able to boot into single-user mode which will give you root by powering off your machine and holding down command+s as it boots back up.

Back to attacking the hash- what I need are the three essential parts of the SHA512 hash:

All of these are stored in the users’s ShadowHashData, so, I just sudo -i to get a root prompt and pull the ShadowHashData this way:

thebox:~ root# defaults read /var/db/dslocal/nodes/Default/users/administrator.plist ShadowHashData > hexcode

This returns a big hex chunk of data to hexcode which, with a bit of prodding, will give me all three magic bits needed to run a dictionary attack on the password:

(<62706c69 73743030 d101025f 10145341 4c544544 2d534841 3531322d 50424b44 4632d303 04050607 0857656e 74726f70 79547361 6c745a69 74657261 74696f6e 734f1080 3d912bed 387aab30 ad2ce4b4 c37aefa0 3d7dbee0 5ffd0c03 e279674f 60491429 d31303d3 67f1f644 12611459 08e35c41 a9cce934 d394e092 683928b5 b827859d 8b5c8c7f 772b2bc9 b8592987 bfc8b6b5 15476922 f6878ffc ced141b6 1118d173 38f2adc0 0bad4ddb 182b0977 8aeeed1e e4ed479e 8b79d38d 855b5d95 841cbdc4 4f10200a 20f6e408 ad8596ed 4243fc07 75e07d28 aacdd29d fa4ad3e6 3fb3dfd4 08ab0311 7b39080b 22293136 41c4e700 00000000 00010100 00000000 00000900 00000000 00000000 00000000 0000ea>)

First we strip that down to the useful parts using some cli manipulation:
cat hexcode | tr -dc 0-9a-f > trimmed

which gives us a file, trimmed, that looks like this:


next, we need to take that hex and turn it into incomprehensible binary.

The nuances of this and the next step escape me somewhat, as I’m not yet familiar enough with OSX and/or cryptographic schemes in general to understand the under-the-hood workings. I can only assume that the hexdump and it’s binary format are intrinsic to the process, and treat them as a black box. To get the binary version into a new file, hexbin:

xxd -r -p trimmed hexbin

Once you’ve got those bits, you can run another neat little OSX native command to make a human-readable plist:

plutil -convert xml1 hexbin -o admin.plist

And voila, finally getting something we can work with in admin.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">


With this we have an iteration integer, and, in base64 again, the entropy and salt values.

Remember, our end goal is to get a hashcat readable hash that I can let my machine run amok against with a password list of some sort. We’re here now:


salt in b64: CiD25AithZbtQkP8B3XgfSiqzdKd+krT5j+z39QIqwM=
entropy in b64: PZEr7Th6qzCtLOS0w3rvoD19vuBf/QwD4nlnT2BJFCnTEwPTZ/H2RBJhFFkI41xBqczpNNOU4JJoOSi1uCeFnYtcjH93KyvJuFkph7/ItrUVR2ki9oeP/M7RQbYRGNFzOPKtwAutTdsYKwl3iu7tHuTtR56LedONhVtdlYQcvcQ=

So, for our purposes we need to convert those b64 salt and entropy values out of b64 and into their original binary format. Furthermore, we need them in hex to be able to work with them.
Let’s quicken the pace and do it in a single command for each:
echo CiD25AithZbtQkP8B3XgfSiqzdKd+krT5j+z39QIqwM= | base64 -D | xxd -p | tr -d \\n > salthex
echo PZEr7Th6qzCtLOS0w3rvoD19vuBf/QwD4nlnT2BJFCnTEwPTZ/H2RBJhFFkI41xBqczpNNOU4JJoOSi1uCeFnYtcjH93KyvJuFkph7/ItrUVR2ki9oeP/M7RQbYRGNFzOPKtwAutTdsYKwl3iu7tHuTtR56LedONhVtdlYQcvcQ= | base64 -D | xxd -p | tr -d \\n > entropyhex

this gives me a salt hex of 0a20f6e408ad8596ed4243fc0775e07d28aacdd29dfa4ad3e63fb3dfd408ab03
this gives me and an entropy hex of 3d912bed387aab30ad2ce4b4c37aefa03d7dbee05ffd0c03e279674f60491429d31303d367f1f6441261145908e35c41a9cce934d394e092683928b5b827859d8b5c8c7f772b2bc9b8592987bfc8b6b515476922f6878ffcced141b61118d17338f2adc00bad4ddb182b09778aeeed1ee4ed479e8b79d38d855b5d95841cbdc4

Now I can complete my hash string:

I write this to a little file, let’s say “machash” and fire up hashcat, specifying hashtype 7100

Targeting whatsapp with wireshark

Why would I want to snoop WhatsApp traffic?

I’m aiming at the moment is to create a “whatsapp alarm” that will inform me and keep a log of when someone I’m stalking comes on and off of whatsapp. An app that used to do this for me what WhatsDog (http://www.appszoom.com/android-app/whatsdog-whatsapps-watchdog-kgyke-download.html) but for whatever reason this doesn’t work anymore. *update, it seems to be working now, might be worth a gander at the code to see how they’re doing this.

Creating a test-bed

I managed to get Android running on a VirtualBox instance using this great guide: http://www.fixedbyvonnie.com/2014/02/install-android-4-4-kitkat-windows-using-virtualbox/. If you’re using that guide make sure you enable virtualization at the BIOS level on your machine else you’ll get a kernel panic, as I did.

I quickly discovered that Whatsapp is using some combination of xmpp and encryption to transmit, so I’ll need to pull some shenanigans to be able to interpret the messages I catch going across the wire. I began with the ill-advised route of attempting to peek at their code and seeing what I could learn from it. In short, not much, but I learned a lot about other things along the way.

Decompiling and re-compiling apks

Using APKTool (https://code.google.com/p/android-apktool/) I was able to decompile their APK into smali and Java, which is great! Sadly though, the good bits of the decompiled code are heavily obfuscated and I’ve wasted a few hours trying to decipher it with no gains. Just looking at the code isn’t enough. If only I could debug it?

Debugging decompiled smali

It seems that this is possible, and there’s a nice link from the apktool page that talks about setting up smali debugging (https://code.google.com/p/android-apktool/wiki/SmaliDebugging). I followed this lead and looked around a bit to get it working with my VirtualBox machine. Specifically, a page from MatD gave me a solution that hooks my VirtualBox machine to my Windows PC:  http://www.mat-d.com/site/developing-android-apps-with-android-x86-and-virtual-box/. Hint: Use a bridged adapter for debugging! Hint 2: For those of us who aren’t native to linux, netcfg is the linux equivalent to winipcfg.

Based on the fact that I hadn’t found anyone who’d been successful in deciphering this madness, I moved on to attempting to MITM their https traffic. I’m just dicking around at this point.
Sadly, I lost patience trying to get my smali debugging doing something usefull, so moved on to look for other options.
  • A bit of googling taught me that whatsapp communications are encrypted via SSL. What a pain. To find this traffic with wireshark I can make a simple filter: (http contains whatsapp)
  • Other sources: This interesting article from 2012 authored by Wolf (http://werew01f.blogspot.com/2012/05/can-you-extract-message-and-photo-from.html) that describes an exploit that could be used to snatch images in the past.

MITM SSL Traffic

It turns out that this is pretty fucking difficult. I’m going to spend some time researching around the web because *surely* someone has managed to pull this off already. I know my job is doing it. Grabbing the Session ID First I need to find whatsapp traffic through wireshark. After a bit of trial-and-error I did track down some communications between my droid box and some whatsapp and whatsapp-related servers. The whatsapp servers that any one phone communicates with sure can bounce around a lot though. Why does this happen?

DNS Lookups

First of all, the randomness of the servers utilized by the whatsapp application is a result of the DNS lookups constantly shifting to create load balancing. I didn’t even know it was done like this in the real world, not a bad idea. They submit a name table so that when someone queries for one of their named boxes they may or may not get a different box.

More on SSL

Apparently, SSL connections are based on a session that gets cached on the server and can be handed back over to the client when they log back in. This explains why it’s hard to monitor someone’s whatsapp messages remotely. I might look into that later. Other interesting notes If you restore whatsapp via titanium and include the app data from a previously working instance, the whatsapp servers appear to be none the wiser. You may receive some message overlap, but eventually they figure out two devices are getting the same messages and your new device controls the account, knocking off your old one. If you try to use the old device it will work but knock the new one offline. This was interesting to me because it seems to invalidate various rumours that I’ve read around the net that the app somehow fixates on your MAC or device ID to validate your connection. I’ve backed up several different phone numbers into a spare real phone I have, as well as the emulator box and watch them trade control of my account all day.