Author Archives: philastokes
The problem with the simple alert I demonstrated last time is that it only hangs around for a second or two (much less than a Folder Action alert, which takes a couple of minutes to time out). In this updated function, it now also writes a list of the file changes to a (by default) file on the Desktop. The write is an append: if the file doesn’t exist it will create it before writing; if it does exist, it will append the latest changes and date to the file. This way, even if you miss the alert, you’ll always have a record of what files have been added, deleted or modified in your watched folder.
In this example, the folder being watched is ~/Library/LaunchAgents since we want to be aware of any adware, malware or other unsavoury processes being surreptitiously added by, for example, apps we download from the internet. Although there are, of course, many legitimate reasons for apps placing items in here, this folder is prime real estate for attackers as it is one of the locations that can launch processes at log in time without the user’s interaction (or knowledge).
Here’s the code, also available from my pastebin here. A code walkthrough follows.
function writeStringToFileWithMode(aString, aPath, aMode)
this_file = io.open(aPath, aMode)
local str = "Launch Agents folder was modified on " .. os.date() .. " :\n\t"
local this_path = os.getenv("HOME") .. "/Desktop/LaunchFolderModified.txt"
local ignore = "DS_Store"
local count = 0
for _,file in pairs (files) do
count = count + 1
i = string.find(file, ignore)
if not i then
str = str .. file .. "\n\t"
if count == 1 then
str = "\n"
str = str .. "\n"
writeStringToFileWithMode(str, this_path, "a")
if string.len(str) > 2 then
hs.alert.show("Launch Agents folder was modified.")
local aWatcher = hs.pathwatcher.new(os.getenv("HOME") .. "/Library/LaunchAgents/", myFolderWatch):start()
The first function, ‘writeStringToFileWithMode’ is just a convenience function. Hopefully the clue is in the name. The ‘aMode’ parameter is either “w” for write(over) or “a” for write(append).
The myFolderWatch function starts off by declaring some local variables.
‘str’ includes the initial line that we want to write to our output file and interpolates the time of the change by calling os.date().
‘this_path’ defines the path that we want to write our list of file names too.
The ‘ .. ‘ in both these assignments is a string concatenator (i.e., like ‘&’ in AppleScript or ‘stringByAppendingString’ in Obj-C).
‘ignore’ is a string that will help us to exclude .DS_Store files from triggering the alert or appearing in the list of file changes.
The ‘count’ variable is an internal var we need in order to eliminate .DS_Store changes when it’s the only change. Lua doesn’t have an easy way to count entries in tables, so we bascially iterate a variable each time through the loop to achieve the same effect.
After that, we have the ‘for’ loop. For loops in Lua are weird (at least for me), as you’ll see that they have this structure for
a,b in pair (aPair). I won’t go into why, other than to say its a result of Lua’s table data structure. The
'_' here is just a dummy variable for the first parameter. The ‘files’ in parentheses are the list of file names (not file specifiers, you AppleScripters!) that were added, deleted, or modified in the watched folder.
The loop begins by incrementing the count, then checks for the ignore file (.DS_Store). If the ignore file is not found, we then append the filename to the str variable.
If it is found, we check the count. If the count is ‘1’ (i.e., the only change was .DS_Store) we discard the entire str var and replace it with new line character. If the count is more than 1 we don’t do anything to ‘str’. We just ignore adding anything to it all.
At the end of the for loop we add another new line to the string just so our outputted text file looks nice and neat.
Then we call the write function mentioned above, passing ‘a’ (append) for the mode.
Finally, we fire the UI alert on the condition that the string has got more than 2 characters in it (if it didn’t it was just the “\n\n” string from ignoring the DS.Store file).
After the function definition, the aWatcher variable sets up the watcher on the path we want to observe and tells the watcher to start monitoring. It tells the watcher to call our myFolderWatch function when anything happens.
Deploying the code
After editing the config file, remember there’s two steps: i. save the file and ii. choose ‘Reload Config’ from the Hammerspoon menu.
More details are available about Hammerspoon from the official site here.
My beginners guide with the original simple watcher function is here.
With malware big in the news again, and evidence that at least one malware variant that targets macOS creates hidden users on the victim’s system, here’s a timely tip on how to check for unwelcome guests.
For this tip, we’re going to use the Terminal, which you can find in the /Applications/Utilities folder. If you’re not a frequent visitor to the land of the command line, you might want to see my 3-part series “Learning the Terminal”.
Regardless, the first thing we’re going to do in Terminal is about the simplest command you’ll ever type:
w. Yep, type a single ‘w’ at the prompt and press return.
w utility is a very quick way to see who’s currently logged on to your system and to ensure that there’s no surprises. You should see a couple of entries for yourself: one as ‘console’ and one as ‘s***’. The first represents a login through the usual Desktop GUI login window; the second is there because you just logged into Terminal. Anybody else logged in either via the command line (like a potential remote user) or the GUI will show up here. Notice that on my machine, there’s another user called ‘Developer’ who hasn’t logged in using the GUI, but is logged in via a command line interface. Note that ‘w’ returns the full user name, not the short one.
w utility will tell you if a hidden user is currently logged on, what if there’s a hidden user that isn’t active at the particular time you check? To look for those, we have a couple of options. First, we can use the
dscl utility to list all users, and you might be surprised at how many there are:
dscl . -list /Users
Look to the end of that list where the names that don’t begin with an underscore start. ‘Daemon’, ‘Nobody’, ‘Root’ and ‘Guest’ are all standard system accounts, as are all those entries that begin with an underscore. Don’t worry about those. However, aside from those, you should only see names that you recognise. To make things a little easier, we can add another command to the dscl command to filter that list. Try this
dscl . -list /Users | grep -vE ‘_|root|nobody|daemon|Guest’
That should now only return the names of real users. There shouldn’t be any names in there you don’t recognise. In my example, I know the last three, but the first one ‘dev’ isn’t familiar to me. Note that unlike ‘w’, this command returns short user names, and that ‘dev’ looks very much like it’s the same account as ‘Developer’ that I saw earlier.
However, what we have so far is a list of users, not a list of hidden users. To see specifically if any accounts are hidden, we need a longer command:
defaults read /Library/Preferences/com.apple.loginwindow
Normally, when there are no hidden users, this will return the contents of a property list file that may look something like this:
GuestEnabled = 1;
OptimizerLastRunForBuild = 31898816;
OptimizerLastRunForSystem = 168494592;
SHOWFULLNAME = 1;
lastUser = loggedIn;
lastUserName = imackim;
That tells us that there’s no hidden users on this mac. How so? Because if there were it would return something very different, like this:
We can see not only the list of hidden users, but also that the preference for hiding users has been set to ‘1’ (in plist syntax, ‘1’ means true and ‘0’ means false). Note again that unlike the
dscl command above, this returns the account’s full name, not the short user name.
If we’d like to ‘unhide’ that user, so the account appears in the login window GUI and in System Preferences’ ‘Users & Groups’ pane, we’ll need admin privileges. To do that, cut and paste the following into Terminal:
sudo defaults write /Library/Preferences/com.apple.loginwindow Hide500Users -bool NO
Supply an admin user password at the prompt and hit ‘return’, but type slowly as the display doesn’t register your key presses, which makes it easy to fat finger your password.
For the more advanced
We can save ourselves some typing by putting much of this into a script so that we can run it whenever we want. If you’re not familiar with how to create and use bash scripts, take a look here.
Our script will basically do the same as all the commands we listed above (except changing the prefs for
Hide500Users) in one fell swoop, and there’s a couple of little twists that I’ll leave as an exercise for the reader to figure out. To save on the typing, you can copy the whole script from my pastebin here.
The script’s output is illustrated in the shot at the top of this post.
Last updated: May 10th, 2017 to include Dok.B variant.
There’s been a lot of drama the last few days over a new malware attack on macOS.
There’s FOUR steps to removing the malware.
1. Remove the installed files
Both my apps, DetectX and FastTasks 2 will detect this malware, and remove the appropriate files. For those of you that like to do things by hand, here’s the list of things to look for. You may find some and not others. Any you do find need to be removed:
You might also want to remove the dead ‘AppStore.app’ login item (if it’s still there) from System Preferences | Users & Groups | Login Items.
2. Remove the network proxy redirecting your internet traffic
Victims also need to remove the sneaky proxy that’s redirecting their internet traffic from System Preferences’ Network pane. While this can be done manually, it’s a lot of clicking, especially since you must do it for all services. Easier, then, to use this AppleScript. Note it will need an Admin password.
Get the script from my pastebin (if you copy and paste from a webpage like this and the script won’t compile, get the source from pastebin).
Phil Stokes -- 2017
Turn off the Automatic Proxy Configuration in Network System Preferences.
Requires Admin password.
This script was developed primarily as part of a remedy for victims of OSX/Dok malware.
set services to paragraphs of (do shell script "networksetup -listallnetworkservices")
set autoproxyURL to " 0.0.0.0"
set autoproxySERVICE to ""
repeat with i from 2 to (count of services)
set autoproxySERVICE to item i of services as text
do shell script ("networksetup -setautoproxyurl " & (quoted form of autoproxySERVICE) & autoproxyURL) with administrator privileges
do shell script ("networksetup -setautoproxystate " & (quoted form of autoproxySERVICE) & " off") with administrator privileges
If you’re not comfortable running AppleScripts, you can do it manually as shown in the screenshot below, but remember you need to go through and do the procedure for every one of your services (Ethernet, Wi-Fi, Bluetooth Pan, etc) individually.
3. Remove the fake certificate
Thirdly, you’ll want to get rid of the fake certificate in the System keychain. In Terminal, search to see if the ‘cert.der’ certificate file still exists:
cd /tmp; ls -alF
If you see ‘cert.der’ listed, then issue the following command in the Terminal window:
security remove-trusted-cert -d /tmp/cert.der
Then, go back to Terminal and do
If not, then try both this
security remove-trusted-cert -D
and check in Keychain Access.app by searching for ‘Comodo’ and looking for a certificate that has the fake Comodo serial number:
00 EB 08 6A 4F 53 BE BA 4D.
4. Remove permissive admin access set by the malware
Back to Terminal for this one, and mind your typing. You don’t want to make any mistakes here…
At the command line prompt, type
and provide an Admin user name. You won’t be able to see what you type, so type slowly, but at least you get 3 goes at it.
When you’ve got that in correctly, you should see the sudoers file, it’ll look something like this:
Use the arrow key to move the cursor down to the beginning of the line that says
%USER_NAME_HERE% ALL=(ALL) NOPASSWD: ALL
On your keyboard hit the ‘d’ key twice (i.e, type
dd). The line should magically disappear*.
(that’s a semi-colon, a lowercase w, lowercase q and an exclamation mark) to save your changes and quit. That’s it!
And with that, you should be done with OSX/Dok malware! 🙂
*If anything went wrong in visudo, you can press the
u key once to undo your last action (the ‘u’ key only undoes the last keyboard action, so if you press it twice it’ll undo the undo = redo, so beware!)
do shell script "SD=~/.spindump.txt; rm $SD; spindump 1 1 -file $SD; grep 'Fan speed' $SD; rm $SD" with administrator privileges
Copy and paste the above into your (Apple)Script Editor and run it. You’ll need an Adminstrator password.
However, that doesn’t really tell you what you want to know: is my mac too hot or not? Should I do something about it?
Fortunately, we can get a better idea of the mac’s thermal state (and we don’t need admin privs to do it!), with this script:
The script not only reports the mac’s thermal state, but prints out Apple’s recommended advice, if any. Uncomment the last line of the script to get the result in a display dialog box; otherwise, you can just read the result in the results pane of your script editor.
Featured Image: Flicker
The idea behind BackupCam is to keep a continuous, rolling video of the last few minutes of activity on your mac, in just the same way as dash cams in cars work.
There’s a couple of scenarios where this might be useful. If you’re working on a project where ‘undo’ doesn’t always work reliably or when you most need it to – Xcode, for example, can often let you get your project in a mess without offering you a clear path as to how you got there or how to get back, short of discarding all changes in a particular file – with BackupCam you’ll be able to see exactly how you got to where you are.
Similarly, BackupCam can also help you to review changes that you may not have noticed at the time – perhaps if you were distracted by something else happening, either on screen or off. This can help both as a security and a troubleshooting tool
BackupCam can record up to the previous 30 minutes activity, so may help you recover something that is missed even by Time Machine or other traditional file backup mechanism.
More details are over on the BackupCam webpage, but I’ll just note here that BackupCam can also be controlled by AppleScript, with all the flexibility that that offers. Here’s a sample script that checks whether the last recording was longer ago than the time interval set in BackupCam. If it is, it kicks off a new recording session:
BackupCam is still in the early stages of development (we’re calling v1 a beta), so please feel free to report any bugs or enhancments you’d like to see. At the moment, it requires 10.11.6 or higher and only records the main display. I plan to add support for multiple displays in a future update.
Is it me, or is AppleScript experiencing something of an Indian Summer? It seems everywhere I go, people are talking more about macOS automation, AppleScript and even Apple’s curious hybrid syntax AppleScriptObjC (ASObjC).
Of course, some people have suffered miserably at the hands of AppleScript in the past, and even though the thought of scripting with access to Cocoa APIs through Objective-C is tempting, they fear the AppleScript side of it.
If that’s you, bear in mind that AppleScriptObjC isn’t really “AppleScript + Objective-C” at all. It is actually just a dialect of Objective-C that will be accepted in the (Apple)Script Editor and can be run by an instance of the AppleScript component. In plainer English, you can use Objective-C in an AppleScript without any AppleScript whatsoever!
The point of doing so would be that one could package Objective-C code in a .scpt file (or scptd bundle or AppleScript .app), and also mix whatever scripting language you prefer with calls to Cocoa’s APIs.*
The problem that using ASObjC presents anyone familiar with Objective-C is how to translate ‘pure’ Objective-C into the dialect that Script Editor (and other applescript runners like FastScripts, Keyboard Maestro, Automator, etc) can understand. If you use LateNight Software’s Script Debugger for scripting, you’ll already know that the work is done for you by the app’s built-in code completion. If you’re battling on in Apple’s default Script Editor, you’ll need to do the translation manually.
By way of example, then, here’s some original Objective-C, and below it, a translation that would work in Script Editor:
NSString *aString = @"hello";
NSString *bString = @" world";
aString = [aString stringByAppendingString:bString];
NSUserNotification *notif = [[NSUserNotification alloc] init];
notif.informativeText = aString;
[[NSUserNotificationCenter defaultUserNotificationCenter] deliverNotification:notif];
set aString to NSString's stringWithString:"hello"
set bString to NSString's stringWithString:" world"
set aString to aString's stringByAppendingString:bString
set notif to NSUserNotification's alloc's init
set notif's informativeText to aString
NSUserNotificationCenter's defaultUserNotificationCenter()'s deliverNotification:notif
As you can see, there’s a direct 1-to-1 correspondence, with the 6 statements in Objective-C paralleled by the 6 statements in AppleScriptObjC.
The main peculiarity is the use of possessive word forms and that variable attribution is done by using
"set X to Y" rather than
"X = Y". Type declaration is done via the idiom
'set <var> to <NSObject>'s <class init method>', which returns an instance of the object just as it would normally. You call instance methods by putting the instance in front of the method just as you would in regular Objective-C (e.g, see line 3 of the examples).
As you can see in the screenshot below showing Xcode and Script Editor, they work in the same way. You’ll notice in Script Editor there is a
'use' statement (equivalent to Objective-C’s ‘import’), and there’s also a whole load of property statements. These latter are peculiar to the ASObjC translation, and don’t have a counterpart in pure Objective-C. All you need to know about these is for each kind of Objective-C object you want to use (NSString, NSArray, whatever*), you’ll want a property statement for it at the beginning of the script. The statement always has the same form:
property <NSObject> : a reference to current application's < NSObject>
I think the best way to think of ASObjC was recently summed up by Sal Saghoian, when he said that ASObjC is “…the ultimate duct tape. You can do anything you want with ASObjC. You own the computer.”
*not all Cocoa frameworks nor all Objective-C objects can be bridged to, but pretty much all the most useful ones are available.
I recently discovered a neat little extra automation tool on top of the familiar ones of AppleScript, Automator, and script runners like FastScripts and Keyboard Maestro. Meet Hammerspoon, which differs significantly in not using Apple Events to do many of its automation tasks. Instead, Hammerspoon bridges directly to Apple APIs using the lua scripting language, and that allows you to do some interesting things.
Here’s a good example. One of the ‘danger zones’ on your mac – by which I mean one of the favourite places for adware, malware and other assorted badwares to infect – is your LaunchAgents folders. Apps like my DetectX and FastTasks 2 keep an eye on these areas by design, warning you in the Changes and History logs when files have been added or removed from them – but Hammerspoon can add an extra little ‘canary’ warning for you too. With only a few lines of code in Hammerspoon’s config file, you can set up an alert that will fire whenever the LaunchAgents folder is modified.
It has been possible to rig up something similar for a long time with Apple’s built-in Folder Actions, but there’s a couple of reasons why I prefer Hammerspoon for this task. One, despite Apple’s attempt to improve Folder Actions’ reliability, I’m still not convinced. I get inconsistent reports when asking System Events to check whether Folder Actions is enabled even on 10.11 and 10.12. Second, Folder Actions is limited in what it will respond to. By default, only if an item is added. With a bit of effort, you can rig it up to watch for items deleted, too, but that’s pretty much it. With Hammerspoon, it’ll alert you whenever the folder or its contents are modified in any way whatsoever. The final reason for preferring Hammerspoon for this particular task is ease of use. It really is as simple as pasting this code into the config file:
hs.alert.show("Launch Agents folder was modified")
hs.alert.show("Canary folder was modified")
local aWatcher = hs.pathwatcher.new(os.getenv("HOME") .. "/Library/LaunchAgents/", myFolderWatch):start()
local bWatcher = hs.pathwatcher.new(os.getenv("HOME") .. "/_Acanary/", canaryFolderWatch):start()
And what’s the config file you ask? Nothing complicated! Just launch Hammerspoon, click its icon and choose ‘open config’.
That will launch your default text editor, and all you do is paste your code into there, save it (no need to tell it where, Hammerspoon already knows) and then go back to the Hammerspoon icon and click ‘Reload config’. That’s it. Less than a minute’s work!
There’s a lot, lot more you can do with Hammerspoon, so if you’re interested head off and check out the Getting Started guide. One of the nice things is that you can even call AppleScripts with it, so you really do have a world of automation options to choose from!
I’ve been wondering ever since Yosemite what Apple had done to mess up Spotlight. It used to be my go-to way to launch apps. Faster than LaunchPad, the Dock or, of course, trawling through the Finder.
But something happened after Mavericks, and things have only being getting worse with Spotlight, right up to and including into Sierra.
Not only has Spotlight been slowed down with ads and ‘suggestions’, but we’ve also even lost the choice of re-ordering search results priority in Spotlight preferences.
I find Spotlight is not only slower than before, but it doesn’t always return the hit I want even when I know what I’m looking for. For a while, I got into the habit of searching using
locate in the Terminal. Like Spotlight, these use an index based search so can return results very fast. Eventually, I got fed up of that, and wrote my own search tool and added it to FastTasks 2
All this is not good, and if you are seeing the same degradation in Spotlight’s usefulness as I have been, try unchecking the following Preferences and see if it works to get Spotlight back up to a useful speed. With these disabled, I’ve seen a remarkable improvement in Spotlight in macOS 10.11.6.
I tend to work on the iMac at home, then take an MBP to work. Several times I’ve thought iCloud had uploaded what I had been working on at home before I left, only to find that when I got to work, the old version was still the latest one on iCloud. Of course, I checked for the spinning little progress indicator, but apparently I either missed it or it didn’t appear.
To mitigate this problem, I came up with this script to tell me what iCloud daemon is doing. If files are pending update or being updated, it will indicate which ones. It will also tell me if the iCloud daemon is either idle or busy / not responding.
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! 😀