Recording a Packet Trace

Question

Created 2w

Replies 18

Boosts 0

Participants 2

I want to track down which part of an app contacts a given domain listed in its App Privacy Report.

Following the instructions given here I am able to capture a packet trace, but traffic to the domain in question is encrypted using QUIC.

Is there a way to insert e.g. mitmproxy into the capture process in order to get hold of the SSLKEYLOGFILE so that I can decrypt the traffic?

Answered by DTS Engineer in 879819022

I was able to get this working today:

On my Mac, running macOS 26.2, I downloaded the Mac version (mitmproxy-12.2.1-macos-arm64.tar.gz).
I unpacked it.
I moved it to the Applications folder.
And launched it (which opens a Terminal window).

It creates its CA (certificate authority) certificates in ~/.mitmproxy . I check that was all present:

% ls -l ~/.mitmproxy 
total 48
-rw-r--r--@ 1 quinn  staff  1172 13 Mar 12:05 mitmproxy-ca-cert.cer
-rw-r--r--@ 1 quinn  staff  1035 13 Mar 12:05 mitmproxy-ca-cert.p12
-rw-r--r--@ 1 quinn  staff  1172 13 Mar 12:05 mitmproxy-ca-cert.pem
-rw-------@ 1 quinn  staff  2384 13 Mar 12:05 mitmproxy-ca.p12
-rw-------@ 1 quinn  staff  2847 13 Mar 12:05 mitmproxy-ca.pem
-rw-r--r--@ 1 quinn  staff   770 13 Mar 12:05 mitmproxy-dhparam.pem

On a victim device running 26.2…

IMPORTANT This process involves changing system-wide trust settings. Given that, it’s not appropriate for a device you actually care about.
I launched Safari and open a private browsing tab (this helps with subsequent steps).
In Settings > Wi-Fi > My Network > Configure Proxy, I selected Manual, and entered my Mac’s IP address and port 8080.
Back in Safari, I went to http://mitm.it.
I tapped iOS > Get “mitmproxy-ca-cert.pem” and agreed to the download.
In Settings > General > VPN & Device Management > mitmproxy, I ran through the install sequence.
In Settings > About > Certificate Trust Settings, I enabled the “mitmproxy” CA.
Back in Safari, I created a new tab and entered https://mitmproxy.org.
In Terminal on my Mac, I saw those requests being proxied.

Note If you press z, you can clear the list of requests which makes it easier to see the new ones.
Back in Safari, I hit the refresh button and watched the requests continue to be proxied.

Neat-o!

I hit one really weird gotcha during this exercise. In step 13 I originally tested with https://example.com. That failed with a 502 Bad Gateway error. I suspect this is some special case within mitmproxy, because it only seems to affect that site.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

jzilske OP

1d

The weird part about this is your suspicion that the traffic is coming from within the web view, but it’s not obvious code running in the web view — so JavaScript, basically — could implement pinning.

No, it's not a WebView where I suspect the traffic comes from, but a (mostly) native app that includes a (small) number of 3rd party dependencies in both source and binary form.

I suspect the traffic comes from one of the binary dependencies, but I am having a hard time pinning down which one. I only have circumstantial evidence (framework name redacted):

$ strings Frameworks/<CFBundleName>.framework/<CFBundleName> | grep google.com
mail.google.com
www.google.com
*.google.com

0

Answer 2

jzilske OP

1d

With mitmproxy you should be able to get the source IP and port number of the request. And you can then use RVI to track the originating process. RVI puts this in packet metadata, which you can display by running tcpdump with the -k option. See the tcpdump man page for details.

How would I go about setting that up?

0

Answer 3

DTS Engineer OP

Apple

6h

it's not a WebView where I suspect the traffic comes from

Ah, OK, thanks for setting my straight.

How would I go about setting that up?

Which bit?

To get the source information from mitmproxy, view the request, switch to the Detail tab, and look at the Client Connection section.

Getting process information from the packet trace is a small extension of the RVI process described in Recording a Packet Trace:

Set up RVI per the Set Up iOS Packet Tracing section.
When you get to the tcpdump command, add the -k option to cause it to dump each packet’s metadata.

And tcpdump naturally logs the port numbers in each packet, so you can look for outgoing packets whose source port matches the port number you get from the proxy.

Having said that, this won’t help given your clarification that the connection is not coming from a web view but from within your own process.

I suspect that your third-party library is using BSD Sockets with its own TLS stack. If that’s the case then it’s going to be hard for you to get at the plaintext. A debugging HTTP proxy is the only general-purpose approach. Given that that isn’t working, your options are:

Dig into the library at the assembly level, either with the debugger or with a reverse engineering tool.
Talk to the library’s vendor to see if they have anything to offer here. For example, there might be an environment variable that causes the library to log its traffic, or TLS keys, or something along those lines.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0