Category Archives: Security

how to keep the iDoctor away

DetectX console log
DetectX has been updated today to v2.37, and amongst other changes now detects and removes This piece of software appears to be another MacKeeper clone, with both sharing a common interface, code and file structures.

In the screenshot above, you can see DetectX doing its work – note the parallel file detections as DetectX hunts down both MacKeeper and iDoctor.

Below is a sidebar shot of MacKeeper on the left and iDoctor on the right. Underneath that are shots showing how the two interfaces are almost direct mirrors of each other. It’s hard to believe these are not both being built from the same base code, and we strongly suspect that the developers of iDoctor are very likely the same developers of MacKeeper, or at least real close friends!

MK vs iDoctor



how to keep track of XProtect & friends

Over on Sqwarq, we’ve just released a new security and troubleshooting utility, the Critical

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.

discovering how Dropbox hacks your mac

Screen Shot 2016-08-26 at 23.05.27

Update: Dropbox hack blocked by Apple in Sierra

Following my post revealing Dropbox’s Dirty Little Security Hack a few weeks ago, I thought I’d look deeper into how Dropbox was getting around Apple’s security.

After a little digging around in Apple’s vast documentation, it occurred to me to check the authorization database and see if that had been tampered with. According to the docs:

In a policy-based system, a user requests authorization—the act of granting a right or privilege—to perform a privileged operation. Authorization is performed through an agent so the user doesn’t have to trust the application with a password. The agent is the user interface— operating on behalf of the Security Server—used to obtain the user’s password or other form of identification, which also ensures consistency between applications. The Security Server—a Core Services daemon in OS X that deals with authorization and authentication—determines whether no one, everyone, or only certain users may perform a privileged operation.

The list of authorization “rights” used by the system to manage this “policy based system” is held in /var/db/auth.db database, and a backup or default copy is retained in /System/Library/Security/authorization.plist.

Looking at the default with

defaults read /System/Library/Security/authorization.plist

we can find that there is an authorization right for System Preferences’ Accessibility list, which says:

