You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/mobile-pentesting/ios-pentesting/burp-configuration-for-ios.md
+38-1Lines changed: 38 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,6 +20,40 @@ The **Burp Mobile Assistant** simplifies the installation process of the Burp Ce
20
20
21
21
The setup enables traffic analysis between the iOS device and the internet through Burp, requiring a Wi-Fi network that supports client-to-client traffic. If unavailable, a USB connection via usbmuxd can serve as an alternative. PortSwigger's tutorials provide in-depth instructions on [device configuration](https://support.portswigger.net/customer/portal/articles/1841108-configuring-an-ios-device-to-work-with-burp) and [certificate installation](https://support.portswigger.net/customer/portal/articles/1841109-installing-burp-s-ca-certificate-in-an-ios-device).
22
22
23
+
### Transparent Proxying via OpenVPN + `iptables` REDIRECT
24
+
25
+
If the target app ignores the configured HTTP proxy, an alternative is to place the iOS device behind a **researcher-controlled VPN gateway** and transparently redirect the traffic into Burp or `mitmproxy`.
26
+
27
+
This is **not a certificate pinning bypass by itself**. It only solves the network plumbing so the device traffic reaches your interception proxy without configuring a per-app or per-device proxy. If the app performs real certificate pinning, HTTPS decryption will still fail until pinning is bypassed separately.
28
+
29
+
Typical flow:
30
+
31
+
1. Run an **OpenVPN** server on a Linux host and connect the iOS device so its traffic arrives on `tun0`.
32
+
2. Bind Burp or `mitmproxy` to the VPN listener IP on port `8080`.
33
+
3. Enable **invisible proxying** in Burp because redirected clients are not proxy-aware and will talk as if they were connecting directly to the destination.
34
+
4. Redirect TCP `80` and `443` arriving on `tun0` to the local proxy listener.
35
+
5. Add a `POSTROUTING`**MASQUERADE** rule on the egress interface so proxied traffic can leave the gateway and replies return through the VPN.
36
+
6. Install and trust the interception proxy CA on the iOS device so apps that rely only on the system trust store accept the generated leaf certificates.
37
+
38
+
Example rules:
39
+
40
+
```bash
41
+
# Redirect VPN client traffic into the local interception proxy
- This is useful when you want **forced interception** without changing the target app or configuring an explicit proxy in iOS Wi-Fi settings.
52
+
- Redirecting `443` to Burp only works for apps that trust the installed CA or for apps where TLS validation / pinning has already been bypassed.
53
+
- The upstream repository example script takes an IP and appends `/24` in the `POSTROUTING` rule. In practice, use the **actual VPN client subnet** instead of assuming a fixed `/24`.
54
+
- If you use Burp, enable **Proxy --> Options --> Edit listener --> Request handling --> Support invisible proxying**.
55
+
-`mitmproxy` can be used in the same layout if it is bound to the VPN listener IP and transparent-mode requirements are satisfied.
56
+
23
57
### Advanced Configuration for Jailbroken Devices
24
58
25
59
For users with jailbroken devices, SSH over USB (via **iproxy**) offers a method to route traffic directly through Burp:
@@ -86,8 +120,11 @@ Steps to configure Burp as proxy:
86
120
87
121
- Click on _**Ok**_ and the in _**Apply**_
88
122
123
+
## References
89
124
90
-
{{#include ../../banners/hacktricks-training.md}}
125
+
- [SSL Pinning Bypass for iOS -- iptables](https://github.com/SahilH4ck4you/iOS-SSL-pinning-bypass-without-jalibreak)
0 commit comments