Category Archives: Sqwarq

how to easily spoof a user’s password





Spoofing or phishing – presenting a user with fake authentication requests – is a common email tactic, but it’s not the only vector where you need to be on your guard. Every version of macOS is vulnerable to a very simple phishing attack right on your desktop that doesn’t require admin privileges to run, would not be detected by GateKeeper or XProtect, and which could easily be placed on your mac by any of the nefarious malware / adware installer scripts that come with some less reputable software downloads.

This attack isn’t new, but it’s not often talked about. The easiest way to see how it works is in this quick 4-minute demo:

As you can see, it’s easy to grab the icon of any Application and put it in the script; it doesn’t even have to be the icon of an app that’s running. The simple demo I gave above could easily launch iTunes first to increase the coherence of the attack, or it could use a completely different icon, including the icon of security programs you may have running on your mac.

How can you check?

If you were presented with a password request like this and wanted to check whether it’s legitimate or not, an easy way would be to use my free utility DetectX Swift’s Profiler. Click the Profiler function, and search for ‘osascript’ within the Running Processes section. Note how DetectX Swift shows you the text of the script being run, confirming that this dialog is up to no good:


DetectX Swift History

DetectX Swift beta has arrived

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

Terminal tricks for defeating adware

So, your browser is acting up, redirecting you to scamsites, offers for MacKeeper and Mac Cleaner and other unwanted software. You have what is technically known as ‘an adware’ infection. It’s not a virus, it’s not a ‘trojan’ and it’s not a ‘worm’, but it is a nuisance and may well be associated with any of the above. What to do?

Here’s 10 Terminal tricks you can use to help identify and remove adware items. It won’t cover every situation: adware mutates faster than a flu virus on amphetamines, but it will catch 90% of the cases currently out there. For the ones it doesn’t, see the ‘Getting Help’ section at the end of this post.

I’m going to split this up into two phases, ‘Gathering Information’ and ‘Dealing with the Results’. After explaining the first half-dozen commands individually, I’ll then give you one ‘master’ or ‘mother’ command which combines them into a single execution, but you should read through the explanations first so that you know what you’re doing and what to expect.

Gathering Info
First, most adware wants to persist on your mac across logins and restarts, and that means it has to put an executable somewhere where macOS will look on start up. One place most users should be familiar with and check first is the Login Items in System Preferences ‘Users & Groups’ pane. A lot of adware will insert itself there for good measure, but most will almost certainly be in other, trickier to find places.

This is where our first Terminal trick comes in. This Terminal trick will output the contents of the main locations where adware typically hides:

1. List the contents of your Launch* folders:


ls -alF /Lib*/Launch*/ ~/Lib*/Launch*/


That’ll output the contents of three different directories, /Library/LaunchAgents, /Library/LaunchDaemons, and ~/Library/LaunchAgents. If you’re planning on getting help by publishing the results in a public forum like Apple Support Communities, then you might want to use this version, which will scrub your username out of the results:

2. Same trick, redacting personal info:


w=`id -un`;ls -alF /Lib*/Launch*/ ~/Lib*/Launch*/ | sed "s@$w@[redacted]@g"


The output of that command will have a load of files with names like ‘com.company.filename.plist’. To give you an example here’s what mine outputs (note, none of these are adware files; unsurprisingly, my Mac is adware free!).

Slipping a shell script into the /etc/ directory is a common adware trick, so let’s also run this one, which will output any files in /etc/ that have the .sh shell script extension:

3. Find shell scripts in /etc/:


