Trying to hack/debug "Argos" (UK) WiFi Christmas lights...
I bought these on sale, reduced from £30 to £7.50. They run on an ST micro "stm32f030f4p6", have a black unmarked 16 pin SMD WiFi module inside, and drive an H-bridge to provide very crude patterns on a dual-polarity (switch the polarity to change which chip [inverse parallel LED elements) per LED bulb - white or coloured - NOT RGB, just fixed LED colours when running on colour mode).
Long story short, this thing is controlled via an Android app, and broadcasts it's own SSID access point, which you connect to.
I am unsure how, but as soon as you connect your phone to that SSID, their app launches automatically!I've done "adb logcat" on Android, can't see what's happening. I've tried sniffing the connection with Wireshark... etc... and I've port scanned the IP of the hotspot AP (192.168.4.1 it is) and NO ports seem to be open, and I scanned them ALL! I've read that these sorts of devices communicate using the "AT" command set - I even tried telling "teraterm" to connect to the IP of the WiFi module in AP mode, to no avail.
Any ideas how I could find out what data is sent to this thing, by the phone? Oh, and I do not have a scope, nor can I borrow one - but I DO have a Bus Pirate.
Thanks (pics attached)
There's some background service in the app that checks if it's connected to the device and opens the app accordingly. Whether or not it opens a security hole or have other unwanted effects is anyone's guess.
I would suggest removing the shield on the module. There's a good chance there's an ESP8266 under it.
There's some background service in the app that checks if it's connected to the device and opens the app accordingly. Whether or not it opens a security hole or have other unwanted effects is anyone's guess.
I would suggest removing the shield on the module. There's a good chance there's an ESP8266 under it.
I've just run extensive Nmap scans, it says port closed or not responding, and then the "best guess" it gave was, yes, an ESP8266. I do not know where to go from here.
Most likely it's accepting UDP packets for control. Maybe try Wireshark?
Most likely it's accepting UDP packets for control. Maybe try Wireshark?
How do I setup Wireshark to ONLY see the source/destination IPs, and only look for UDP, please?
Thanks
https://www.wireshark.org/docs/wsug_html/I recommend spending a little time learning how to use it - it really is a very useful tool. I would suggest just capturing everything at first, then filter it during analysis. There's unlikely to be very much traffic for such a simple device and you would probably be able to figure it out even without any filtering.
https://www.wireshark.org/docs/wsug_html/
I recommend spending a little time learning how to use it - it really is a very useful tool. I would suggest just capturing everything at first, then filter it during analysis. There's unlikely to be very much traffic for such a simple device and you would probably be able to figure it out even without any filtering.
Yep, I know, I have been using it (crudely) for many years, it's invaluable. I just didn't know how to cap these packets...
thx
So I setup a "man in the middle" ARP poisoning config with my laptop & Ubuntu, using "ettercap-graphical" & Wireshark, set a UDP filter to port 8504, and sure enough, it is talking via very primitive packets/commands to the lights. What is odd, is when you first launch the app, a popup says "DEVKEYOK" and some long hex string; there are also hex strings in the UDP packets, but not the same one as shown on the app popup. The hotspot SSID created is always called "ClickLights", and the password is always "12345678".
Ongoing ...
thanks!
Having LOTS of fun debugging this thing. I have now found that, in Linux, you can send a UDP packet directly to an IP from bash, thus:
echo "<some_commands>" > /dev/udp/192.168.X.X/<PORT#>
In my case, this is: echo "setbuf1=<lotsofbytes>" > /dev/udp/192.168.4.1/8504
I managed to modify the hex strings being sent to the device, and have seen immediate changes to brightness, etc... (there seems to be 3 commands so far:
"setonoff=1" (turn on), "setonoff=0" (turn off), "setbuf1=<HEX_STRING>" and "setbuf2=<HEX_STRING>"
The light controller seems to remember the last sequence that was sent, as it resumes it upon cold boot from unplugged (flash, I assume)
If only there was some command I could send to it to query ALL of it's available commands/syntax, and have it return that via UDP...