[sasas]

TLDR; purchase an device that pairs with your phone, follow a hunch that it's doing a lot more then what it advertises it does.

A week ago I purchased a bluetooth device that takes some measurements. You require an Android or iOS application. The first thing the iOS app did was request permission for your location. Immediate fired up MITMproxy [1] running in transparent `--mode wireguard` and installed it's certificate in the iOS trust store. It was sending a whole bunch of data to China and HK. Since I don't have a jailbroken iPhone, it's off to Android.

For BLE scanning, Android does require permissions for location, but this application is using a Chinese branded tracking SDK and sending encrypted blobs (within already encrypted TLS). So it's time to start reversing and instrumenting the runtime.

Well - not so easy, they used a commercial packer that encrypts their compiled bytecode and decrypts and I think executes it within C++ library that might be an actual interpreter. I managed to pull the Dalvik bytecode out of memory using Frida[2] after the packer had decrypted the base application and converted it to java bytecode with dex2jar[3] then into decompiled java with jadx [4].

Since the developer relied on the packer to hide/obfuscate their software, it's quite easy to follow the deobsfucated code. The libraries that do the location tracking on the otherhand are obfuscated so now I'm at the stage of identifying where to hook before the encrypted blobs are sent to servers in China.

Here it would be nice to have a call flow graph generated based on the static decompiled java code - can anyone recommend anything?

I've sunk about 8 hours into this so far. The message here is that to understand what some applications on your phone does you need to really invest time and effort. The developers increase the cost to the consumer to know what their application is doing by obfuscation, encryption and packing. It's asymmetric. Also note: the play store and apple store state the app does not send data, which is demonstrably false.

I can also see that the tracking SDK has what looks like functionality to dynamically invoke code - which would break the terms and conditions of the app stores.

At some point I will reimplement it's primary BLE functionality and release it as opensource to the public and perhaps write a blog post.

[1] https://mitmproxy.org/posts/wireguard-mode/

[2] https://frida.re/docs/android/

[3] https://github.com/pxb1988/dex2jar

[4] https://github.com/skylot/jadx

[gabanutrition]

This topic is intriguing. Could you please provide more information about the device and application? I'd appreciate the opportunity to examine them more thoroughly.

[sasas]

Sure! feel free to reach out direct; contact details in my HN profile.

[sizzle]

Wow amazing write up, start a consultancy and start charging to audit the privacy of apps, imagine getting paid to do this on every App Store update of Tik Tok and the like for agencies or companies auditing their apps, etc.

You are really talented, now get paid for it or open source some automated tools for getting the trail to see behind the curtain for these apps that force you to enable permissions to use them.

[sasas]

Hey thanks! There are quite a few static based automated tools that can help as a first run such as https://sisik.eu/apk-tool

Perhaps there are opportunities for developing easy to use dynamic analysis tools for the general population.