Skip navigation

I have been seeing A LOT of people lately who have been caught in today’s most common computer scams.

I want to review them briefly and help you avoid making a mistake and giving control of your computer or bank account to a scammer. All of them are modern takes on the “snake oil” smoke-and-mirrors show from history designed to separate you from your money.

There are three ways that the latest wave of tech scams work:

  1. You get a random call from someone claiming to be from Microsoft or another large computer company, sometimes on all of your cell and home phones in a short time frame. They’re always sporting a fairly heavy foreign accent and phrase things strangely. They’ll tell you all kinds of stories about how terrible your computer is or how many viruses you’re leaking on the Internet. It’ll sound REALLY BAD. They’ll offer to help you fix it…for a price of course.
  2. The pop-up scary talking warning! Your browser loads an infected website or a malicious ad and gets kicked over to a HUGE SCARY WARNING that says your computer is infected and you need to call the number on the screen. If your speakers aren’t muted, it’ll also talk to you in a synthesized voice. If you call, you’ll get the same people as in (1) but this time they didn’t have to luck up and cold-call you, plus you’ll already be terrified so they can trick you into doing what they want.
  3. You call “tech support” for a large company like HP or Dell. You’re not really talking to an HP or Dell employee; you’re talking to an iYogi employee in India whose job is to sell you a support contract. I’m not sure if they’re the same people doing the other two, but it’s the same song and dance as the other two: you’ll get a nice show hyping up how horrible of a situation your computer is in and a hard sell on buying support from them.

In all of these situations, the person on the phone will want to use remote support tools such as TeamViewer or Citrix GoToAssist to get remote control of your computer. Once they have remote control, they are capable of doing ANYTHING THEY WANT to your computer, though they don’t usually seem to infect machines; it’s mainly a high-pressure sales pitch for $300 of computer snake oil.


For cold-call scammers in (1), hang up quickly. If they call again later, keep hanging up. The more they talk, the more likely it is that they’ll convince you to remote them in and pay up.

For the huge scary pop-up in (2), open Task Manager and kill your browser from there. If that’s not working out, just hold the power button on the computer for five seconds and it’ll shut off. Your computer IS NOT INFECTED. If it happens again after rebooting, try power-cycling your modem and router; these can get temporarily “infected” in a way that causes the computer to land on these scary sites quickly, but this “infection” doesn’t survive the power to the box being unplugged.

For the big corporate tech support calls in (3), it’s a bit more difficult because sometimes you’ll be talking to a legitimate support agent that isn’t going to try to scam you. The key things that tell you it’s going to be a scam are that they (A) want to get remote access to your computer without spending a lot of time trying to talk you through it first, (B) they tell you that your computer has serious problems and want to help you fix them, or (C) they mention money at any point in the process. IF ANY OF THESE THREE THINGS HAPPENS, try calling back or seek help from someone else that you trust. Make sure you’re calling the support phone number on the manufacturer’s official website as well!

Almost all of the computers I’ve checked in the past month that were targeted by these scams didn’t have any serious problems before or after the scammer got on, but many of my customers had to initiate chargebacks on their cards or change their bank accounts or get their cards exchanged which is frustrating and annoying.

If you’re in or near the Chatham County, Randolph County, Orange County, or Wake County areas of North Carolina and you’re concerned that your computer has been messed up by a scammer, you can get support from me at Tritech Computer Solutions in Siler City, including 100% free in-store diagnostics and repair quotes.

If you haven’t heard the buzz lately, here’s the deal: YouTube has gone on a massive campaign of stripping content creators’ videos of monetization for the content being “advertiser-unfriendly.” I don’t want to get into the details because they’ve been written about practically everywhere else online at this point. The bottom line is that YouTube won’t pay creators any ad revenue for videos that they deem as not “advertiser-friendly,” which you would think means that ads won’t be run at all on those videos since they’re obviously “not advertiser friendly.”

Let’s see if that’s true.






YouTube is taking monetization from videos under the premise of “not advertiser friendly” and still running ads on the content, keeping all the money for themselves.

I have a cleanup program that I’ve written as a Bash shell script. Over the years, it has morphed from a thing that just deleted a few fixed directories if they existed at all (mostly temporary file directories found on Windows) to a very flexible cleanup tool that can take a set of rules and rewrite and modify them to apply to multiple versions of Windows, along with safeguards that check the rules and auto-rewritten rules to prevent the equivalent of an “rm -rf /*” from happening. It’s incredibly useful for me; when I back up a customer’s PC data, I run the cleaner script first to delete many gigabytes of unnecessary junk and speed up the backup and restore process significantly.

Unfortunately, having the internal rewrite and safety check rules has the side effect of massively slowing the process. I’ve been tolerating the slowness for a long time, but as the rule set increased in size over the past few years the script has taken longer and longer to complete, so I finally decided to find out what was really going on and fix this speed problem.

Profiling shell scripts isn’t quite as easy as profiling C programs; with C, you can just use a tool like Valgrind to find out where all the effort is going, but shell scripts depend on the speed of the shell, the kernel, and the plethora of programs executed by the script, so it’s harder to follow what goes on and find the time sinks. However, I observed that a lot of time was spent in the steps between deleting items; since each rewrite and safety check is done on-the-fly as deletion rules are presented for processing, those were likely candidates. The first thing I wanted to know was how many times the script called an external program to do work; you can easily kill a shell script’s performance with unnecessary external program executions. To gather this info, I used the strace tool:

strace -f -o strace.txt tt_cleaner

This produced a file called “strace.txt” which contains every single system call issued by both the cleaner script and any forked programs. I then looked for the execve() system call and gathered the counts of the programs executed, excluding “execve resumed” events which aren’t actual execve() calls:

grep execve strace.txt | sed ‘s/.*execve/execve/’ | cut -d\” -f2 | grep -v resumed | sort | uniq -c | sort -g

The resulting output consisted of numbers below 100 until the last two lines, and that’s when I realized where the bottleneck might be:

4157 /bin/sed
11227 /usr/bin/grep

That’s a LOT of calls to sed, but the number of calls to grep was almost three times bigger, so that’s where I started to search for ways to improve. As I’ve said, the rewrite code takes each rule for deletion and rewrites it for other possible interpretations; “Username\Application Data” on Windows XP was moved to “Username\AppData\Roaming” on Vista and up, while “All Users\Application Data” was moved to “C:\ProgramData” in the same, plus there is a potential mirror of every single rule in “Username\AppData\Local\VirtualStore”. The rewrite code handles the expansion of the deletion rules to cover every single one of these possible cases. The outer loop of the rewrite engine grabs each rewrite rule in order while the inner loop does the actual rewriting to the current rule AND and all prior rewrites to ensure no possibilities are missed (VirtualStore is largely to blame for this double-loop architecture). This means that anything done within the inner loop is executed a huge number of times, and the very first command in the inner loop looked like this:

if echo “${RWNAMES[$RWNCNT]}” | grep -qi “${REWRITE0[$RWCNT]}”

This checks to see if the rewrite rule applies to the cleaner rule before doing the rewriting work. It calls grep once for every single iteration of the inner loop. I replaced this line with the following:

if [[ “${RWNAMES[$RWNCNT]}” =~ .*${REWRITE0[$RWCNT]}.* ]]

I had to also tack a “shopt -s nocasematch” to the top of the shell script to make the comparison case-insensitive. The result was a 6x speed increase. Testing on an existing data backup which had already been cleaned (no “work” to do) showed a consistent time reduction from 131 seconds to 22 seconds! The grep count dropped massively, too:

97 /usr/bin/grep

Bash can do wildcard and regular expression matching of strings (the =~ comparison operator is a regex match), so anywhere your shell script uses the “echo-grep” combination in a loop stands to benefit greatly by exploiting these Bash features. Unfortunately, these are not POSIX shell features and using them will lead to non-portable scripts, but if you will never use the script on other shells and the performance boost is significant, why not use them?

The bigger lesson here is that you should take some time to learn about the features offered by your shell if you’re writing advanced shell scripts.

Update: After writing this article, I set forth to eliminate the thousands of calls to sed. I was able to change an “echo-sed” combination to a couple of Bash substring substitutions. Try it out:


It accepts $VARIABLES where the strings go, so it’s quite powerful. Best of all, the total runtime dropped to 10.8 seconds for a total speed boost of over 11x!

%d bloggers like this: