Month: December 2019

(Note: Everything below is evil and should only be used to access data you are legitimately allowed to access. Also, while TV makes things look cool and easy, hacking someone’s macOS password is likely to take a very long time and should only be attempted if you’re comfortable with breaking your computer quite badly. Your Mileage May Vary. Do Not Feed The Dog. You get the idea…)

(Additional note: I’ve had some feedback from some nice people at Apple that the original version of this article was more of a hacking how-to than they were strictly comfortable with, so this has been edited to make it clear that the mechanics of trying to hack a macOS login password are messy, haphazard and extremely time and effort-intensive. And very easily defeated if you employ some of the built-in tools.)

I love watching “Mr Robot”. Not just because of Rami Malek’s extraordinary acting and weirdly hypnotic bug eyed monologuing (although that never gets old) – no, I love it for the same reason that a lot of people in my trade love it; because it tries very hard to stick to the actualities of computer and network securities and most of the time it does an excellent job. Sure, they fudge it a little here and there for the sake of the plot, but in general if our protagonist is going to do some particularly clever piece of hacking then what they show you on the screen will be at least broadly accurate.

My wife and I were watching a recent episode in which our Kali Linux-loving hoody-wearing pal was trying to hack into a Mac, and I spent the whole sequence grinning like an idiot. “Wait, is that possible?” my wife asked. “He just hacked into that Mac. I thought Macs were unhackable?”

And therein lies the rub. The old adage was that the only real security is physical security, and as long as your device is accessible there’s always a way in. These days – with modern advances like the T2 chip and Secure Enclave – that’s starting to look less like an absolute and more like a general rule that has the occasional exception.

If you’ve done any of the elementary things you can do to secure your Mac (Filevault, used the Startup Security Utility to limit external boot, put a firmware password in place) then you’re in good shape and your Mac is (at least as things stand right now) safe from miscreants and TV hackers.

Still, for fun, I thought I’d replicate the broad strokes of what our hero did to hack a macOS login password and gain access to an account on that Mac. Oddly enough, life mirrored art in that a week after figuring this all out I was contacted by a client who had an employee leave under strained circumstances and who had changed the login password on an important computer and then “forgotten” what they’d changed it to.

First we’re going to take it that you’re sat at a Mac that nobody has made any attempt to protect. No biometric precautions, no firmware password, not even Filevault. If you’re sat at the Mac login screen then you are – by default – presented with a list of users and a field for the password for that user. If you don’t know the password then you can get a hint, but let’s assume that when the target set up their Mac they made that hint either wildly inaccessible or just left the field blank. Without that password it’s impossible to get into the account in any meaningful way; sure, if you have an external bootable drive and you’re not dealing with a Mac that’s been set up to disallow external booting (and you know what you’re doing) then you can get some access to files, but passwords and protected data is off the table.

So, what do you do? Well, first things first; you make yourself an account on the machine with full admin privileges to do so:

• Boot into recovery by holding down Command-R

• In the Terminal, turn off SIP by typing in csrutil disable

• Reboot into Single-User mode by holding down the s key

• delete /var/db/.AppleSetupDone, then reboot.

The computer now thinks that it’s a brand new device and prompts you to create an account which will be – because it thinks its a new device – an account with full administrator privileges.

Congratulations! Now you have an account on the computer and can perform further mischief. At this point you could change the password on the account you want to access and be able to log in, but that would blow out the keychain password and you wouldn’t be able to get any other credentials or passwords off the thing – and you certainly wouldn’t be able to cover your tracks so that the legitimate owner of the machine wouldn’t know you’d been tinkering around.

No, to really give them a bad day you’ll need to find where the OS keeps the encrypted hash of their password and then throw that into something that’ll brute force it into submission.

As of macOS Catalina, password hashes for local accounts are kept in /var/db/dslocal/nodes, so once you know the name of the account you’re trying to access (for the sake of argument we’ll call it “test”) you’ll need to copy that users’ plist to some place where you can get at it, thus:

sudo cp /var/db/dslocal/nodes/Default/users/test.plist ~/Desktop

That gives you a file called test.plist, which contains all sorts of data that the OS stores relating to that user’s authentication on the computer. That file will still have the default permissions on it, so you’ll need to Get Info on it and add yourself as a user with read/write permissions to go further with it. The password for the account is stored in a hash that you can get out with an assortment of tools, but I like to use plist2hashcat, so download it and use the terminal to change to its directory to run the command thus:

sudo python plist2hashcat.py ~/Desktop/test.plist

It’ll spit out the hash it pulls from that file, which will look something like this (note – example hash, not a real one):

$ml$34602$964ef09ca051dcfca85bc4b733ef70aef3cbe294db43cb0f2efcfdfc8f140f8d$acf35221b0e1bc4097db1d919c13839bbe2c4712044ecd4daa2c3803798a57179269e99ee745ad592614426e3a955695198f3581f8cd467d29ef073325ae408a

Copy that to a file called, I don’t know, say, test_hash.txt on your Desktop.

Finally, you’ll need some way to brute force that hash against a list of passwords (and a list of passwords to use). There are many, many sources for passwords out there and I’m not going to link to them because a lot of them are taken from actual data breaches and there’s a fine line between an academic discussion of how a thing can be done and pointing people at resources to engage in criminal conspiracy. Suffice to say that there are sources out there, and that I have a passwords file that I’m going to call passwords.txt and put it on my Desktop along with test_hash.txt. We’re also going to need a place to dump the finished file, so let’s create a directory at the root level of user folder called pots, thus:

mkdir ~/pots/

Next, we’ll install hashcat. I like John The Ripper too, but hashcat is light and easy and relatively flexible, and besides, I think that’s what Eliot used. Download it, install it, then cd into its directory and type the following to tell it to select the test_hash file, pull from that dictionary file and dump the results into the pots directory:

sudo ./hashcat -a 0 -m 7100 ~/Desktop/test_hash.txt ~/Desktop/passwords.txt -w 4 --potfile-path ~/pots/result.pot

This will take – depending on the complexity of the password and the size/scope of the dictionary file – a while. And by “a while” I mean somewhere from light lunch to come-back-tomorrow-morning. Further, it’s in no way a slam-dunk certainty that you’ll get anything useful out of it, and while it looks cool on TV it is a moderately miserable experience in real life. It will, however, eventually spit out a password if you’re lucky (note: the password it found for Mr Test was test1, because I guess he/I wasn’t feeling that creative).

And really, what does it get you anyway? Access to the user’s keychain is handy, sure, but if you’re after files locked away in a user account there are far simpler and faster ways of getting access to those files that don’t require downloading and compiling a bunch of python scripts and trawling around some of the sketchier bits of the web for lists of hacked passwords.

And it’s readily defeated, too. When you set up a new machine you get the option to turn on Filevault – and you should absolutely do that (and you can do it afterwards at any point from the Security & Privacy Preference). Further, with T2 protected machines there are protections in place to prevent booting from external drives, which makes attempting to use another drive to boot into the machine pretty much impossible.

This is one that – except in very fringe cases – is either extraordinarily time consuming or woefully impractical. Looks good on TV, though…

This is almost by way of a followup on last week’s update.

If you’re like me (and I’m assuming for the sake of argument that you and I are functionally identical in our interests and peccadilloes), you have a share on your work server that you use exclusively for old OS installer media. Partly out of some sort of sense that one day it might be useful to have a copy of Mac OS X v.10.1, but mostly out of a sort of obsessive compulsive need to have the full set.

Yeah, it’s probably not a healthy impulse, but storage space is comparatively cheap and it’s not an impulse that’s actively harming anyone. I can feel the condemnation through the magic of the internet, and I spurn it with my foot. Digital hoarding is pretty low-footprint, anyway.

So, whole bunch of macOS installers, dating all the way back to the Public Beta. The only problem is that nowadays most of them are uninstallable. When you try anything back past the last couple of releases you run into a nasty bug whereby the installer looks at the date on your machine, realizes that it’s installer certificate has expired, and calmly tells you that the installer is corrupt or damaged and that instead of installing Mac OS X Lion you’re more than welcome to hang your head in shame and weep the bitter, bitter tears of defeat.

If only there were some way to trick the installer? Okay, you can probably see where this is going. Enter the date command.

date allows you to either read or set the system date and time down to the minute, following a [mm][dd][HH][MM][yy] format. In human readable terms, that’s month-day-hour-minute-year in double digit form, so that, say, September 27th 2017 at 4:27pm would read 0927162717

So, neat. Right? Right. What do you do with this nugget of information? Simple enough; fool the installer into thinking it’s actually the past (a time when it was perfectly acceptable to install oldie timer operating systems while waxing your lustrous mustache whiskers and riding your penny farthing) and not the present, when we’re all wearing disposable paper clothes in our flying cars and living on the moon. We’re going to lie to the computer, in essence. We’re bad people. And this is how we do it.

First, you’ll need to know when in the past you’re going to tell the computer to imagine that it is. To do that, I utilize the magical powers of the internet to find the release date of the operating system I’m after, and then I add a few days and convert that date into the appropriate string. The example earlier isn’t random – it’s a couple of days after High Sierra/macOS 10.13 hove into view, and thus a good date to use for an install of that OS.

Next, create installer media for the appropriate macOS version (using the well-documented createinstallermedia method seen here), plug that installer media into the computer you’re installing onto, then hold down the option key while rebooting to choose the installer media as a startup disk.

Once you’re booted into the installer, disconnect from the internet/turn off wifi and open the Terminal from the Tools menu. Type in the command date followed by the string you worked out earlier, e.g., date 0927162417, then hit return.

Quit out of the terminal, jump back into the install, and proceed as normal expectations dictate. One thing to remember is that once you’ve finished the install and booted back into the OS that date flag remains set – in other words, if you tell your computer that it’s 2017 then it’ll keep thinking it’s 2017 until notified otherwise, which can play all kinds of havoc with software updates/the Mac App Store. Fire up System Preference, hit the Date & Time pane, uncheck the “Set date and time automatically” checkbox, then check it again to force the OS to go out and get the right time.

Et, as they say, voila!

Actually, the title is a bit misleading; mas allows you to download anything from the Mac App Store that you’ve purchased or previously downloaded for free – so if you’ve legitimately acquired every macOS release since the beginning of recorded time (like I have) then it’s a simple matter to go and grab those installers and download them to your Mac for your archiving/amusement/future use needs.

So, how to do it. First, you’ll need to go and download and install a package manager like homebrew. You can get the latest version by copying and pasting this into your browser of choice:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

You’ll also need the current version of the Xcode command-line tools (if you don’t already have the current version of Xcode downloaded and installed). There are pre-built packages kicking around Apple’s site, but the easiest way to get the current version is to put this into the Terminal:

xcode-select --install

…and then sitting back and clicking the appropriate buttons to say that yes, you want to install this and you haven’t just decided to start slapping a bunch of additional tools into place on your system just for the hell of it.

Once both homebrew and the Xcode tools are in place, you can start downloading mas by typing the following:

brew install mas

Simple enough, right? The next part is a tiny bit trickier.

Typing mas into a new Terminal window will helpfully default to giving you the options that you have to play with, thus:

Now, provided you’re already signed into the App Store on your Mac you shouldn’t have to tinker around with the account option, but blindly typing in mas install isn’t going to do you any good unless you know what ID the App Store has assigned to the package that you’re looking for. The easiest, simplest way of locating the information you need is to go to the App Store via the built-in app and search from there. Let’s use macOS Catalina as an example, thus:

Click on the share icon and choose “Copy Link”:

…and then paste that into the text editor of your choice to get the full URL of the application you’re targeting:

The ID that we’re looking for is the number to the right of the “id” – in this case 1466841314.

Finally, feed that number to mas like so:

mas install 1466841314

Your application should start downloading once you hit return.

There are some gotchas with this, and it’s not universally reliable. If you share purchases with someone via Family Sharing then the App Store will occasionally decide that irrespective of whether you’re the person who purchased the app or not the app belongs to the other person, and that you’re not allowed to download it. Additionally, you might also run into the odd “HTTP 500 Internal Server” error, although I’ve found that waiting a few minutes and trying again seems effective.

Still, the good thing about using mas to download packages is that it can be an enormous time-saver if your company has a standard suite of applications that it owns through the App Store and wants to deploy to new machines that don’t use/aren’t enrolled in some kind of Mobile Management or Deployment scheme. After all, if you can get homebrew onto a machine then it’s possible to script mas to download specific items to specific machines.

As someone who primarily makes their living supporting businesses that use the Mac platform, I’ve been watching the tea leaves as close as most of my peers re: when this thing is going to actually hit the proverbial streets.

After all, the Mac Pro is a staple of the platform – or at least it’s historically filled that role. The new Mac Pro has been referred to as akin to a halo car by better writers who are in greater possession of greater creative gifts than those sandwiched between my ungainly ears, and they’re right; it’s the biggest, baddest, fastest consumer computer that you can buy and has a price tag to match. It’ll be amazing and lionized – but it won’t be ubiquitous.

Now, I may be biased because I’m typing this on an early 2009 Mac Pro that I assembled from a box of scraps in a cave a la Tony Stark, but this isn’t the first Mac Pro I’ve owned. Back in the late 00’s I had a couple of early cheesegrater/classic Mac Pros because they were relatively affordable and phenomenally expandable, and then later on I bought a 2013 trashcan Mac Pro because I needed a desktop that wasn’t an iMac and Apple had decided to let the Mac mini languish to the point of irrelevance. If you put together everything that I spent on those three computers you’d have a sum sufficient for me to roll around at the lower entry point of the new machine.

And really, that’s okay. Would I like Apple to offer a lower-spec, expandable entry-level Mac Pro? Yes. Yes I would. There’s a healthy market of folks who do professional work who need something with expandability and a decent amount of grunt to do heavy lifting, and that’s why prior to 2013 you’d find a Mac Pro under every desk at every design firm or architect office. But the use-case scenario has shifted – mostly, I suspect, as a matter of circumstance. Apple whiffed on the 2013 Mac Pro, let it languish, and the audience for that product hung onto their old gear until it became untenable to support it any more and then winced, shut their eyes, and ordered iMacs to replace them.

Timeliness is the key. If Apple had had a better grasp on what their customers wanted and – possibly – updated, upgraded and improved the 2013 Mac Pro in line with that then they might not have put themselves into a position where the product is boxed into a corner, where a great number of potential users are already invested into other products. More plainly; if the 2013 Mac Pro had kept pace with the new technologies that other products introduced and embraced (USB-C, Thunderbolt 3, the T2) then chances are that the new machine wouldn’t be priced to start at about $6k and pitched toward a small handful of highly specialized use cases who are probably going to be the only ones who’ll find any real value in that kind of outlay.

Which is kind of a shame. The new Mac Pro is imminent (any day now – supposedly by the end of the month with a quiet release, and there are already support documents floating around for the thing) and it’s a remarkable piece of design and engineering that demonstrate that Apple hasn’t missed a beat in those departments. It’s sad that I suspect that we won’t be seeing many under desks for a long, long time.

One of the primary purposes of this blog is for me to write things down that would otherwise disappear out of my feeble, aging mind; thus they stand not only as the moderately-indifferent ramblings of a middle-aged nerd but also as a sort of ad-hoc playbook for the things that I’d really like to dip into now and again. This entry, however, doesn’t fall into that category. Mostly because – unlike a lot of things I do – my .zprofile isn’t something that I forget about and have to be reminded of, and is in fact something that I have to look at Every. Single. Day.

Compared to some, it’s relatively short and simple. I’ve written long profiles before and crammed them with aliases and whatnot, but in the end simple muscle-memory evolution and reduced expectations have kind of stripped that down into the abbreviated list below.

