Wireshark won’t show you anything if it’s encrypted, other then a communication taking place. There’s nothing stopping them from batching or otherwise obfuscating things through all kinds of means.
It entirely depends on how you set it up and where in the transport pipeline you’re intercepting pockets from.
how do you circumvent the HTTPS encryption?
By combining with other methods for intercepting HTTPS traffic, typically involving installing certificates or modifying system configurations like configuring your browser or operating system to log secret keys.
To break down the process of the cert method :
- Device Trust: Install a trusted Root CA certificate (issued by you) on the Android device using Root permissions. This certificate tricks apps into trusting the proxy. Without Root level install the apps may reject the certificate as User Installed.
- Device Routes Traffic : Configure the rooted Android device to route its traffic to the proxy on the separate system. This can be done through proxy settings.
- Proxy Decryption : Configure the proxy to use the corresponding private key to decrypt the HTTPS traffic coming from your device, this key is generated when you created/issued the Root CA.
- Traffic Inspection : With the traffic decrypted, you can use Wireshark configured to the proxy to inspect the traffic.
- Proxy Re-encrypts and Forwards: After inspection, the proxy re-encrypts the traffic using a legitimate certificate and forwards it to the real website.
They are, so, why bother?
Should the notification tell you when an app uses your mic when not inside the app?
Oh wait, it can’t if one bypasses the API.
Put your phone in a Faraday bag for an extended period of time, then check what kind of ads you get.
That depends on how conclusive you need your proof to be.
For example, you could run your phone software in an emulator and prove that your emulated microphone isn’t being accessed except when it should, because all attempts to access hardware are provided by your emulator. You would simply detect if this happens.
You could debug the kernel on device to detect request to access the microphone hardware and correlate this data with user activities to show that it’s quite unlikely you’re being monitored.
Perhaps you could insert physical probes into a real physical device to detect whether the application processor wakes up to service that data when you are speaking. If it doesn’t wake up, then you can reasonably argue that the data must not be getting stored or processed.
In general, irrefutable proof will be difficult to acquire. As far as we know, most phones don’t listen to the microphone and record audio while the screen is locked. They have a coprocessor that does this but it wouldn’t have the memory to record more than a second or two and is used mainly for hotword detection.
