How much is difficult realize a malware ignored by antimalware solutions?

Pretty simple, according to recent researches!

A group of the researchers from the Iswatlab team at the University of Sannio demonstrated how is easy to create a mobile malware that eludes antivirus solutions.

The research was conducted by Corrado Aaron Visaggio and Francesco Mercaldo, who realized an engine that applies the following transformations chain to an android malware code which alter the code’s shape, but not the behavior of the malware:

Changing Package Name
Data Encoding
Code Reordering
Insert Junk Instruction NOP
Insert Junk Instruction Branch
Insert Junk Instruction Garbage
Identifiers Renaming Package
Identifiers Renaming Class
Call Indirection

We developed a framework which applies a set of transformations to Android applications smali code. We then transformed a real world malware data-set and then we submitted the applications to the website, in order to evaluate the maliciousness before and after the transformations (we submitted every sample pre and post transformation process).

Some sites named this solution the “Malware Washing Machine“.

The tests

We worked on a data-set, composed of 5560 malwares belonging to 178 different malware families.
We applied all the transformations combined together on the malware data-set.

The malware data-set is available at:

The results?

The results is impressive: the antimalware is not able to recognize the transformed malware (given that it was able to recognize the original malware)

From the paper:

Percentage ratio of antimalwares that detect as malicious more than 
90% of the malwares that analyze.

  • Original malware set : 47%
  • Transformed malware set: 7%

The simple transformation of malwares can turn a known and recognizable malware into an undetectable malware.

This should lead research and industry to develop detection mechanisms which are robust against this trivial evasion techniques.

For more information about result and more technical details regarding the transformation chain, refer to the original paper:

The source code

Freely available on GitHub:

10 tips to secure your mobile phone, by MalwareBytes

Some are useful, others a little trivial

Recently i have read a useful article in MalwareBytes Blog, that shares 10 tips for securing mobile devices.

Just last month, vulnerabilities in iOS 9.3.5 were being exploited by the notorious NSO Group, maker of surveillance software, to read text messages and emails, record sounds, collect passwords, and even track the calls and whereabouts of users. Apple released a security patch on August 25 in response.

Meanwhile, on the Android side, a Linux bug first introduced in Android 4.4 (and present in all future versions) left 1.4 billion users vulnerable to hijacking attacks. The vulnerability allows attackers to terminate connections and, if the connections aren’t encrypted, inject malicious code or content into users’ communications. Representatives from Google say they are aware of the vulnerability and are “taking the appropriate actions.”

I have highlighted tips that are (in my opinion) the most important

Ways to stay secure

  1. Lock your phone with a password or fingerprint detection. 
    Set the time on your password lock to be short as well — 30 seconds or less should cut it.
  2. If it’s not already the default on your phone, consider encrypting your data.
  3. Set up remote wipe. If your phone is lost or stolen, you’ll be able to wipe all of its data remotely.
  4. Back up phone data. Consider connecting your device to its associated cloud service in order to automatically back up data (and encrypt it).
  5. Avoid third-party apps. If you’re on an iPhone, you don’t have much of a choice. However, for Android users, staying on Google Play and not allowing apps from unknown sources keeps you relatively safe. If you do decide to use third-party apps, research to be sure you’re not getting a malicious one. Read reviews, and if the app asks for access to too much personal data up front, don’t download it.
  6. Avoid jailbreaking your iPhone or rooting your Android. While the processes are different, the end result is bypassing what phone manufacturers intended (including security protocols) and ultimately weakening the security of your device.
  7. Update operating systems often.
  8. Be wary of social engineering scams.
  9. Use public wifi carefully: public wifi is inherently insecure, so try not to make transactions or transmit sensitive data while using it. 
    Consider using a VPN service to encrypt data transmitted online.
  10. Download anti-malware for your mobile device. If you do happen to download a malicious app or open a malicious attachment, mobile anti-malware protection can prevent the infection.

The original article

Top 10 ways to secure your mobile phone

Xiaomi’s Analytics app can install any app on you Android device?

Xiaomi, what are you doing?

The security researcher Thijs Broenink has reversed the app AnaliticsCore, that comes preinstalled on his Xiaomi Mi4, and found that this app checks for a new update from the company’s official server every 24 hours.

With these request to, the app sends device identification information with it, like IMEI, Model, MAC address and other.

If there is an updated app available on the server with the filename “Analytics.apk” it will automatically get downloaded and installed in the background without user interaction and without any validation to check which APK will be installed to the device.

This means Xiaomi can remotely and silently install any application on your device just by renaming it to “Analytics.apk” and hosting it on own server:

It seems like there indeed is no validation on what APK is getting installed. So it looks like Xiaomi can replace any (signed?) package they want silently on your device within 24 hours. And I’m not sure when this AppInstaller gets called, but I wonder if it’s possible to place your own Analytics.apk inside the correct dir, and wait for it to get installed (edit: getExternalCacheDir() is inside the app’s sandbox, so probably not).

But this sounds like a vulnerability to me anyhow, since they have your IMEI and Device Model, they can install any apk for your device specifically.

For more technical informations and code analysis, check Thijs Broenink’s Website.

Automated Android Malware Analysis with CuckooDroid

Mechanical Bird!

Cuckoo Sandbox is a famous Open Source software for automating analysis of suspicious files.

CuckooDroid is an extension that brings to Cuckoo the capabilities of execution and analysis of android applications.

Developed by Idan Revivo and Ofer Caspi, CuckooDroid provides both static and dynamic APK inspection as well as evading certain VM-detection techniques, encryption key extraction, SSL inspection, API call trace, basic behavioural signatures and many other features.


git config --global "[email protected]"
git config --global "Your Name"
git clone --depth=1 cuckoo -b 1.2
cd cuckoo
git remote add droid
git pull --no-edit -s recursive -X theirs droid master
cat conf-extra/processing.conf >> conf/processing.conf
cat conf-extra/reporting.conf >> conf/reporting.conf
rm -r conf-extra
echo "protobuf" >> requirements.txt

More info and downloads

New Android vulnerability affects over 900 million Qualcomm devices

Yep! Another vulnerability in Qualcomm devices, dubbed “QuadRooter”, was disclosed by Check Point in a session at DEF CON 24 in Las Vegas

QuadRooter is a set of four vulnerabilities discovered in devices running Android Marshmallow and earlier that ship with Qualcomm chip could allow an attacker to gain root-level access to device.

If exploited, QuadRooter vulnerabilities can give attackers complete control of devices and unrestricted access to sensitive personal and enterprise data on them. 
According to the latest statistics, the chip is found in more than 900 Million Android devices including the latest and most popular devices found on the market today:

  • BlackBerry Priv
  • Blackphone 1 and Blackphone 2
  • Google Nexus 5X, Nexus 6 and Nexus 6P
  • HTC One, HTC M9 and HTC 10
  • LG G4, LG G5, and LG V10
  • New Moto X by Motorola
  • OnePlus One, OnePlus 2 and OnePlus 3
  • Samsung Galaxy S7 and Samsung S7 Edge
  • Sony Xperia Z Ultra

The four security vulnerabilities

  1. CVE-2016–2503 discovered in Qualcomm’s GPU driver and fixed in Google’s Android Security Bulletin for July 2016.
  2. CVE-2016–2504 found in Qualcomm GPU driver and fixed in Google’s Android Security Bulletin for August 2016.
  3. CVE-2016–2059 found in Qualcomm kernel module and fixed in April, though patch status is unknown.
  4. CVE-2016–5340 presented in Qualcomm GPU driver and fixed, but patch status unknown.

The vulnerabilities were disclosed in a session at DEF CON, and in a post on Check Point blog:

QuadRooter vulnerabilities are found in software drivers that ship with Qualcomm chipsets. Any Android device built using these chipsets is at risk. The drivers, which control communication between chipset components, become incorporated into Android builds manufacturers develop for their devices.

Since the vulnerable drivers are pre-installed on devices at the point of manufacture, they can only be fixed by installing a patch from the distributor or carrier. Distributors and carriers issuing patches can only do so after receiving fixed driver packs from Qualcomm.

This situation highlights the inherent risks in the Android security model. Critical security updates must pass through the entire supply chain before they can be made available to end users. Once available, the end users must then be sure to install these updates to protect their devices and data.

How to check if my device is vulnerable?

You can check if your smartphone or tablet is vulnerable to QuadRooter attack using Check Point’s free app.


Protect privacy while using Pokémon GO

You like playing Pokémon GO? Good, but not forget your privacy!

Since this is an augmented reality game, Pokémon GO requires your GPS location and a data connection (either WiFi or cellular data), so you can not expect your privacy to be guaranted while playing this game.

Furthermore, the previous versions of Pokémon GO app requires extensive permissions to your Google account:

“See and modify nearly all information in your Google Account (but it can’t change your password, delete your account, or pay with Google Wallet on your behalf).”

This means that an old Pokémon GO app could:

  • Read all your email.
  • Send email on your behalf.
  • Access your Google Drive documents (including deleting them).
  • Look at your search history as well as Maps navigation history.
  • Access your private photos stored in Google Photos.
  • And a whole lot more.

Although the security hole has been patched in the current version, a new bug could be discovered at any time.

So, i feel to suggest don’t use your personal Gmail account to log in, as this links your personal information including your GPS location and Pokémon GO activity.

You can use a “disposableGoogle account: create an all new Google account, with nothing in it, and use this account to sign into Pokémon GO as well as other apps that you may find doubtful.

Androguard : reverse engineering tool for Android applications

“Always Ready Always There”

Androguard is a great tool written in Python to analyse/reverse Android applications.

Developed by Anthony Desnos and Geoffroy Gueguen, Androguard is released under Apache License 2.0


  • Map and manipulate DEX/ODEX/APK/AXML/ARSC format into full Python objects
  • Diassemble/Decompilation/Modification of DEX/ODEX/APK format
  • Decompilation with the first native (directly from dalvik bytecodes to java source codes) dalvik decompiler (DAD)
  • Access to the static analysis of the code (basic blocks, instructions, permissions and create your own static analysis tool
  • Analysis a bunch of android apps
  • Analysis with ipython/Sublime Text Editor
  • Measure the efficiency of obfuscators
  • Determine if your application has been pirated (plagiarism/similarities/rip-off indicator)
  • Detection of ad/open source libraries
  • Risk indicator of malicious application
  • Decompile Android’s binary xml
  • Integration with external decompilers (JAD+dex2jar/DED/fernflower/jd-gui…)


Hacking of the Qualcomm Secure Execution Environment permit to break Android Full Disk Encryption

Yes: if you have an Android smartphone with Qualcomm chipset FBI could be able to decrypt your device!

Bits, Please!” has published an article in which he explains how, with the complicity of a feature of QSEE (Qualcomm Secure Execution Environment) and some errors in the Android code, you can decrypt devices with Full Disk Encryption enabled.

Google started to implement Full Disk Encryption on Android starting with version 5.0 with the purposes of protecting data on the device from unauthorized access.

Android’s disk happens in the background and invisible to the user, the disk is encrypted/decrypted transparently.

Bits, Please!” recently has analyzed Android’s Full Disk Encryption implementation and came to the conclusion that that Android’s disk encryption on devices with Qualcomm chips hinges on the user’s account password only.

Android uses the user’s password to create a strong 2048 RSA key but, using a feature in the Qualcomm chipset is possible to extract the encryption key.

Qualcomm Trusted Execution Environment allows small apps, known as “Trustlets”, to run inside of this secure environment and away from the main Android OS. 
And one of these QSEE apps running is KeyMaster:

But exploiting an Android vulnerability you can load a custom QSEE app inside TrustZone, which can lead to privilege escalation and hijacking of the full space, as well as the theft of the unencrypted blob containing the keys generated for full-disk encryption.

Once this step is complete, with a brute-force attack it’s possible to extract the user password, PIN, or lock, and all you need to decrypt Android FDE:


The key derivation is not hardware bound. Instead of using a real hardware key which cannot be extracted by software (for example, the SHK), the KeyMaster application uses a key derived from the SHK and directly available to TrustZone.

Qualcomm and OEMs can comply with law enforcement to break Full Disk Encryption. Since the key is available to TrustZone, Qualcomm and OEMs could simply create and sign a TrustZone image which extracts the KeyMaster keys and flash it to the target device. This would allow law enforcement to easily brute-force the FDE password off the device using the leaked keys.

Patching TrustZone vulnerabilities does not necessarily protect you from this issue. Even on patched devices, if an attacker can obtain the encrypted disk image (e.g. by using forensic tools), they can then “downgrade” the device to a vulnerable version, extract the key by exploiting TrustZone, and use them to brute-force the encryption. Since the key is derived directly from the SHK, and the SHK cannot be modified, this renders all down-gradable devices directly vulnerable.

Android FDE is only as strong as the TrustZone kernel or KeyMaster. Finding a TrustZone kernel vulnerability or a vulnerability in the KeyMaster trustlet, directly leads to the disclosure of the KeyMaster keys, thus enabling off-device attacks on Android FDE.

The exploit

The researcher has published on GitHub the full sourcecode of the exploit ( and a set of python scripts which can be used to brute-force Android Full Disk Encryption (

The original paper

The original article is highly technical but very interesting for a programmer or a security expert: