Author: Dave

I love The Expanse. If you’re looking for solid science fiction that invests heavily in world-building and doesn’t resort to ludicrous, flow-breaking space magic nonsense then you can’t go far wrong with a fictional world comprised of people doing what it is that people do best: trying to get by.

Life in space is allegorically like life in the modern world. You have limited resources that have to be inventively and creatively used, and there’s a clear and pragmatic need for the kind of muscular morality that actually makes the world work. Don’t mess with the air and water, recognize that the people you work with (whether you love or hate them) are functionally indispensable and should be protected, and maintain your tools. Sound advice.

It’s the latter that I’m talking about today, though. There’s a character in the books – a phlegmatically amoral psychopath who unaccountably seems to be one of the good guys – who repeats that maxim (or variations of it) at various points, using downtime to disassemble, clean and check tools and equipment that are vital to his job. As maxims go, it’s a good one, and one that I have pinned as a geeklet on my desktop, thus:

In a pragmatic, actual sense there’s a lot to be gained by making this punchy quote into something you can actually implement provided you take the time to think about what needs to be done, take the time to do it, build a solid routine and invest time and resources in carrying it out. This applies to anyone who uses their Mac (or really any computer) for something indispensable, whether it’s one iMac or Mac mini that sits on your desk for emails or it’s a Mac Pro stuffed to the gills with upgrades that you use as an Xcode build monster.

Taking the time to think about what needs to be done.

Block out an hour. Quit email and any messaging apps. Put your phone on Do Not Disturb. Get your non-alcoholic beverage of choice, sit down, and really consider the machine in front of you. What do you use it for? What are the apps and utilities that you crucially rely on? Has anything been acting up of late? Is everything backed up, patched and updated?

You get the idea. Consider the lump of glass, metal and plastic in front of you and then imagine what your next steps would be if it suddenly and mysteriously went away. Run through worst-case scenarios. What would you need to have on hand if you woke up one day and found your MacBook so broken that the only logical move was to go and buy another one? What solutions and strategies should you be thinking about and investing in? Switching things around – what do you not use your computer for? What applications or tools or data do you have on there that you no longer want or need?

I have a friend who periodically clears out her workspace by assessing each object and asking whether it’s something to keep, put in storage, or throw away. Those are brutally broad categories, but effective nonetheless; something you don’t use every day can either be thrown out or cleared away to free up space and resources, and there’s no shame involved in whichever option she chooses. The trick isn’t in making ruthless decisions about paring away the tools and data you need; instead it’s being ruthless about executing those decisions. That old piece of software or utility you’ve kept around for a decade and resisted upgrading? Keep it! Those old notes that you might some day need to dip into? Keep them or file them away somewhere safe. The pre-installed copy of Garageband with its attendant huge libraries? Pft. Throw it out.

Taking the time to do it.

Santa Barbara has had a pretty terrible time of it recently. I can’t complain because I live about as far toward the edge of the world as possible and because fires and floods would have to pretty much take out the entirety of Santa Barbara and much of Goleta before they arrived on my doorstep, but I’m the lucky one. I had clients lose their computers, hard drives, photographs, personal documents, homes and everything they’ve ever owned, made, worked on or created in their lives in the floods that came after the Thomas fire. That kind of loss – the sheer breadth of it – is overwhelming and almost incomprehensible; to lose everything in an instant and still have to count yourself as one of the lucky ones. And then, on top of that, I had a family member die unexpectedly in the last year in media res, leaving behind a broken iPhone and locked PC and no accessible backups that would help us figure out their tangled finances and byzantine business dealings. It sounds facetious and we’re all sick of hearing it, but seriously; back up your data. Terrible things can (and do) actually happen, and you literally never know when your number is going to be up. Have backups and a plan, and if you’re like me have an old MacBook Air and all the chargers and dongles you’d need to work it stuffed into a backpack at a secure location along with encrypted copies of insurance and financial documents. Paranoia is cheap compared with losing, well, everything.

Back up your computer. Ideally, to two different physical drives. If you have a computer that will accommodate a spare internal drive then slap a big hard drive in there and only use it for backups. Go buy another external drive – one of those little USB-powered ones will do – and plug that in as a second backup drive, and then to finish up go and invest in an online backup service. I like Backblaze, but there are many other excellent options out there. Back up photos and home movies and any vital financial data onto a hard disk and put it in a safe deposit box, then make sure that your relatives can get to it if you’re not around. It’s a couple of hundred bucks a year, and completely worth it.

Do the research on updates and patches, and while it’s important to install urgent fixes for critical problems it’s also prudent to do some reading around on any problems raised by updates. You don’t want to update to the latest OS only to find out that it breaks compatibility with a crucial, professional-grade application. If you use a package management solution like Homebrew then update your installs, and go look through what you’ve installed and decide whether there’s anything that you need to get rid of.