"system.preferences.accessibility" = {
class = user;
comment = "Checked when making changes to the Accessibility Preferences.";
group = admin;
shared = 0;
timeout = 0;

That file’s comments also state that “The allow-root property specifies whether a right should be allowed automatically if the requesting process is running with uid == 0. This defaults to false if not specified.”

In other words, if allow-root isn’t explicitly set, the default is that even a process with root user privileges does not have the right to perform that operation. Since that’s not specified in the default shown above, then even root couldn’t add Dropbox to the list of apps in Accessibility preferences. Is it possible then, that Dropbox had overriden this setting in the auth.db? Let’s go and check!

To see what the current policies are, you have to actually read the sql database in /var/db/auth.db. There’s various ways of doing that, but the easiest for me was to access auth.db through the command line using the security tool. Issuing the following command in Terminal will return us the currently active policy for Accessibility:

security authorization read system.preferences.accessibility

On my machine, this returned:

Screen Shot 2016-08-26 at 20.57.12

Root wasn’t allowed to override Accessibility, and authenticate was on, so it couldn’t be this way that Dropbox was hacking my mac.

Security on OS X is a complex beast, however, and there are other authorization protocols at work. One that I already knew of is tccutil. If you issue man tccutil in Terminal, you’ll see this:

tccutil(1) BSD General Commands Manual tccutil(1)

tccutil — manage the privacy database

tccutil command service

The tccutil command manages the privacy database, which stores decisions the user has made about
whether apps may access personal data.

One command is current supported:

reset Reset all decisions for the specified service, causing apps to prompt again the next time
they access the service.

To reset all decisions about whether apps may access the address book:

tccutil reset AddressBook

Darwin April 3, 2012 Darwin

I had heard of a hack of this utility that was related directly to adding apps to Accessibility list over a year ago when I stumbled across this stackexchange page. In short, what that hack suggests is that you modify tcc directly by inserting an entry into the sql database located here /Library/Application Support/

You can read the current list with the command:

sudo sqlite3 /Library/Application\ Support/ 'select * from access'.

To insert an app in the list, you grab it’s bundle identifier (in the case of Dropbox, that’s com.getdropbox.dropbox), and issue:

sudo sqlite3 /Library/Application\ Support/ “REPLACE INTO access VALUES(‘kTCCServiceAccessibility’,’com.getdropbox.dropbox’,0,1,1,NULL, NULL);”

(*note the code given on the stackexchange page isn’t quite correct for the latest builds of the mac operating system, in which the access table now has 7 columns and so requires and extra “NULL” on the end as shown above).

I tested this with several of my own apps and found it worked reliably. It’ll even work while System Preferences is open, which is exactly the behaviour I saw with Dropbox.

It remained to prove, though, that this was indeed the hack that Dropbox was using, and so I started to look at what exactly Dropbox did after being given an admin password on installation or launch. Using DetectX, I was able to see that Dropbox added a new folder to my /Library folder after the password was entered:

Screen Shot 2016-08-26 at 21.36.35

Screen Shot 2016-08-26 at 21.37.09

As can be seen, instead of adding something to the PrivilegedHelperTools folder as is standard behaviour for apps on the mac that need elevated privileges for one or two specialist operations, Dropbox installs its own folder containing these interesting items:

Screen Shot 2016-08-26 at 21.40.45

Not one, but three binaries! I wonder what they do? The first thing I did on each was to run the strings command on them. I still haven’t determined what that 1.5MB DropboxHelperInstaller binary is doing (that’s pretty big for a binary for a helper app), but its jam-packed with strings relating to file compression and encryption. The string output for dbfseventsd binary didn’t reveal anything much interesting, but with the deliciously named dbaccessperm file, we finally hit gold and the exact proof I was looking for that Dropbox was using a sql attack on the tcc database to circumvent Apple’s authorization policy:

Screen Shot 2016-08-26 at 23.05.27

This is all the more telling when we look at what Dropbox themselves say when queried about why their app is in the list of Accessibility apps here. After a great deal of obfuscation, misdirection and irrelevance in which they mention everything about permissions in general and nothing about Accessibility in particular, or that they’re hacking their way into the user’s Accessibility list rather than going through the supported channel of presenting the user with a dialog box and asking for permission, comes this line:

we need to request all the permissions we need or even may need in the future.
(my emphasis)

Ostensibly, that’s in the context of Drobpox on mobile apps, but since the question isn’t related to mobile apps at all, I think interpreting anything said there as being honest is naive at best. What I do suspect, especially in light of the fact that there just doesn’t seem to be any need for Dropbox to have Accessibility permissions, is that it’s in there just in case they want that access in the future. If that’s right, it suggests that Dropbox simply want to have access to anything and everything on your mac, whether it’s needed or not.

The upshot for me was that I learned a few things about how security and authorisation work on the mac that I didn’t know before investigating what Dropbox was up to. But most of all, I learned that I don’t trust Dropbox at all. Unnecessary privileges and backdooring are what I call untrustworthy behaviour and a clear breach of user trust. With Apple’s recent stance against the FBI and their commitment to privacy in general, I feel moving over to iCloud and dropping Dropbox is a far more sensible way to go for me. For those of you who are stuck with Dropbox but don’t want to allow it access to Accessibility features, you can thwart Dropbox’s hack by following my procedure here.


Further Reading:

Dropbox hack blocked by Apple in Sierra

Revealing Dropbox’s Dirty Little Security Hack

Hackers steal over 60m Dropbox user account passwords

How keyloggers get around OSX Security


revealing Dropbox’s dirty little security hack

Screen Shot 2016-07-28 at 14.54.30

Update: also see Discovering how Dropbox hacks your mac

If you have Dropbox installed, take a look at System Preferences > Security & Privacy > Accessibility tab (see screenshot above). Notice something? Ever wondered how it got in there? Do you think you might have put that in there yourself after Dropbox asked you for permission to control the computer?

No, I can assure you that your memory isn’t faulty. You don’t remember doing that because Dropbox never presented this dialog to you, as it should have:


That’s the only officially supported way that apps are allowed to appear in that list, but Dropbox never asked you for that permission. I’ll get to why that’s important in a moment, but if you have the time, try this fascinating experiment: try and remove it.

Ok, you say, no problem. We all know how to do that – open the padlock, un-click the checkbox. Click the ‘-‘ button to remove it from the list. Simple, right? Look there it goes, no more Dropbox in the the Preferences panel, right?

Wrong…like a bad penny it’ll be back again before you know it. Either log out and log back in again or quit Dropbox and restart it. Dropbox will surreptitiously insert itself back in to that list AND the checkbox will be checked. That’s the magic of Dropbox for you. If you don’t want to try it for yourself, watch me do it:

That leaves a couple of questions. First, why does it matter, and second, is there any way to keep using Dropbox but stop it having access to control your computer?

There’s at least three reasons why it matters. It matters first and foremost because Dropbox didn’t ask for permission to take control of your computer. What does ‘take control’ mean here? It means to literally do what you can do in the desktop: click buttons, menus, launch apps, delete files… . There’s a reason why apps in that list have to ask for permission and why it takes a password and explicit user permission to get in there: it’s a security risk.

Interlude: Contrary to Dropbox’s completely spurious “explanation”/obfuscation here, Accessibility has nothing at all to do with granting permissions to files. Accessibility frameworks were first introduced in Mac OS X 10.2 and expanded in 10.3 to allow control of user interface items via System Events and the Processes suite. As anyone can readily see, what that allows is GUI control just as if the program or script was clicking buttons and menu items.

But perhaps you implicitly trust Dropbox to not do anything untoward. After all, they’re a big name company who wouldn’t want to upset their customers, right?

There’s two flaws in reasoning that way. One: the bigger the name, the less effect customer dissatisfaction has. Let’s face it. If a 1000 people read this post and stop using Dropbox because of it, it’s not going to make much difference to Dropbox. So assuming you can trust a “big name” company not to “feck you off’ because they might lose your business is not “smart computing”, even less smart if they figure that you’re a customer on a free plan anyway… :p (See this for more reasons why big companies in general don’t pay much attention to ethical values). Two, and more importantly, you already have hard proof that Dropbox can’t be trusted. It just overrode your and Apple’s security preferences without asking you, and – as you’ve seen if you tried to remove it and noticed its magic reappearance act – it disregards your choices and re-inserts itself even after you’ve explicitly removed it (we’ll sort this naughty behaviour out in a minute).

It matters for another reason, too. Let’s assume for the sake of argument that Dropbox never does any evil on your computer. It remains the fact that the Dropbox process has that ability. And that means, if Dropbox itself has a bug in it, it’s possible an attacker could take control of your computer by hijacking flaws in Dropbox’s code. Of course, that’s entirely theoretical, but all security risks are until someone exploits them. The essence of good computer security and indeed the very reason why OSX has these kinds of safeguards in place to begin with is that apps should not have permissions greater than those that they need to do their job.

Which is the third reason why it matters: Dropbox doesn’t appear to need to have access to Accessibility features in order to work properly (update). I figured out what Dropbox was up to in October 2015. Why has it taken me this long to write about it? First, because after having reported it to Apple Product Security at that time, I wanted to see if they would force Dropbox to change this behaviour (they haven’t…yet ;)). Second, because the only way I could be sure that DB didn’t need to be in the list of apps with Accessibility privileges was to test it over a period of time. I use Dropbox across 3 different macs and an iPhone. I haven’t experienced any issues using it whatsoever while denying it access to Accessibility. Caveat: I haven’t tested Dropbox against all of OSX’s Accessibility features, but certainly for a ‘standard’ set up of OS X, it is not needed – and, let me repeat, even if it were needed for some particular feature to work, Dropbox should have explicitly asked for this permission, like every other app, and obeyed the user’s decision to revoke that permission when removing it from the list of allowed apps.

