Plug in, unplug, and shake: a “magical” combination!

What would you name as the worst kind of computer threats?

Today ransomware Trojans—malware that locks devices until a ransom is paid to unlock them—pose one of the greatest threats to computer and mobile device users. Two years ago, only Windows users suffered such attacks, but today increasingly more Android users are coming forward with complaints that their devices have been infected by ransomware. To tighten the screws, some of these malware programs use the front camera of a device to photograph their victim. The resulting image appears on screen in a dialog designed to look like an intelligence agency-issued directive.

Attempts to eliminate these programs by rebooting, continuously tapping, or pressing buttons are fruitless. The only way for an inexperienced user to get rid of these Trojans is to restore the default settings.

Knowing that users don't always update the anti-virus protection installed on their devices, criminals release new strains of ransomware daily, in the hope that one of them will be successful, and occasionally that is the case. While developing Dr.Web for Android, we decided to address the problem of protected devices being locked by Trojans by creating a special feature that could be incorporated into our Android app.

The idea we came up with was to have the app receive a particular signal that would initiate the shutdown of all running applications, including ransomware Trojans. Once the shutdown was complete, Dr.Web would open in the foreground, and the user would be able to update their virus databases and run a new check for threats, or promptly contact our technical support team.

Our developers, along with our UX department, stipulated that the signal had to come from an Android device’s mechanical components since the home screen would be locked.

The next question was which signal to choose. We know that every Android smartphone has the following components:

• Volume buttons 
• Accelerometer 
• Headphone jack 
• Charging socket 

Click Here for Dr.Web Security Discount and Deals

Volume buttons
What if we use the volume buttons as the signal’s source? The problem with that is that when users press volume buttons, only a change in volume level is transmitted, and it’s hard to keep track of how long a button is pressed.

Moreover, users can increase or decrease the volume level on Android devices by sliding the volume bar with their finger, and this action would transmit the same signal to the anti-virus.

Volume buttons are used in some games and also in some other apps. For example, when users take photos, they can use a special bar on the screen to zoom in.

The probability of false positives was too high, so we rejected volume buttons.

Accelerometer
Our next idea was to use the accelerometer—to ask users to shake their phones up and down, and from left to right.

However, the accelerometer is used in many situations.
For example, racing games are motion sensitive, enabling users to change the direction of or steer a race car.

Moreover, using the accelerometer, Android users can lock their device’s home screen or mute their device just by turning it face down.

They can also change their screen’s orientation for better web browsing or photo viewing.

In addition, Android devices have various degrees of sensitivity to accelerometers; therefore, depending on the device model involved, the same motion transmits different signals.

We realised that the risk of false positives was high, so to mitigate that risk, we decided to use a combination of several signals and began mulling over possible solutions.

Headphones+Accelerometer
People usually have headphones on hand, so we contemplated the notion that headphones could help simplify and speed up the phone unlocking procedure.

However, after analysing potential user behavioural patterns, some of which are described below, we concluded that the headphones-plus-accelerometer combination wouldn’t eliminate false positives.

We considered what would happen in the most common example we could think of: a user who gets a call while walking down the street, listening to music. They’d remove their headphones and put their phone up to their ear, however, instead of the incoming call, the anti-virus would appear on screen.

Another scenario we thought of: users going out for a run. They’d plug their headphones into their device, launch the music player, and start jogging. The music would be interrupted, and instead of the player, they’d see our anti-virus on screen.

We concluded that false positives such as these would make this feature very inconvenient for our customers, and so we began to look for another option.

Charger+Accelerometer
How about combining the charger and accelerometer signals? After all, this combination is not likely to be required elsewhere. However, we reasoned that this could be even more problematic than the previous options.

It’s well known that batteries run down faster during game play, so users prefer to connect their phones to a power supply before jumping on the sofa to play games. These actions can trigger the same combination of signals. In addition, as we mentioned before, games can also involve the use of the accelerometer.

Some people often toss their phone on a table after connecting it to a power supply. This action would also trigger our app.

The most irritating thing for users, in our opinion, would be driving on a bumpy road with map open and phone charging, and seeing the anti-virus dialog on the screen instead of their maps app.

Moreover, some USB connectors are of very poor quality, resulting in loose connections. The charging/not-charging signals are transmitted so fast, they are imperceptible. And, wireless chargers are often more poorly made than USB connectors.

We knew we’d experience a barrage of negative feedback if we went for this combination, so we abandoned it and moved on.

Charger+Headphones+Accelerometer
This is the final solution we came up with. Proven to be resistant to false positives, this combination seems to work best for devices infected with ransomware Trojans.

To unlock your device:

• Plug in and then unplug the charger. 
• Plug in and then unplug the headphones. 
• Shake the phone. 

This combination has already unlocked thousands of Android devices. Nonetheless, when we advise ransomware victims to take the above steps, they always ask us incredulously, “Are you serious?!”

Yes, we are, and it really works!