Inventory the software on your computer – make sure you have copies of serial numbers and if possible have disk images saved and backed up someplace they can be readily retrieved if needed.

Build a solid routine.

An hour invested in maintenance on a regular basis – even if it’s just once a month – has the capacity to save you a lot more time further down the road. Seth and I often found that the servers we looked at and maintained for a few minutes every week had the longest uptimes and the fewest failures; by taking the time to really consider anything that seems out of place we’d catch odd log messages or note that some tasks or diagnostics took longer, and we’d catch issues long before they became critical. So, block out time on a regular schedule and stick to that schedule. You’re probably not going to run into anything disastrous on an ongoing basis, but noticing something awry in advance of failure is preferable to noticing it after failure has occurred. Read the Console.app for errors. Google the stuff you don’t understand to make sure that something disastrous isn’t around the corner.

Every Monday morning I spend thirty minutes or so doing all the above. Check the log files on the home and office servers, install critical updates and patches (or schedule downtime to run anything that needs a reboot), check logs and run updates on my desktop and laptop, run brew upgrade, check that automatic backups are working and that the things I have to backup manually are done and checked. That may sound a little OCD, but it’s thirty minutes out of the week that pays for itself in avoided failures and outages.

Invest time and resources.

So, thirty minutes a week is non-insubstantial if you bill for your time, and that time is valuable – but if you’re dead in the water then your time rapidly turns from a commodity into a liability. Likewise resources. Maintaining your computer isn’t a zero-cost solution, and if it is then you’re doing it wrong. Buy good components and quality parts. Don’t buy the dirt-cheap hard drive with a thousand single-star reviews; go tighten your belt, grit your teeth and buy the drive that isn’t likely to blow up or grind to a halt within a couple of months.

Thomas Hobbes said it best when he opined that life is “Nasty, brutish and short”, and while that sounds like the worlds’ most unpleasant law firm it has the ring of truth to it. The best way you can protect yourself isn’t with a backups or redundancies – it’s with thought and care and planning and the application of caution and investment of time.

More of a best-practices post than a concrete article, but nonetheless there might be some value here.

Time Machine has worked in pretty much the same way since its incarnation on the grounds that macOS has also pretty much run the same way since its incarnation: as a monolithic OS that sits on a big volume with lots of bits of data sloshing around on said volume. Time Machine would obligingly go and grab all those bits of data, compare them against a destination, then bring over all the bits of data that it deemed had changed so that you had a snapshot of whatever was on there at the moment you did the backup.

This was all very sensible and worked just fine – right up to the point where the basic underlying mechanic of the way that macOS handled files (all sloshing around on a big volume) – irrevocably changed into more intelligently having all your files sloshing around on two entirely separate APFS volumes. And when I say “irrevocably” I mean it in the tangible, literal sense of “you can’t go back to the old way.” Apple makes this moderately clear in this document, right down there at the bottom:

“If you upgraded to macOS Catalina on a Mac that uses a Time Capsule or other network storage device as the backup destination, your existing backups are also upgraded and can be used only on macOS Catalina. New backups that are created can be used only on macOS Catalina.”

Well. Good to know. In case there was any doubt about this, Catalina changes out the tried and trusted .sparsebundle suffix for the new and improved .backupbundle, the latter of which cannot be opened on anything earlier than Catalina.

There’s further good news and bad news. The good news is that (at least in most typical cases) Time Machine seems to update your existing backups as part of setup once you’ve upgraded to Catalina. The bad news is that this takes a long time and uses a lot of space, as putting everything you use onto two APFS volumes with a drastically different file structure requires significant rewriting of your backup file. In fact, it’s pragmatically a toss-up about whether to let Catalina update your existing fresh ones or just start a new one.

I’ve found that if you have the time (and additional drives) then the best practice seems to be to try and get the best of both worlds. Back up everything under Mojave to two backup sets, detach one of them and stash it in a safe place so you’ll have a backup of your backup, then run the update to Catalina and let it go hog crazy on your remaining backup set. That way if things go awry then you have another clean copy of your old backups to pull data from (and, if it becomes apparent in short order that Catalina isn’t going to work for you, enough data that you can wipe the computer and roll back to Mojave with relative ease.)

New technologies always require transitions, and those transitions are inevitably messy – no matter how well-conceived and well-implemented. Time Machine is practically a venerable institution at this point, and while some parts of this new incarnation have been extant prior to now – local snapshots, I’m looking at you – making substantive changes in the way things work is always going to have rough edges.

And – although this is a good thing – I’ve yet to hit a point where it’s really been put to the test due to hardware or software failure (although I’ve done some full restores on new machines without incident.) Still, time will tell…

“If Mac Pro is in firmware recovery mode, the status indicator light rapidly flashes amber three times, briefly flashes amber three times, then rapidly flashes amber three times. This repeats until the computer is turned off. You might need to revive the firmware on your Mac Pro. If you still need help, contact an Apple Authorized Service Provider“

So, to be perfectly clear about this, they’re saying that if your Mac Pro, say, suffers a power failure during a firmware update and requires repair then it lets you know this by flashing the standard International Morse Code signal for S.O.S?

That’s outstanding.

Back in the day when Apple was telling ACNs that Xsan was the new thing that we all had to know everything about I went out and bought an Xserve.

Okay, it wasn’t just me: it was my fellow ACN and business partner Seth and I . And it was three Xserves. And an Xserve RAID. And a giant box to put them all in. And a fiber channel switch, a ton of cards and cables and adaptors and assorted doo-dads. And it was glorious. And cost as much as a reasonable used Toyota. And it was loud.

Really loud. Really, really loud. To the point where Seth and I would eventually pad the mobile rack with a foam kit, and then wheel it into the back corner of our office in Carpinteria, and then finally wheel it into another room, and then close the door. Don’t get me wrong; Xsan was incredible once you got it set up, and it was equally incredibly advantageous to have a test platform in place that you could throw enormous amounts of data at and have it not even blink. But when we finally pulled the plug on the Xserve/Xsan/RAID experiment after one Xserve blew a processor and another developed some kind of remarkable fault with a backplane we saw the writing on the wall, migrated everything to a couple of nice Promise RAIDs, and ended up giving away, parting out, and eventually recycling the whole lot.

And then Apple stopped making anything that would fit in a rack mount (I’m not talking about you, Mac mini/Mac Pro 2013 rack conversion kits. Sit down at the back, there). Until they came out with this:

I find myself more curious about this than I am about the stock Mac Pro – and not just because it’s a fabulous-looking piece of industrial design (and for my money much better looking than the standard Mac Pro), but because for a platform that’s been carefully engineered for cooling and silence a rack-mountable version is a slam dunk.

The thing is that it’s not simply like they slapped a couple of 19″ rails on the side of the existing box so you could stick it into a rack; it’s an entirely different machine. Sure, there are a lot of similarities with the regular Mac Pro. The base models are identical on specs, but the rackmount version is $500 more, and that $500 gets you a different chassis with migrated ports from the top of the case to the front, built-in spots to attach the included rail kit and a slightly altered rear plane that looks like it’ll accommodate increased airflow. There are those who’ll look at the $500 increase and chalk it up to Apple padding their profits unnecessarily (cough cough Pro display stand cough), but I’d ask those people to go out and look for good rail kits for rack mount servers. Not the cheap, nasty powder coated jobs that eventually buckle and refuse to extend; a really good rack kit. Go on. I’ll wait.

You’re back? And you clocked that a 4U, four-post rack kit can handily set you back about $700? Yeah. I hear you.

It kind of makes sense, though. Four-post rack kits are pricey, and with good reason. If you’re putting your 40lb, $20,000 server six feet up in the air then you want to be very, very sure indeed that it’s not being held in place by something that’s going to snap or warp or wear out, and thus risk turning your extremely pricey (and probably business-critical) asset into a large aluminum box full of broken bits.

This a machine that exists in a world of very limited uses. For every hundred Mac Pros Apple sells they’ll be lucky if they sell one or two of these. This product is an anachronism. A delightful, absurdly clever and well-designed anachronism, but an anachronism just the same; a call-back to a product that existed for a few scant years, failed to thrive, and although it was brilliant never found sufficient traction to compete or persevere.

Which is a shame, because this is exactly the machine that the Xserve should have been; powerful, price and feature comparable with the Pro desktop du jour, and (once you get over the fact that a good rack kit is a non-trivial expense) cost-effective.

And quiet. So, so very quiet.

I toyed with including this last time, but in the end opted to go a different way as macOS Catalina seems to (as of writing this) refuse to work very well with the latest version of John The Ripper. Worse still, the homebrew version seems to either not work at all or throw out very peculiar permissions-based errors no matter what machine I try and run it on. Still, undeterred, here’s how to use the “Pro” version of John The Ripper to crack macOS passwords.

Obligatory note: This is not in anyway an invitation to anyone to try and break into anyone else’s Mac. As mentioned last week, Apple includes very good security options right out of the box on their computers, and those are absolutely things that everyone should be employing. At the very least I implore you to turn on Filevault. Come on, folks.

Additional Obligatory note: Everything in this article would only be possible if you were able to follow the instructions I put in the last article about this sort of thing and thus had full, unfettered, unobstructed access to the OS.

A word about that “Pro” thing. Openwall – who host and distribute JtR – offer it for download to the world for free but will also sell you a copy for about $40 that gives you the kinds of boring things that you like to have when you’re a legitimate IT outfit and that are worth the money; i.e., something you can deduct from your taxes as a business expense and something to put in your asset file that helps you keep tabs on your tools and equipment. Openwall also offer tiered options and licenses that include assorted types of support, but I opted for the simple download sans support because I like figuring this stuff out for myself.

Which, it turns out, is shockingly straightforward. Just like last time, we’ll use the following command to go grab a copy of the target’s hashed password:

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

…and then use plist2hashcat.py to pull the hash out and put it into a file that we can use:

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

Next, download and build/use Homebrew to install/buy the pre-assembled binary of John The Ripper from Openwall, then download and unzip it into a directory of your choosing. I threw it in my $PATH, but your mileage may vary and I can think of a few good reasons that you might want to just tuck something like this away in a safe place and only pull it out when needed.

Fire up the Terminal, then cd to the run directory in the unzipped John folder. Once there, the syntax to run the thing is about as straightforward as it gets. I’m using the same hashed file as last time, thus:

./John ~/Desktop/test_hash.txt

Now, hashcat is great and it’s well-supported and super-flexible, but compared to John The Ripper it’s like swimming through a sea of molasses with concrete flippers. John The Ripper is fast. Like, seriously fast. From hitting return on that last command I counted twenty-two seconds before it spat out the following:

Twenty-two seconds to digest that hashed password and spit out “test1” which, drumroll, is the correct answer.

Again, as I pointed out last week this kind of thing is only useful on machines that aren’t using encryption like Filevault, and this only makes it clearer than ever that those kinds of protections are no longer optional in a day and age where someone with $40 and a little free time can break into your Mac seemingly at will…

Today – January 5th, 2020 – is a banner day for Apple and anyone who uses Apple products and services. It’s the twentieth anniversary of a product/service that has become integral to the company’s entire internet strategy, app and media distribution efforts, and is the foundation block that every vital service – particularly development and device management – rest on. It is, in point of fact, the thing that turned Apple from a company clawing its way out of financial ruin and irrelevance into the behemoth it is today.

You might think – and I say this not in a subjective sense but in the sense of a person who asked his friends about this – that I’d be talking about something revelatory like the iPod (although you’d be a year or so early) or possibly the iMac (although you’d be a couple of years too late). Those are solid answers, but the real hero of the piece is our old friend, .Mac.

Okay, to be fair, it was originally called iTools because Apple was squarely fixated on their internet strategy and had made the reasonable decision to prefix everything with an “I”, but when you signed up for it (and I did on January 5th, 2000 from the cramped confines of our tiny apartment on Capitol Hill over a 28.8k modem) you got an actual email address @Mac.com and so much more.

Almost everything that came with iTools was weird, and is now gone. The two goofiest ones are easy picks: iReview and iCards. iReview was a sort of peculiar review site for web pages (a noble goal, but ultimately unworkable considering the exploding rate of web adoption amongst the world at large), iCards was a sort of Blue Mountain-esque web greeting card outlet.

Homepage wasn’t awful, and in fact was a fairly serviceable web-page tool that allowed you to host your own site on your iDisk, which could handle up to a whopping 15mb of content. iDisk itself enjoyed direct support in the OS, too; you had the ability to mount the thing on your desktop as if it were just another drive that made copying data to and from the thing laughably simple and intuitive in a way that probably makes iCloud Drive wake up in a cold sweat every night.

A couple of years later iTools became .Mac, and then .Mac became iCloud, and now I have an email address that works with all of those suffixes and has done so – reliably – for twenty years. And because I’m a digital packrat, I can look at those early mails like some sort of data archaeologist and capture little glimpses of the places we all lived and the things we all did back then. There are pictures of my first new car in there, and long email chains between my wife and I that are weird echoes of who we were before we had kids and mortgages. Updates from friends whose names I’ve long-since forgotten, and notes to and from my Dad who passed away almost eighteen years ago.

My private fear is that someday some bean-counter at Apple will look at iCloud and decide that enough is enough and that .Mac addresses will no longer Be A Thing and that we’ll be left with .me.com and iCloud.com, and while that may cause some headaches about AppleIDs and address books I don’t think it’ll be the end of the world. Still, it would be a shame. Twenty years is an eternity in the internet age.

So, Happy Birthday iTools. If I have one wish it’s that you’ll be here in another twenty years time, and that I’ll be around to check back in with you then.

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