These first six entries are ssh key-protected remote logins to servers that I hit on a fairly regular basis to do routine maintenance. Actual domains and machines replaced with “x”s to protect the innocent. I mean, I’d have replaced the usernames too, but they’re all pretty cookie-cutter…
alias casa='ssh localadmin@xxxxxxxxx.local'
alias dh1='ssh odadmin@xxxxxx.com'
alias office='ssh officeadmin@xxxxxxxxx.net'
alias wm1='ssh w_admin01@xxxxx.xxxxxxx.com'
alias wm2='ssh w_admin02@xxxxx.xxxxxxx.com'
alias wm2='ssh w_admin03@xxxxx.xxxxxxx.com'

This next one pairs the ssh access with a command to run a shell script called (appropriately) stopthemadness.sh which quits Filemaker and reinitializes it. The server is running a very, very large Filemaker application that ties into a very, very complicated pre-press system. Once in a blue moon the thing just throws up its hands and decides that it doesn’t feel like working, so this script fires it up again.
alias pantskick='ssh filemakeradmin@xxxxxxx.xxxxx.com "./stopthemadness.sh"'

This alias gives me my external address and a geolocated stab at where I am. Handy when using a VPN.
alias whereami='curl ipinfo.io/'

This next one is probably the one I use the most:
alias la='ls -al'

I made an ASCII art version of Clarus, because the underrepresentation of Dogcows in modern operating systems is a borderline atrocity. This calls the appropriate cowfile, and is cute but utterly useless for anything except making me grin. If I ever have the chance I’d love to find some way to pipe output from Pine into Cowsay so I could have cows (or Dogcows) tell me my email.
alias clarus='cowsay -f clarus'

Alias that takes me to the git repo of the game I’m working on:
alias tdg='cd ~/dev/tdg'

Change directory to the home directory. This one really should be in the OS by default as far as I’m concerned.
alias ~='cd ~‘

Sometimes you just want to throw something in the trash from the command line (as opposed to instantly deleting it). Just type trash and then the file name…
trash () { command mv "$@" ~/.Trash ; }

Hides the ~/Library folder…
alias hide='chflags hidden ~/Library'

…and reveals it again.
alias goseek='chflags nohidden ~/Library'

I like to start nettop up in display per-process mode (as talked about here), so there’s this:

alias net='nettop -P'

Finally, here are a few things that I like to have appear in my prompt. Uptime simply shows you how long the system has been running for, as well as the number of users and the load average of the system.
uptime

This calls sysctl to print out the type of processor you’re running. It’s useless for any real practical purpose, but I have a lot of Xeons rattling around in my Mac Pro and sometimes it’s nice to be reminded of that, thank you very much.
sysctl -n machdep.cpu.brand_string

Fortune prints out a random saying or pithy bon mot for your delectation and enjoyment. Sometimes I find it helpful to have an inspiring quote to carry me through a particularly frustrating time behind the keyboard. And by inspiring I usually mean spiteful, angry and profane. Hey, each to their own:

fortune

Next, I like to be able to quickly switch audio output sources from the command line because I am fundamentally lazy and don’t like to drag the mouse pointer to the sound menu item and try and remember which option goes to what speaker. It’s easier just to have settings for “speakers” and “headphones” and be done with it, so I used Homebrew to install switchaudio-osx and set up a couple of aliases, thus:

alias speakers='switchaudiosource -s "Built-in Line Output"'
alias phones='switchaudiosource -s "Built-in Output"'

Finally I have a line break and then a quote from Wargames. Because both Matthew Broderick and Tic-Tac-Toe are cool:
echo '=================================='
echo 'Greetings Professor Falken. Would you like to play a game?'

Configuring your .profile/.zprofile with aliases and little customizations like this is both simple and – when it gets down to it – fun. But there are some very real, very useful applications to being about to add your own complex, bespoke commands and workflows to your command-line experience, and while most of these trend more toward the fun side of things I’ve found that getting my profile set up right out of the box is both the first thing I do with a new machine and also incredibly valuable at saving time and having to reinvent the wheel…