tuya-cloudcutter / lightleak

Firmware version-agnostic PoC exploit for smart devices
47 stars 10 forks source link

Couldn't receive packets (was: The device does not respond to ping requests (which device is the app talking about?)) #23

Open whcrg opened 9 months ago

whcrg commented 9 months ago

Trying to dump flash. Have Sonoff SV that I flashed with the custom ap, the wifi network is visible.

The android app says device is nor responding... Is the custom ap not ok? Or the device I am trying to exploit is not answering?

Do the instructions miss a part where I somehow connect the victim device manually to the custom ap or would that come later? I cannot understand/find out when and how to do that. What am I doing wrong :P

Screenshot_20240118-222833

whcrg commented 9 months ago

There is maybe a bug in the android app, selecting unconfigured never seems to lead to actually connecting the tuya device... but when I accidentally clicked the second option (which to me sounds like it should be for already connected devices) it actually tries to access the device.

Screenshot_20240122-153535

Though fails the same on all profiles (and tyua devices just keeps blinking). Screenshot_20240122-153505

whcrg commented 9 months ago

Not in language I really know (Java?) but what I think I understand about the sequential stuff here https://github.com/tuya-cloudcutter/cloudcutter-android/blob/2cd28dd2d9a5e1157983980bbff1649c611f974f/app/src/main/java/io/github/cloudcutter/work/exploit/ActionGraph.kt#L141 in the android app it must my customAP device that is not playing along, despite LightleakIdle wifi showing up...

Reflashing not helping. Need to get some other board for trying again.

whcrg commented 9 months ago

Tested now with the Sonoff SV board (esp8266) and now with Atom S3 (esp32-S3) and both give identical results: device (the custom AP) not responding to ping requests. Also tested with two different android phones without change in results.

Looks like there is a bug somewhere. Either the custom AP or the android app but I have no idea which. I am willing to try to do more debugging if someone has ideas on what/how. Should there be serial output?

whcrg commented 9 months ago

Got serial working. This much I get:

Starting default AP - SSID: LightleakIdle / Password: cl0udcutt3r!@#
Station connected! Default AP mode, timeout disabled

and nothing else. so in loop line 26 on not happening for whatever reason...

whcrg commented 9 months ago

Connectin to the customAP wifi manually and trying to access stuff manually with phonw web browser leads to more results:

Starting default AP - SSID: LightleakIdle / Password: cl0udcutt3r!@#
Station connected! Default AP mode, timeout disabled
Client connected
Read timeout!
Client disconnected
Client connected
Read timeout!
Client disconnected
Client connected
Read timeout!

This leads me to think its the android app part that is not doing something right.

whcrg commented 9 months ago

The ip-adreses made me think they are familiar. I realized I have nordvpn meshnet on on both phones 🤦‍♂️ Disabled meshnet and now connecting to the customAP works! Stupid to overlook such earlier.

Now stuck at the already seen on other threads couldn't receive packets from the device. More trying later.

jeremysalwen commented 1 month ago

Could you explain a bit more what happened? I was following along right up till

There is maybe a bug in the android app, selecting unconfigured never seems to lead to actually connecting the tuya device... but when I accidentally clicked the second option (which to me sounds like it should be for already connected devices) it actually tries to access the device.

Which is exactly where I am. Except I don't have meshnet or a vpn or anything close to that, so I don't understand what you did to fix it. I don't understand how it is supposed to work since it never even seems to try connecting to the devices AP, only to the customAP if you select "unconfigured"...

jeremysalwen commented 1 month ago

For me, this issue was caused by using an older version of Android (version 9). It was indeed skipping steps where it sets up the device to connect to the CustomAP, etc. Using version 14 on a different phone did not have the same issue.