Reverse engineering packets of IOT device

[Fire Doger]

Hello,
Recently I got some RGB lightbulbs, although their software sucks, I am working on a desktop app that will control led strips with my own controller, smoke machines (yes I have a smoke machine at home) etc...

Almost all RGB lights, mains switch, etc comes with a phone APP (a crappy one).
My question is which software do you recommend to setup on pc (windows would be great) to perform MTM attack between my android phone and IOT device.
My phone is rooted but it was a pain to sniff a packet and transfer it to pc.
Also some tips about setup, like "make a hotspot from PC, use wifi adapter which supports monitoring"

I want to build a "solid" setup that will be a straightforward to sniff any kind of device, use it in the future to test security of my own devices, see how they behave under attack, crack bought ones etc...

Thank you

[bateau020]

Most cheap RGB lamps work either Bluetooth, WiFi or Zigbee. You do not mention a hub, so it is probably Wifi or Bluetooth that you want.
But you didn't tell what traffic you want to intercept, so I'll just go broad.

My question is which software do you recommend to setup on pc (windows would be great) to perform MTM attack between my android phone and IOT device.

The main tool for this: Wireshark + androiddump (see https://www.wireshark.org/docs/man-pages/androiddump.html).
Using the app in the android emulator (see Android Studio --the android development environment--) may make things easier.

It will easily allow you to intercept IP traffic. And Bluetooth in some cases.
You are probably aware, but if the light works on IP, then this setup will only work for you if the android app talks directly to the light, and not through some cloud service.
And even if the traffic is directly, if it is encrypted, you may have a hard time getting through.
If it is bluetooth, you might need Ubertooth. Bluetooth can be hard to sniff. Also found this, but never tested it: https://github.com/mobilesec/android-ubertooth-btle-sniffing

[fordem]

There is a second aspect that needs to be considered - the "transport medium" - if it's bluetooth, the "sniffer" will need to be bluetooth equipped, if it's WiFi, the "sniffer" will need to be WiFi equipped - OR - the network will have to be configured to route the traffic to the PC so it can be seen.

I'm not familiar with the ins & outs of bluetooth, but for tcp/ip networking using WiFi & ethernet, the network adapters, or specifically their drivers need to support promiscuous mode, and as far as I know, few WiFi adapter manufacturers make promiscuous mode drivers available, it may be easier to find a promiscuous mode driver for an ethernet card, but, most ethernet based networks are now switched networks, and the network switch used will need to support port monitoring, if not, a MITM hack will be needed - easier said than done on a typical residential network where the internet gateway acts as firewall/router/switch and wireless access point.

After all of this has been setup - you'll be able to see the traffic using WireShark or similar, and you'll need to learn how to filter out what you're interested in, and then most likely encryption will be your next problem.

[Renate]

Why reverse engineer packets when you can just reverse engineer the software?
This software runs on Android? Just apktool it.
Oh, you're not very good at reading smali? Post the apk somewhere and I'll take a peek.

Also, if it's BLE it might be completely open GATT and you can just read the Characteristics and Descriptors.

[fordem]

Perhaps because the software on my phone doesn't actually communicate with or control the device?

With the devices I've used, the Android app sends a command to a server, and the server in turn sends a command to the device, and in some case, there may be multiple servers involved - I use Google home assistant, so my Android app talks to Google's servers, which then send a command to the device manufacturer's servers, which in turn send a command to the device.  I also have some GE lamps and on those the sequence is Android app to Google's servers, to the Google Home, and then blue tooth to the lamps.

If I'm going to go to the trouble of writing my own software, why would I run it through a third party's servers?

[Fire Doger]

I found that someone else had reverse engineer what I was looking for and totally forgot this thread.
As it looks like many of "smart" thingies are based on this https://www.tuya.com/ in case anyone is looking for it in the future.

Many of the devices use remote server but they fall back on lan if the cant access outside world which makes sense.
They should work even if internet is down.

Thank you about the BT info, I will use it in a future project.

For HTTPS I have used 'Charles' in the past, with emulator it may be possible to use 'Fiddler' but haven't tried it yet. Also there was a plugin in xposed or magisk to force certifications on apps like instagram which has higher level of security but I didn't have much luck.


With apktool I remember 5-6 years ago I managed to get readable source code for an app but now every variable is a, b, c
I don't intent to patch anything soon, sniffing looks like faster approach on my newbies eyes 

Thank you for your suggestions. Emulator sounds promising, I will post my setup when I set it up 

[fordem]

Many of the devices use remote server but they fall back on lan if the cant access outside world which makes sense.
They should work even if internet is down.

I don't know which smart devices you've used, but, every one I've used lose their "smarts" without an internet connection to the control server - yes, I can still turn them on/off by pushing a button, but I can't do it from the app on my phone, even when the phone & the device are both on the same LAN.

[radiolistener]

I think more easy way is to disassemble it. Most of all it contains standard wifi/bt module, so you can connect logic analyzer to it and capture raw packets