disable certificate pinning in Android apps

Have you been in the situation where you start an app and want to intercept network traffic because you are curious what messages are exchanged between the client and the API? So you spin up mitmproxy, charlesproxy, burpsuit or whatever and you see.. nothing?? Hmm, that might be because certificate pinning implemented in the client. Luckily there are some methods to bypass that. One method, that sometimes works for Android apps is to patch the app.

get it

My preferred way to get an APK from an Android device (for reverse engineering purposes etc) is this helpful bash script. No root required, adb installed, phone in developer mode.

i=$(adb shell pm list packages | awk -F':' '{print $2}' | grep $appname);
adb pull "$(adb shell pm path $i | awk -F':' '{print $2}')";
mv base.apk $i.apk 2&> /dev/null;

decompile it

This steps generates smali code. Smali is an assembler for Dalvik Virtual Machine bytecode; The assembled dex (Dalvik executable) bytecode can be decompiled into smali code. That’s what we are doing now.

apktool d targetapp.apk

There is an interesting thread on smali on the xda-developer forum.

EDIT 1: For those who are interested, checkout the Dalvik bytecode reference: https://source.android.com/devices/tech/dalvik/dalvik-bytecode

patch it

Ok, now that we have the smali code, we can start browsing where the app checks the x.509 certificate. “checkClientTrusted” and “checkServerTrusted” are really good candidates. We patch those two functions to return before the actual check executes by adding “return-void” (line 453 and 467)


compile it

apktool b targetapp -o modfied_targetapp.apk

sign it

First, we generate a key and then we use jarsigner to sign the apk

keytool -genkey -v -keystore my-release-key.keystore -alias somealias -keyalg RSA -keysize 2048 -validity 10000

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore modified_targetapp.apk somealias

install it

adb install modified_targetapp.apk


If the app doesn’t crash ;-), you should be able to analyze the network traffic now. There are other methods available too. Take a look at FRIDA

Temperature controlled fridge for beer fermentation.

The smart fridge is here! No displays, no stupid useless functionality – but precise temperature control and monitoring.

A Fridge is a very simple device. It’s a refrigerating compressor that is turned on and off by a thermostat. Turing on the compressor leads to a drop in temperature, which is monitored by the thermostat. If the target temperature is reached, the thermostat cuts the 230V power and the compressor turns off.  Naturally, the temperature is rising again and the cycle start all over again.

This temperature range between compressor on and off is not precise enough for our needs. Therefore, we will replace the old thermostat with a microcontroller and a relay. As a nice benefit, this also allows us to monitor the temperature and change the target temperature from remote.

Part 1: Hacking the Fridge

If you want to learn more about how a fridge works, checkout https://www.brewpi.com/fridge-hacking-guide/. Most of this sections part is identical to the guide above and they did a really good job describing how fridges work.


  • 2x DS18B20 Temperature Sensor
  • 2x XLR 3-Pin Connector pair
  • Wemos D1 mini
  • USB Power Supply
  • Solid State Relay
  • Silicone for insulating and closing the old cable hole of the thermostat.
  • 1x 4K7 Ω Resistor

Replacing the old thermostat with a Relay

Time to rip out the old thermostat:

For easy cleaning, we want to make the temperature probes removable. XLR connectors are a cheap and reliable way to attach sensors if you only require 3 lines. An advantage of using DS18B20 sensors is, that they are using a 1-wire bus. That means we can add many sensors and still require only one long cable from the fridges connector panel to the controller board.

Part 2: Building the Controller Board.

The controller board is in charge of monitoring the 2 temperature probes,  reporting the temperature values to the cloud and of course, switching the compressor relay.

Our main controller, the Wemos D1 mini is based on an ESP8266 SoC, has multiple GPIO Pins exposed and WiFi onboard. This allows us to add more sensors later. For example, we could add an MHZ 19 CO2 Sensor into the fridge to check when the fermentation started without opening the door.
But for now, we only need 4 of those pins to control our smart fridge.

  1. 1 Pin for a status LED to check the current status and inform about problems.
  2. 1 Pin to add a button for simple control like resetting, thermostat on/off, enter configuration mode etc..
  3. 1 Pin for the temperature probes. We are using digital temperature sensors (DS18B20) and a 1-Wire protocol, so we can put multiple probes on one pin.
  4. Relay to control the compressor.
Finished controller board.
Solid State Relay (left) is switching the compressor.

Part 3: Software Setup

After flashing the Wemos with the standard “sonoff.bin” build of Tasmota, we are ready to create the rule set for the thermostat. But first, let’s check if the temperature probes are working. We can go the easy way and use the built-in web interface, the serial console or we can do it more complicated. Like this:

mosquitto_sub -h $MQTT_HOST -t '#' -u fridge -P $_MYMQTTPASSWD -F '%t -> %p'

Here, we subscribed to the MQTT broker directly. I like this way of debugging since you get to see what’s actually going on on the message bus.

After a while, we expect to see a message like this:

tuberlin/beer/tele/SENSOR ->
  "TempUnit" : "C",
  "Time" : "1970-01-01T00:34:16",
  "DS18B20-2" : {
    "Id" : "0517B02035FF",
    "Temperature" : 12.5
  "DS18B20-1" : {
    "Id" : "0517B01741FF",
    "Temperature" : 15.3

Now that everything is running, let’s configure the thermostat. For this, we need to set some basic configuration. We use the backlog command to queue and execute all settings together. This avoids restarts.

backlog SwitchMode1 3; Rule 1; Rule 4; TelePeriod 60; SetOption26 1; SetOption0 0; poweronstate 0; mem1 0; mem2 25; mem3 23; var1 0


  1. SwitchMode1 3: Configure the switch to send a toggle command when the switch is released
  2. Rule 1: Turn on rules
  3. Rule 4: turn off one-shot rule
  4. TelePeriod 60: MQTT telemetry interval sent every 60 seconds. This includes the temperature sensor data and will trigger the thermostat later.
  5. SetOption26 1: Use an index on the relay. If we receive an MQTT message, tasmoa will know which relay to switch and use POWER1 instead of POWER
  6.  SetOption0 0: Disable saving the power state, because…
  7. poweronstate 0: …after a restart, the relay should always be off.
  8. mem1 0; mem2 18; mem3 16: We can store up to 5 variables in the flash memory. mem1 is used to enable (1) or disable (0) the thermostat. This can be set by MQTT: Publish a 1 or a 0 to cmnd/sonoff/mem1. mem2 and mem3 are the upper and lower setpoints of the thermostat.
  9. var1 0: This is a variable, which allows us to check it the thermostat is usable. 1 means OK and 0 means not ready. Subscribe to cmnd/sonoff/var1 to check the status. A reason why the thermostat might not be ready is, that the temperature sensor can’t be found.

The groundwork is done. Let’s create a rule. You can configure up to 5 rules; we are using Rule1. It’s simple, you create one big line with all the conditions and actions:

Rule1 on system#boot do RuleTimer1 70 endon on Switch1#State do event toggling1=%mem1% endon on event#toggling1=0 do mem 1 endon on event#toggling1=1 do mem 0 endon on Rules#Timer=1 do backlog var1 0; RuleTimer1 70; power1 0 endon on tele-DS18B20-1#temperature do backlog var1 1; RuleTimer1 70; event ctrl_ready=1; event temp_demand=%value% endon on event#ctrl_ready>%mem1% do var1 0 endon on event#temp_demand>%mem2% do power1 %var1% endon on event#temp_demand<%mem3% do power1 0 endon


  • Rule1: Use Rule1
  • on system#boot do RuleTimer1 70 endon: When the systems starts, start a Timer that either evaluates the rules or only Rule1. If you can figure this out, let me know in the comments.
  • on Switch1#State do event toggling1=%mem1% endon: The moment, the state of Switch1 changes,

Part 4: Using it!

The setpoints can be controlled either by using the built in webserver or MQTT. The webserver has a virtual command prompt. To set the thermostat to an upper setpoint of 18 degrees Celsius and a lower setpoint of 16 degree, write


Finally, if not done yet, write


to activate the Thermostat. Alternatively, you can also press the button on the control board once.


AAAAAAAND here we come to a stop. The summer semester 2019 has ended and the rooms are locked down until winter semester. Everyone let’s go to the beach! This post will hopefully be continued soon. Stay tuned!

Transforming the Adafruit Bluetooth LE Friend to a Bluetooth LE Sniffer

I wanted to document the steps that are necessary to transform the Adafruit Bluetooth LE Friend (https://www.adafruit.com/product/2267) to an passive Bluetooth 4.0 Low Energy Sniffer device. This sniffer can be used to monitor the bluetooth communication between 2 LE devices. Which makes it a useful and cheap tool for security research and development.

The Bluetooth LE Friend comes in 2 versions – one with a preinstalled Bootloader, Softdevice and Application to control the on-board Nordic nRF51822 chipset using AT Commands. This Is already really useful for prototyping your own bluetooth applications. It supports OTA updates and Adafruit provides an Android application together with some demo projects.

As mentioned, Adafruit offers the same hardware in a Sniffer version, which comes with custom Sniffer firmware from Nordic preinstalled.

Flashing the Nordic Firmware on the BLE Friend

So, you own a BLE Friend, want to Sniff Bluetooth Traffic and don’t want to spend another 24$+shipping for the Sniffer version? Flash your BLE Friend!

You’ll need:

Step 1:  Wire up your programmer

I’m using the STLink V2 SWD programmer (the white box).

ST-Link V2
Wired up ST-Link adapter

You need to connect 4 lines to it.

  • Ground (Blue)
  • Target Voltage for sensing (Green)
  • SWCLK (Purple)
  • SWDIO (Grey)

Now, you need to connect those lines to the SWD connection pads on the bottom of the PCB of your LE Friend. Soldering them on is the fasted way in my opinion.

Adafruit Bluetooth LE Friend v3 with soldered on SWD pins

Note that we don not need to connect the reset pin – the  reset is done via the SWDIO line.

Step 2: Prepare

For simplicity, you’ll flash the LE Friend using Adalink. (https://github.com/adafruit/Adafruit_Adalink). Adalink is a python wrapper for OpenOCD that abstracts away the complexity of OpenOCD – which is good and bad a the same time.

on osx:

$ git clone https://github.com/adafruit/Adafruit_Adalink.git
$ cd Adafruit_Adalink
$ virtualenv --python $(which python2.7) venv
$ source venv/bin/activate
$ pip install click

There are 2 files that we need to collect:

  • The Booloader (https://raw.githubusercontent.com/adafruit/Adafruit_BluefruitLE_Firmware/03110f6819d2e8c0928ce1f3879df22dab562447/bootloader/bootloader_0002.hex)
  • The Sniffer Firmware (https://raw.githubusercontent.com/adafruit/Adafruit_BluefruitLE_Firmware/03110f6819d2e8c0928ce1f3879df22dab562447/sniffer/1.0.1/ble-sniffer_nRF51822_1.0.1_1111_Sniffer_No32kHz.hex)

Save those files – you’ll need them in the next step.

Step 3: Flash the firmware

Connect your Programmer with your computer and Plug the LE Friend into USB – This powers the nrf51 – the programmer alone does not provide any power to the LE Friend.

With adalink, we can simply run

$ adalink nrf51822 \
--programmer stlink \
--wipe \
--program-hex path/to/the/bootloader_0002.hex \
--program-hex path/to/the/ble-sniffer_nRF51822_1.0.1_1111_Sniffer_No32kHz.hex


As I said, I’m not a big fan of abstracting complicated tasks away from the Hacker: A look under the hood of Adalink reveals what it does. Based on your programmer, it loads the necessary target and board configuration (the -f flags) and executes a bunch of commands (the -c flags).  The call above results in 2 subprocess calls:

1: The wipe command in adalink for the stlink adapter:

$ openocd -f interface/stlink-v2.cfg \
-f target/nrf51.cfg \
-c  init \
-c "reset init" \
-c halt \
-c "nrf51 mass_erase" \
-c exit

This clears the flash memory. After the wipe is done, it loads the bootloader and the sniffer program

$ openocd \
-f interface/stlink-v2.cfg \
-f target/nrf51.cfg \
-c  init \
-c "reset init" \
-c halt \
-c "flash write_image /abs/path/to/bootloader_0002.hex 0 ihex" \
-c "flash write_image /abs/path/to/ble-sniffer_nRF51822_1.0.1_1111_Sniffer_No32kH.hex 0 ihex" \
-c "reset run" \
-c exit

If everything worked, the Bluefruit LE should boot with the sniffer firmware after the reset and you should see the blue led flickering – this indicates that you were successful. 


Pendant Lamp

I needed a lamp. And I wanted to build it myself. I’ve found a couple cool lamps on Thingiverse, but  the one I liked provided unprintable, broken models. So I started Thingiverse and built my own model.

For the wood, i’ve used 5mm square mahogany timber from my favourite art supply store Modulor.

I’ve published the .stl files on Thingiverse: https://www.thingiverse.com/thing:2757065

feel free to build your own – It’s CC BY-NC-SA 3.0

33C3 Retrospective

For those who missed it – the 33rd Chaos Communication Congress took place from 27.-30.12.2016 – and it was the last one in Hamburg. And I got a ticket. I haven’t seen a lot of talks, because I spent most of my time walking around the hack area and talking to people.  But here are some of the talk highlights that I can recommend:

1: Shut Up and Take My Money! – The Red Pill of N26 Security

…or how a broken authentication system could lead to corrupt transactions.


2: SpiegelMining – Reverse Engineering von Spiegel-Online

David Kriesel, who presented the lovely talk about the Xerox Scanner Bug at 31C3, demonstrates how he used big data to determine internal structures of the Spiegel publishing company. Must see!




The big red IFTTT Button

I’ve built an IoT button a while ago. I’ve also written a short log of the project on hackday.io

The ESP8266, which is used here, is  a small, WiFi-enabled chip which can be programmed. I hooked it up to send web request to IFTTT to trigger actions.

I started with a prototype on a ESP8266 NodeMCU development board. The button causes the ESP to send a web request to IFTTT, which is configured to send a push notification to my iPad in this example, but can trigger nearly any action that is supported by IFTTT.

after testing the firmware on the development board, I flashed it on the chip and put everything together.

IFTTT SmartButton from the inside.Tada! We do now have a battery powered push button for the internet of things.

The finished project


Project #3: Facemash Clone

I did this small project on a summer weekend in 2015. I just saw the movie “the Social Network” where Marc had  this idea of rating girls using an algorithm called ELO which is actually used for rating chess players based on their wins and losses against other players.

Personally, I think rating girls is disgusting. But rating Bananas and Apples is fine. An I’m more interested in the theory and the Algorithm itself. So I thought, hm, how hard could it be to implement a system like this – turns out: not that hard.

Short theory of the ELO algorithm:

The ELO Algorithm is a very simple, but effective rating algorithm. Assume that we are in the world of fantasy curling players. Naturally there are good players out there with a high reputation and a high chance of winning, and not-so-good players wich are less likely to win a game against the big fishes.  Let’s also assume you are a medium level player with a ELO number of 30. The best player has a ELO number of 70. Today is the big day and you will play a match against Player 2 with a rating number of 61. The rank list right now looks like this:

  1. Player 1: 70
  2. Player 2: 61
  3. Player 3: 32
  4. You:           30
  5. Player 5: 10
  6. Player 6:   2

According to the rules of fantasy curling, there has to be a winner and a looser – a remi is not allowed. At the end of the day, you either won or lost. The outcome of the match will affect both players ELO ratings. The more unlikely the win is, the more impact on the overall rating table this match will have. Let’s have a look at both possibilities.

Option 1 – You will loose

To calculate the new ElO ratings, you have to understand how the Algorithm works. You only need to calculate the expected point difference of one player, because of the simple fact that 

R_A and R_B are the current “pre-match” ELO ratings of Player A and Player B.

E_A is a value between 1 and 0. The 400 you see here is a historic value chosen by a guy named Arpad Elo and is since used for the chess rating system. Surprisingly, fantasy curling uses the same value ;-). But feel free to modify it.

So you lost against Player 2 with a rating of 61, which leads to the E_A value for you of 0.4555054269169921. (This is close to 0.5 wich would mean that the parameter 400 is not idea, but works for our example. I would suggest choosing a smaller value if you working with ELO ratings that close to each other.) According to the rule, your opponent has an E_B of 0.544494573083008.

How does that value generate the new ELO rating?

This is actually even simpler:

Your new ELO number will be your current rating (30) plus a factor k (assumed 10) multiplied by the difference of the S_A value (0 , because you lost, 1 otherwise, 0.5 for a draw, which does not exist here) and your just calculated E_B value:  25.444945730830078.

Player 2 now has a new ELO number of 65.55505426916991.

The k factor defines the impact of the match on the game. The higher the k is, the more impact it has. You can also fine-tune here.

Option 2 – You win:

for the unlikely case of a win against one of the leaders of the list, we will result in the following ELO numbers:

Player 2: 55.55505426916992

You : 34.55505426916992

The impact of the match on the table is defined by the constants k, the constant value 400 and the point difference of the opponents (which is variable). The whole systems is based on the simple assumption that games between a higher rated player and a low rated player are more important and have a greater impact on the result. This allows new players wich usually start with an average value to climb up the ladder very fast.


Similar to our example, Facemash also some kind of system with rounds where 2 opponents can either win or loose a match. Every element starts with a basic value of 2500 rating points. As a user, you now decide who wins the round and the ELO algorithm decides the new value.

Matchmaking is implemented to be random.

How my facemash clone looks like

It’s a very simple way to get elements in some kind of order. I was actually surprised how well it works.

The face mash clone is written in Python and uses Flask as underlaying framework.

Check out the project on my GitHub – it’s open source.


Project #2: Secret Santa

the Secret Santa Project was one of my favourites during the time at university. It’s a kiosk-like service for sending anonymous SMS messages with the goal to surprise your friends with a chocolate santa. The chocolate part makes it even better.

Background and motivation:

At university, I was a volunteer at our local UNICEF university group. In winter semester 2013, we had the task of doing a project that has something to do with Christmas – and in the group we came up with a little game: The original intention was to create a kiosk like interface, which students can use to send anonymous messages to a fellow student and inform them, that he or she just received a little present (we got some chocolate form our sponsor).

Kiosk mode as the student would see it on the stand


Let’s assume you want to suprise your close friend – she’s still stuck in a boring class about business administration.

  1. Go to the UNICEF stand in the hallway, say hello to the people in the unicef shirts and type in the kiosk system:
    • the name of the lucky recipient
    • the mobile-number or email address
    • a short message
  2. Check the checkbox if you want to add a personal message pinned to the Chocolate-Santa
  3. Be kind and maybe donate some coins you found in your pocket (because there will always be change for the bar visit the night before and who puts change back in the wallet anyway)
  4. Every message will be logged in a database, but only be marked as ‘sent’ when we know the message was sent out successfully.
  5. She will receive the message via SMS or email including a pickup code! This message is anonymous and will not contain the name field. Even if you entered your name in the sender-field.
  6. She will pick up her present at the UNICEF stand in the hallway. Therefore she tells the people in the blue UNICEF shirts her pickup ID (It’s the last 4 digits of the SMS)
  7. They will then type the ID in the searchfield and set the checkbox ‘delivered’. TADAAAA: you just sent an anonymous secret chocolate santa!

Every message sent out contains a 4 digit pickup code (the lenght is configurable btw).

The Management view of the system looks like this: not a s pretty, but practical:

This is the management view of the project

The search is implemented in JavaScript wich makes this fuzzy search field very fast and useful.

As a little gimmick, I recently added a small dashboard to keep the motivation of the group at the stand up and tracks their progress with 2 simple values:

The Metrics Dashboard

We now did this project a couple times and It was totally worth it – besides It was a great learning experience, we had a lot of fun planning the events.

If you like this project, give it  a star on GitHub 🙂


Project #1: Student Timetable

THI Timetable is the inofficial Timetable for Students of Technische Hochschule Ingolstadt. It brings your schedule to any device via iCal without having to install an App – you can use your native calendar application!

Background and motivation

Although the university provides a working system, it lacks important features like export or sync functionality. Additionally, the usability is poor: It is written with JSP, making it slow. Another Problem is the layout, which is not optimized for mobile devices. The most annoying aspect of this system is, having you to sign in each time you want to check your timetable.

This is the landing page for the TimeTable Project – you can subscribe with your university credentials.


First I had to analyze the original page. A great tool to look under the hood of a webapp is a browserextension like Firebug. The first step was to reverse engineer the login process to obtain a valid session-id. The prototype of the autenication method looked like this:

Next step is to feed it with username and password and it will send a request to the hiplan-app, parse the result using a regular expression and return the session-id. Now we are logged in, we can dig a little deeper. The hiplan-app uses Ajax to load background-data which turned out to be valid JSON. Fancy! Next we have to parse it. We just transformed the event-jsons to objects, so we can use them to export to any format we want – in this case iCalendar-Format. There is a nice python-library called icalendar which gets the job done. So – next step is to combine all these results and create a first version as a commandline tool. It is available on Github. Just have a look at the examples.

Since the goal is to make this tool accessible to the masses and considering the fact that nobody uses python command line tools, we need a better looking, user-friendly interface. There are several options:

  • stay on the commandline-way: small user-base
  • Native Apps: Need support for iOS and Android and Windows Phone (just kidding – windows phone was already doomed to fail back in 2014 when I started the project)
  • Webapp: Need only one Version for multiple devices / easy to maintain

So I decided for the Webapp. I hosted this service on Googles AppEngine, since it includes everyhing I need: a Python-Webframework called webapp2 that comes with a jinja2-like template system, a data storage which is needed to hold the user data and last but not least probably the most important part: A cron-service to schedule tasks. The system is build on a polling mechanism to scrape the calendar data from the hijacked api, therefore I needed the cron-service to schedule the update-tasks.

If you signed up successfully with your university credentials, your calendar gets parsed for the first time. You will see a success message and a copy-paste text field with a unique url that contains a long, random looking number. This url will point to your calendar in ICAL-Format – a Format which is readable by most native calendar software like google mail, Apple iCalendar, Android etc.. You simply need to pass this link to your calendar software and it will sync on a regular basis. If everything worked as expected, you should see something like this:

This is the way I want to check my daily schedule!

You’re welcome.

The service is online! check it out