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.
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! 🙂
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.
The standard method for doing this, either in Terminal or in code (via NSTask) has always been
defaults write com.apple.finder AppleShowAllFiles -bool true; killall Finder.
In every version of OS X from 10.6 thru to 10.10 this works as expected. In 10.11 I see a reproducible though not always consistent bug when using any GUI-wrapped app to toggle this Finder setting. The bug basically ends up with Finder showing the opposite of both what the app shows and what ‘defaults read’ shows (see image above; the value should be ‘1’ when invisible files are visible).
We believe a related bug is that Finder sometimes fails to show the new version of an app in the Finder preview after the app has been updated.
In both cases, there’s a couple of ways to deal with it (albeit temporary until Apple applies a proper cure):
i. log out then log in
ii. issue a ‘killall Finder’ on the command line
iii. purge the RAM then toggle the setting again in whatever app you’re using to toggle invisible files.
Version 2.06 is now available.
We’ve added more adware definitions and included MacBooster in the list of commercial apps that DetectX will find and remove.
We just released version 2.04 of DetectX, but if you’re finding that you can’t update, here’s the reason (and the fix!).
Thanks to Apple’s new AppTransport security layer and Amazon S3 not supporting perfect forward secrecy protocol, users of DetectX on any version prior to 2.04 who are running El Capitan (OSX 10.11) will find that DetectX can’t be updated from within the app even though we use a secure https connection.
The simple, if inconvenient fix, is to download DetectX directly from sqwarq. We’ve fixed the bug so that once you’re on v2.04, the in-app update mechanism will function properly again (even on El Capitan !).
Back in the days of Mountain Lion when Apple introduced GateKeeper, a lot of talk was heard about the best way to protect your mac being to only download apps from the App Store. With several hundred malware infected apps discovered in the App Store last month alone, what’s clear is that leaving your security up to someone else (even if its Apple) is short-sighted at best, and disastrous at worse, particularly if your reliable source just happens to be of great interest to hackers (especially if its Apple!).
Rather than relying on others for your protection, the solution is to have a system in place that will protect you and allow you to recover completely and quickly regardless of the source of the infection. In this post I’m going to share with you (part of) my security set up. Of course, at least in part, it uses my own s/w (if I can’t trust my own software, who can? And besides, my s/w is free!), but there are other ways to achieve the same thing. What’s important is the process, rather than the particular tools mentioned to implement it.
I’ll break these five essential security tips down into two parts, protection and recovery. However, if this post looks too intimidatingly long, skip to the end where I summarise the essential points in the TL;DR. OK, here we go:
1. Log changes to your system
I achieve this with my app DetectX (my app FastTasks 2 also does this, but DetectX is better at it). I have DetectX (v2 or higher) in my Login Items. This means every time I login, DetectX reports what’s changed on my system. If you’re starting from a clean bill of health as hopefully you are now, this is vital information in tracking down what’s changed when new trouble begins.
If I don’t log out at the end of the day, I run DetectX the next day, and I always run it after downloading and installing any new software. That means I have a record of what that s/w has done and I know exactly how to uninstall it if I need to.
Incidentally, as soon as you’ve launched DetectX and taken a note of any changes (signalled by the yellow alert triangle), you can quit it. It doesn’t need to be running. It just needs to launch and scan (literally, takes a second) and then quit.
2. Do NOT use your AppleID for your admin account password
Use a unique password for your Admin user account and do NOT allow the options for the user to reset the password using AppleID or to administer the computer using your AppleID. This is a massive security flaw (this setting is made in System Preferences > Users & Groups). Your AppleID is hackable and indeed there has been at least one famous case of a Wired journalist who had his entire mac wiped in front of his eyes while sitting at home by a hacker who had ascertained his AppleID.
3. Use a Password manager
I use 1Password myself, but any similar product will do. The point is that i. you’re not using the same credentials on more than one site and ii. that you’re using passwords whose length and structure is uncrackable. No matter how ingenious you think your passwords may be, trust me if you made them up yourself they are not. Do a search on ArsTechnica.com for “password cracking” and weep at the ease with which this is possible. A password manager is the only sensible solution.
If you care at all about your data you need to invest in a structured backup system. Simply plugging in Time Machine isn’t sufficient since, as many have already discovered, TM will back up all the ‘infections’ along with everything else. When you try to recover, you just end up re-infecting your machine.
This is what I do.
4. Use a variety of both clones and Time Machine on a staggered schedule
I have a TM disk always connected. On top of that, I clone my entire internal HD on Wednesday and Saturdays. This clone is NOT connected to the mac except during backup. I also clone my HD onto a separate disk once a month. Again, this disk is never connected to the mac except when I’m backing up. (I use an app called Carbon Copy Cloner to manage these schedules.)
If any one of these disks gets ‘infected’ or just dies out of natural usage, I’m covered. If I were to get some kind of infection, I’ve got known clean backups for at least one month. So long as the problem manifests itself within that period, I can simply boot from a clean clone and diagnose the problem using the tools mentioned above in PROTECTION. I can then clean my TM Disk and any others once I’ve determined the problem, and of course then I haven’t lost any backup data.
5. Consider CrashPlan or similar online recovery service
I don’t use it myself because I consider my user behaviour as very low risk and my precautions adequate, but if I were either less technically inclined or without the time to manage a system like I described above, CrashPlan is a way to insure yourself without the hassle, (albeit at a cost, so you need to weigh that up). In particular, what I like about the CrashPlan idea is that it offers you protection against ransomware threats (not that we’ve had any serious ones on the mac yet, but I wouldn’t bet against these appearing in the not too distant future). Note that services like CrashPlan are not at all the same kind of thing as Dropbox or iCloud, but the best way to find out more is to head on over to the CrashPlan page and read up on what they offer.
Those are the 5 essential things I think you need to do or consider, but let’s just round this off with some things that you probably don’t need to do.
Do you need AV Software?
Some people are adamant about using this kind of software because of its necessity on Windows machines, where there’s decades of reusable malware going around which makes this kind of app necessary.
On a mac, there isn’t that kind deep history of malware in circulation; the really dangerous stuff is perhaps only now just being written, and none of the AV tools will know about that until after the fact. In other words, any decent malware being written for macs now will get past all the AV vendors. Moreover, much of the worst of known malware is already blocked by Apple via OS X’s Xprotect system. That means your AV software isn’t really doing much other than what OS X is already doing for you.
The other problem with AV software is that its always running on your machine and slowing things down.
Finally, most AV software requires you to give it your Admin password and runs its processes in a persistent ‘super user’ or admin mode. That’s a security compromise in at least two ways. First, it means you are at risk from the AV software vendor if they are not trustworthy themselves. Second, it means your system is vulnerable to bugs or exploits existing in the security software. Hackers love nothing better than finding ways to compromise security software, and if a hacker can get into your machine through bugs in an AV program running on your mac with admin privileges, well, then, you are “pwned” as they say.:o
By way of contrast, DetectX doesn’t need to know about threats in advance; it will tell you whether something new has been added to your mac and where, regardless of what it is, so it will also spot even those kinds of “zero day exploits” that try to sneak malicious files onto your mac. DetectX doesn’t run any ‘always on’ processes or use any system resources in the background. Finally, DetectX doesn’t require you to give it an Admin password.
(Technical note: if you use the Trash function in DetectX, then OS X will ask for your password to trash files outside of your user account, but that’s not a request coming from my app, but from the system. Importantly, authorising that request only allows the system to do what you told it to do: delete the given file selected in DetectX. It cannot be hijacked to do anything else and the authorisation is single-use only. If you tried the same operation again it wouldn’t work without being authorised again).
Should I avoid updating my mac?
In short, no – you should always be on the most recently available update
for your release of OS X as updates almost always address security flaws that have come to light since the last update.
However, update doesn’t mean upgrade. Generally, if you’re going to upgrade (such as from Yosemite to El Capitan), do the upgrade on a spare external disk first and test that everything works OK. Whatever you do, do not just install an upgrade directly over your one-and-only copy of your HD. If you don’t follow the advice above about testing the new OS on an external drive, then at least make an external bootable clone (not Time Machine, too unreliable) of your internal HD first. Anything less is asking for trouble.
Pretty much the same advice can be applied to updates, certainly the early ones. It’s not unknown for a .1 or .2 update to break something serious. These kind of bugs get less likely as you get nearer .4 and .5 updates when everything is fairly stable, but it’s still never a bad idea to make a complete bootable back up of your system just before doing either an update or upgrade. That way, you’re covered whatever happens and can easily roll back to the previous version if necessary.
OK, if I wanted to sum up all of this into two simple golden rules for security and protection it wouldn’t be ‘use this app or that app’ or ‘only trust this source or that source’ it would be: educate yourself about how your mac works, where malicious files hide and keep an eye on those places on a regular basis. That’s what I wrote DetectX to do, but you can do it in other ways without using my app. Secondly, backup regularly and backup onto different disks on a staggered schedule so that you always have a clean, uninfected backup to turn to in case you need it.
Enjoy and share! 🙂