In combination, this device schema provides a powerful setup to analyze traffic in a stationary, controlled setting.īut what if we don’t have the luxury of a testing lab? What if the app behavior changes based on your location, or interaction with the outside world? For instance, if you use an app to rent a car or unlock a door to a shared workplace, the real-time behavior of the app will be different from what you can replicate in a lab. HTTPS traffic can be intercepted in this way by overloading the app calls to Java’s TrustManager and providing our own, which accepts the proxy certificates that we provide. An additional control laptop might be added to the mix, which is connected to the test device via USB, to run adb commands on the device or overload Java methods using the dynamic instrumentation toolkit Frida. A typical setup might involve a test device where the app runs, connected to a wireless access point running mitmproxy, Burp Suite or something similarly tasked with recording traffic. Traditionally, this has been the job of dynamic analysis - running the app and capturing traffic as the user interacts with it. Without knowing exactly what traffic is being sent, you’d never know. An app asking for permission to your location may only use it to send it to your friends, or it may be tracking your every move. In order to audit the privacy and security practices of the apps we use on a daily basis, we need to be able to inspect the network traffic they are sending. Testing described in this post is done at the reader’s own risk and should only be conducted on devices and networks that you have permission to test on. Note: This post provides technical guidance only.
0 kommentar(er)