ls -alF /etc/*.sh


(this one won’t contain your user name, so we don’t need to redact anything).

A lot of adware persists by running sneaky little AppleScripts from a shell script. We can detect if any of these are at work with this little spell:

4. List osascript processes targeting your browser:


ps -axo ppid,pid,command | grep 'osascript -e global' | egrep -i "if is_Firefox_running|if is_Safari_running|if is_Chrome_running" | grep -v "grep" | grep -v ' 1 ' | awk '{ print $1, $2}'


All this command outputs is two numbers, perhaps like this:

7783 7792
7783 7825
8978 8987

We’ll discuss what to do with those in the ‘Dealing with Results’ section below.

Next, we want to see what processes are actually running in the background. This will both confirm and possibly add to information we collected earlier. To do this, we need a little trick which looks like the same command twice, but which in fact operates on two different lists of processes:

5. List loaded background processes:


w=`id -un`; r="s@$w@[redacted]@g"; launchctl list | grep -v apple | sed "$r"; sudo launchctl list | grep -v apple | sed "$r"; sudo -K


When you run this one, a list of processes will be output, and then you’ll be asked to supply an Admin password on the command line (where even the key presses won’t be visible when you type). Supply the password and a second list will be produced. We will want to examine both later.

A file name common to a widespread family of adware is rec_script.sh, and this can be hidden anywhere in the user or local Library folders, so let’s run this one, too (here we will add the redacting again in case you’re posting the results in a public forum). You’ll need to supply an admin password for this though:

6. Find a common adware executable:


w=`id -un`; sudo find /Library ~/Library -name "*rec_script.sh*" | sed "s@$w@[redacted]@g"; sudo -K


This one may take a couple of seconds to complete.

That concludes the first step of our info gathering stage, but for convenience, I’m going give you them all again concatenated into one, single ‘mother of all commands’ 😀 string. Even more conveniently, I’ve added code to output the results to a text file on your Desktop, called ‘adware_search.txt’, so after running the code below go look for ~/Desktop/adware_search.txt in Finder. If you’re posting to a public forum, it’s much easier to copy and paste the results from the text editor rather than from Terminal.

TL;DR
If you triple-click anywhere in the block of code below, you can copy and paste the whole block into Terminal and execute all of the commands given above in one fell swoop. Remember you’ll need a password.

7. The ‘Mother’ of all the above:


w=`id -un`; r="s@$w@[redacted]@g"; f="/Users/"$w"/Desktop/adware_search.txt"; ls -alF /Lib*/Launch*/ ~/Lib*/Launch*/ /Users/Shared /usr/local/bin | sed "$r" >> "$f"; printf "\n\n/etc:\n" >> "$f";ls -alF /etc/*.sh 2>/dev/null >> "$f"; printf "\n\n# osacript processes:\n" >> "$f"; ps -axo ppid,pid,command | grep 'osascript -e global' | egrep -i "if is_Firefox_running|if is_Safari_running|if is_Chrome_running" | grep -v "grep" | grep -v ' 1 ' | awk '{ print $1, $2}' | sed "$r" >> "$f"; printf "\n\n# User launchd:\n" >> "$f"; launchctl list | grep -v apple | sed "$r" >> "$f"; printf "\n\n# Root launchd:\n" >> "$f"; sudo launchctl list | grep -v apple | sed "$r" >> "$f"; printf "\n\n# Find rec_script.sh:\n" >> "$f"; sudo find /Library ~/Library -name "*rec_script.sh*" | sed "$r" >> "$f"; sudo -K


Interlude: Playing Safe
Before we move on to dealing with the results, I want to stress that you don’t want to be deleting files that you’re not sure of. Good practice is to move files to a temporary Quarantine folder, or at least move them to but don’t empty the Trash.

Even better practice is to make sure you have an up-to-date, bootable backup disk as well as a Time Machine backup, so that you can easily recover your system if you make a mistake and delete something you shouldn’t.

Dealing with the results
Looking at the output of the first Terminal command given above (Trick 1 or 2), how can you tell which are good and which are bad? In a lot of cases, you’ll recognise the app or developer name. TunnelBear, for example. “Sure, yeah, I’ve got that” and so on. Others, however, will look and sound weird, like these (all genuine adware file names):

com.glutting_Panagia.plist
com.pPHGASlN.plist
com.phellonic.plist

Google anything you’re not sure of, and see if it’s already been identified as adware. See ‘Getting Help’ at the end of this post if you’re not sure.

Walking up & down the tree
Assuming you’ve found some candidates for removal, the next job is to find the parent and child processes associated with each. We do that with a couple more Terminal tricks.

For the first one, we want to find any process that contains the same name as our suspected adware. For each suspect, take the unique part of the name for your search term. With this one we can put all our candidates in one command like so:

8. Search for your target’s family members:


w=`id -un`; ps -axo ppid,pid,command | egrep -i "glutting_Panagia| pPHGASlN | phellonic" | grep -v ' 1 ' | grep -v grep | sed "s@$w@[redacted]@g"


Note the part after egrep -i that’s inside quote marks. Each search term is separated between a vertical bar, aka the pipe character. Note that the terms themselves are not inside quote marks individually. One pair of double-quote marks is used to encapsulate all terms.

So to use the command above replace “glutting_Panagia| pPHGASlN | phellonic” with “search term 1 | search term 2 | search term 3”, where ‘search term n’ is your search term. Of course, you can have more or less than three search terms. Just add or remove as required.

When you examine the results, so long as the first number is not ‘1’ (it shouldn’t be if you executed the command correctly, as all those should have been excluded), follow the file path shown under the ‘Command’ column using either Finder or the Terminal. If you’re sure you’ve found a baddie, send it to the Trash or your quarantine folder! If you’re not sure, see ‘Getting Help’ below.

You will need to construct and run the next command separately for each suspect. The output will give you the path to the binary being executed by the plist. In many cases, you’ll have already found that from the previous commands, but in some cases – particularly if the plist has failed for some reason or if the binary isn’t running when you do your search – it won’t. This one’s the trickiest because you’re going to have to construct most of it yourself. Here’s an example (this is actually a legitimate file, but it will serve for our purposes):

cat /Library/LaunchAgents/com.razer.rzupdater.plist | grep -iA3 program

Let’s look at how that command is structured:

9. Find more children:


cat [path to file] | grep -iA3 program


You get the ‘path to file’ part from the results of your /Library/Launch* searches, and there’s no harm in practising this one on good files to get used to the output. For each item you search, it should return something that looks like this:

Here we see the path to the executable that the plist is launching. If this were a bad guy, I’d be straight over there to send him where he belongs, too.

After working through all your suspects with Trick 8, now take a look at the results of the command to output shell script file names from /etc/ (Trick 3). If there were any results at all (hopefully there wasn’t), you’re going to have to open that file in a text editor and determine whether it is malicious or not. This is the hardest part for the novice, because there’s certainly plenty of reasons to have a shell script in /etc/ depending on what 3rd party software you’re running. I can only repeat here what I have said above: see the ‘Getting Help’ section below if in any doubt.

Next, let’s take a look at the results for the osascript processes (Trick 4). Hopefully, you got no results, but if you had two sets of numbers outputted like this:

7783 7792

then the first number is the parent process ID, and the second number is the child ID. We want to find and eliminate both the parent (again, so long as this number is not ‘1’) and the child.

Take the first number and execute this in Terminal

10. More parents on the loose:


ps [number]


Take a note of the path that’s shown and ensure it doesn’t belong to a legitimate app that you recognise. Again, if in doubt, ask Google, or see ‘Getting Help’ below.

Now, do the same with the second number, the child process. Work through however many numbers were output, ‘quarantining’ as you go.

Almost there! Take a look at the output of the two launchd lists (Trick 5). You should have a good idea by now which ones are suspect and which are OK. You may have found the paths to any suspicious ones already, but if not, we’ll use the same command as we just used with the osascript processes. Here’s the output on my machine of the Trick 5 command (all legitimate) for comparison:

We’re only interested in the first number (the second one is status code). For any suspicious process, take the first number shown in the list, and use the Trick 10 command on these to find the parent file path (you know what to do with the ones that aren’t legitimate!).

If there is only a ‘-‘ dash instead of a number, it means that process is or was loaded but is not currently running. That dash may or may not be followed by another number that is not ‘0’. That number is just an error code and isn’t really relevant to us here. For any of your suspects that have failed like that, hopefully the info you gathered earlier will give you some clues (if not, see ‘Getting Help’ next).

Finally, anything found in the ‘find’ command (Trick 6) is almost certainly malware. Of course, be mindful that it’s entirely possible a legit’ script could accidentally have a name clash and be called rec_script.sh, but it’s highly unlikely and definitely should be examined closely. Also, if you see that the path is within an application bundle like this …Contents/MacOS/rec_script.sh, don’t hesitate to pull the trigger on that one.

Getting Help
I want to repeat that doing this safely and effectively takes practice and experience, and you should in no way be surprised that, if you don’t have that experience, you’re not sure whether something you’re looking at is good or bad, or that you go through all of this and still can’t find the problem. There’s some fairly obscure ways that adware and other malware can infest and persist on your mac that only experts will be able to advise you on. Throughout this post I’ve glossed over a few situations where you’ll draw a blank, and that’s because most of the other techniques for spotting malware require that experience.

To ameliorate this, I wrote an app called DetectX Swift to deal with this and many other things, and you can download it and use it without any requirement to pay. You can also use it to get personal, free-of-charge, help from me through the Help > Report a Problem to Sqwarq Support if your troubles persist.

Let me be clear why I don’t charge for this personal service: the payoff for me is I get to improve my app’s heuristics from what I learn about infections that DetectX doesn’t automatically detect. All information is kept strictly confidential and I do not sell or use your email address or other information for any marketing purposes whatsoever.

If you want to read more about me, also see the about page on DetectX’s parent site, Sqwarq.com.

Happy hunting! 🙂

 

how to create a bootable macOS installer

If you are preparing to install macOS on multiple computers, one of the things that can make your life simpler (and the waiting shorter) is a bootable USB installer.

The idea of the installer is that you only need to download the macOS Installer.app from the App Store once. Usually, when you run the installer after downloading it, it’ll delete itself and you have to go through the whole download process again on each machine or disk that you want to install macOS onto. By making a bootable USB drive, you simply plug the drive in to your mac, launch the installer app and tell it where to install the OS. You can repeat this as many times as you like as the installer will remain safe on your USB.

There are various ways to make a bootable USB installer, but they all involve the same process:

1. Download the macOS Installer from the App Store.
2. Run the createinstallmedia command from the Terminal, an AppleScript or a helper app.
3. Reboot your mac, choosing the newly created USB as the startup disk.
4. Run the installer.app from the USB.

Step 2 is where the fun is. The createinstallmedia command can be tricky to get right, particularly if you’re not familiar with working on the command line. For those of you that are, follow Apple’s instructions here.

For a little more convenience, I wrapped all that inside an AppleScript which will first ask you for the location of the installer, then ask you to choose the USB target.

For maximum convenience, I also wrote a free little Swift app I’ve dubbed ‘Boot Buddy‘ (cos “Create bootable macOS Installer Drive.app” just didn’t quite have the right ring to it..!) that will present the whole thing in a neat little user interface. Three clicks, more or less, and you’re done.

Boot Buddy doesn’t require an admin password to install, but you do need to provide an admin password to actually create the bootable installer as the createinstallmedia process has to be run as root. Boot Buddy doesn’t see or use this in any way whatsoever other than to start the createinstallmedia process or to cancel it (if you choose to do so); authorisation is handed off to macOS to take care of.

Boot Buddy requires macOS 10.11 or higher and can create bootable USBs from Mavericks, Yosemite, El Capitan, Sierra and High Sierra installer apps.











Share and enjoy! 🙂


WWDC: get it for free (OSXClock)

Screen Shot 2016-06-13 at 20.31.55

Apple’s WWDC 2016 conference is about to start. Is it the end of OSX? Rumours are widespread that the venerable old operating system is about to change its name to macOS.

Right or wrong, commiserate or celebrate, we thought we’d mark the occasion by giving away free copies of the full-paid version of our OSXClock.app.

The offer is already up and live and will continue to be available until WWDC 2016 closes on the 17th.

We’ve also just released an update to OSXClock yesterday adding world time zones, so there’s no better time to take advantage of this giveaway.

Enjoy! 🙂

keep an eye on Console with ConsoleSpy

icon_512x512

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

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

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

Screen Shot 2016-05-22 at 13.24.10

 

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

Download ConsoleSpy

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

 

 

 

DetectX v.2.22 released

Screen Shot 2016-03-17 at 21.56.27

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.

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 🙂

%d bloggers like this: