Looking for ways to unlock and read the content of an encrypted PDF without knowing the password?

Well, that’s now possible, sort of—thanks to a novel set of attacking techniques that could allow attackers to access the entire content of a password-protected or encrypted PDF file, but under some specific circumstances.

Dubbed PDFex, the new set of techniques includes two classes of attacks that take advantage of security weaknesses in the standard encryption protection built into the Portable Document Format, better known as PDF.

To be noted, the PDFex attacks don’t allow an attacker to know or remove the password for an encrypted PDF; instead, enable attackers to remotely exfiltrate content once a legitimate user opens that document.

In other words, PDFex allows attackers to modify a protected PDF document, without having the corresponding password, in a way that when opened by someone with the right password, the file will automatically send out a copy of the decrypted content to a remote attacker-controlled server on the Internet.

The researchers tested their PDFex attacks against 27 widely-used PDF viewers, both for desktop and browser-based, and found all of them vulnerable to at least one of the two attacks, though the majority were found vulnerable to both attacks.

The affected PDF viewers include popular software for Windows, macOS and Linux desktop operating systems such as:

  • Adobe Acrobat
  • Foxit Reader
  • Okular
  • Evince
  • Nitro Reader

…as well as PDF viewer that comes built into web browsers:

  • Chrome
  • Firefox
  • Safari
  • Opera

PDFex Attacks Exploit Two PDF Vulnerabilities

Discovered by a team of German security researchers, PDFex works because of the two major weaknesses in the PDF encryption, as described below:

1) Partial Encryption — Standard PDF specification by design supports partial encryption that allows only strings and streams to be encrypted, while objects defining the PDF document’s structure remains unencrypted.

Thus, support for mixing of ciphertexts with plaintexts leaves an opportunity for attackers to easily manipulate the document structure and inject malicious payload into it.

2.) Ciphertext Malleability — PDF encryption uses the Cipher Block Chaining (CBC) encryption mode with no integrity checks, which can be exploited by attackers to create self-exfiltrating ciphertext parts.

PDFex Attack Classes: Direct Exfiltration and CBC Gadgets

Now, let’s briefly understand the two classes of PDFex attacks.

Class 1: Direct Exfiltration — It abuses the partial encryption feature of a protected PDF file.

While leaving the content to be exfiltrated untouched, an attacker can add additional unencrypted objects in a targeted encrypted PDF, which can be used to define a malicious action to be performed when successfully opened by a legitimate user.

These actions, as listed below, defines the way a remote attacker can exfiltrate the content:

  • Submitting a form
  • Invoking a URL
  • Executing JavaScript

“The Action references the encrypted parts as content to be included in requests and can thereby be used to exfiltrate their plaintext to an arbitrary URL,” the paper reads.

“The execution of the Action can be triggered automatically once the PDF file is opened (after the decryption) or via user interaction, for example, by clicking within the document.”

For example, as shown in the picture, the object which contains the URL (in blue color) for form submission is not encrypted and completely controlled by the attacker.

Class 2: CBC Gadgets — Not all PDF viewers support partially encrypted documents, but many of them also don’t have file integrity protection, which allows attackers to modify the plaintext data directly within an encrypted object.

The attack scenario of CBC gadget-based attacks are almost the same as the Direct Exfiltration attacks with the only difference that here attacker modifies the existing encrypted content or create new content from CBC gadgets to add actions that define how to exfiltrate data.

Besides this, if a PDF contains compressed streams to reduce the file size, attackers need to use half-open object streams to steal the data.

PoC Exploit Released for PDFex Attacks

The team of researchers, which includes six German academics from Ruhr-University Bochum and Münster University, has reported their findings to all affected vendors and also released proof-of-concept exploits for PDFex attacks to the public.

Some of the previous research by the same team of researchers include the eFail attack revealed on May 2018 that affected over a dozen popular PGP-encrypted email clients.

For more technical details of the PDFex attacks, you can head on to this dedicated website released by the researchers and the research paper [PDF] titled, “Practical Decryption exFiltration: Breaking PDF Encryption.”

If you have an account with the Comodo discussion board and support forums, also known as ITarian Forum, you should change your password immediately.

Cybersecurity company Comodo has become one of the major victims of a recently disclosed vBulletin 0-day vulnerability, exposing login account information of over nearly 245,000 users registered with the Comodo Forums websites.

In a brief security notice published earlier today, Comodo admitted the data breach, revealing that an unknown attacker exploited the vBulletin vulnerability (CVE-2019-16759) and potentially gained access to Comodo Forums database.

It’s worth noting that Comodo forum was hacked on September 29, almost four days after vBulletin developers released a patch to let administrators address the vulnerability, but the company failed to apply the patches on time.

As The Hacker News broke the news last week, an anonymous hacker publicly disclosed details of a critical then-unpatched vulnerability in vBulletin—one of the widely used internet forum software—which could have allowed remote attackers to execute arbitrary commands on the web server.

However, Comodo has not specified which of the company’s forums has been hacked out of the two separate forums it owns.

One the forums, “forums.comodo.com,” is hosted at Comodo’s own sub-domain and is powered by the different forum software, called Simple Machines Forum, and appears not to be impacted.

The second forum, which runs over the vBulletin software and has likely been hacked, is ITarian Forum hosted at “forum.itarian.com,” a discussion board where the company offers technical assistance to the users of its products.

What Type of Information Was Accessed?

The breached database contains forum users’ information, including:

  • Login username
  • Name
  • Email address
  • Hashed passwords
  • Last IP address used to access the forums
  • Some social media usernames in very limited situations.

The company became aware of the security breach over the weekend on September 29 morning, which suggests users registered on Comodo Forums until this Sunday are impacted by the breach.

“Very recently a new vulnerability in the vBulletin software, which is one of the most popular server applications for website comments including the Comodo Forums, was made public,” the company says.

“Over the weekend at 4:57 am ET on Sunday, September 29, 2019, we became aware that this security flaw in the vBulletin software had become exploited resulting in a potential data breach on the Comodo Forums.”

Immediately after detecting the security intrusion, the Comodo IT infrastructure team immediately took the forums offline in an attempt to mitigate the vBulletin exploit and applied the recommended security patches.

What Users Should Do Now?

If you have registered with Comodo Forums on or before September 29, you are highly recommended to immediately change the password for your forum account to a strong and unique one and for any other online account where you use the same credentials.

Although the account passwords were hashed in vBulletin for the Comodo Forum users, Comodo advises users to change their passwords as part of good password practices.

“We deeply regret any inconvenience or distress this vulnerability may have caused you, our users,” the company says.

“As members of our community of Comodo Forum users, we want to reassure you that we have put in place measures to ensure that vulnerabilities in third-party software, such as vBulletin, will be patched immediately when patches become available.”

The infamous eGobbler hacking group that surfaced online earlier this year with massive malvertising campaigns has now been caught running a new campaign exploiting two browser vulnerabilities to show intrusive pop-up ads and forcefully redirect users to malicious websites.

To be noted, hackers haven’t found any way to run ads for free; instead, the modus operandi of eGobbler attackers involves high budgets to display billions of ad impressions on high profile websites through legit ad networks.

But rather than relying on visitors’ willful interaction with advertisements online, eGobbler uses browser (Chrome and Safari) exploits to achieve maximum click rate and successfully hijack as many users’ sessions as possible.

In its previous malvertising campaign, eGobbler group was exploiting a then-zero-day vulnerability (CVE-2019-5840) in Chrome for iOS back in April, which allowed them to successfully bypass browser’s built-in pop-up blocker on iOS devices and hijack 500 million mobile user sessions in just a week to show pop-up ads.

Malicious sample pop-up ad showing how attackers social engineer victims

Though Google already patched the vulnerability with the release of Chrome 75 in June, eGobbler is still using the flaw to target those who haven’t yet updated their Chrome browser.

eGobbler Exploits WebKit Flaw to Redirect Users to Malicious Sites

However, according to the latest report published by security firm Confiant, the eGobbler threat actors recently discovered and started exploiting a new vulnerability in WebKit, the browser engine used by Apple Safari browser for both iOS and macOS, Chrome for iOS and also by earlier versions of Chrome for desktop.

The new WebKit exploit is more interesting because it doesn’t require users to click anywhere on legit news, blog or informative websites they visit, neither it spawns any pop-up ad.

Instead, the display ads sponsored by eGobbler leverage the WebKit exploit to forcefully redirect visitors to websites hosting fraudulent schemes or malware as soon as they press the “key down” or “page down” button on their keyboards while reading the content on the website.

This is because the Webkit vulnerability actually resides in a JavaScript function, called the onkeydown event that occurs each time a user presses a key on the keyboard, that allows ads displayed within iframes to break out of security sandbox protections.

“This time around, however, the iOS Chrome pop-up was not spawning as before, but we were, in fact, experiencing redirections on WebKit browsers upon the ‘onkeydown’ event,” the researchers said in their latest report.

“The nature of the bug is that a cross-origin nested iframe is able to ‘autofocus’ which bypasses the ‘allow-top-navigation-by-user-activation’ sandbox directive on the parent frame.”

“With the inner frame automatically focused, the keydown event becomes a user-activated navigation event, which renders the ad sandboxing entirely useless as a measure for forced redirect mitigation.”

Though Apple’s app store guidelines restrict all iOS apps with web browsing ability to use its WebKit framework, including for Google Chrome for iOS, mobile users are still less likely to be impacted by the redirection flaw as the ‘onkeydown’ event doesn’t work on the mobile OS.

However, the eGobbler payload, often delivered through popular CDN services, also includes code to trigger redirections when visitors of a targeted web application try to input something in a text area or search forms, likely “to maximize the chances of hijacking these keypresses.”

As researchers believe, “this exploit was key in magnifying the impact of this attack.”

Between August 1 and September 23, the threat actors have been seen serving their malicious code to a staggering volume of ads, which the researchers estimate to be up to 1.16 billion impressions.

While the previous eGobbler malvertising campaign primarily targeted iOS users in the United States, the latest attack targeted users in Europe countries, with a majority being from Italy.

Confiant privately reported the WebKit vulnerability to both the Google and Apple security teams. Apple fixed the flaw in WebKit with the release of iOS 13 on September 19 and in Safari browser 13.0.1 on September 24, while Google has yet to address it in Chrome.

Syhunt Community is a web and now mobile application security scanner. Syhunt is able to scan any kind of application source code for potential security vulnerabilities, pinpointing the exact lines of the code that need to be patched. Or you can simply enter a start URL and get detailed vulnerability information – Syhunt is also composed by a deep crawler able to fully map a website structure and an automated injector able to adapt, mutate, analyze and test the web application response to thousands of different web attacks.


Bulletproof hoster not so Bulletproof after all.

Authorities in Germany have raided, busted and seized a massive data bunker called “Cyberbunker 2.0” used by dark web criminals to run drugs, explicit child content and other illegal activities. 

The data center was being run inside a former NATO bunker in the town of Traben-Trarbach in Western Germany. In total, 600 police officers took part in the raid seizing over 200 servers and arresting 7 individuals at a local restaurant in Schwalbach, a town outside Frankfurt.

According to Deutsche Welle, the bunker is 5,000-square-meter with iron doors, which goes five floors deep underground. The building was located on a 1.3-hectare (3.2-acre) property secured with a fence and surveillance cameras.

1: The area from a bird’s-eye view – 2: Police entering the bunker – 3: Massive servers inside the data center – 4: “Workplace” in the bunker. Images provided by German Police.

According to AP, the former military bunker was also hosting dark web marketplaces like “Cannabis Road,” “Orange Chemicals,” “Flight Vamp 2.0” and infamous “Wall Street Market” which was seized and shut down earlier this year.

Wall Street was one of the largest dark web marketplaces known for selling illicit drugs, stolen databases, hacking tools, ransomware, and other illegal stuff. Flight Vamp 2.0 was supposed to be the largest Swedish darknet marketplace for the illegal sale of narcotics. There were over 600 sellers and about active 10,000 in the marketplace.

Moreover, the same data center is believed to be used by cybercriminals to carry out 2016’s large scale DDoS attack on Deutsche Telekom, a German telecommunications company.

On the other hand, Brian Krebs reported that German police also managed to seize two dark web domain including cb3rob[.]org and ZYZTM Research in The Netherlands (zyztm[.]com).

Homepage left by authorities on cb3rob.

In a press briefing, Prosecutor Juergen Bauer said that 13 people aged 20 to 59 are currently under investigation including three German and seven Dutch citizens. It is worth noting that authorities in Luxembourg, Netherlands and Poland also carried out separate raids related to the operation. It is unclear if any arrest was made.

The 59-year-old Dutchman man whose name has not been shared is believed to be the owner of the bunker who reportedly setup “bulletproof hoster” to run illegal content in the data center.

Police officers seized the bunker at night – photo: German Police

Regional criminal police chief Johannes Kunz said that “I think it’s a huge success … that we were able at all to get police forces into the bunker complex, which is still secured at the highest military level. “We had to overcome not only real, or analog, protections; we also cracked the digital protections of the data center,” Kunz said.

There is a trove of data stored on the servers seized by authorities and it may take years for them to analyze it. Meanwhile, prosecutors are gearing up for starting proceedings against the culprits arrested by German police. Stay tuned.

A critical security vulnerability has been discovered and fixed in the popular open-source Exim email server software, which could allow a remote attacker to simply crash or potentially execute malicious code on targeted servers.

Exim maintainers today released an urgent security update—Exim version 4.92.3—after publishing an early warning two days ago, giving system administrators an early head-up on its upcoming security patches that affect all versions of the email server software from 4.92 up to and including then-latest version 4.92.2.

Exim is a widely used, open source mail transfer agent (MTA) developed for Unix-like operating systems like Linux, Mac OSX or Solaris, which runs almost 60 percent of the Internet’s email servers today for routing, delivering and receiving email messages.

This is the second time in this month when the Exim maintainers have released an urgent security update. Earlier this month, the team patched a critical remote code execution flaw (CVE-2019-15846) in the software that could have allowed remote attackers to gain root-level access to the system.

Identified as CVE-2019-16928 and discovered by Jeremy Harris of Exim Development Team, the vulnerability is a heap-based buffer overflow (memory corruption) issue in string_vformat defined in string.c file of the EHLO Command Handler component.

The security flaw could allow remote attackers to cause a denial of service (DoS) condition or execute arbitrary code on a targeted Exim mail server using a specially crafted line in the EHLO command with the rights of the targeted user.

According to the Exim advisory, a currently known PoC exploit for this vulnerability allows one to only crash the Exim process by sending a long string in the EHLO command, though other commands could also be used to potentially execute arbitrary code.

“The currently known exploit uses an extraordinary long EHLO string to crash the Exim process that is receiving the message,” says the Exim developers’ team.

“While at this mode of operation, Exim already dropped its privileges, other paths to reach the vulnerable code may exist.”

In mid-year, Exim also patched a severe remote command execution vulnerability (CVE-2019-10149) in its email software that was actively exploited in the wild by various groups of hackers to compromise vulnerable servers.

Therefore, server administrators are highly recommended to install the latest Exim 4.92.3 version as soon as possible, since there is no known mitigation to temporarily resolve this issue.

The team also says, “if you can’t install the above versions, ask your package maintainer for a version containing the backported fix. On request and depending on our resources, we will support you in backporting the fix.”


* Monitor mode
* Frame injection
* Wi-Fi Direct
* Hostapd
* Kernel up to v5.3+
* RTKMPtool for low level debug


* Test & fix the 8821au support (@fariouche has been working on it)
* Clean out Windows & FreeBSD code (partially. some NDIS code and switches around)
* Clean out unsupported chipsets (partially. some switches left all around
* Throw/rip Intel WIDI support out, it's left behind anyway.
* Consider adding rtl8188eus HAL/phydm support into the driver for simplicity.

IPERF3 benchmark

[Device] Alfa Networks AWUS036ACH
[Chipset] 88XXau (rtl8812au)
[Branch] v5.6.4.1
[Distance] 10m free sight

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  11.6 MBytes  97.4 Mbits/sec    0   96.2 KBytes       
[  5]   1.00-2.00   sec  11.2 MBytes  93.8 Mbits/sec    0    100 KBytes       
[  5]   2.00-3.00   sec  11.2 MBytes  93.8 Mbits/sec    0    100 KBytes       
[  5]   3.00-4.00   sec  11.2 MBytes  93.8 Mbits/sec    0    100 KBytes       
[  5]   4.00-5.00   sec  11.2 MBytes  93.8 Mbits/sec    0    100 KBytes       
[  5]   5.00-6.00   sec  11.4 MBytes  95.9 Mbits/sec    0    105 KBytes       
[  5]   6.00-7.00   sec  11.2 MBytes  93.8 Mbits/sec    0    105 KBytes       
[  5]   7.00-8.00   sec  11.3 MBytes  94.9 Mbits/sec    0    157 KBytes       
[  5]   8.00-9.00   sec  11.2 MBytes  93.8 Mbits/sec    0    157 KBytes       
[  5]   9.00-10.00  sec  11.2 MBytes  94.3 Mbits/sec    0    157 KBytes       
[  5]  10.00-11.00  sec  11.2 MBytes  93.8 Mbits/sec    0    157 KBytes       
[  5]  11.00-12.00  sec  11.2 MBytes  93.8 Mbits/sec    0    157 KBytes       
[  5]  12.00-13.00  sec  11.2 MBytes  94.4 Mbits/sec    0    157 KBytes       
[  5]  13.00-14.00  sec  11.2 MBytes  93.8 Mbits/sec    0    157 KBytes       
[  5]  14.00-15.00  sec  11.2 MBytes  94.4 Mbits/sec    0    157 KBytes       
[  5]  15.00-16.00  sec  10.9 MBytes  91.7 Mbits/sec    0    157 KBytes       
[  5]  16.00-17.00  sec  11.2 MBytes  94.4 Mbits/sec    0    157 KBytes       
[  5]  17.00-18.00  sec  11.2 MBytes  94.4 Mbits/sec    0    157 KBytes       
[  5]  18.00-19.00  sec  11.2 MBytes  94.4 Mbits/sec    0    157 KBytes       
[  5]  19.00-20.00  sec  11.2 MBytes  93.8 Mbits/sec    0    157 KBytes       
[  5]  20.00-21.00  sec  11.2 MBytes  93.8 Mbits/sec    0    157 KBytes       
[  5]  21.00-22.00  sec  11.2 MBytes  93.8 Mbits/sec    0    157 KBytes       
[  5]  22.00-23.00  sec  11.2 MBytes  93.8 Mbits/sec    0    157 KBytes            
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-23.15  sec   260 MBytes  94.2 Mbits/sec    0             sender
[  5]   0.00-23.15  sec  0.00 Bytes  0.00 bits/sec                  receiver


This driver can be installed using [DKMS]. This is a system which will automatically recompile and install a kernel module when a new kernel gets installed or updated. To make use of DKMS, install the dkms package, which on Debian (based) systems is done like this:

sudo apt-get install dkms

Installation of Driver

In order to install the driver open a terminal in the directory with the source code and execute the following command:

sudo ./dkms-install.sh

Removal of Driver

In order to remove the driver from your system open a terminal in the directory with the source code and execute the following command:

sudo ./dkms-remove.sh


For building & installing the driver with ‘make’ use

make install



git clone -b v5.6.4.1 https://github.com/aircrack-ng/rtl8812au.git
cd rtl*

Package / Build dependencies (Kali)

sudo apt-get install build-essential
sudo apt-get install bc
sudo apt-get install libelf-dev
sudo apt-get install linux-headers-`uname -r`

For Raspberry (RPI)

sudo apt-get install bc raspberrypi-kernel-headers

Then run this step to change platform in Makefile, For RPI 1/2/3/ & 0/Zero:

$ sed -i 's/CONFIG_PLATFORM_I386_PC = y/CONFIG_PLATFORM_I386_PC = n/g' Makefile

But for RPI 3B+ & 4B you will need to run those below which builds the ARM64 arch driver:

$ sed -i 's/CONFIG_PLATFORM_I386_PC = y/CONFIG_PLATFORM_I386_PC = n/g' Makefile
$ sed -i 's/CONFIG_PLATFORM_ARM64_RPI = n/CONFIG_PLATFORM_ARM64_RPI = y/g' Makefile

For setting monitor mode

  1. Fix problematic interference in monitor mode.
airmon-ng check kill

You may also uncheck the box “Automatically connect to this network when it is avaiable” in nm-connection-editor. This only works if you have a saved wifi connection.

  1. Set interface down
sudo ip link set wlan0 down
  1. Set monitor mode
sudo iw dev wlan0 set type monitor
  1. Set interface up
sudo ip link set wlan0 up

For setting TX power

sudo iw wlan0 set txpower fixed 3000

LED control

You can now control LED behaviour statically by Makefile, for example:


value can be y or n

statically by module parameter in /etc/modprobe.d/8812au.conf or wherever, for example:

options 88XXau rtw_led_enable=0

value can be 0 or 1

or dynamically by writing to /proc/net/rtl8812au/$(your interface name)/led_enable, for example:

$ echo "0" > /proc/net/rtl8812au/$(your interface name)/led_enable

value can be 0 or 1

check current value:

$ cat /proc/net/rtl8812au/$(your interface name)/led_enable

USB Mode Switch

0: doesn’t switch, 1: switch from usb2.0 to usb 3.0 2: switch from usb3.0 to usb 2.0

$ rmmod 88XXau
$ modprobe 88XXau rtw_switch_usb_mode:int (0: no switch 1: switch from usb2 to usb3 2: switch from usb3 to usb2)


Newer versions of NetworkManager switches to random MAC address. Some users would prefer to use a fixed address. Simply add these lines below


at the end of file /etc/NetworkManager/NetworkManager.conf and restart NetworkManager with the command:

sudo service NetworkManager restart

Credits / Contributors

astsam      - https://github.com/astsam
aircrack-ng - https://github.com/aircrack-ng
evilphish   - https://github.com/evilphish
fariouche   - https://github.com/fariouche
CGarces     - https://github.com/CGarces
ZerBea      - https://github.com/ZerBea
lwfinger    - https://github.com/lwfinger
Ulli-Kroll  - https://github.com/Ulli-Kroll

Aldo, thanks to Realtek and Alfa Networks for all they're help & support.

All the others interested and participating. Appreciate it!


This project is intended for learning purposes only and is not affiliated with Google in any way.


Before interacting with the Play Store you have to provide valid credentials and an ANDROID ID associated to your account. Please modify the credentials.json file and insert the required information before trying to use this tool:

  • Enter your Google email and password in the USERNAME and PASSWORD fields of the credentials.json file. This information is needed to authenticate with Google’s servers.
  • Use the above credentials on an Android device (real or emulated) and download at least one application using the official Google Play Store on the device. This step is necessary in order to associate the ANDROID ID of the device to your account, so that you will be able to download applications as if you were directly using your device. Do not remove the account from the device or its ANDROID ID won’t be valid anymore.
  • Get the ANDROID ID of the device and fill the ANDROID_ID field of the credentials.json file. You can obtain the ANDROID ID by installing the Device ID application on your device, then copy the string corresponding to Google Service Framework (GSF) (use this string instead of the Android Device ID presented by the application).
  • In case of errors related to the authentication after the above steps, consider allowing less secure apps to access your account by visiting https://myaccount.google.com/lesssecureapps (visit the link while you are logged in).

Note that you will be able to download only the applications compatible with the device corresponding to the aforementioned ANDROID ID and further limitations may influence the total number of applications available for download.


Apart from valid Play Store credentials, the only requirement of this project is a working Python 3.6 installation. The first thing to do is to get a local copy of this repository, so open up a terminal in the directory where you want to save the project and clone the repository:

$ git clone https://github.com/ClaudiuGeorgiu/PlaystoreDownloader.git
$ cd PlaystoreDownloader

Make sure to execute the following commands in the previously created PlaystoreDownloader directory:

# If not using virtualenv (https://virtualenv.pypa.io/), skip the next 2 lines
$ virtualenv -p python3 venv
$ source venv/bin/activate

# Install PlaystoreDownloader requirements
$ pip3 install -r requirements.txt

After configuring the Play Store credentials as described in the configuration, simply call the following instruction using the package name of the app you want to download:

$ python3 download.py "com.application.example"

If the download is successful, the resulting .apk file will be saved in the PlaystoreDownloader/Downloads directory. You can change the name and the location of the downloaded .apk file by providing an additional -o "path/to/downloaded.apk" argument to download.py (type $ python3 download.py --help for more information).

Docker is also supported:

# Make sure to have valid credentials inside credentials.json file before building the image
$ docker build -t downloader .

# Download the selected application in the current directory
$ docker run --rm -u $(id -u):$(id -g) -v "$PWD":"/app/Downloads" downloader "com.application.example"


Obfuscapk is a modular Python tool for obfuscating Android apps without needing their source code, since apktool is used to decompile the original apk file and to build a new application, after applying some obfuscation techniques on the decompiled smali code, resources and manifest. The obfuscated app retains the same functionality as the original one, but the differences under the hood sometimes make the new application very different from the original (e.g., to signature based antivirus software).

Obfuscapk is designed to be modular and easy to extend, so it’s built using a plugin system. Consequently, every obfuscator is a plugin that inherits from an abstract base class and needs to implement the method obfuscate. When the tool starts processing a new Android application file, it creates an obfuscation object to store all the needed information (e.g., the location of the decompiled smali code) and the internal state of the operations (e.g., the list of already used obfuscators). Then the obfuscation object is passed, as a parameter to the obfuscate method, to all the active plugins/obfuscators (in sequence) to be processed and modified. The list and the order of the active plugins is specified through command line options.

The tool is easily extensible with new obfuscators: it’s enough to add the source code implementing the obfuscation technique and the plugin metadata (a <obfuscator-name>.obfuscator file) in the src/obfuscapk/obfuscators directory (take a simple existing obfuscator like Nop as a starting example). The tool will detect automatically the new plugin, so no further configuration is needed (the new plugin will be treated like all the other plugins bundled with the tool).

❱ Installation

There are two ways of getting a working copy of Obfuscapk on your own computer: either by using Docker or by using directly the source code in a Python 3.7 environment. In both cases, the first thing to do is to get a local copy of this repository, so open up a terminal in the directory where you want to save the project and clone the repository:

$ git clone https://github.com/ClaudiuGeorgiu/Obfuscapk.git

Docker image


This is the suggested way of installing Obfuscapk, since the only requirement is to have a recent version of Docker installed:

$ docker --version             
Docker version 19.03.0, build aeac949

Official Docker Hub image

The official Obfuscapk Docker image is available on Docker Hub (automatically built from this repository):

$ # Download the Docker image.
$ docker pull claudiugeorgiu/obfuscapk
$ # Give it a shorter name.
$ docker tag claudiugeorgiu/obfuscapk obfuscapk


If you downloaded the official image from Docker Hub, you are ready to use the tool so go ahead and check the usage instructions, otherwise execute the following commands in the previously created Obfuscapk/src/ directory (the folder containing the Dockerfile) in order to build the Docker image:

$ # Make sure to run the command in Obfuscapk/src/ directory.
$ # It will take some time to download and install all the dependencies.
$ docker build -t obfuscapk .

When the Docker image is ready, make a quick test to check that everything was installed correctly:

$ docker run --rm -it obfuscapk --help
usage: python3.7 -m obfuscapk.cli [-h] -o OBFUSCATOR [-w DIR] [-d OUT_APK]

Obfuscapk is now ready to be used, see the usage instructions for more information.

From source


Make sure to have apktooljarsigner and zipalign installed and available from command line:

$ apktool          
Apktool v2.4.0 - a tool for reengineering Android apk files
$ jarsigner
Usage: jarsigner [options] jar-file alias
       jarsigner -verify [options] jar-file [alias...]
$ zipalign
Zip alignment utility
Copyright (C) 2009 The Android Open Source Project

To install and use apktool you need a recent version of Java, which should also have jarsigner bundled. zipalign is included in the Android SDK. The location of the executables can also be specified through the following environment variables: APKTOOL_PATHJARSIGNER_PATH and ZIPALIGN_PATH (e.g., in Ubuntu, run export APKTOOL_PATH=/custom/location/apktool before running Obfuscapk in the same terminal).

Apart from the above tools, the only requirement of this project is a working Python 3.7 installation (along with its package manager pip).


Run the following commands in the main directory of the project (Obfuscapk/) to install the needed dependencies:

$ # Make sure to run the commands in Obfuscapk/ directory.

$ # The usage of a virtual environment is highly recommended, e.g., virtualenv.
$ # If not using virtualenv (https://virtualenv.pypa.io/), skip the next 2 lines.
$ virtualenv -p python3.7 venv
$ source venv/bin/activate

$ # Install Obfuscapk's requirements.
$ python3.7 -m pip install -r src/requirements.txt

After the requirements are installed, make a quick test to check that everything works correctly:

$ cd src/
$ # The following command has to be executed always from Obfuscapk/src/ directory
$ # or by adding Obfuscapk/src/ directory to PYTHONPATH environment variable.
$ python3.7 -m obfuscapk.cli --help
usage: python3.7 -m obfuscapk.cli [-h] -o OBFUSCATOR [-w DIR] [-d OUT_APK]

Obfuscapk is now ready to be used, see the usage instructions for more information.

❱ Usage

From now on, Obfuscapk will be considered as an executable available as obfuscapk, so you need to adapt the commands according to how you installed the tool:

  • Docker image: a local directory containing the application to obfuscate has to be mounted to /workdir in the container (e.g., the current directory "${PWD}"), so the command:$ obfuscapk [params…]becomes:$ docker run –rm -it -u $(id -u):$(id -g) -v “${PWD}”:”/workdir” obfuscapk [params…]
  • From source: every instruction has to be executed from the Obfuscapk/src/ directory (or by adding Obfuscapk/src/ directory to PYTHONPATH environment variable) and the command:$ obfuscapk [params…]becomes:$ python3.7 -m obfuscapk.cli [params…]

Let’s start by looking at the help message:

$ obfuscapk --help
obfuscapk [-h] -o OBFUSCATOR [-w DIR] [-d OUT_APK] [-i] [-p] [-k VT_API_KEY] <APK_FILE>

There are two mandatory parameters: <APK_FILE>, the path (relative or absolute) to the apk file to obfuscate and the list with the names of the obfuscation techniques to apply (specified with the -o option, e.g., -o Rebuild -o NewSignature -o NewAlignment). The other optional arguments are as follows:

  • -w DIR is used to set the working directory where to save the intermediate files (generated by apktool). If not specified, a directory named obfuscation_working_dir is created in the same directory as the input application. This can be useful for debugging purposes, but if it’s not needed it can be set to a temporary directory (e.g., -w /tmp/).
  • -d OUT_APK is used to set the path of the destination file: the apk file generated by the obfuscation process (e.g., -d /home/user/Desktop/obfuscated.apk). If not specified, the final obfuscated file will be saved inside the working directory. Note: existing files will be overwritten without any warning.
  • -i is a flag for ignoring known third party libraries during the obfuscation, in order to use less resources, to increase performances and to reduce the risk of errors. The list of libraries to ignore is adapted from LiteRadar project.
  • -p is a flag for showing progress bars during the obfuscation operations. When using the tool in batch operations/automatic builds it’s convenient to have progress bars disabled, otherwise this flag should be enabled to see the obfuscation progress.
  • -k VT_API_KEY is needed only when using VirusTotal obfuscator, to set the API key(s) to be used when communicating with Virus Total. Can be set multiple times to cycle through the API keys during the requests (e.g., -k VALID_VT_KEY_1 -k VALID_VT_KEY_2).

Let’s consider now a simple working example to see how Obfuscapk works:

$ # original.apk is a valid Android apk file.
$ obfuscapk -o RandomManifest -o Rebuild -o NewSignature -o NewAlignment original.apk

When running the above command, this is what happens behind the scenes:

  • since no working directory was specified, a new working directory (obfuscation_working_dir) is created in the same location as original.apk (this can be useful to inspect the smali files/manifest/resources in case of errors)
  • some checks are performed in order to make sure that all the needed files/executables are available
  • the actual obfuscation process begins: the specified obfuscators are executed (in order) one by one until there’s no obfuscator left or until an error is encountered
    • when running the first obfuscator, original.apk is decompiled with apktool and the results are stored into the working directory
    • since the first obfuscator is RandomManifest, the entries in the decompiled Android manifest are reordered randomly (without breaking the xml structures)
    • Rebuild obfuscator simply rebuilds the application (now with the modified manifest) using apktool, and since no output file was specified, the resulting apk file is saved in the working directory created before
    • NewSignature obfuscator signs the newly created apk file with a custom certificate contained in this keystore
    • NewAlignment obfuscator uses zipalign tool to align the resulting apk file
  • when all the obfuscators have been executed without errors, the resulting obfuscated apk file can be found in obfuscation_working_dir/original_obfuscated.apk, signed, aligned and ready to be installed into a device/emulator

As seen in the previous example, RebuildNewSignature and NewAlignment obfuscators are always needed to complete an obfuscation operation, in order to build the final obfuscated apk. They are not actual obfuscation techniques, but they are needed in the build process and so they are included in the list of obfuscators to keep the overall architecture modular.

❱ Obfuscators

The obfuscators included in Obfuscapk can be divided into different categories, depending on the operations they perform:

  • Trivial: as the name suggests, this category includes simple operations (that do not modify much the original application), like signing the apk file with a new signature.
  • Rename: operations that change the names of the used identifiers (classes, fields, methods).
  • Encryption: packaging encrypted code/resources and decrypting them during the app execution. When Obfuscapk starts, it automatically generates a random secret key (32 characters long, using ASCII letters and digits) that will be used for encryption.
  • Code: all the operations that involve the modification of the decompiled source code.
  • Resources: operations on the resource files (like modifying the manifest).
  • Other

The obfuscators currently bundled with Obfuscapk are briefly presented below (in alphabetical order). Please refer to the code for more details.

NOTE: not all the obfuscators below correspond to real obfuscation techniques (e.g., RebuildNewSignatureNewAlignment and VirusTotal), but they are implemented as obfuscators in order to keep the architecture modular and easy to extend with new functionality.

AdvancedReflection [Code]

Uses reflection to invoke dangerous APIs of the Android Framework. In order to find out if a method belongs to the Android Framework, Obfuscapk refers to the mapping discovered by Backes et al.

ArithmeticBranch [Code]

Insert junk code. In this case, the junk code is composed by arithmetic computations and a branch instruction depending on the result of these computations, crafted in such a way that the branch is never taken.

AssetEncryption [Encryption]

Encrypt asset files.

CallIndirection [Code]

This technique modifies the control-flow graph without impacting the code semantics: it adds new methods that invoke the original ones. For example, an invocation to the method m1 will be substituted by a new wrapper method m2, that, when invoked, it calls the original method m1.

ClassRename [Rename]

Change the package name and rename classes (even in the manifest file).

ConstStringEncryption [Encryption]

Encrypt constant strings in code.

DebugRemoval [Code]

Remove debug information.

FieldRename [Rename]

Rename fields.

Goto [Code]

Given a method, it inserts a goto instruction pointing to the end of the method and another goto pointing to the instruction after the first goto; it modifies the control-flow graph by adding two new nodes.

LibEncryption [Encryption]

Encrypt native libs.

MethodOverload [Code]

It exploits the overloading feature of the Java programming language to assign the same name to different methods but using different arguments. Given an already existing method, this technique creates a new void method with the same name and arguments, but it also adds new random arguments. Then, the body of the new method is filled with random arithmetic instructions.

MethodRename [Rename]

Rename methods.

NewAlignment [Trivial]

Realign the application.

NewSignature [Trivial]

Re-sign the application with a new custom signature.

Nop [Code]

Insert junk code. Nop, short for no-operation, is a dedicated instruction that does nothing. This technique just inserts random nop instructions within every method implementation.

RandomManifest [Resource]

Randomly reorder entries in the manifest file.

Rebuild [Trivial]

Rebuild the application.

Reflection [Code]

This technique analyzes the existing code looking for method invocations of the app, ignoring the calls to the Android framework (see AdvancedReflection). If it finds an instruction with a suitable method invocation (i.e., no constructor methods, public visibility, enough free registers, etc.) such invocation is redirected to a custom method that will invoke the original method using the Reflection APIs.

Reorder [Code]

This technique consists of changing the order of basic blocks in the code. When a branch instruction is found, the condition is inverted (e.g., branch if lower than, becomes branch if greater or equal than) and the target basic blocks are reordered accordingly. Furthermore, it also randomly re-arranges the code abusing goto instructions.

ResStringEncryption [Encryption]

Encrypt strings in resources (only those called inside code).

VirusTotal [Other]

Send the original and the obfuscated application to Virus Total. You must provide the VT API key (see -k option).


SafeSide is a project to understand and mitigate software-observable side-channels: information leaks between software domains caused by implementation details outside the software abstraction.

Unlike other side-channel attacks — e.g. measuring power use or electromagnetic emissions — software-observable side-channels don’t require physical access or proximity.

Our early focus is on transient execution attacks and leaks from software cryptography implementations.

What’s here?

This repository provides a home for:

  • Practical demonstrations
    Robust, portable examples that leak data through different side-channels under real-world conditions.For more on building and running our examples, see the demos README.
  • Documentation
    References to research that describes what causes side-channels and how they behave.Docs are here.
  • Mitigation development
    Ideas and prototypes for how to find and stop side-channel leaks.


This project is new and under active development. To start, we have a few examples of Spectre side-channel leaks and a collection of links we’ve found useful.

For more information on our plans and priorities, see our Roadmap.


This project is focused on defense. While we enthusiastically believe in the value of adversarial testing (e.g. red teaming) for securing software systems, this repository is not intended to advance the state of the art for attackers.

To that end, we have some ground rules:

  • No nonpublic attacks. This isn’t the place to research new side-channels, discuss any embargoed or otherwise undisclosed vulnerabilities, or try to bypass currently-effective mitigations.
  • No exploits that leak interesting data. We want to show side-channels in action, but we will only leak synthetic data that we put there to be leaked.


These are the areas where we plan to spend our effort and where we think contributions will be most useful.


We’re not satisfied with an archive of proof-of-concept apps. The examples in this repository should read like Knuth-style literate programs, making it abundantly clear how the infoleak functions end-to-end: what setup is strictly necessary; what implementation behaviors we’re relying on or working around; and what we’ve added to make the demonstration more robust.

This standard applies to our examples, the library code they share, and the support infrastructure we provide to get things running.

We’re always on the lookout for ways we can make examples in this project simpler to understand. We expect that will most often mean better comments and better factoring of code. But sometimes it will mean step-function improvements through entirely new, more straightforward approaches.


These examples are each designed to exercise specific vulnerabilities, and they should produce consistent and useful results anywhere those leaks are present.

This could mean amplifying or cleaning up side-channel signal (on the producer or consumer side) or retrying on failure.


This project hopes to provide examples of every kind of software-observable side-channel. They should run in as many environments as they can to enable comprehensive testing of mitigations. We think we’re off to a good start, but we hope to improve our coverage along several dimensions.

Leak vectors

We should have examples embodying most or all known timing leak sources, including (non-exhaustively): Spectre (all variants), Meltdown, Speculative Store Bypass, L1 Terminal Fault (L1TF), and Microarchitectural Data Sampling (MDS).


Our examples should compile with GCC, Clang, and Microsoft Visual C++ (MSVC). (Stretch: ICC.)

Operating systems

Our examples should build and produce useful results on macOS, Windows, and Linux — including, where possible, when those OSes are running virtualized. Eventually we also hope to provide something worth running on iOS and Android.

We intend to explore more virtualized scenarios over time, in which case we will want to cover a diversity of hypervisors and VMMs.

Leak gadgets

Our examples should cover known ways of establishing covert side-channels. Data or instruction cache timing are most popular, but we should also explore execution unit contention (SMoTherSpectre) or activation latency (NetSpectre).

Security domains

We want to show information leaks across a variety of typical security boundaries. In what we think is roughly increasing order of difficulty:

  • Same user address space (e.g. code loaded in a sandbox)
  • User to kernel
  • Two user processes on the same kernel
  • VM guest to VM host kernel
  • Two VM guests on the same host
  • Host to BIOS/SMM
  • Host to trusted execution environment (TEE) / enclave
  • Two systems connected to a fast local network

We expect many of these examples will require turning off existing mitigations or security features that are widely deployed. When we want to demonstrate an attack that isn’t possible on a modern, patched system, we’ll provide infrastructure to create an old, unpatched system.


We want examples that provide clear positive (or negative) results across a wide range of processor generations from different vendors across different architectures. That said, we’ll also generally prioritize working examples for hardware with the broadest deployment.

Target code

We want to demonstrate timing leaks against analogues of different kinds of data-handling code: serialization, cryptographic algorithms, application business logic, etc.

Quantitative evaluation

We believe the robustness of our samples, and the usefulness of potential mitigations, can be evaluated by extracting metrics that can be compared across instances. Bandwidth — correct bytes leaked per unit time — seems like one obvious choice.


We want to make it easy to run many examples across many environments quickly and reproducibly. This supports our mission of enabling quantitative comparison, and should allow for a quick feedback loop for developers prototyping new software-based mitigations.

One of the goals of producing a broad set of examples is to be able to show the effectiveness of mitigations, so we also want to add infrastructure to build and test with existing mitigations enabled.

For example:

  • MSVC: /Qspectre
  • LLVM: -mspeculative-load-hardening
  • GCC: various flags like -mfunction-return and -mindirect-branch
  • ICC: similar to GCC


Bad Authentication data.