[Delta 2] APIs stopped to work after device firmware update

[anton-ptashnik]

Describe the bug After a recent device firmware update to the version below, calls to circuit switching functions don't have any effect. start_state_stream still works but for a limited time - BLE connection becomes lost after 5sec approx since establishment.

Firmware version v1.0.1.97 Wifi: v1.0.5.22

Expected behavior All APIs work as documented

Logs N/A

[jsiedentop]

I have similar behavior:

• A call to turn_on_circuit/turn_off_circuit has no effect.
• start_state_stream returns REMAINING_TIME, CHARGE_TH_MIN, CHARGE_TH_MAX and CHARGE_SPEED

Unlike you, i probably don't have the latest firmware version. Bought my Delta 2 in late 2021 and never did an firmware upgrade and never connected the battery to the internet.It seems that the data format changes frequently with newer firmware version. Could you share how you recorded the data packets for each function? I would like to help fix this bug for my firmware version.

[anton-ptashnik]

Welcome here @jsiedentop , thanks for your willing to contribute!

Could you share how you recorded the data packets for each function?

Initially I tried to use Android built-in capturing feature located in Developer tools but I had no luck with that, I just could not find a capture file at the end of capturing session. Browsing the Web showed others have the same issue and I did not find a clear solution. I ended up using a dedicated hardware BLE sniffer. It works well allowing me to see live capture in Wireshark. Here is the one I use https://www.nordicsemi.com/Products/Development-hardware/nRF52840-Dongle

[Ne0-Hack3r]

@anton-ptashnik have you had any success determining what changed or how to regain control of Delta 2 after the firmware update?

Prior to update I was able to keep a BLE session open to D2 but now the session disconnects after a couple of seconds. I'm wondering if the device is looking for some kind of ACK or initial command from the app which it is not receiving when using external methods like your library. I'm also wondering if these were incidental changes or an attempt to lock out this sort of access and only allow communication with the native app.

I'm not aware of recent firmware updates "requiring" a subsequent app update so if they did implement some sort of "security" perhaps it is only on the device side (looking for certain expected I/O interactions with the native app our external scripts would have to "mimic" to get things working again). Unfortunately, I do not have BLE sniffing hardware. What I've got has been derived from a JADX decompile of the Android APK (which I'm only marginally capable of using) and BLE command sequences from another repo. I just discovered your Python library doing a search in hopes someone had discovered how to get re-connected post update.

[anton-ptashnik]

@Ne0-Hack3r not yet but I hope I'm close to that.

Meanwhile I started to think about a security concern. The fact no extra verification over BLE was required before, it meant any person in BLE range and with proper knowledge could connect and play with power station output switches lets say. It feels not good and I question myself how an owner can restrict access via BLE in such case

[Ne0-Hack3r]

@anton-ptashnik that is the irony here... the poor software and security has allowed us access but it also shows just how vulnerable these devices are (typical of IoT in so many cases). No hacking or tech expertise required, just get in range of an EF devices and "add" it to your app. I had another person load the native app and setup a new account with no devices in it and they were able to grab control of my EF devices at will.

What we really want is a secure API that exposes all the data/settings but requires proper authentication/validation. In the mean time, we keep finding ways to obtain the data without a proper API and want better security while not losing the access (and local control) we've gained.

Unfortunately, thus far, the best we can seem to hope for is a cloud based API allowing access to whatever data they choose to expose. Even that process has been extremely slow and not given much priority with no indication whatsoever that they ever intend of giving us a local API.

[anton-ptashnik]

@Ne0-Hack3r thanks for taking time , your explanation is very concise and clear. It seems I have some finding regarding this connection issue. Please message me via email and we'll discuss it: iavtomator@gmail.com

[Ne0-Hack3r]

I ended up using a dedicated hardware BLE sniffer. It works well allowing me to see live capture in Wireshark. Here is the one I use https://www.nordicsemi.com/Products/Development-hardware/nRF52840-Dongle

@anton-ptashnik

What pieces/steps are required to set up the BLE sniffer? Is it supported directly within WireShark? Does it require additional software on the PC to interface with WS? Can it be run on Windows or does it require a Linux build on a device with BLE (and if so, can it be setup on Raspberry Pi)?

[Ne0-Hack3r]

@anton-ptashnik

After some trial and error (and figuring out where to find btsnoop_hci.log) I was able to sniff the packet sent by the app after connection for both my D2 and D2M. Sending an exact copy of the captured packet, after connecting to the device, appears to allow the connection to continue. The packet data (payload) appears to be unique to each device (probably derived from the serial number and/or other unique identifiers).

[iBobik]

Hello, do you see any hope it will be possible to reverse engineer current local authentication (used by an app)?