SAsasas·Mar 15, 2023
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 commerc
Read the rest
ial 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