RWX Consulting

(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…

…is (at least on AT&T’s network), almost impossible.

Now, I consider myself a technically adept individual. Then again, a lot of forty-six year old people fall into that category; some of us are real stinkers in this department and others of us, well, we all have gaps in our personal objectivity that conform to the exact size and shape of our own weak points. I’m not perfect is what I’m trying to convey here; although there’s a statistically decent chance and a pretty consistent pool of data to point to the idea that I’m probably not awful.

Migrating AT&T’s Numbersync service from one Apple Watch to another seems like something pretty straightforward. When you set the service up you effectively make your cellular-capable Apple Watch a new cell device on their network that acts as a surrogate phone (complete with it’s own phone number) which in turn uses authentication on the device to tell AT&T when to dynamically forward calls to that device. It works very well, and I have no problem with it except that when you decide to move that service to a new watch then it all goes horribly wrong.

My wife and I each have an Apple Watch Series 3 with cellular, and as she likes to leave her phone at home when she goes running (and as I tend to leave my phone in odd places and not notice for an hour or two) having the ability to have calls bounce to the watch has been very handy. Still, her stainless steel series 3 is a little heavy and I have a pretty big chunk of trade-in credit with the Apple Store, so I went and bought her a nice, shiny new aluminum Series 5.

“Can I get calls on it?” she asked me. “Sure,” I told her. “No problem. I’ll take care of that right now.”

That was three days ago.

What followed would have been simpler had AT&T’s site not choked on something for a couple of days and flatly refused to let anyone log in, but only a little simpler. I used the time by googling and poking around forums to see the exact routine required to migrate numbersync from an old Apple Watch to a new one, and found out that, well, there isn’t one.

Here is what AT&T has to say about Numbersync. This is pretty much the final word on the subject other than a lot of marketing blurb. For those who don’t want to follow the link, it gets you this:

So, what it is, how to add it to a new watch, and how to remove it. Crucially, there’s also this line:

“Heads up: If you remove NumberSync, your watch won’t be able to use our mobile network. But, the watch will stay on your plan and you’ll still be billed for its monthly service. To cancel your plan, contact Customer Care.”

…so you can remove Numbersync from the device but they’ll keep charging you that $10/month per device? Right.

Still, I finally managed to get the site to load, logged in, and decided that I’d try and transfer Numbersync from my stainless steel watch to the aluminum one I wear when I’m doing the kinds of things that might entail scratching up a nice stainless steel watch (i.e., most of the things I do all day). That way I’d be the experiment and if it all went wrong then my wife wouldn’t have to deal with things not working properly. Following a post on the AT&T forums I went in and removed the watch from the synced devices connected to my phone number on my AT&T account, unpaired the old watch and told it that I didn’t want to keep the cellular plan enabled, and then enabled service on my aluminum watch.

And everything worked great! The old watch disappeared, the new watch showed up, and all was well. And then the old watch reappeared as a device on my account, neither watch showed as being synced with the phone, and AT&T sent me a nice note to the effect that they really appreciated me giving them $20/month for two watches instead of $10/month for one.

Finally, I called AT&T support and talked to Ron. I don’t know if Ron is his real name or where Ron is (I suspect India) but Ron is clearly the kind of hero we all need. Ron was kind and patient and told me that I wasn’t out of my mind, and that in fact there is no way to transfer numbersync service from one Apple Watch to another other than by calling support and having them remove the existing device from the account and then manually adding the new one afterwards.

And this, while mildly inconvenient, would be fine. I can make a phone call and talk to a guy; that’s not a controversial or challenging thing for the vast bulk of people. It is, however, moderately staggering that Apple can sell millions of watches with cellular capability and a major carrier has no easy way to accomplish something this simple…

I didn’t really start to poke around with nettop until about five years ago, when I got the opportunity to go and give a talk about the nascent iCloud Drive and all the assorted shenanigans that went with it. iCloud, it transpired, would throw all kinds of data up from your machine to all kinds of places in the cloud in a pretty fascinating and intelligent way, and nettop was absolutely vital in showing what went where. Still, right out of the box nettop isn’t particularly user friendly. What follows is an abbreviated primer on how I use nettop. It doesn’t hit on every option, but it’s a good swing at the essentials.

When I plug nettop into the Terminal.app I am immediately hit with something like this:

Still, it’s worth sticking with because it’s entire purpose in life is to report in exacting detail on every single bit of data that goes in and out of your computer; what ports are in use, what interface you’re using, where that data is going and how fast it’s moving at. Used properly, it’s astonishingly capable and useful.

Making it readable

c - collapse all

This is the first option I hit when firing nettop up. The way that the tool throws the expanded view at you by default is pretty frustrating, and this immediately knocks that down to something more like this:

Out of the box you can get this view by launching nettop with a -P option to show a per-process summary. In fact, I’ve added this to my .zprofile:

alias net='nettop -P'

x – toggle human readable numbers

By default nettop is pretty much ideally setup. It’ll give you columns for rx and tx, and let you know in bytes, kilobytes, megabytes, gigabytes and who knows? Probably terabytes and petabytes, too.

You can also hit j in nettop to get this handy menu allowing you to select, deselect and reorder menus, thus:

Being picky

You can use the lowercase -p option to specify a process number or name, thus:

nettop -p Dropbox

…will feed you this:

But better yet you can use this:

nettop -Pp Dropbox

…to get this:

If you don’t know the name of the process you want to isolate (or you just want to pick from a menu later on) then you can hit p while in the nettop screen to get something like this:

If you want to break nettop results down by interface then that’s doable too.

nettop -t wifi – wifi interfaces.

nettop -t wired – wired interfaces.

nettop -t loopback – loopback interfaces.

nettop -t external – the combination of all non-loopback interfaces.

Delta mode

By default nettop shows you the current running total of data in/out for each process, but if you want a more granular look at the current bandwidth in use then you can toggle delta mode by either hitting d in nettop or launching it with the appropriate flag:

nettop -d

This option is pretty useful if you’re looking at a process that’s resting somewhere in the gigabytes. If you’re at 1Mb then the jump to 2Mb goes pretty quickly in the default view, but if a process is sitting at 17GB then it could be a long, long time before it refreshes to 18GB. Jumping into delta mode is a fast way of figuring out if the process is still pushing data in/out, or if it’s stuck or has fallen apart into a thousand little pieces.

Handling data

It’s great that nettop stays open until you want to close it, but sometimes you just want to be able to go grab a cheesy, delicious slice of a few seconds’ worth of output and then get back to your regularly scheduled prompt. That’s where the -l flag comes in; just specify the number of seconds you want to snag and it’ll take the appropriate snapshot and log it to the screen for you. It’s good on its own, but also great with other flags.

Thus nettop -t wifi -t wired -P -l 1 gets you this:

As I said at the top, there’s a lot more to nettop than these basics, and poking around the manpage will doubtless reap you rich rewards…

I mean, look:

It’s very, very pretty and very, very powerful, and the screen is lovely. But what we all care about is the keyboard, and that’s entirely understandable because the circa 2015-2019 “butterfly” keyboards are just horrible. When they don’t break they still feel cheap and tappy and wretched, and as the primary sensory experience that people have with their laptops fixing that is kind of a big deal.

Still, as far as I can tell it’s not user-upgradeable, and I won’t be getting one. I understand the reasoning behind having everything soldered onto the board; it reduces costs and makes the machine faster, more reliable and more secure. It’s just that it’s a lot of money for something that I could buy, use, and then run out of space on.

I’m hoping (and betting on) Apple promulgating this new keyboard across the line. I’m a consultant, which means that most of the time I’m looking for portability over power, so a big, beautiful, heavy laptop isn’t my speed. Put that keyboard in a MacBook Air and I’ll be beating a path to the Apple Store with my hands full of Benjamins and my heart full of joy…

(February update – after a lot of soul-searching I went and bought one. And it’s amazing, and I’m profoundly glad that I didn’t wait for them to make a 13″ version. You forget how handy it is to have a huge screen until you sit down and reflect how bad your eyesight is and how much more you can get done with the extra screen real estate…)

Even though Apple has effectively killed off macOS Server (or at least gutted it and left it a smoking ruin of its former glory) there are still a lot of uses for a big box full of drives stuck in a closet for people to keep all their files on. While the assorted macOS Server services have largely gone away there are lots of good third-party services that have taken their place, and they are still things that need remote access, control, troubleshooting and tweaking. Which means you still need to be able to get to them quickly, fully, and securely.

Now, there’s a phrase that I trot out whenever I’m asked to stand up in front of a crowd in a hotel ballroom and talk about security. Helen Keller nailed when she said that “Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it.” It’s a quote that I think should be seared onto the back of the eyelids of anyone who works in IT; there’s no such thing as “security,” and when you’re talking about that as a concept what you’re really talking about it the Mitigation of Risk.

There are no absolutes; every security procedure is effectively just a barricade, and you have to assume that time and ingenuity by bad actors are going to bring it down. The best thing you can do is stay vigilant and use common sense and good tools. In this case, that means using encrypted keys to authenticate access to servers.

So, here’s the scoop:

I have a 2009 Mac Pro sitting under my desk that I’ve hotrodded within an inch of its life with NVMe storage, a beefy graphics card, USB-C 3.1 and an astonishing twelve (twelve!) core 3.47Ghz Xeon. It’s full of big, fast storage and it’s a beast for Xcode builds, and the best thing about it is that I cobbled the thing together out of a lot of boxes of scrap. It’s running Catalina 10.15.1 with the dosdude1 hack, and I’ve ported my old .profile file into the new, shiny, zsh-compliant .zprofile file. I like to throw a lot of aliases in there, and what I really wanted to do was have aliases I could bang into the keyboard that’d log me into one remote server in my basement and another that sits across town in my office. Additionally, there are a couple of client servers that we have maintenance contracts on that I like to keep an eye on a couple of times a day on the grounds that this is an excellent way to catch little things before they turn into big things.

So, in total there are four servers, each in a separate geographic location and each with their own frighteningly complex password structure. I don’t keep passwords and credentials on a sticky note on my desk because that’s breathtakingly irresponsible, and Terminal doesn’t want to play nice with stashing credentials in Keychain, so I needed a better way of quickly getting remote access from the Terminal, and this is where SSH came in.

Step 1: Make some SSH keys using ssh-keygen.

It’s worth looking through the man page for ssh-keygen, as there’s a lot of good stuff there. What we need to do is pretty straightforward, though; make a private/public key pair and specify the type of key you want to make with the -t flag. There are a few options, but I used rsa:

ssh-keygen -t rsa

Step 2: Answer some questions.

Hit return to save the key to the default location in your home folder. Enter a passphrase, because not password-protecting your keys is A Bad Idea. There are many reasons to password-protect this key but the biggest, scariest one is that in the very unlikely event that anyone got hold of your ~/.ssh/id_rsa file then they’d be able to use it to log in as root on any server set up to take use that for authentication. Password protecting it with a strong password is essential.

Step 3: Push the public key to the remote machine.

You’ll need to have SSH enabled for this on the remote machine, but chances are that if you’re doing this then you already enabled SSH several months ago. The following command goes and reads the public key you created in ~/.ssh, then pipes that to an ssh session that logs into the remote machine, creates the user-level .ssh directory and writes that key into the authorized_keys file:

cat ~/.ssh/id_rsa.pub | ssh user@remotelocation.server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Step 4: Tell your client machine to cache the keys.

The key pair you generated way back in step 1 essentially works on a session basis. If you restart your Mac then you’ll have to enter the password to get this all working again. Fortunately, you can pre-cache the keys by using the ssh-add command

Step 5: Embrace the laziness.

Fire up your command-line text editor of choice (I like pico/nano) and edit your .zprofile with something like the following:

alias server1="ssh adminuser@remoteserver1.net"

alias server2="ssh adminuser@serverinmybasement.com"

alias server3="ssh admin@ancientxserveintheoffice.net"

…you get the idea. Save the file, open a new shell, and all things being equal you’ll be able to use those new aliases to securely log in to the appropriate remote server without fat-fingering a lot of fiddly passwords.

Step 1: Pursue a career in Broadcast Journalism.

Admittedly this seems an odd place to begin your exciting journey into the world of professional IT consulting, but here’s the thing they don’t tell you about working in radio right out of college: it’s nothing but long hours and the pay is an amount so minuscule that your paycheck is almost a piece of collaborative fiction that you and your employer get to co-author and enjoy together. It’s the early 1990’s and you have your freshly-minted Anthropology degree and nobody is scouring the earth for twenty-two year olds who can talk about Ritual Gift Exchange in Papua, so an opportunity to get paid to talk on air to Londoners slogging their way around the M25 will sound like a nice change of pace. But don’t be fooled. You’re going to need a second job, and possibly a third.

Step 2: Get a second job (and possibly a third).

If you’re pondering a second job then I’d suggest starting out doing sales for a large UK-based Apple reseller with a complicated and bloody-minded returns policy. As the new kid you’ll be the poor sap who has to do ad-hoc tech support, but hopefully you’ll be like me and turn out to – against all common sense and expectations – be really rather good at it. So good, in fact, that you’ll end up with a third job peddling your skills around Central London, fixing things for fledgling Creative Agencies and falling asleep on the tube a lot. You should keep doing that though, because eventually you’ll end up doing the same job in Atlanta and then New York and then Seattle; happily being given Macs that don’t work and poking and prodding and repairing until they’re back to their original state.

Step 3: Get a better job (and get better at it).

You’re going to also want to go work in-house for a really, really cool design firm for about seven years – right around the time when Apple decided to scrap the old Classic MacOS and replace it with the BSD-enhanced Mac OS X. Pro tip: spend nights and weekends learning everything you can about Linux and BSD so that when Mac OS X finally gets released you’re in the minority who actually know how to work with the thing. (You’ll particularly enjoy the part where you realize that you can effectively automate about thirty percent of your workload, but I’d recommend you don’t talk about that too loudly).

Step 4: Be your own boss.

Quitting when that company gets sold twice in two years and then sort of falls apart like Mister Potato Head is going to be difficult, sure, but you’ll do okay if you strike out as an independent IT consultant specializing in Mac OS X client and Server configuration, installation and support in a huge design market. I’d recommend getting a lot of qualifications and certifications and being diligent about treating people with respect because that attitude seems to be something in woefully short supply with some of your competitors. After all, are you an attorney or an architect or an artist or surgeon? No, no you’re not, and people who fill their heads with doing complex and fascinating work shouldn’t be expected to spend a lot of time worrying about how their network works. You take care of that, and they’ll take care of building and making things and changing lives. It’s a fair trade. Oh, and get pretty good at running cable and chasing down network issues, too. Maybe hire a couple of people once things really get into high gear.

Step 5: Be your own boss (with fewer clouds).

Moving to Santa Barbara a few years later – which will involve selling your existing business and starting another one in a different state entirely from scratch – will be more difficult, but if you got this far you probably don’t shrink from challenges so you’ll work hard and (because you’re pretty firm about the whole treating-people-with-respect thing) it should work out… pretty great. You’ll be surprised that Santa Barbara – which seems at first inspection to be a touristy hotspot – has a thriving underbelly of commerce, biotech and industrial design. Did you know that the Lunar Rovers were designed and developed in Goleta? No? Well they were! Who knew? Not you, it seems.

Step 6: Do interesting work with interesting people.

You’ll want to partner with other people who are really great, too. I’d suggest doing that for about ten years, but eventually it’ll make sense to go and do your own thing, and you should go and do that because, well, you like it. After all, you get to swan up and down the Central Coast of California, meeting jewelry designers, restauranteurs, industrial designers, munitions researchers, professional chocolatiers, architects, veterinarians, graphic designers and architects and plastic surgeons and artists and people who build exquisitely, meticulously precision-crafted homes out of old delivery trucks.

So, that’s my advice. If you’d like to know more then drop me a line…