I often want to examine the web traffic generated by browsers, and other apps.
Sometimes I can use the tools built into browsers, other times proxies, but when I want to take a deeper look and particularly if I’m looking at how a browser is using HTTP/2, I rely on packet captures.
One challenge with analysing HTTP/2 traffic is that it’s encrypted and while Chrome and Firefox support logging TLS keys and tools like Wireshark can then decrypt the traffic.
Safari and iOS doesn’t have this feature natively, and proxies like Charles only communicate to the browser via HTTP/1.x so I needed to find another solution.
In this post I walk through how I capture iOS apptraffic using
tcpdump, and how I use a Frida script to extract the TLS keys during the capture so that I can decrypt the traffic too.
Capturing iOS network traffic
Apple support capturing iOS device network traffic via a Remote Virtual Interface (RVI). This mirrors the network traffic from the device to a virtual interface in MacOS and from there the traffic can be captured using tools like tcpdump and Wireshark.
You can find more details in this article from Apple but the basic process is:
- If they’re not already installed, install xcode’s command line tools:
If you’re unsure whether you have the command line tools installed, run the above command anyway and it will display an error message if they are already installed.
- Attach an iOS device, and grab it’s UDID
I can’t remember where I got the command line below from but it extracts the device’s UDID from the
1 2 3
- Start the Remote Virtual Interface
1 2 3
- Capture traffic using tcpdump (or Wireshark)
-P option is an Apple extension that captures the traffic in pcap-ng format, and includes metadata such as process name, pid etc. against each packet.
Unfortunately Wireshark can’t display or filter by this data yet but I’m hoping someone might implement support for it soon. Apple’s tcpdump can display it, see the
-k option in man pages for more details.
- Generate some network traffic
Open an app on the device e.g. Safari, and generate some network traffic to a site that uses HTTPS e.g. https://www.bbc.co.uk/news
When your done hit
Ctrl-C in the terminal to stop tcpdump capturing.
- Open the packet dump in Wireshark
If you don’t already have Wireshark installed, download and install it from https://www.wireshark.org, and then open the pcap:
You should see a screen something like this:
I’ve filtered the capture to just display the traffic to and from www.bbc.co.uk. But as the traffic is encrypted using TLS 1.2 we can’t see the contents of the packets.
To decrypt the packets we need the matching TLS keys, Chrome and Firefox will provide these when the SSLKEYLOGFILE environment variable is set but unfortunately there seems to be no equivalent for Safari.
Fortunately thanks to tools like Frida, we have the ability to implement it ourselves.
Extracting TLS Keys and Decrypting iOS Traffic
I’m testing with a Jailbroken iPhone 5S running iOS12.4.3, with Frida installed from Cydia. It’s possible to use a non-jailbroken device if you can include Frida’s libraries in the app - either via debugging an app you own, or repackaging someone else’s app and injecting the dylib.
As I want to decrypt Safari’s traffic I’m sticking with the Jailbroken phone.
- Follow the Frida installation instructions for MacOS and iOS
MacOS CLI - https://frida.re/docs/installation/
iOS Device - https://frida.re/docs/ios
- Check Frida is installed and working by listing the currently running apps
-U option instructs Frida to attach to a USB device
- In one terminal window start the frida script:
The script for extracting the keys is hosted on Frida Code Share, I’ll walk through the process of how it works later in the post.
-o option writes the output of the script to a file, but it’s also mirrored to the console too so you can see the output as it happens too.
Safari’s networking happens in a separate process so the command above connects to that process rather than Safari itself.
Also the first time you use a script from codeshare you’ll be prompted whether to trust it.
If you want to inspect a different app
frida-ps -Uai will list many of the apps available, and you can also select the app via Process ID too.
- In a second window start the TCP capture
- Open the app you want to decrypt the traffic from and generate some traffic
In this example I’m using Safari and https://www.bbc.co.uk/news
- Terminate the tcpdump, and frida commands, and then use
exitto quit the Frida REPL
You should have two files, in this example they will be
- Open the packet capture and provide the keylog as an option
You can also launch Wireshark, open the packet capture, and then specify the keylog in
Preferences > Protocols > TLS > (Pre)-Master-Secret log filename
You should see a screen something like this:
I’ve filtered the capture to just display HTTP and HTTPS traffic and highlighted the start of one of the decrypted HTTP/2 connections.
How the Frida Script Works
I first came across Frida a few years when someone shared Tom Curran and Marat Nigmatullin’s paper on TLS Session Key Extraction from Memory on iOS Devices.
Tom and Marat used Frida to hook the CoreTLS function (
tls_handshake_internal_prf) that generated key material and dump the relevant TLS keys.
Although I got a modified version of their code working well enough to inspect some apps, and talk about it at JSOxford I never quite managed to address extracting keys for resumed TLS sessions and some other cases where it didn’t work.
In iOS11, Apple migrated from OpenSSL to Google’s BoringSSL so Tom and Marat’s code stopped working but the ideas it introduced remained valid and compared to OpenSSL the BoringSSL code easier to understand.
And as Chrome supports TLS key logging so BoringSSL already contains code to log TLS keys.
Searching the code for the labels that are defined in key log format finds examples like this one in handshake.cc where the CLIENT_RANDOM values are being logged:
1 2 3 4 5
ssl_log_secret is defined in ssl_lib.c – it checks whether a callback function for logging is defined and if it is, builds the log line and calls the callback with log line.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
To enable TLS key logging, it appears we just need to be able to set a logging callback function.
The logging callback is set via
SSL_CTX_set_keylog_callback but unfortunately this doesn’t seem to be included in Apple’s version of BoringSSL – to check, I extracted libboringssl.dylib from the shared dylib cache and disassembled it using Hopper but couldn’t find the function.
1 2 3 4
Reading the source code and tracing the execution of
com.apple.WebKit.Networking using frida-trace, I came across
SSL_CTX_set_info_callback appears to be called once per task and gets passed the address of the struct containing the pointer to logging callback function:
1 2 3 4
If we create our own logging function, and wrap it in a native callback
1 2 3 4 5 6 7
We can then intercept calls to ‘SSL_CTX_set_info_callback` and write the address of the native callback created above into the relevant entry in the SSL struct:
1 2 3 4 5 6 7 8 9 10 11 12
CALLBACK_OFFSET was determined by disassembling libboringssl.dylib, and like all magic numbers is fragile as it may change if the struct changes in future versions, or on different CPU architectures.
The completed code (TBH it’s more comments than code) is available from https://codeshare.frida.re/@andydavies/ios-tls-keylogger/ under an MIT License so feel free to build on it, incorporate it into other utilities etc.