how to set up Burp Suite mobile proxy on a cloud phone
how to set up Burp Suite mobile proxy on a cloud phone
if you do mobile security testing, Burp Suite is probably already in your toolchain. it is the de facto standard for HTTPS inspection in pentests, vulnerability scanning, and OWASP-driven mobile security work. this guide walks the full Burp setup against a cloudf.one Singapore cloud phone: install Burp, configure the proxy listener for remote devices, install the Burp CA, configure the cloud phone’s proxy, decrypt HTTPS, run the active scanner, and tear down cleanly.
cloud phones are an attractive Burp target because they are real arm64 Singapore hardware. that matters for security testing because real-device behaviors (Play Integrity, biometric prompts, native pinning, FCM tokens) only fire correctly on real hardware. emulators give false negatives.
why Burp over Charles or mitmproxy for security work
three reasons security teams prefer Burp. first, the active scanner. Burp’s scanner runs payloads against captured requests to find SQLi, XSS, IDOR, and other server-side bugs. Charles and mitmproxy do not have a scanner. second, the extension ecosystem. Burp’s BApp Store has hundreds of extensions for mobile-specific work (pin-bypass plugins, SAML auditing, JWT analyzers). third, professional reporting. Burp generates findings reports that fit straight into pentest deliverables.
if your work is purely traffic capture for QA, mitmproxy is probably enough; see our mitmproxy guide. if your work is structured security testing aligned with OWASP MAS, Burp is the right tool.
prerequisites
on your laptop: Burp Suite (Community Edition is free; Professional is paid), Java 17 or newer, network reachability to the cloud phone over ADB-over-network.
# install Burp Community on macOS
brew install --cask burp-suite
# verify by launching
burpsuite
for context on cloud phone basics, see cloud phone vs physical Android device and how to set up ADB on cloudf.one.
step 1: configure Burp’s proxy listener for remote devices
Burp’s default listener is 127.0.0.1:8080, which only accepts connections from your laptop. for a cloud phone, you need a listener reachable from outside.
in Burp, go to the Proxy tab, then Proxy settings, then Proxy listeners. edit the existing listener: change Bind to address from “Loopback only” to “All interfaces” or to a specific local network IP. apply.
note the port (default 8080). you’ll point the cloud phone here.
step 2: bridge the network gap
cloud phones run in Singapore. your laptop runs elsewhere. options:
option A: ngrok TCP tunnel.
ngrok tcp 8080
ngrok prints a public hostname like tcp://2.tcp.ngrok.io:14837. that’s the proxy host for the cloud phone.
option B: cloudf.one reverse tunnel.
cloudfone tunnel reverse --local 8080 --device $DEVICE_ID
both expose port 8080 to the cloud phone.
step 3: configure the cloud phone’s proxy
via ADB:
adb -s adb-sg.cloudf.one:5555 shell settings put global http_proxy proxy.host.example:14837
# bounce WiFi
adb -s adb-sg.cloudf.one:5555 shell svc wifi disable
adb -s adb-sg.cloudf.one:5555 shell svc wifi enable
verify:
adb -s adb-sg.cloudf.one:5555 shell settings get global http_proxy
step 4: install Burp’s CA on the cloud phone
in Burp, go to Proxy, then Proxy settings, then Import / export CA certificate. export Certificate in DER format. save as cacert.der.
convert to PEM:
openssl x509 -inform DER -in cacert.der -out burp.pem
push to the cloud phone:
adb -s adb-sg.cloudf.one:5555 push burp.pem /sdcard/Download/
install via Settings, Security and privacy, More security and privacy, Encryption and credentials, Install a certificate, CA certificate. browse to /sdcard/Download/, select burp.pem, give it a name like “burp.”
on Android 7.0+, user-installed CAs only work for apps that opt in via Network Security Config. for apps you own, modify the debug network-security config. for apps that pin, see step 8.
step 5: confirm HTTPS interception works
on the cloud phone, open Chrome and visit https://example.com. in Burp’s Proxy, HTTP history tab, you’ll see the request flow. click on it; you can see headers, body, and the response.
for the request to be decrypted, Burp needs to be in “intercept” mode (Proxy, Intercept tab, Intercept on / off). intercept off means Burp passes traffic through transparently while logging it; intercept on lets you modify each request before it forwards.
step 6: send a request to the Repeater
right-click any captured request, then Send to Repeater. Burp’s Repeater lets you modify and resend the request manually. great for testing input validation, authorization bugs, and parameter tampering on mobile APIs.
POST /api/v1/profile/update HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJ...
Content-Type: application/json
{"display_name":"test","email":"test@example.com"}
modify the body, hit Send, watch the response. iterate until you find or rule out a vulnerability.
step 7: run the active scanner (Pro only)
in Burp Pro, right-click a request, then Scan. the active scanner runs payloads to find OWASP Top-10-style server-side bugs. results appear in the Dashboard.
scope your scan to your own domains: in Target, then Scope, add your test domain. don’t scan domains you don’t own; that’s an attack, not a test.
step 8: handle certificate-pinned apps
cert-pinned apps refuse the Burp CA. options:
option A: Network Security Config opt-in. modify res/xml/network_security_config.xml in your debug build:
<network-security-config>
<debug-overrides>
<trust-anchors>
<certificates src="user"/>
</trust-anchors>
</debug-overrides>
</network-security-config>
debug builds now trust user-installed CAs. release builds remain pinned.
option B: Frida pin-bypass. for legitimate research, use a Frida script to patch pinning at runtime. our Frida hooking post covers the pattern.
option C: BApp Store extensions. several Burp extensions ship pin-bypass routines for OkHttp, Volley, and Retrofit. in Burp, go to Extensions, then BApp Store, search “ssl pinning.”
step 9: tear down
# remove proxy from cloud phone
adb -s adb-sg.cloudf.one:5555 shell settings put global http_proxy :0
adb -s adb-sg.cloudf.one:5555 shell svc wifi disable
adb -s adb-sg.cloudf.one:5555 shell svc wifi enable
remove the Burp CA via Settings, Security, User credentials.
stop ngrok or the cloudf.one reverse tunnel.
OWASP MAS alignment
Burp on cloud phones is the workhorse tool for the network-security half of the OWASP Mobile Application Security Testing Guide. MASVS-NETWORK requirements (correct TLS, cert pinning, no plaintext on wire) are tested by capturing real traffic from the app and validating with Burp. our OWASP MAS testing post covers the broader workflow.
try Burp on a real Singapore cloud phone
register for a free trial for a one-hour cloud phone token. install Burp Community, set up the proxy and CA, capture HTTPS from your debug app. for ongoing pentest work, scale to a paid plan with persistent rooted devices.
frequently asked questions
is Burp Community enough for mobile testing?
for capture and manual analysis, yes. for the active scanner and many BApp extensions, you need Burp Pro. most pro mobile testers buy Pro.
does Burp work over a slow network?
ADB-over-network adds 150 to 250 ms from outside Singapore. Burp’s Repeater and Intruder are interactive but tolerant. for heavy active scanning, run from an Asia-Pacific runner.
can I use Burp with mitmproxy chained?
yes, but rare. usually you pick one. Burp for security testing, mitmproxy for scriptable capture in CI.
what about apps using HSTS?
HSTS is enforced at the browser level. the WebView in Android apps respects HSTS. since Burp’s CA is trusted by the device, the HSTS check passes (the cert chain is valid from the client’s perspective). HSTS does not block proxying when the CA is installed.
is using Burp on cloud phones legal?
testing your own apps and authorized targets is legal. unauthorized scanning is not. always confirm scope before any active scanning. cloudf.one’s terms forbid unauthorized testing on the platform.