Alternative title: Or how I made ‘making a phone call with my mobile’ impressive
Alternative title: Ziggo (smol) pap
So, I started reverse engineering Ziggo’s mobile VOIP app. The app allows you to call through your home phone, but while being somewhere else. I like this, and it could be useful for stuff, so I decided to reverse engineer it.
Step 1: Reverse engineering
I started by downloading the app and pulling the .apk off my phone. This was easy. I then tried to run it in a VM. This was less easy. The app is programmed to only work on wifi (why?) and Android’s stock emulator doesn’t do wifi emulation. So I had to download Visual Studio’s Android emulator, which is even a bit nicer. :) After downloading the virtual machine, I just dropped the .apk on top, and it worked! I then got bored reverse engineering it and started poking at the app using Wireshark. VOIP communications are encrypted (luckily), so I couldn’t read them. So, I used dex2jar and jd-gui to get an insight in what the app was doing. Quickly, I noticed the app using pjsip, which is an SIP library. Yay for standards!
Next step: Trying to connect without the app.
Step 2: The connect-a-thon
So I filled the credentials into a SIP client, and pressed connect. Nothing. I tried some settings, and still nothing. It just didn’t like some of the settings. Let’s try to sniff the network traffic instead. I made a
fake certificate, let the VM trust it, and set a few DNS entries to fake the server. It connected, but didn’t like the certificate, which is good. Next step: how to trust it? I shut down the VM and manually mounted the
.vhd, and played a bit with ext2fsd to mount it. I went into the
shared_prefs folder for the app, and found a few .xml files. One of which contained a ton of settings for the pjsip library, including
tls_verify_server. Which is now
false. That was easy. Restarted the VM (after unmounting everything) and it worked! (Afterwards I realised that the VS
android VM comes prerooted, so I could’ve just pulled the file, but I had already done this…) I could sniff the connection! (But the app didn’t like it when I tried to make a call, still). So, why did that work, but not manually connecting to the server? the
User-Agent header contains a special token. I manually set the user agent in my SIP client, and… it connected! :D :D :D
Step 3: Some kind of dial-a-thon, I guess
Okay, so I enter my mobile number in the dial pad, and press call, and….. [phone rings] Success! I quickly set the client to send the loopback stream, and turn on Never gonna give you up, and test it… It works, although it’s a bit low quality. Yay! So, I call the home phone, and… nothing happens. Disappointing. Turns out, after Ziggo and UPC merged (into Ziggo), the whole infrastructure is double, once for Ziggo, once for UPC, and we are still in the Ziggo area, so no being called yet (the UPC app does do that, disappointingly :<)
Well, since you read this far, or scrolled down to the end for TL;DR, here’s what kind of settings you need (if you would normally use Ziggo Bapp, if you are in the UPC area, I don’t know)
These settings are tested with MicroSIP, and if you can find the same settings in other clients, it will probably work.
- User: email address (with
@mvoip.ziggo.nl(so if you use
- Password: the password from Bapp settings, in lower case, no spaces.
- Media encryption: mandatory
- Transport: TLS
Important: In the MicroSIP config (
userAgent="Ziggo Converged App #wa5hBu5THd#" to trick the server into letting you connect.