ConsoleSpy is a simple but powerful little app that offers a window into system.log and which can trap incoming messages meeting user-defined search criteria. It’s aimed at software testers, bug hunters, security researchers and anyone who needs to do analytical troubleshooting work on a mac.
Minimum system requirements: OS X 10.11. ConsoleSpy is currently free.
Here’s an intro to its features and how you can use ConsoleSpy to aid in analysing your mac and your software.
What does it do?
The best way to illustrate the use case for ConsoleSpy is to consider a couple of ‘based on a true story’ user problems I’ve encountered recently.
Case 1: In one case, a user was concerned that an attacker was logging into her computer remotely. Unaware of how that might be happening, the user searched the Console.app and found a number of suspicious remote login attempts. However, these always seemed to occur at times she wasn’t at the computer and sometimes weeks apart. It became a laborious job and anxious routine for her both to remember and to search through the Console logs every morning to see if anything suspicious had occurred.
Case 2: In the second case, a user realised that the Time Machine backups she’d been relying on had been silently failing to pass verification checks. There was no indication from Time Machine itself, and she only discovered the problem, weeks after it had began, by a fortuitous glance at the Console.app where she discovered multiple ‘Backup verification failed’ messages.
In both these cases, ConsoleSpy could have alerted the user to the problem as soon as it had occurred. ConsoleSpy allows you to set search terms to trap incoming messages. Both a Dock badge and a visual indicator in ConsoleSpy’s display indicate when a message has been trapped. By using the search term ‘sharing,’, our user worried about remote hacking would have instantly been able to see if a log in had been attempted and when. Our user with the failed backup problem would have likewise been alerted instantly the first time the problem occurred by using ‘backup,’ or ‘backup verification,’ (if she had only wanted to trap specific verification messages) as Alert strings.
ConsoleSpy becomes more useful the more accurately you know what you’re looking for. For bug hunters and software developers, simply setting an alert on your app or process id name will immediately funnel all incoming messages into ConsoleSpy’s ‘Alerts received’ box, allowing you to exercise your app in various conditions and immediately see the results. You can get as specific or as general as you want, but do see the help on Alert string syntax.
How do I use it?
After launching ConsoleSpy, you’ll be presented with an ‘always on top’ display of the most recent message into the Console. You can move the display around by clicking anywhere in the black part of the display and dragging. The four buttons on the right hand side offer you access to all of ConsoleSpy’s main functions, clockwise from top left:
i. Freeze the display: in the event that you see something interesting and want more time to read it before the next message comes in, you can lock the display by clicking the little padlock button. When locked, the text in the display changes colour and a padlock appears at the end of the text. Note that when the display is locked, the View buttons in the Preferences window (See below) will have no effect. Click the padlock again to unlock the display.
ii. Hide ConsoleSpy: click the orange button to hide ConsoleSpy. Often, you won’t want the display visible but you will want ConsoleSpy to keep watching for alerts. You can also hide the app with ‘Command-H’.
iii. Open Console.app: the little ‘eye’ button immediately opens Console and takes you to the most recent message in system.log.
iv. Preferences: this is a toggle button that opens or closes the Preferences drawer. We’ll get to that next.
The controls on the far left should be self-explanatory, but a couple of notes are in order.
View: As mentioned above the ‘View’ buttons are disabled when the display is locked, but otherwise they toggle the length of the display. The ‘Long’ view is particularly useful when reading multiple messages in the ‘Alerts received’ box.
Frequency: this controls the frequency at which ConsoleSpy updates the display. Note that ConsoleSpy continues to scan for messages that meet your Alert string criteria even between polls regardless of whether the app is visible or hidden, or the display is locked (see above). ConsoleSpy’s buffer can handle up to 40 messages between polls. If ConsoleSpy’s buffer is flooded with more than that, the display will show a ‘Flood’ warning. For more information see ‘The Hoary Gory’ section below.
Alert Strings: this is the most important field you’re going to want to manage. When you first launch ConsoleSpy, you’ll see some default search strings are already included by way of example. You can remove or add to them by clicking the ‘Edit’ button at the bottom left of the text box. Search string syntax is fairly basic, but allows you to be as specific or as general as you wish. Ensure that each term is comma-separated and the entire list is comma-terminated (i.e, there should be a comma after the last search term in the list, too). Click the ‘?’ button to go to the support page giving examples of search string syntax. Drop us a line in the Comments if you need help or contact Sqwarq support.
Alerts received: this is the main display for your results. You can select and copy all or parts of the message to search in Console.app if you want to see the message in context. Using the date string without the seconds is a particularly useful way to search for messages in Console if you want to see what else was happening around the same time.
You can clear the ‘Alerts received’ box (and the Dock badge and the display alert symbol) by clicking the ‘-‘ minus button at the bottom left of the text box. We suggest regularly and promptly removing messages from the Alerts received box once you’ve read them as the messages are already archived in Console.app.
The Hoary Gory
ConsoleSpy polls the system log every 1, 2 or 5 seconds according to the Frequency setting in the Preferences, and displays the most recent message. Unless the system log is being flooded with more than 40 messages since the last poll, ConsoleSpy won’t miss a thing and you’ll get an alert if any message meets your search criteria, even if it wasn’t displayed in ConsoleSpy’s display. If ConsoleSpy’s buffer is flooded, a small ‘flooding’ alert symbol shows in the display. The start and end flood times can be displayed in the Alerts Received box by setting an alert string for ‘flood,’.
If you experience a lot of flood warnings (entirely possible in scenarios where you are beta testing software or even the operating system itself), try using a faster frequency (i.e, 1 sec). While this may seem counterintuitive, it is a consequence of ConsoleSpy’s fixed buffer size. The buffer can hold up to 40 new messages since the last poll, so the amount of messages ConsoleSpy can search between each poll is 40/(frequency). As we develop the app, we plan to include a choice of larger buffer sizes. The current buffer size is a conservative choice designed to ensure the app is usable even on smaller, less powerful macs.
If you’re already using the fastest poll time of 1 sec and flood warnings are occurring constantly, this is a good sign that some software is not behaving as intended. Of course, when testing beta software, especially a beta OS, there may be so many deliberate logs to the system log that ConsoleSpy reports flooding almost all the time. This is not a problem for ConsoleSpy; indeed, having ConsoleSpy alert you of flooding is one of its intended functions, so that you can see just when and how often something is happening. The main thing to be aware of during times of repeated or constant flooding is that ConsoleSpy may not be able to search every single message received against your search terms. You can, of course, turn Alerts off during such times, but a better solution is to leave Alerts on (ConsoleSpy will still return most if not all search hits, depending on how severe the flooding) and simply use the Console.app itself to do an historical search to see if any crucial messages you would have expected but which did not get spotted by ConsoleSpy are in the log.
Note that while Alert string searches begin as soon as ConsoleSpy is launched, flood detection is not enabled until 30 seconds after launch. This is due to the fact that ConsoleSpy’s buffer needs to be full before it can determine the rate of incoming messages.
That about rounds up our introduction to ConsoleSpy. We hope you find it useful, and if you have any questions, drop us a comment or email us at Sqwarq support.
If you find Time Machine’s taciturn silence on what it has and will do a bit frustrating at times, the command line utility tmutil can offer you a bit more insight.
In particular, if you’d like to see what Time Machine is going to back up just before it’s about to run, execute the following command in the Terminal:
That will compare the machine as it is now against the last backup (See the man page for more options on the output). It took about 5 minutes on my mac, but I have a small hard drive. It could take somewhat longer depending on how much data you’ve got to trawl through. Remember that you’re doing a diff on a moving target, so the less you can use the machine for other tasks while this command is running the faster it’ll complete.
On the other hand, you might want to know more about what Time Machine has just done after a backup. Which files did, or did not, get changed, added or removed?
You can find out what got backed up after the task finishes by comparing the most recent snapshot (the one that’s just completed), with the previous one (this is much faster, took about 35 seconds here). You can do that in Terminal, too, but the syntax can be a bit tricky. To make it easier, here’s a handy AppleScript that will do it for you. Just pop it into the (Apple)Script Editor.app and hit the ‘Run’ ▶︎ button.
# This script compares the most recent backup to the previous one
# indicating what was changed, added or removed
set backupList to paragraphs of (do shell script "tmutil listbackups")
if (count of backupList) < 2 then
display dialog "Sorry, couldn't find anything to compare. Try again after the next backup"
set path1 to quoted form of item -2 of backupList
set path2 to quoted form of item -1 of backupList
do shell script "tmutil compare " & path1 & " " & path2 & " | open -f"
If you’re finding that the large blue location circle is obscuring your view of your current location, here’s a quick script that will allow you to toggle it on and off. You could create a Service and then a hotkey for it, or save the script as an Application and add it to your Dock. That’ll give you a one-click method for toggling the circle on and off – you can also turn it back on (but not off!), just by clicking the usual Location button in Maps’ user interface.
Posted: 10th May, 2013
If you have multiple accounts on your mac, you may sometimes wish to log out one or more of those accounts without actually having to sign in to them first via the fast user switching menu. There’s a couple of ways to do this. First, if the issue is just that you want to shutdown the computer, you can log out all users by entering an Admin user name and password when this dialogue automatically appears after hitting ‘Shutdown’ (it won’t appear if no other users are logged on):
However, there are times when you may just want a quick way to log out users without shutting down and without wasting time logging in to their accounts first. Be aware that in killing a user’s process without logging in to the account first, any data in that user’s account that is not already saved (or autosaved) will be lost. If you’re sure that’s not a problem, then follow this short procedure manually or use the AppleScript version that follows:
1. Open up Activity Monitor (/Applications/Utilities/Activity Monitor.app)
2. Use the drop down menu in the Task bar to change the menu to ‘Other User Processes’ (note: you can use ‘All Processes’ in the menu if you wish, but that is less safe as it makes it possible to accidentally click on your own user process in step 4 below!).
3. In the filter bar, type
4. From the list of users that show up, for each one that you wish to log out:
- click on its row in the Activity Monitor pane to highlight the process
- press the ‘Quit Process’ icon in the Task bar above
- from the resulting dialogue window, click ‘Force Quit’
- supply an Admin password if requested.
Repeat for any further accounts that you wish to quit. (Tip: If you want to kill the ‘Guest User Account’, you’ll need to switch back to ‘All Processes’ and kill the loginwindow assigned to the ‘root’ user).
And that’s it. Your unwanted users are now logged out!
Update 30th April, 2016: If you get tired of doing this manually, you can log out all other real users at once with this AppleScript:
set thisUser to do shell script "whoami"
set usrList to paragraphs of (do shell script "ps caux -o args | grep loginwindow")
repeat with i from 1 to number of items in usrList
set this_item to item i of usrList
set thatUser to word 1 of this_item
if thisUser is not equal to thatUser then
set theProcessNum to word 2 of this_item
do shell script "kill -9 " & theProcessNum with administrator privileges
To help ameliorate that, I’ve produced a script that will abort a scheduled backup task using Carbon Copy Cloner if a user-defined percentage of changes have occurred in a designated ‘Canary’ folder.
Here’s how it works. In order to be successful, ransomware must change a large percentage, if not all, of your personal files in your Home folder by encrypting them. That means we can determine if a folder has been encrypted by looking for an unusual amount of changes or additions since the last backup.
A Canary folder is a folder that we use to warn us of precisely that. It should be a folder that contains some random dummy files (.doc, .png, .xls files etc), and/or a folder which you don’t make large changes to from one backup to the next. The script itself will change the folder slightly each time it runs, to ensure that the Canary folder does not look like it’s ‘stale’ (which might cause an attacking script to ignore it).
The key to the Canary is that the percentage of files changed or added on each scheduled backup is less than the threshold you set in the script. The default is set to no more than 10%. If the number of files changed or added is higher than that, then the backup aborts. You can of course change the default to a bit higher if you use a ‘real’ folder that you don’t change often, but remember we’re only talking changes between one scheduled backup and another, so it will also depend on how frequently your backups are scheduled.
For example, I have a 2-hour scheduled backup and I use my ‘Documents’ folder as the Canary. Since I only use that folder for long-term archives, it is actually rarely changed, and certainly never as much as 10% within 2 hours, and that makes it a perfect choice as a Canary. You can pick any real, rarely used folder or you can set up a complete dummy folder if you prefer.
If you do pick a real folder, keep in mind its size. The larger the folder, the longer it’s going to take the script to determine the differences between it and the last backup of it. A couple of thousand files is OK, but once you get into the tens of thousands you might find the script takes several minutes to complete. With only a few hundred files in my Documents folder, it takes literally a second or two.
Here’s a sample output from the log file the script produces in the ‘Canary’:
Destination /Volumes/Backup Disk/Users/phil/Documents has 360 files in the folder. There are 3 changes between it and the source /Users/phil/Documents. The threshold for aborting the task is 10 percent, or 30 changes. Result: task will run.
For our strategy to be successful, we need to ensure the attacking script doesn’t ignore the Canary and does try to encrypt the Canary before the next backup is scheduled. For that reason, if you opt for a complete dummy folder, you might like to give it a name so that it’s somewhere near the beginning (alphabetically) of your Home folder. Since the Canary folder will be slightly modified each time the script runs, it should get hit early if the attack is looking either for recently modified files or just starts trawling your home folder in ascending name order (and I know what you’re thinking: what about descending order? Sure, you could add another Canary at the end, and modify the script to check both ;)).
Note that this script is for use only with a regular, scheduled backup task, and only for use with Carbon Copy Cloner (version 4). We’ll be posting about Time Machine strategies later.
Another note of caution is that while this script should stop your scheduled CCC task from infecting a backup drive, it won’t stop an attacking script from attempting to encrypt any mounted drives it finds by itself. That really depends on the sophistication of the attack. To that end, we’ll soon be posting a general strategy for detecting a ransomware attack on your internal drive using multiple Canaries and a bit of Folder Action script magic. Stay tuned for that.
In the meantime, here’s the script. Due to the vagaries of WordPress.com formatting, I’ve hosted it over on my pastebin. Please read the extensive comments, which also explain how to set it up and how to use it. Any questions, drop a comment below.
Picture Credits: ‘Caged Egg’ by Marije Berting
This update sees the introduction of a major new feature, the TaskPad. If you’ve ever been frustrated by the limitations of Apple’s Notes and Reminders apps and wondered why they didn’t, well, just combine the two, then FT2’s TaskPad may be for you.
Inspired by one of my favourite free apps from the Snow Leopard era, Lighthead software’s Remember.app (still available but sadly never updated to 10.7 and beyond), the TaskPad keeps things light and simple, while having a lot of power to keep you organised and on task.
You can set due dates, add rich-text notes, as well as order and re-order via drag and drop. If you want to use the same database across more than one mac, that’s possible, too (requires an independent syncing service such as Dropbox or similar). You can also maintain more than one list database and switch between them as you need.
Since FastTasks is all about being fast, you don’t need to wade through the main menu to call up the TaskPad (though of course you can do that if you want!). Just hold down the Command key and click the F2 icon and the TaskPad will immediately appear.
Another change in this update is that the Eject Disks function will now let you eject individual disks as well as all disks. We’ve also updated the Analyser with new definitions.
The FT2 2.8 update is available to users on 10.10.5 or above. Unfortunately, FT2 no longer supports OS X Mavericks, but 10.9 users can still download the previous version (2.7) of FT2 for the time being.
We’re now up to v2.22 of DetectX.
The major change is that we’ve moved to a generous 60-day trial period for non-license holders. Prices for home use and commercial use remain at $15 & $79.99, respectively, as promised for the remainder of v2 releases.
Heads up though, folks. DetectX 3 is nudging over the horizon (we’ve been working on it since late last year and only need to get the next FastTasks update out of the way first!) and the price of both home and commercial license keys is expected to rise for unregistered users. DetectX 3 will bring a modern UI interface and a whole new suite of tools intended to make it the most powerful tool on the market for analysing and troubleshooting you mac. If you hold a license key for any version of DetectX 2 prior to the release of version 3, you’ll get a free upgrade to DetectX 3.
The release notes for DetectX 2.22 can be found here.
It all started with 2.16, which introduced some changes to the licensing and user interface. All well and good, until we noticed a serious security issue with Microsoft Silverlight had recently surfaced, and we didn’t want to wait to address it.
That resulted in 2.17, which added a Silverlight check to the detector Search function. If you have a version of MS Silverlight that is not the currently patched version, you’ll see a warning in the log drawer when you run a search. In 2.17 we also fixed a false positive in the Keylogger detector and updated some search definitions.
Alas, we’d inadvertantly let a bug slip in with v2.16 that prevented DetectX from quitting in certain situations. Luckily that report came in pretty quick (many thanks to Al), and we were able to address the bug with a simple code tweak (if you got bit by that bug, please open and then close the Licensing window before attempting to update to v2.18).
So, here we are at version 2.18 … we’re a bit breathless, so it’s time for a sit-down and a nice cup of tea!
Yes, two in two days! We’ve added a Preference Pane since yesterday, and improved the performance of the search function. Note that the new Sparkle Vulnerability check we introduced in v2.13 is now off by default. It can be turned on from the Preference Pane (see above).
Other changes are listed in the release notes.
DetectX is still free, fully-functional, and without time-limit for home users. Available for download from here.