Thread by @mame82

Put another day into bypassing anti debug/instrumentation measures of the "DJI Go 4" app. Reached my goal, but in contrast to published reports on the app results are very disappointing. Not much is sent outside by the app

To put it into perspective, here are the same visualizations for the Burger King app. Compared to DJI it has to be called a privacy nightmare

The BK app not only sends out your location (before the confirmation dialog in "King Finder" tab), it also combines re-settable and persistent identifiers (Android ID and Advertising ID). This allows bridging user initiated resets of the Advertising ID.

There could be several reasons, on why my results differ from earlier reports:
- the app was reworked meanwhile
- former reports used dated Android versions (newer SDK levels prevent reading privacy related device data in many cases)

Also the app requests and processes more data on the device and potentially could send it outbound (this is the case for most apps).

Here is another graph showing data accessed by the DJI app at runtime (not complete, as I have no category for Camera/Sensor/Microphone access):

Please note, that the DJI app does not even try to read the ANDROID_ID ... only the ADVERTISING_ID is requested.

In case you noticed:

One of the first screenshots for the DJI app includes web requests to a local IP. The IP corresponds to the proxy-host, which is requested by the app.

The plain HTTP request for a "getFileList" endpoint on port 8081 is a bit fishy (code source in trace)

... the actual proxy HTTP port is 8080 (known by the app, as it is requested at runtime, too)