Category Archives: Sierra
Since releasing DetectX Swift back in January, a lot of people have been asking me how the new ‘Swift’ version differs from the older one, aside from requiring 10.11 or higher (the original will run on 10.7 or higher).
Well sure, it’s written in Swift — and it’s much swifter, literally, but of course there’s a lot more to it than that.
I’ve finally had a spare moment to enumerate the feature list and create a comparison chart. Although the image above is essentially the same as the one you’ll see at the link address at the moment, there’s still a bunch of features to be added as we go through development of version 1. Thus, be sure to check the latest version of the chart to get the most up-to-date info.
Given news that some hackers are using websites to mine cryptocurrency even when users apparently close their browser on Windows, I got to wondering whether a similar exploit would work on macOS.
As the video above shows*, a malicious app can easily hide an open Safari window from all desktop workspaces, making it incredibly difficult for users to notice or to make visible again even when they do. This trick can be exploited without elevated privileges, and it doesn’t matter whether the malicious app is code-signed or not.
An invisible Safari window is a problem because it could be running scripts, mining cryptocurrency, redirecting to sites for adware revenue or doing all manner of other things. Note the window could contain multiple tabs that the user may have already been tricked into opening before the window is made invisible.
As can be seen in the video, the Safari window isn’t in another full screen workspace, or minimized in the Dock or hidden by any other window or toolbar (as in the Windows 10 trick).
On the contrary, it can’t actually be found anywhere, and nor will Window > Bring All To Front help. If you open a new window and then try to use Merge All Windows to bring the hidden window out, all that happens is your new window will disappear with the hidden window too.
The only visible indicators that there’s an invisible window open are the window list in the Window menu, and the invisible outline revealed by Expose (four-finger swipe down).
So what if you find there is an invisible window hiding from you, how do you get it back?
To retrieve and kill the hidden window, you need to click View > Enter Full Screen, then click the red close button. Don’t click the green button to take it out of full screen though, as that’ll just cause it to hide again, with a nice animation that you can see on the video!
Another day, another hacker trick to watch out for folks!
* This vulnerability was demonstrated on 10.12.6. It also exists in both 10.11.6 El Capitan and 10.13.2 High Sierra.
Spoofing or phishing – presenting a user with fake authentication requests – is a common email tactic, but it’s not the only vector where you need to be on your guard. Every version of macOS is vulnerable to a very simple phishing attack right on your desktop that doesn’t require admin privileges to run, would not be detected by GateKeeper or XProtect, and which could easily be placed on your mac by any of the nefarious malware / adware installer scripts that come with some less reputable software downloads.
This attack isn’t new, but it’s not often talked about. The easiest way to see how it works is in this quick 4-minute demo:
As you can see, it’s easy to grab the icon of any Application and put it in the script; it doesn’t even have to be the icon of an app that’s running. The simple demo I gave above could easily launch iTunes first to increase the coherence of the attack, or it could use a completely different icon, including the icon of security programs you may have running on your mac.
How can you check?
If you were presented with a password request like this and wanted to check whether it’s legitimate or not, an easy way would be to use my free utility DetectX Swift’s Profiler. Click the Profiler function, and search for ‘osascript’ within the Running Processes section. Note how DetectX Swift shows you the text of the script being run, confirming that this dialog is up to no good:
It’s been unusually quiet on Applehelpwriter these past few months, and the reason is that I’ve been devoting all my time and efforts to the new version of DetectX. The new version is called DetectX Swift because (yeah, you guessed it) I wrote it in Swift and because it’s considerably faster than its older sibling.
DetectX Swift’s got a new interface, but there’s far more going on under the hood. The Search uses some fancy heuristics as well as hard-coded and live update search definitions to ensure it provides the very best in security threat scanning.
The new Profile view employs some super cool dynamic highlighting and lets you inspect the contents not only of directories but also of scripts, plists and other files that could execute troublesome code on your mac.
There’s changes in the History view, too, both in the display and functions. One of the coolest things I like about the new History function is that you can run a diff on any previous run against the latest run, immediately seeing how they differ.
There’s tons more to DetectX Swift, but the best way to find out about it is just to try it. The beta version is free to use for both Home and Commercial users, so just head off over to its home page and grab yourself a copy!
Don’t forget to keep us informed of how it goes. The beta is still in an early stage and more features are slated as it develops, but feel free to tell us about anything that you feel could be done better or things that you’d like to see added.
Share and enjoy! 🙂
One of the things I find intrusive are the constant Swift Compiler warnings while I’m actually in the middle of writing a block of code (e.g, ‘…value was never used consider replacing…’). Well, yeah, it’s not been used *yet* …grrr!
However, turning off compiler warnings isn’t something I want to do either. It’s too easy to go into the build settings, turn them off, do a bit of coding, take a break, do a bit more coding…oh, three thousand lines later and I suddenly realize why Xcode hasn’t been correcting my mistakes all afternoon!
This script allows you to quickly and easily toggle the warnings from a hotkey, and just gives you a gentle reminder as to what you’ve done. Of course that won’t stop you forgetting, but assigning a hotkey for this script makes it painless to just turn warnings off and back on again as soon as you’ve got past whatever bit of code the compiler was complaining about.
Xcode unfortunately doesn’t have its own scripts menu, so in order to assign the script a hotkey, you’ll need to either make it into a Service with Automator or use a script runner like Red Sweater’s FastScripts.
display notification "Suppress Warnings was set to " & aVal with title "Swift Compiler - Warnings Policies"
tell application id "com.apple.dt.Xcode"
tell its front document
tell its front project
tell its front target
tell its build configuration "Debug"
set b to build setting "SWIFT_SUPPRESS_WARNINGS"
if b's value is "NO" then
set b's value to "YES"
set b's value to "NO"
my sendNotification(b's value)
If you are preparing to install macOS on multiple computers, one of the things that can make your life simpler (and the waiting shorter) is a bootable USB installer.
The idea of the installer is that you only need to download the macOS Installer.app from the App Store once. Usually, when you run the installer after downloading it, it’ll delete itself and you have to go through the whole download process again on each machine or disk that you want to install macOS onto. By making a bootable USB drive, you simply plug the drive in to your mac, launch the installer app and tell it where to install the OS. You can repeat this as many times as you like as the installer will remain safe on your USB.
There are various ways to make a bootable USB installer, but they all involve the same process:
1. Download the macOS Installer from the App Store.
2. Run the
createinstallmedia command from the Terminal, an AppleScript or a helper app.
3. Reboot your mac, choosing the newly created USB as the startup disk.
4. Run the installer.app from the USB.
Step 2 is where the fun is. The
createinstallmedia command can be tricky to get right, particularly if you’re not familiar with working on the command line. For those of you that are, follow Apple’s instructions here.
For a little more convenience, I wrapped all that inside an AppleScript which will first ask you for the location of the installer, then ask you to choose the USB target.
For maximum convenience, I also wrote a free little Swift app I’ve dubbed ‘Boot Buddy‘ (cos “Create bootable macOS Installer Drive.app” just didn’t quite have the right ring to it..!) that will present the whole thing in a neat little user interface. Three clicks, more or less, and you’re done.
Boot Buddy doesn’t require an admin password to install, but you do need to provide an admin password to actually create the bootable installer as the
createinstallmedia process has to be run as root. Boot Buddy doesn’t see or use this in any way whatsoever other than to start the
createinstallmedia process or to cancel it (if you choose to do so); authorisation is handed off to macOS to take care of.
Boot Buddy requires macOS 10.11 or higher and can create bootable USBs from Mavericks, Yosemite, El Capitan, Sierra and High Sierra installer apps.
Share and enjoy! 🙂
Last week I was asked whether I could produce a script that would keep track of Carbon Copy Cloner backup tasks so that a user could tell which of many, multiple backups of the same source disks were the most recent.
Of course, CCC has its own Task History and Disk Center functions to provide information, but these turn out to be insufficient in common scenarios. To see why, let’s consider a hypothetical task set-up and recovery situation.
In this situation, let’s suppose I’m keeping 2-hourly, daily and weekly clones of my mac’s internal disk. While I’m logged in to my mac, I can of course check CCC’s Task History to see when the last back up was, the destination, and whether it was successful or not.
However, suppose the internal disk fails – just the situation for which I keep my CCC backups on a regular schedule. Which disk contains my latest backup? The information from CCC’s history task is on the failed internal disk, so it is not now available to me. Of course, each backup contains CCC’s earlier History too, but there’s several problems here. First, these cloned task histories do not contain the history from the *last* task (that’s only written to the source disk after the last backup completes). Second, to compare them, I’d have to boot each clone individually – a time-consuming and not terribly convenient process. Third, CCC’s ‘Disk Center’ only provides backup information about connected disks if the current startup disk was used to run the backup task. Thus, if I backup Disk B from Disk C, that information won’t be available to me when I startup my mac with Disk A.
Before I discuss the solution to this, let me just complicate the scenario further. I have two other macs – two 13″ MacBook Pros that have been going strong since 2009 – each of which I backup to individual clones. There’s no way for me to see all the backup dates from all my macs with CCC. Further, we don’t need to consider only disk failure as a reason to need comparative backup history. Since some files are shared or swapped across my three macs, there’s no way to find out from CCC’s Task History or Disk Center when the latest backup of any particular one of those files was made, or on which backup disk I can find it. For example, the connected disk ‘MBP Z Clone’ is a scheduled task on my MBP, but looking at this disk when connected to my iMac gives me no information about its backup history:
Fortunately, CCC has two features which make our problems solvable. First, each source disk keeps detailed logs of the backups it has run (from which the Task History and Disk Center info is constructed); secondly, CCC allows us to run a shell script after each task has completed.
These two little features are going to allow us to build a shell script that will write a special log file to the destination after each task completes, and then retrieve it and compare it against both the current source and other disks. That means we’ll be able to get CCC backup data from any disk we connect to any mac, since the data will be stored on the destination disk itself thanks to our shell script (for the technically minded: to avoid permissions problems, the script writes to /Users/Shared/ if it’s a bootable clone, or to the root of a disk that isn’t).
That’s the outline of the problem and the solution. What started out as a simple AppleScripting task soon blossomed into a full-blown app. Although much of the background work I’ve outlined above is achievable via AppleScript, displaying the data effectively is rather cludgy, even if one uses some of the excellent scripting libraries like Shane Stanley’s ‘Myriad Tables’ to improve on the stock AppleScript offerings.
Accordingly, after about a week or so of wrestling with an acceptable solution, I finally came up with the Disk Inspector.app to solve all these problems in one go and add a few niceties on top. 😉
Whatismore, since it’s Christmas :D, I’m publishing this as a free utility on my software site, Sqwarq.com. Check out Disk Inspector’s support and download page here: https://sqwarq.com/disk-inspector
Here’s a quick overview of the main features:
1. See dates of all connected disks that have been backed up via CCC*
2. See the latest backup and (if available) Time Machine backup for the current source disk
3. See the OS Version and Build Number on connected, bootable drives
4. Open any disk’s root folder in the Finder by double-clicking its name in DI’s main view
5. See an estimate of the total and available space on each disk (rounded to the nearest GB)
6. Save all the data to a log file for easy record keeping of your backups
* after completing Disk Inspector’s set up procedure
For full instructions refer to the Support page, but the basic idea is that on first launch, you run the ‘Set Up’ wizard to configure your tasks in Carbon Copy Cloner. Disk Inspector’s ‘Set Up’ wizard walks you through 5 simple steps to accomplish all this.
Once you’ve completed the set up procedure and each of your scheduled CCC tasks has run, you’ll start to see information for each backup disk in Disk Inspector’s main view on any mac (or on the same mac booted from a different drive) that you subsequently connect those disks to.
Disk Inspector runs on 10.10 and higher.
Enjoy, and Happy holidays to all! 😀
This little tool will help you keep track of when Apple make changes to system config data like XProtect, Gatekeeper and the Malware Removal Tool. It will also alert you if there is a Security update in the App Store that needs to be manually applied.
Critical Updates is free for home use. Organisations wishing to license it for commercial-scale use should contact me through Sqwarq support.
With macOS 10.12 Sierra due out sometime this month, some will no doubt be wondering whether their current mac will make the cut.
First thing you’ll need to know is your model identifier. If you’re using DetectX or FastTasks 2, it’s displayed at the top of the Profile log. In FastTasks 2, you can also find it in the menu under ‘Model Overview’.
If you’re not using either of those, you can get your model identifier from > About This Mac > System Report… Look for ‘Model Identifier’ under the Hardware Overview section.
Barring any unlikely last minute changes from Apple, here’s the full list of models that are supported: