Author Archives: philastokes

how to retrieve forgotten Wifi password


At our house, giving visitors the wifi password is always an exercise in frustration. Can’t remember? Oh, then I’ve got to either go trawling through Keychain Access or log in to the router, neither of which are particularly appealing.

Here’s an easier way. It’ll require an admin password (and you’ll need to supply it for as many passwords as you’re looking for – no ‘with administrator privileges’ will help here I’m afraid), but otherwise requires nothing more than a quick double-click of this saved script, once you’ve added your own SSID names in place of the dummy ones.

Just to be clear, you do NOT need to add the passwords to the script. So long as the mac that you run this script on already knows the Wifi password, the script will retrieve it.

Get the script from my pastebin

Enjoy!

how to remove “Plugins Button” from Chrome





Update: DetectX v2.75+ now deals correctly with the Plugins Button adware and the instructions below are now redundant.  Just ‘Search’ and ‘Trash All…’ should be sufficient.



 

If you’re having trouble trying to remove the “Plugins Button” from Chrome because its ‘managed and cannot be removed or disabled’, then follow this procedure.

1. Launch DetectX and do a search. You should see at least 5 items. Do NOT click the Trash button yet.

2. Quit Chrome

3. In Terminal, execute this command* (you’ll need admin privileges)

sudo /usr/bin/profiles -P; sudo -K

If you see a single configuration profile installed with the profileIdentifier ‘org.superduper.extension’, then execute

sudo /usr/bin/profiles -D; sudo -K

to remove it.

Type ‘y’ when prompted.

4. Read the caveats below, and then if appropriate, in DetectX, now click the ‘Trash All…’ button.

5. Relaunch Chrome and check that all is well.

Caveats
* If you or the machine’s administrator are using ‘Managed Preferences’ and have profiles other than the one mentioned above installed, then do NOT use the ‘-D’ switch in step 3. You’ll need to identify the correct profiles. Use the -P switch to list the installed profiles and only delete the one with ‘org.superduper.extension’ identifier. Likewise, do NOT use the Trash All… feature in DetectX, which will remove the Managed Preferences folder***. Instead, double-click the items in DetectX’s window to open them in Finder and remove them manually that way.

** You’ll need to authorise the deletions when macOS asks you as DetectX doesn’t have the permissions to do that (a safety feature).

*** Note that the ‘Managed Preferences’ folder is a perfectly legitimate folder for server admins that have knowingly installed managed preferences for their users, or for those using Parental Controls. An application update for DetectX will be released shortly to more accurately target this issue rather than flagging the entire Managed Preferences folder.

how to find the paths of all loaded kexts

Thanks to a tip from Erik Gomez, I’ve only just noticed that the kextfind utility restricts its default search to just the System and local Library Extensions folders (note to self: RTF man page!). While you can name specific folders in a custom search, kextfind doesn’t have a recursive option to trawl the whole system or even all children of a parent directory. You might bash your way around that, but it’ll be slow and take forever.

Instead Erik offers a python script that hooks into Objective-C to find both loaded and unloaded kexts. As my job mostly involves disarming currently running badware, I’m generally more concerned with what’s actually running on a user’s system at the time I’m troubleshooting it, i.e., kexts that are currently loaded, and I figured I could probably do a quicker-and-dirtier job of that on the command line without needing to actually write an executable script or doing a slow trawl with the find tool.

The problem is that while we can get kexts in /Library/Extensions and /System/Library/Extensions easily enough from kextfind, what about all those 3rd party extensions lurking in unknown places? The answer lies in part with the kextstat utility, but unfortunately that will only tell us what the loaded kexts are, not where they are located.

The rest of the answer is to take the bundle identifiers provided by kextstat and then coerce kextutil into supplying the paths. We’ll then do a merry dance with a few other utilities (that don’t begin with the word ‘kext…’) and a temp file to parse out the noise and spit out the paths that we wanted all along. Finally, we’ll clear up after ourselves by deleting the temp file we created.

Here’s the whole command, then I’ll walk through how it works:


t="Desktop/kx.txt"; kextArray=`kextstat -l | grep -v com.apple | awk '{print $6"@"$3}'`; for i in $kextArray; do kextutil -a "$i" >> ~/"$t" 2>&1; done; v=$(<~/"$t"); echo "$v" | cut -d" " -f1 | grep -iv warning | awk '/^\s*$/ {next;} {print $1}'; rm ~/"$t"


At this point I’ll apologise to the learned: a better shell scripter than I would surely do this with far more panache, and my lazy habit of defaulting to solving new problems through familiar tools is undoubtedly clumsy; for our purposes here, however, if it works it’ll serve (feel free to add your own better solutions in the comments!).

So we start with a variable that we’ll substitute in later for our temp file path. We next get a list of running kexts’ bundle identifiers from kextstat. This tells us what’s loaded, and we grep out any of the Apple ones. The awk command after that rearranges the output from kextstat to a format that kextutil will like, and the whole lot is saved in an array.

We next iterate over the array and write out the result to a text file, appending as we go. We’re redirecting both standard out and standard error to our file.

Now, kextutil isn’t really meant for looking up paths per se, but we can leverage its –address flag to get those out of a more verbose kext debugging message.

We now read the file back in, and pretty much everything after that is my mangled attempt at parsing out the extraneous (for our purpose) messaging that kextutil provided.

The result? On my machine this code produces what you see in the screenshot at the top of this post. Since these kexts are all in the default locations, I could have got them simply from kextfind, but what I know now that kextfind wouldn’t have told me is that there aren’t any other 3rd party kexts in any other places loaded on this particular machine, and if there were, this little script would have told us where to find them. For troubleshooting purposes, that info is well worth having!

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*/ | sed "$r" >> "$f"; printf "\n\n/etc:\n" >> "$f";ls -alF /etc/*.sh >> "$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 to deal with this and many other things, and you can download it and use it without any requirement to pay (though registration is encouraged for regular users). 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 quickly toggle Swift Compiler warnings





I thought I’d share this little AppleScript for anyone working with Xcode 8.3.3 and using Swift.

One of the things I find intrusive are the constant Swift Compiler warnings while I’m actually in the middle of writing a block of code (e.g, ‘…value was never used consider replacing…’). Well, yeah, it’s not been used *yet* …grrr!

However, turning off compiler warnings isn’t something I want to do either. It’s too easy to go into the build settings, turn them off, do a bit of coding, take a break, do a bit more coding…oh, three thousand lines later and I suddenly realize why Xcode hasn’t been correcting my mistakes all afternoon!

This script allows you to quickly and easily toggle the warnings from a hotkey, and just gives you a gentle reminder as to what you’ve done. Of course that won’t stop you forgetting, but assigning a hotkey for this script makes it painless to just turn warnings off and back on again as soon as you’ve got past whatever bit of code the compiler was complaining about.


Xcode unfortunately doesn’t have its own scripts menu, so in order to assign the script a hotkey, you’ll need to either make it into a Service with Automator or use a script runner like Red Sweater’s FastScripts.

#start
on sendNotification(aVal)

display notification "Suppress Warnings was set to " & aVal with title "Swift Compiler - Warnings Policies"

end sendNotification

tell application id "com.apple.dt.Xcode"
tell its front document
tell its front project
tell its front target
tell its build configuration "Debug"
set b to build setting "SWIFT_SUPPRESS_WARNINGS"
if b's value is "NO" then
set b's value to "YES"
else
set b's value to "NO"
end if
my sendNotification(b's value)
end tell
end tell
end tell
end tell
end tell
#EOF

If copying the code above doesn’t build, get the raw source from my pastebin here. Here’s how it looks in Script Debugger 6:

Enjoy! 🙂


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


how to remove adware from your mac




Despite removing MacKeeper, I occasionally get reports from DetectX users who find that when they open their browser, MacKeeper is still haunting them. If your browser is popping open with images like the ones above, then like those users, you’ve got an adware infection.

It sounds nasty, but it’s more annoying and intrusive. It also may signal that your mac has been compromised in other ways by malware such as Pirrit, which has the capability to do more than just harrass you through your browser.

The easy solution to adware is to run my free app DetectX. If you find the problem isn’t solved, you can also send me the DetectX report and I’ll solve it for you, for free.

If you like rolling your sleeves up yourself, then follow this procedure:



1. Preparation
As you should always be running with a recent backup anyway (right, folks?) be sure to do a TM backup or clone before you start in case anything goes wrong. Do not ignore the necessity for a backup. If you don’t have one, stop now and get one.

You’re going to want to hunt down the adware in a few places. Be careful not to delete anything, but instead move suspicious items to a folder on your Desktop so that you can return them to where they came from if they are innocent. Create a new folder on your Desktop called ‘Quarantine’ for this purpose.

You’re going to want to keep a note of what you find and where you found it, so have a text editor like BBEdit or TextEdit open while you work. Save this file in your Quarantine folder, too.

When you find a suspicious item, an easy trick is to drag the suspect first into the editor to copy its path, and then drag it into your makeshift ‘Quarantine’ folder to move it. To copy the path in this way, use a plain text format in TextEdit. If you’re using BBEdit, command-drag the item. For moving to your Quarantine folder, you’re going to need to use ‘Command’-drag and supply an Admin password for the move if the item is outside of your Home folder.



2. Local and User Domain Libraries
Note these are two different libraries, but I’m assuming that if you’ve elected to follow this “roll your sleeves up” procedure, you already knew that. If you didn’t, I strongly suggest you reconsider trying to do this yourself. Messing under the hood requires a certain minimum level of experience and knowledge to avoid borking your entire system.

Assuming that all warnings and caveats so far have been heeded, you’re ready to inspect the /Library and ~/Library folders. Treat as suspicious anything at the root of /Library that begins with a lower case letter, particularly if it is an executable. Aside from the hidden .localized file, Apple don’t put anything at the root of /Library that begins with a lower case letter, and responsible 3rd party developers don’t either. If you find anything like that and you don’t know what it is, make a note of it (don’t move it yet).

At this point I’d love to be able to give you a list of file names to look out for, but I’m afraid we’re talking in the thousands if not more. A lot of this adware creates its own unique names on install by randomly choosing words from the /usr/share/dict/words file. Some of them disguise themselves as Apple files, like com.apple.morkim.plist and others disguise themselves by hiding themselves from the Finder (so ideally you want to be doing this on the command line, or at the very least use the Finder with invisible files showing).

The good news is that a lot of this adware is fairly obvious when you look at it. Move into the local (not user) Library’s LaunchAgents and LaunchDaemons folders and inspect the items in there. Move items that have random dictionary word names like ‘Bolshevik-remindful’ or gibberish concatenations of consonants and vowels like ‘com.xpbbptejonfy.plist’. If you’re not sure, open the plist (you can cat or sudo cat it if you’re in the Terminal) and see what executable it refers to. If that refers to a path to some similarly named binary you’ve never heard of, go check it out and see what it is. If in doubt, use Google your favourite search engine to search for that name on the web and see if its legit. Anything legitimate will be easy to find a reference to on the web. Anything that fails these tests should be moved to your Quarantine folder. If you find anything that refers to a folder or file you made a note of earlier in the root of /Library, then move both to your Quarantine folder.

After that, you’ll want to move on to your ~/Library/LaunchAgents folder, and follow the same procedure. Any items in here should refer to an app that you recognize and regularly use. Items with names that mispell words like ‘update’ and ‘download’ are dead giveaways as adware.

Adware plist files in here will typically refer to something funny sounding in your ~/Library/Application Support/ folder. Any apps found in the Application Support folder or subfolders should be treated as suspicious. Again, check the name through an internet search if you’re in any doubt, but since this is stuff in your user domain, really anything you don’t recognize shouldn’t be there anyway.



3. Browser Extensions
While you’re in the user Library, go check on what is in Safari/Extensions folder. You should see an Extensions.plist and only the safariextz files that refer to Extensions you use, if any. Fire up Safari, and check in the Preferences’ Extensions tab to uninstall any that you don’t use. If you use other browsers, use the Tools menu to inspect Extension or Add-ons, again removing any that you don’t use.



4. Restart and test
It’s time to restart your mac. After restarting, you’ll need to reset your browser to its default state. First, hold down the shift key while launching the browser from the Dock.

If you get redirected to an adware page or still get a pop up, clear your browser’s default settings. Although adware can no longer easily alter Safari’s defaults, you can check that your home page is correct in Safari’s Preferences. You can empty history and caches from the Safari menu and the Develop menu, respectively. For the latter, click ‘Advanced’ in Safari’s Preferences and check the ‘Show Develop menu in menu bar’ box at the bottom to enable the menu.

To reset Chrome and chromium based browsers to default settings, see:

https://support.google.com/chrome/answer/3296214

For Firefox, see

https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and-settings



Fixed it or not?
If you correctly identified and moved the adware, you should be all good. Depending on what you moved and from where, you might want to hang on to the items in your ‘Quarantine’ folder until you’re sure everything is working correctly. If you accidentally moved something you shouldn’t have, you’ll likely soon notice something isn’t working like it used to. Use your notes or your backup to undo the damage. When you’re sufficiently confident that everything in your Quarantine folder is definitely badware, move your notes to somewhere else if you wish to keep them for reference (I’d appreciate a copy of them, too :)) and delete your Quarantine folder.

If things didn’t work out, don’t despair or feel bad. Adware is complex, and the simple DIY guide above won’t cover all the cases. There are other places adware can hide, but it takes a lot of experience to track it all down. If you can’t solve the problem yourself, you can always check your mac with DetectX or contact me through DetectX’s Help menu item ‘Report a Problem to Sqwarq’ and have me do it for you (and no, I don’t charge for this service).



Good luck! 🙂

Related posts: Terminal tricks for defeating adware


how to display wifi name (ssid) in menu bar



If you’re one for visiting coffee shops and other places with public networks, you might have an interest in today’s Hammerspoon tip.

This little code added to your config file will display the name (SSID) of the currently connected Wifi network in your menu bar. Whenever the Wifi network changes, the name will automatically update so you can always see at a glance that you’re connected to the Wifi network that you think you are.

Playing around with that unusually long number (between 2147483644 and …647) will move the SSID name along the icon bar. Set it to the default ‘1000’ if you want macOS to decide where it should be.

wifiWatcher = nil
function ssidChanged()
local wifiName = hs.wifi.currentNetwork()
if wifiName then
wifiMenu:setTitle(wifiName)
else
wifiMenu:setTitle("Wifi OFF")
end
end

wifiMenu = hs.menubar.newWithPriority(2147483645)
ssidChanged()

wifiWatcher = hs.wifi.watcher.new(ssidChanged):start()







Enjoy! 🙂



Further Reading
More fun with Hammerspoon
Get automated with Hammerspoon

more fun with Hammerspoon

For anyone using Hammerspoon and folder ‘watchers’ to alert them to changes to a given folder, I’ve updated the watcher function I wrote about here

The problem with the simple alert I demonstrated last time is that it only hangs around for a second or two (much less than a Folder Action alert, which takes a couple of minutes to time out). In this updated function, it now also writes a list of the file changes to a (by default) file on the Desktop. The write is an append: if the file doesn’t exist it will create it before writing; if it does exist, it will append the latest changes and date to the file. This way, even if you miss the alert, you’ll always have a record of what files have been added, deleted or modified in your watched folder.

In this example, the folder being watched is ~/Library/LaunchAgents since we want to be aware of any adware, malware or other unsavoury processes being surreptitiously added by, for example, apps we download from the internet. Although there are, of course, many legitimate reasons for apps placing items in here, this folder is prime real estate for attackers as it is one of the locations that can launch processes at log in time without the user’s interaction (or knowledge).

Here’s the code, also available from my pastebin here. A code walkthrough follows.

function writeStringToFileWithMode(aString, aPath, aMode)
local this_file
this_file = io.open(aPath, aMode)
this_file:write(aString)
this_file:close()
end

function myFolderWatch(files)
local str = "Launch Agents folder was modified on " .. os.date() .. " :\n\t"
local this_path = os.getenv("HOME") .. "/Desktop/LaunchFolderModified.txt"
local ignore = "DS_Store"
local count = 0

for _,file in pairs (files) do
count = count + 1
i = string.find(file, ignore)
if not i then
str = str .. file .. "\n\t"
else
if count == 1 then
str = "\n"
end
end
end
str = str .. "\n"
writeStringToFileWithMode(str, this_path, "a")

if string.len(str) > 2 then
hs.alert.show("Launch Agents folder was modified.")
end
end

local aWatcher = hs.pathwatcher.new(os.getenv("HOME") .. "/Library/LaunchAgents/", myFolderWatch):start()



Code walkthrough
The first function, ‘writeStringToFileWithMode’ is just a convenience function. Hopefully the clue is in the name. The ‘aMode’ parameter is either “w” for write(over) or “a” for write(append).

The myFolderWatch function starts off by declaring some local variables.

‘str’ includes the initial line that we want to write to our output file and interpolates the time of the change by calling os.date().

‘this_path’ defines the path that we want to write our list of file names too.

The ‘ .. ‘ in both these assignments is a string concatenator (i.e., like ‘&’ in AppleScript or ‘stringByAppendingString’ in Obj-C).

‘ignore’ is a string that will help us to exclude .DS_Store files from triggering the alert or appearing in the list of file changes.

The ‘count’ variable is an internal var we need in order to eliminate .DS_Store changes when it’s the only change. Lua doesn’t have an easy way to count entries in tables, so we bascially iterate a variable each time through the loop to achieve the same effect.

After that, we have the ‘for’ loop. For loops in Lua are weird (at least for me), as you’ll see that they have this structure for a,b in pair (aPair). I won’t go into why, other than to say its a result of Lua’s table data structure. The '_' here is just a dummy variable for the first parameter. The ‘files’ in parentheses are the list of file names (not file specifiers, you AppleScripters!) that were added, deleted, or modified in the watched folder.

The loop begins by incrementing the count, then checks for the ignore file (.DS_Store). If the ignore file is not found, we then append the filename to the str variable.

If it is found, we check the count. If the count is ‘1’ (i.e., the only change was .DS_Store) we discard the entire str var and replace it with new line character. If the count is more than 1 we don’t do anything to ‘str’. We just ignore adding anything to it all.

At the end of the for loop we add another new line to the string just so our outputted text file looks nice and neat.

Then we call the write function mentioned above, passing ‘a’ (append) for the mode.

Finally, we fire the UI alert on the condition that the string has got more than 2 characters in it (if it didn’t it was just the “\n\n” string from ignoring the DS.Store file).

After the function definition, the aWatcher variable sets up the watcher on the path we want to observe and tells the watcher to start monitoring. It tells the watcher to call our myFolderWatch function when anything happens.

Deploying the code
After editing the config file, remember there’s two steps: i. save the file and ii. choose ‘Reload Config’ from the Hammerspoon menu.



Further Reading:
More details are available about Hammerspoon from the official site here.

My beginners guide with the original simple watcher function is here.


%d bloggers like this: