Thread by @haxrob

A friend asked me to find out why his connected lightbulb app was asking for his location, so I ducked out to Australia’s favourite hardware store, Bunnings, and grabbed one to check out.

The Android grid connect app has 500k+ downloads.

Let’s take a quick look! 🧵
(1/n)

The app has a feature where it can auto discover your BLE devices. Is locations permission needed here? It depends. From Android API SDK v31 things have improved where fine location is not needed for BLE scanning.

The app is forcing this even though we are on v31.

(2/n)

Let's allow it "for science". The device is paired. We also have the option to enter our Wifi credentials. I assume this is so the light can be remotely controlled over the Internet. It's automatable too. One condition is "when location changes". Let's not touch these.

(3/n)

Time to fire up trusty #mitmproxy to look at the network traffic. Traffic is going to . Familiar domain. I came across Tuya used in a Mirabella Genio Smart light I got at a supermarket.

Tuya is an IoT OEM found everywhere.

postData is encrypted.

(4/n) https://t.co/OuNOulw8nltuyaeu.com

Let's pull the .apk from the device and take a look at the manifest. We could of course grab it from APK Pure.


Yikes! recording audio, access to camera, location..
Assume there is a legitimate functional use for all of this. Trust but verify?

(5/n) https://t.co/jDPPrTBbuAm.apkpure.com/grid-connect/c…

Our focus here is what is happening with location permission other then BLE scanning. We need quick wins as this app isn't trivial and is obfuscated. Crypto routines related to the postData appear to implemented in native arm64 within a shared library.
(6 / n)

Dynamic instrumentation with #frida will really speed things up. JADX can emit a boiler plate hooking .js snippet to use in Frida. We just need to modify to to convert the plaintext byte array passed into encryptPostData from signed integers into a readable string.

(7/n)

Looks like it worked! We have visibility on any data that is passed as a parameter to encryptPostData().

No need to reverse the encryption function to figure out how to decrypt the data - we have it before it's encrypted and sent over the wire.

MASSIVE TIME SAVER. 🙏

(8/n)

So far no location data. Are we looking in the right place?

Remember we are after "quick wins". The minimum time investment possible to answer my friend's question "what's it doing with my location" ?

The developer's logging class seems perfect to hook into -… https://t.co/RocbDYlOW4twitter.com/i/web/status/1…

You beauty - it worked. We now have visibility into what is encrypted in the postData form field.

We can account for the data in HTTP post towards the Tuya cloud API endpoint.

But what are we exactly looking for?

(10/n)

Probably these parameters? "lat" and "lon".

hmm.. KEY_IMEI and KEY_IMSI are probably worth looking into too at some point. 🧐🧐

But alas, we must stay on track. KEY_LAT and KEY_LON it is for now.

Live tweeting this enquiry keeping me on track🤣

(11/n)

ok, we got a match. GPS co-ordinates of where I am - although this was data *received* from the cloud server. How did my location get there in the first place? Perhaps when the application was first installed? Back to square one - but this time we know what to log.

(12/n)

Application reinstalled.

Boom! we see the exact packet where our GPS co-ordinates are sent to Tuya's remote server over the Internet.

We can identify this in packets that have the "a" field "b.m.sys.location.get".

(13/n)

So what do we make of all this?
The developer discloses on the app store that the precise location data collection is optional.
Is this misleading?

What we have discovered in this Twitter thread is that if you try to pair one of their devices via Bluetooth scanning, the app… https://t.co/2IPhlaum0Dtwitter.com/i/web/status/1…

Going to wrap up the live tweeting on this one.

If you found this interesting/helpful, feel free to like/retweet. We need as many people as we can to be encouraged to discover and call out companies that harvest location data from their devices. 15/15

https://twitter.com/haxrob/status/1676416949499338752

It doesn't feel complete with out a map.

Coverage map using advertised BLE device name "TY" and the mac address prefix A8:80:5 (Tuya Smart Inc.) - beaconed out from my lightbulb.

This is why Google (rightfully so) considers Bluetooth scanning "location data"

(..16/15)