Category Archives: software

Intercepting HTTPS Traffic from Apps on Android 7+ using Magisk & Burp

Intercepting HTTPS traffic is a necessity with any mobile security assessment. By adding a custom CA to Android, this can easily be done. As of Android Nougat, however, apps don’t trust client certificates anymore unless the app explicitly enables this. In this blogpost, we present a new Magisk module, that circumvents this requirement, by automatically adding client certificates to the system-wide trust store, which is by default trusted by all apps.

Basic HTTPS interception

Intercepting HTTPS on Android is a very straight-forward job, which only takes a few steps:

  1. Set Burp as your proxy
  2. Visit http://burp
  3. Install the Burp certificate as a user certificate
  4. Intercept

After following these steps, you can view all HTTPS traffic that is sent through the user’s browser. A more detailed explanation can be found on Portswigger’s website.

In the past, this approach would even work for app traffic as the application would trust all installed user certificate by default. One way to prevent app traffic from being intercepted, is by installing certificate pinning. Certificate pinning means that on each SSL connection the certificates presented by the server will be compared to a locally stored version. The connection will only succeed if the server can provide the correct identity. This is a great security feature, but can be tricky to implement.

Enter Android Nougat

Starting with Android Nougat, apps no longer trust user certificates by default. A developer can still choose to accept user certificates by configuring the networkSecurityConfig attribute in the app’s AndroidManifest.xml file, but by default, they are no longer trusted.

A first approach would be to decompile, modify and recompile the application, which are quite some steps to perform. If the app turns out to have protection against repackaging files, this would also be very difficult. An example of this technique can be found on

A different approach is adding the user certificate to the system store. The system store is located at /system/etc/security/cacerts and contains a file for each installed root certificate.

Screen Shot 2017-12-15 at 16.07.58A very simple solution would be copying the user installed file (found at /data/misc/user/0/cacerts-added) to this folder. This is only possible, however, if the system is mounted as r/w. Now, while it is possible to remount /system and perform the necessary actions, this is a rather dirty solution and some root-detection algorithms will detect this modification.

Using Magisk

Magisk is a “Universal Systemless Interface, to create an altered mask of the system without changing the system itself.” The fact that Magisk doesn’t modify the /system partition makes it a very nice solution for security assessments where the application has enhanced root detection. By activating “Magisk Hide” for the targeted application, Magisk becomes completely invisible.

Magisk also supports custom modules that are fairly easy to create. In order to have any user certificate recognized as system certificates, we made a simple Magisk module which can be found on our github. The logic of the module is very basic:

  1. Find installed user certificates
  2. Add them to the /system/etc/security/cacerts directory

When installed, the content of the Magisk module is mounted on /magisk/trustusercerts/. This folder contains multiple files, but the most important one is the system directory. This directory is automatically merged with the real /system directory, without actually touching the /system partition. As a result, all certificates in /magisk/trusteusercerts/etc/security/ will end up in /system/etc/security.

Using the module is easy:

  1. Install the module
  2. Install certificates through the normal flow
  3. Restart your device

After installation, the certificates will show up in your system wide trust store and will be trusted by applications:



Of course, if the application has implemented SSL Pinning, you still won’t be able to intercept HTTPS traffic, but this little module makes Android Nougat apps perform the same way as pre-Android Nougat apps.

If you have any suggestions on how to improve this module, or any ideas on how to add the ability to disable SSL Pinning on the Magisk level, let us know!

Download Magisk Module from Github

About the author

Jeroen Beckers is a mobile security expert working in the NVISO Cyber Resilience team. He also loves to program, both on high and low level stuff, and deep diving into the Android internals doesn’t scare him. You can find Jeroen on LinkedIn.

Who is watching your home surveillance systems?

This morning, I heard on the radio that dozens of Belgian families were being watched through their own home surveillance system in Belgium. Nothing new here, as we already know for years that sites exist through which you can watch camera footage of unknowing victims, and this problem is not just limited to Belgium of course.

Now, looking at this from an IT security perspective, it would be easy to say “it’s their own fault, they should have changed their default passwords!” or “it’s their own fault, why would you make your surveillance system internet accessible?”. The reality is that most users don’t see an issue with connecting their home surveillance system to the internet – especially not if it’s fully supported by the vendor! In the end, it’s reasonable for the user to expect from the vendor that the surveillance system is installed in a secure way.


A quick search on Shodan – a search engine for connected devices – shows thousands of publicly exposed surveillance systems all over the world.

A few weeks ago, one of our colleagues had a specialized firm install security cameras around the house. Our colleague had to move heaven and earth to explain that the video controller should not be directly connected to the internet but that it should be connected to the internal network which is firewalled. As you can see, most people would have no notion of this and would be happy to see the video footage everywhere they go from an app on their smartphone without any type of authentication.

Now, how to avoid your home surveillance system from being viewed by anyone in the world? Well there are several things you can do here, varying in terms of technical difficulty (non-exhaustive list).

  1. Password-protect all your connected devices, and remove anonymous access.
  2. Change the default password on all your connected devices. This will prevent that these devices can be accessed by anyone on the internet using default credentials, such as username and password both being “admin” or “demo”.
  3. Keep your camera software up to date. As with all electronic devices running software is the case, camera systems could contain bugs that allow unauthorized individuals to take control of and view your images. When bugs in cameras are identified, usually (unfortunately not always), the vendors release patches to fix these bugs.
  4. Connect wireless cameras to a secured wireless network. If you use wireless cameras, it is important to connect them to a secure (WPA2) wireless network. This will prevent anyone in the vicinity of your network to eavesdrop on and intercept the communication.

Last but not least, more and more vendors are allowing end users to connect their devices to the cloud and have them view the images through a secured online portal. Moving forward this looks to be a good solution for private homes as with this solution it is not needed to make your cameras internet accessible but in the same time you would be able to view your live feeds from anywhere. In this case, the security of the solution also depends on the security of the vendor cloud environment.

We are currently performing research on the security of home surveillance systems and will post updates on this soon, so stay tuned!

unnamed 2

Our team is researching common security errors in IoT devices as we speak

Decompiling py2exe Executables

We had to decompile an executable (.exe) generated with py2exe for Python 3.

py2exe takes a Python program and generates a Windows executable. This .exe file contains the Python bytecode of the program, a Python interpreter and all the necessary modules. The bytecode is stored as a resource inside the .exe file.

unpy2exe will extract the Python bytecode as a pyc file from the .exe file, which can then be decompiled with uncompyle6. Unfortunately, unpy2exe does not support files generated with py2exe for Python 3.

We release our program decompile-py2exe to handle py2exe Python 3 executables. It is simple to use:


decompile-py2exe takes an executable as argument, extracts the Python bytecode and decompiles it with uncompyle6, all in one step. The executable can also be passed via stdin or inside a (password protected) ZIP file. Be sure to use Python 3 to run decompile-py2exe.