There really isn’t any excuse for Dropbox to ride roughshod over users’ security and preference choices. So that leaves us with just one last question: how to get Dropbox out of there? The short answer is that you first quit Dropbox, then remove it from the Accessibility pane, then delete the DropboxHelperTools folder (see my procedure here). Relaunch Dropbox, but now you hit ‘Cancel’ when it asks you for an admin password:

Stop! Choose 'Cancel' !!!

Stop! Choose ‘Cancel’ !!!

The dialog box apparently lies (again, still trusting this big name firm?) when it says Dropbox won’t work properly and clearly deceives because this is NOT the dialog box that Dropbox should be showing you to get access into Accessibility. Indeed, even with your admin password, it still shouldn’t be able to get into Accessibility. Clearly Dropbox’s coders have been doing some OS X hacking on company time.

Now, there’s a slight catch. So long as you never give Dropbox your admin password, it won’t be able to install itself in Accessibility and you can keep on using Dropbox just as you have done before. However, it will throw up this dialog box on every restart of the machine or relaunch of Dropbox. So the catch is that you have to actually notice what’s asking you for your password and not just blindly throw your password into the box without looking. :O

But you shouldn’t be doing that anyway, of course, cos that’s not good security practice… 😉 , but given that the dialog box looks just like*** an authentic password request from the OS itself, that may be a habit you have to train yourself into.

Slightly annoying, but not as annoying as having an app hack your mac (of course, if you forget, you’ll have to go uninstall Dropbox again, remove it from Accessibility, then reinstall it).


***But not “like” enough – note the ‘Type your password…’ sentence is both misaligned and is spaced into a separate paragraph, unlike genuine authentication requests from OS X. The phrasing of the first sentence “your computer password” is also very “un-OS X”.

Further Reading: Discovering How Dropbox Hack’s Your Mac

Last edit: 21 Sept, 21:35 ICT.


keep an eye on Console with ConsoleSpy


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.

Screen Shot 2016-05-22 at 13.22.36

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

Screen Shot 2016-05-22 at 11.24.57

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:

Screen Shot 2016-05-22 at 13.49.17

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

Screen Shot 2016-05-22 at 13.24.10


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

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

Download ConsoleSpy

how to stop ransomware infecting a backup disk



If you use a scheduled backup task such as Time Machine or Carbon Copy Cloner, any ransomware infection of your internal drive could soon propagate to your scheduled backup.

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

Screen Shot 2016-04-29 at 11.00.23



Picture Credits: ‘Caged Egg’ by Marije Berting



FastTasks 2 v2.8 released

Screen Shot 2016-03-27 at 19.09.23


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




news: DetectX v2.18 released

We’ve had a bit of a mad day here at Sqwarq and Applehelpwriter, releasing three updates within a few hours of each other for DetectX.

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!

Enjoy 🙂

how to: check for Sparkle vulnerability

Screen Shot 2016-02-12 at 15.32.18

[updated Mon 15th:]

Here’s what we know about the widely-reported vulnerability found in Sparkle so far:

1. It requires a version of Sparkle earlier than 1.13
2.1 It requires the SUFeedURL address to be an unencrypted http address AND/OR
2.2 the release notes address to be an unencrypted http address.

Condition 1 and one (or more) of conditions 2 need to be true to make the exploit possible. You can check to see if condition 2.1 is true for many apps on your system with the following procedure:

1. Control-click on the app in the Finder
2. Choose ‘Show Package Contents’
3. Navigate to /Contents/Info.plist
4. Hit the space bar to open in quick look, scroll down for the SUFeedURL field (it won’t have one if it doesn’t use Sparkle). The field will show you whether the address is https or not.

To make life easier, you can run this script in the AppleScript Editor (/Applications/Utilites/Script to do the job for you.

#script version 1.64
#regression to 1.52 and then
#added: now includes apps that do not have SUFeedURL key in plist and reports their Sparkle version number
#added: borrowed Bill Cheeseman's idea of using choose list and offering to launch the app
#added: borrowed reverse_offset handler from Nigel Garvey's post on MacScripter
#changed: test if Sparkle is < 1.13.1 first
#shows the Sparkle version number for each entry in the list
#added logic for opening prefPanes if chosen from the list
#changed the mdfind command to improve speed
#searches for keys of the form "SUFeedURL*" rather than just "SUFeedURL"

on extractSUFeedURL(aRecord)

set aRec to "httpx"
set aRec to item 1 of aRecord
on error errorMessage
set aRec to errorMessage
set aRec to my parseErrorMsg(aRec)
end try

return aRec

end extractSUFeedURL

on parseErrorMsg(aErr)

set what to "SUFeedURL" --define the full or partial record name you're trying to find
if aErr contains what then
set theStart to offset of what in aErr
set thisString to text theStart thru -1 of aErr
set theEnd to offset of "," in thisString
set subString to text 1 thru theEnd of thisString
--log subString --see the record name and its value in Script Editor's Messages pane
return subString
end if
end parseErrorMsg

on reverse_offset(d, t)
set astid to AppleScript's text item delimiters
set AppleScript's text item delimiters to d
set ro to (count t) - (count text item -1 of t)
set AppleScript's text item delimiters to astid
return ro
end reverse_offset

set foundCounter to 0
set infoFilePath to "/Contents/info.plist"

set theApps to do shell script "mdfind \"kMDItemFSName == '*.prefPane'cd || kMDItemFSName == '*.app'cd'\""
set theApps to paragraphs of theApps
set sparkleAppsList to {}

tell application "System Events"
repeat with anApp in theApps
set anApp to anApp as text
set aFrameWork to anApp & "/Contents/Frameworks/Sparkle.framework"

if exists disk item aFrameWork then
--get Sparkle Version first
set aSparklePlist to aFrameWork & "/Versions/A/Resources/Info.plist"
set thePlist to contents of property list file aSparklePlist
set theValue to value of thePlist
set sparkleVersion to CFBundleShortVersionString of theValue as text
on error
set sparkleVersion to CFBundleVersion of theValue as text
end try
end try
-- compare version num
considering numeric strings
set vulnerable to sparkleVersion < "1.13.1"
end considering
if vulnerable then
--get SUFeedURL if it exists
set thePlist to contents of property list file (anApp & infoFilePath)
set theValue to value of thePlist

set thisSUFeedURL to my extractSUFeedURL(theValue)
if length of thisSUFeedURL = 0 then

set thisSUFeedURL to "httpx"
end if
on error
set thisSUFeedURL to "httpx"
end try

if thisSUFeedURL contains "http:" then
set end of sparkleAppsList to anApp & " : uses insecure update URL (not https) " & "with Sparkle v" & sparkleVersion
set foundCounter to foundCounter + 1
else if thisSUFeedURL contains "httpx" then

set end of sparkleAppsList to anApp & " : update URL unknown (http/https??); uses Sparkle v" & sparkleVersion & linefeed & linefeed
set foundCounter to foundCounter + 1

end if

end if
end if
end repeat
end tell

set thePrompt to "Found " & foundCounter & " items that may be using a vulnerable form of the Sparkle framework: " & linefeed & linefeed

choose from list sparkleAppsList with title "Sparkle Vulnerability Check" with prompt thePrompt OK button name "Launch"

if result is not false then
set appPath to item 1 of result
get offset of " :" in appPath
set appPath to text 1 thru (result - 1) of appPath
set ro to reverse_offset("/", appPath)
set appPath to text (ro + 1) thru -1 of appPath
if appPath contains "prefPane" then
set paneOffset to offset of "." in appPath
set paneName to text 1 thru (paneOffset - 1) of appPath
log paneName
tell application "System Preferences"
reveal (first pane whose name is paneName)
end try
end tell
tell me to launch application appPath
end if
end if


However, be aware that this script will not find certain plug-ins (e.g., Mail plug-ins that use Sparkle).

If the app runs on 10.6, it’s not possible for Sparkle to be updated to the latest secure version, 1.13.1, so you need to check with the developers that they’re using https addresses for both the appcast feed and the release notes html.

Rest assured that Sqwarq apps that use Sparkle (App Fixer, DetectX, FastTasks 2, and OSXClock) all use encrypted https update feeds and release notes addresses, so as far as we’re aware at the moment, none of our apps are vulnerable to the exploit regardless of what version of Sparkle they’re using.

As said above, we’ll update this post if things change as the story unfolds.

Credits: Thanks to Yvan for significantly improving my earlier drafts of the AppleScript and writing the code for retrieving the Sparkle bundle number. Thanks to Chris Stone for tweaking and eeking a bit more speed out of the mdfind command. Thanks to Al for pointing out that in earlier versions of the script the Display Dialog message could get truncated.

how to recover Safari from a browser hijack

Screen Shot 2015-12-10 at 13.32.39.png

The quickest way to get out of a persistent popup that won’t go away (unless you do what it demands!) is to quit or force quit* the browser then restart Safari holding down the ‘Shift’ key.

Holding down Shift allows Safari (or any other app) to restart without resuming its last state.

While this is a great, fast way to solve the problem, it can be annoying if you had other tabs open, and you don’t want to loose those too (or any unsaved data they may contain).

Here’s how you get rid of these kinds of Javascript hijacks without losing your other tabs.

1. Go to Terminal and paste this command (it’s all one line):

defaults write "" 0; killall Safari

This turns off Javascript and quits Safari.

2. Reopen Safari
You’ll get all your tabs back including the hijacked tab, but the pop up won’t appear, and you can now close the hijacked tab.

3. Go to Safari Preferences and reenable JavaScript in the Security prefs
(alternatively you can do that in Terminal).
Don’t forget this step, or you’ll think the web is broken!

More sophisticated or persistent adware and malware attacks can be mitigated by using apps like my free App Fixer or DetectX.

*You can force quit an app by pressing the following keys in combination on your keyboard <command><option><esc> then choosing the app you want to quit.


Screen Shot 2015-12-10 at 13.39.57.png



%d bloggers like this: