Finish API documentation about python-eufy-security

[gingermike]

I was able to decompile. On the hunt.

EDIT: Well, after several hours, I'm reminded how difficult Java is. 😆I don't see any particular API that gets called when the mode (Away/Home/etc.) buttons are tapped. Interestingly enough, I also see no reference to /api/v1/web/equipment/start_stream or /api/v1/web/equipment/stop_stream; this, combined with the fact that the mobile app's API calls start with https://security-app.eufylife.com/v1 and the web app's start with ``https://mysecurity.eufylife.com/api/v1`, makes me think we're dealing with different things.

Also worth noting that the web app doesn't appear to support modes currently.

I had a quick look at the decompiled APK. I think that the mode changes are handled by the com.oceanwing.battery.cam.guard.logic.ModeManager class.

The setMode method calls through to the ZMediaCom class, which appears to use some classes labelled as using P2P connectivity. This connection is then handled through a native interface - so no idea how it's initiated or where it's going to! I need to fiddle with the REST API - I think some clues might exist there...?

Also, in regards to MQTT it looks like Anker has hardcoded the passwords to their broker 🤦‍♂. Looks like there are thousands of topics, one per mobile device. Messages being sent over the wire appear to be connect/disconnect notifications with IP addresses embedded.

[keshavdv]

I assumed the identifiers aren't entirely random and might be assigned in chunks to manufacturers, but regardless, you're right in that the space is so large that at that point, somebody has better odds trying to guess your password instead.

Finally got something together in a PR in #44 and would love some additional testers with more than one device and ideally somebody with an actual Homebase (doorbells and floodlights are kind of special since they have a "hub" built in)!

[FuzzyMistborn]

The APK is available online on APK Mirror. https://www.apkmirror.com/apk/anker/eufy-security/

[FuzzyMistborn]

Still digging but looks like @joepadmiraal is on to something. Seeing traffic going to "security-mqtt.eufylife.com:8789". Trying to get details.

Drony doesn't give out more details and I can't find a better working option that I can set up. Hit my limit for the evening, hope someone else can take the url at do some more sniffing.

[nonsleepr]

Awesome. I actually also managed to pull video steam from the camera. I decoded the frame, next step would be to integrate it with HASS. Speaking of encryption, if you leave encryptkey empty, you'll get unencrypted steam. And that bothers me when more.

I wasn't able to enable telnet either, I patched Android app to enable telnet instead of doing other actions with no success.

Haven't looked at Firebase yet.

I'm hesitant to release any code right now because of the level of security implemented by the doorbell.

[basriram]

@keshavdv have you figured out where's the list of IPs for the initial discovery comes from? I bet it's hardcoded somewhere.

It looks like the app_conn string is encoded/encrypted with the server information of the initial discovery servers but I have not been able to figure out what type of encryption the native library is using though.

[nonsleepr]

That's what I was waiting for :) (I mean, the changes).

The OpenHAB binding is 3 months old.

I will attempt to find some time this week to take a look at their changes.

[asiridol]

@Sillium Turned out the communication is done through a native library (ZMediaJNI). I have managed to create a c# wrapper for it and switch between different alarm modes on a sample android app. To create a web hook I think you'll have to host it on a raspberry pi or a similar hardware because the native library is built for armeabi-v7a (which supports armeabi, Thumb-2 and VFPv3-D16 instruction set) and arm64-v8a (AArch64 instruction set) ABIs. However I did managed to get hold of the iOS fat binary too. Not sure which ABI it was built for.

[asiridol]

@Sillium Sure but this is not in a state to share though. I'll have to finish the wrapper first. Will keep you posted.

[keshavdv]

While I was personally using my hacked together Node.js script that was able to re-create a live RTSP stream directly from the camera and toggle basic things like the floodlight, I was apprehensive about releasing anything because essentially every Eufy cam was vulnerable to being viewed and controlled by an external attacker without authentication by a super trivial enumeration attack. Eufy seems to have finally added a layer of protection on the initial discovery mechanism, so I'm hoping if I can work through that piece again, I can finally share some of what I have working.

[keshavdv]

Correct, it's still possible to gain access to a device without knowing a user's credentials, but it requires knowing the target's public IP address to brute force the UDP hole punching that's used for external access and a specific identifier for the camera which theoretically could be enumerated, but I think this raises the level of the attack above the grasp of most folks. This makes me a lot better about sharing what I have, so I've been working on a Python implementation of the protocol analysis I've done so far and hope to have a PR up soon.

[nonsleepr]

requires knowing the target's public IP address ... and a specific identifier for the camera

I would say that's quite a big search space. If all you know is a public IP, you'd still have to scan 65k ports for 10^6 digits and 26^5 letters.

[martinorob]

Hello, i discover this thread that make me happy :) thank you all for the job.

I would like to automate the security mode from my domoticz (if possible using dzvents).

I already set up the connect sequence to get my token : OK
I already setup the dev_devs_list to get the list of devices : OK
-> I have in the return a lot of information like that (here is a partial extrat of my return
"station_conn": {
"station_sn": "manually removed",
"station_name": "manually removed",
"station_model": "T8002",
"main_sw_version": "2.1.0.5h",
"main_hw_version": "P1",
"p2p_did": "manually removed",
"push_did": "manually removed",
"ndt_did": "manually removed",
"p2p_conn": "manually removed",
"app_conn": "manually removed",
"binded": false,
"setup_code": "",
"setup_id": "",
"wifi_mac": "8C:85:manually removed"
},
"family_num": 0,
"member": {
"family_id": 19171,
"station_sn": "manually removed",
"admin_user_id": "manually removed",
"member_user_id": "manually removed",
"short_user_id": "0000",
"member_type": 2,
"permissions": 0,
"member_nick": "",
"action_user_id": "manually removed",
"fence_state": 0,
"extra": "",
"member_avatar": "",
"create_time": 1566489076,
"update_time": 1566489076,
"status": 1,
"email": "manually removed",
"nick_name": "manually removed",
"avatar": "https://d10z7gzu6c6vo4.cloudfront.net/users/*manually removed*",
"action_user_email": "manually removed",
"action_user_name": "manually removed"
},

Now I try to get the json response to the API all: https://security-app-eu.eufylife.com/v1/app/equipment/get_dsk_keys
in order to establish P2P connexion later

I use reqbin to test it and i put correctly the header with my token and then content with my station_sn

When I call the API I get a 200 return code (meaning url AND token are OK) but json contain no other information than that :
{
"code": 10000,
"msg": "Failed to request."
}

Can you help me ?

I got my token using this url : https://mysecurity.eufylife.com/apieu/v1/passport/login

thank you

I have the same problem, did you solve this?

[89jd]

@89jd I know that @bropat was working on it, but I don't know if he has finished that feature. Checkout https://github.com/bropat/ioBroker.eufy-security

Cheers for reply. Doesn't look like it does, but looks close. Will dig deeper in to that code, thanks :)

[bachya]

I've tried a MITM proxy for these actions, too, with no luck.

I did see something interesting while setting the mode: while on the same network as the Eufy hub, I couldn't see any obvious API calls, but the mode was successfully set; while on a cellular network (and, again, with the proxy in the middle), the mode changes never succeeded. No clue what that means.

Any Android users out there who'd be willing to decompile the app and see what is going on?

[bachya]

I was able to decompile. On the hunt.

EDIT: Well, after several hours, I'm reminded how difficult Java is. 😆I don't see any particular API that gets called when the mode (Away/Home/etc.) buttons are tapped. Interestingly enough, I also see no reference to /api/v1/web/equipment/start_stream or /api/v1/web/equipment/stop_stream; this, combined with the fact that the mobile app's API calls start with https://security-app.eufylife.com/v1 and the web app's start with ``https://mysecurity.eufylife.com/api/v1`, makes me think we're dealing with different things.

Also worth noting that the web app doesn't appear to support modes currently.

[joepadmiraal]

I had a quick look at the APK and it seems to have some MQTT classes.
Maybe it's using MQTT instead of HTTP for the mode buttons.

[FuzzyMistborn]

That would be fascinating if true. Would also likely be true for some of the settings/configuration then too. Still would think the calls would show up in HTTP(S) traffic.

[bachya]

Fascinating!

Most proxies aren't configured to handle raw TCP over TLS – they only look at HTTP traffic. Perhaps using a SOCKS proxy would be better, since that would redirect all traffic. Unfortunately, the Charles iOS app doesn't handle this yet.

[FuzzyMistborn]

If you know of an android option I'm happy to give it a go.

[bachya]

Maybe try this? https://play.google.com/store/apps/details?id=org.sandroproxy.drony&hl=en_US

[FuzzyMistborn]

Will give it a go tonight if I have time.

[joepadmiraal]

Maybe Mallet or Mallory can do the trick?
I would love to do some tests myself but the doorbell is not available in the Netherlands yet.

[mjhram]

Hi
I am trying to use the API's. The login is successful, but the get device list returned no data!
{
"code": 0,
"msg": "Succeed."
}
what am I doing wrong?

[nonsleepr]

I've looked into decompiled Android app and my understanding is that the doorbell communicates with the cloud via MQTT while the phone gets notifications via FCM with the directions on how to connect to cloud's MQTT broker. Static analysis wouldn't help here. I will try to MITM the app some time later.

[keshavdv]

While I only have the Eufy Floodlight and not the doorbell to test with, I've been able to identify enough parts of the UDP-based P2P protocol to be able to successfully toggle the light outside of the app. The approach seems to use the same control plane that I think the app uses to talk to the Eufy HomeBase, but I don't have one to confirm. So far, the floodlight seems entirely independent of the MQTT pipeline that seems to exist for the doorbell only.

[nonsleepr]

@keshavdv This is great, do you have any snippets of code you can share, a gist would be enough.

[keshavdv]

I’ll put something up in a bit, but it’s mostly based on a custom version of https://github.com/fbertone/lib32100 for the initial handshake and custom data packets. Interestingly, I tried the HTTP API you exposed in the other PR to set device params and while the property does seem to exist for the manual light state (1400) and is reported, flipping it only caused the app UI state to update but didn’t actually turn the light on or off.

[nonsleepr]

Have you checked what (other things) changes in the params when you flip the switch in the app?

[nonsleepr]

I was able to capture the contents of the app chatter with https://security-app.eufylife.com. It's pretty much the same is of the WebApp. It obtains a private key for the p2p communication and registers FCM token though. It then talks to the doorbell directly using 32100 protocol (thanks @keshavdv for pointing to it), it uses UDP port 10125 though (maybe just in my case).

The app also talks with security-mqtt.eufylife.com:8789, I wasn't able to decrypt that yet though.

[nonsleepr]

Alright! I have everything I need to start working on p2p part. Just added an endpoint here used to obtain private keys for p2p communication.

[nonsleepr]

@keshavdv What were you able to achieve so far? It seems that p2p communication after the handshake is different from the protocol implemented be the library.

[keshavdv]

After the initial handshake, the protocol is indeed different, but replaying packet payloads that were generated from the app seems to work pretty reliably to do certain things (change light/detection settings).

I've made progress on reversing the actual protocol itself and I think with the packet types I've decoded so far, we can change most of the boolean/string based parameters that are available in the app. So far, and a bit worryingly, it seems like most control actions are not encrypted/authenticated apart from the actual video stream itself (I think this is where the key returned by the endpoint you linked comes into play).

[nonsleepr]

Oh, you're right! I thought the settings are set via the API, but there's a P2P communication.

Tried to disable the motion detection and that's what I got:

0000  f1 d0 00 3c d1 00 00 01 58 5a 59 48 a4 06 28 00   ...<....XZYH..(.
0010  00 00 01 00 ff 00 00 00 7b 22 63 6f 6d 6d 61 6e   ........{"comman
0020  64 54 79 70 65 22 3a 31 30 31 36 2c 22 64 61 74   dType":1016,"dat
0030  61 22 3a 7b 22 65 6e 61 62 6c 65 22 3a 30 7d 7d   a":{"enable":0}}

Do you also see those XZYH all over the place?

Not encrypting the data above is indeed concerning.

[nonsleepr]

I saw the option to open telnet in the app disassembly. It is probably meant for the base station though. Anyway, would be cool to get telnet access.

[keshavdv]

Sweet, thanks for sharing! Since I only have one device, I couldn't tell what was user/device specific versus a constant, but it looks like the preamble (XYZH) is the same. Nice find on telnet! I'll see if I can enable it on my device since I think the doorbell and floodlights also act as independent "hubs/stations".

[nonsleepr]

The telnet command is 1247. I tried it via API but that didn't work. I think the API's params endpoint is just for the app and the actual command is sent via p2p. That explains why you weren't available to switch the floodlight.

I'll implement the p2p option setting in the next few days.

[nonsleepr]

@keshavdv have you figured out where's the list of IPs for the initial discovery comes from? I bet it's hardcoded somewhere.

[nonsleepr]

That hardcoded MQTT username/passwords are disturbing as well. No other permissions required to get doorbell events. On the other hand, we can simply subscribe to doorbell button events.

[keshavdv]

I didn't have any luck with turning on telnet on the floodlight -- I do think that's something only available on the homebase. In other news, I've been able to figure out enough to decode a live video stream via P2P but I'm pretty shocked by the pretty shoddy level of encryption and lack of authentication that is used to protect these.

@nonsleepr, it seems like the only authentication that is actually done is by the firebase API which I believe uses some combination of the p2p_conn and p2p_did from the HTTP API. So far, getting motion event seems like the big last milestone left.

[nonsleepr]

Oh, and FCM isn't required, it's all in MQTT.

[mrjasonjordan]

I'm just desperate for the motion notifications so I can switch the lights on around the house when motion is detected by any of the cameras.

Why this functionality isn't already built-in amazes me. Especially considering MQTT is already in there!

[FuzzyMistborn]

Why this functionality isn't already built-in amazes me. Especially considering MQTT is already in there!

Uhh...because this is an alpha integration/library that is far from being feature complete and is only maybe a month old? Give it time.

[mrjasonjordan]

My apologies @FuzzyMistborn - it wasn't meant as a criticism of you or your work - I think you've done a brilliant job.

I was trying to say that I thought Anker should have included the functionality.

Brickbats to them. Bouquets to you!

[joepadmiraal]

Also, in regards to MQTT it looks like Anker has hardcoded the passwords to their broker man_facepalming. Looks like there are thousands of topics, one per mobile device. Messages being sent over the wire appear to be connect/disconnect notifications with IP addresses embedded.

Were you (or anyone else) able to connect to their MQTT server?
I tried with several tools (MQTT explorer, paho_cs_sub, etc.) but none of them were able to connect.
I seem to get ssl errors.

[nonsleepr]

That issue is (being) fixed.

[FuzzyMistborn]

Any ETA? Not pressuring but are we close/medium/far? Just so expectations can be set.

[joepadmiraal]

That issue is (being) fixed.

Was that a response to my question?
If so, is there a known issue on the eufy side with their MQTT service?

I'm posting here again as I now have bought an Eufy doorbell so I can help figuring out how it work.

[nonsleepr]

There are no issues with their MQTT, but the authorization part is flaky. I would say, the ETA for working doorbell event integration is 2-4 weeks.

[FuzzyMistborn]

Thanks!

Passing this one along:
http://community.anker.com/t/open-api/70397/17

[csrui]

Unfortunately no contribution on my part but I want to let you know that this thread was a delight to read. Awesome effort that I see here. You guys are amazing.

[FuzzyMistborn]

Looks like Eufy has changed things up according to this OpenHAB thread:
https://community.openhab.org/t/new-binding-eufy-doorbell/89513/26

Here's the github for it: https://github.com/basriram/openhab2-addons/tree/eufysecurity/bundles/org.openhab.binding.eufysecurity
Looks to be in Java but might be useful.

[FuzzyMistborn]

Right, figured it was outdated but looks like it definitely had more functionality built in. I might reach out to the dev there and point him here to pool resources a bit.

[basriram]

@FuzzyMistborn I am the developer of that openhab binding. It was working fine until Eufy released a new firmware version for the doorbell as well as a mandatory upgrade of the mobile app. With this update Eufy has switched to using FCM (firebase cloud messaging) for the most part and doorbell, motion detection etc., are delivered as push notification to the app and their mqtt topics have no messages. Hence it makes it harder to implement outside a mobile app.

[FuzzyMistborn]

Thanks for the information @basriram much appreciated. That sounds good for security but obviously more annoying for our purposes. Really wish they'd do an open API or even IFTTT at this point.

[asiridol]

Hey everyone, I am trying to reverse engineer the Eufy security app too, not the complete app just enough to arm/disarm using an ESP32. I have enabled debugging on their app and was able to capture most of the API logs from device logs. I have found out that there's a UDP port 39855 opened on the device too. Everything looks promising so far. Except when I send the same arm/disarm request to https://security-app.eufylife.com/v1/ the results are very different. If there's an MQTT client do you guys know the port it is using and the authorization?

[asiridol]

I can share the debuggable apk file if anyone's interested. I have added the ability to use custom certificates to use MITM to intercept traffic.

[Sillium]

Hey everyone, I am trying to reverse engineer the Eufy security app too, not the complete app just enough to arm/disarm using an ESP32. I have enabled debugging on their app and was able to capture most of the API logs from device logs. I have found out that there's a UDP port 39855 opened on the device too. Everything looks promising so far. Except when I send the same arm/disarm request to https://security-app.eufylife.com/v1/ the results are very different. If there's an MQTT client do you guys know the port it is using and the authorization?

Nice! Good luck with that, I'd be really interested in arming/disarming the eufys with IFTTT, Webhook, iOS-Shortcut, flic-Button, whatever...

I cannot help you here but hope you you'll be successful.

[Sillium]

@asiridol Hosting something on a Raspberry should be no problem. May I ask if you have anything I can try to deploy on one of my Raspberrys?

[Sillium]

@asiridol And: I see you made some nice progress there, congrats!

[joepadmiraal]

Eufy has switched to using FCM (firebase cloud messaging) for the most part and doorbell, motion detection etc., are delivered as push notification to the app and their mqtt topics have no messages.

My goals is to have a tablet show the doorbell camera stream when somebody rings it.
@basriram If I red your comment correctly it means we are not able to do such a thing without hooking into the push notifications somehow right?

For my personal purpose I sniff the push notifications on the tablet.
However I think such an approach can never work for the python-eufy-security or openhab projects.

[bertramlyons]

"Awesome. I actually also managed to pull video steam from the camera. I decoded the frame...."

Originally posted by @nonsleepr in #3 (comment)

Hi @nonsleepr, I'm wondering if you (or anyone in this thread) knows the encryption technique that is used to encrypt the first 70 (or 128) bytes of the raw video i-frame that is stored on the device itself? I have analyzed the raw-stored video enough to know that there is only a very small (70 or 128 bytes) chunk of the video that is actually encrypted at rest for each i-frame in the video that is found in .dat files on the device. Any chance someone can steer me to the encryption technique employed in the code?

[nonsleepr]

@bertramlyons The video stream is encrypted with the public key (which you can generate), it would then be decrypted with your private key.

At rest, how did you pull that?

[bertramlyons]

@nonsleepr The at-rest data was provided to me - extracted from the chip directly using forensics tools. I, personally, do not have the ability to pull the at-rest data directly.

[keshavdv]

It seems the protocol is still relatively unchanged apart from the initial discovery mechanism, so while it's at least considerably more difficult for an attacker to find an exposed device, it is still possible. With that said, I think it'd be good to start getting some stuff out in the open to make more progress on the P2P protocol analysis and hopefully get closer to being HA/homebridge compatible.

[nonsleepr]

@nonsleepr The at-rest data was provided to me - extracted from the chip directly using forensics tools.

@bertramlyons Interesting, did you (or someone else) desoldered the eMMC chip?

it is still possible.

@keshavdv Are you talking about local device discovery with broadcasts or completely remote connection? It seems the device would listen on the UDP port 32108 and reply to the broadcast.

[joepadmiraal]

Finally got something together in a PR in #44 and would love some additional testers with more than one device and ideally somebody with an actual Homebase (doorbells and floodlights are kind of special since they have a "hub" built in)!

I have a doorbell and would like to test your PR.
I'm not sure what's te best way to run the example, but for now I simply moved the test_p2p.py to the root of the repository so it can find async_login etc.
I made sure the EUFY_EMAIL and EUFY_PASSWORD env vars are set and ran the python script.
I get this output:

DEBUG:asyncio:Using selector: EpollSelector
INFO:eufy_security.api:Switching to another API_BASE: https://security-app-eu.eufylife.com/v1
------------------
Station Name: eufy base
Serial Number: T8010P2320020A43
DEBUG:eufy_security.station:Unable to process parameter "1266", value "0"
DEBUG:eufy_security.station:Unable to process parameter "1176", value "192.168.0.248"
DEBUG:eufy_security.station:Unable to process parameter "1236", value "1"
DEBUG:eufy_security.station:Unable to process parameter "1155", value "2"
DEBUG:eufy_security.station:Unable to process parameter "1135", value "0"
DEBUG:eufy_security.station:Unable to process parameter "1670", value "0"
DEBUG:eufy_security.station:Unable to process parameter "1265", value "1"
DEBUG:eufy_security.station:Unable to process parameter "1362", value "1"
DEBUG:eufy_security.station:Unable to process parameter "1253", value "0"
DEBUG:eufy_security.station:Unable to process parameter "1200", value "6"
DEBUG:eufy_security.station:Unable to process parameter "1043", value "0"
DEBUG:eufy_security.station:Unable to process parameter "1280", value "30"
DEBUG:eufy_security.station:Unable to process parameter "1140", value "1"
Station params: {1266: '0', 1176: '192.168.0.248', 1236: '1', <ParamType.GUARD_MODE: 1224>: 1, <ParamType.CAMERA_SPEAKER_VOLUME: 1230>: 26, 1155: '2', 1135: '0', 1670: '0', 1265: '1', <ParamType.CAMERA_UPGRADE_NOW: 1133>: 0, 1362: '1', 1253: '0', 1200: '6', 1043: '0', <ParamType.SCHEDULE_MODE: 1257>: 63, 1280: '30', 1140: '1'}
Camera params: DeviceType.STATION
INFO:eufy_security.p2p.session:Connecting to ZXCAMAA-044232-KMFBG with 1WL0flYmXBx9swhcROn2
INFO:eufy_security.p2p.session:Trying discovery seed 34.235.4.153
INFO:eufy_security.p2p.session:Trying discovery seed 54.153.101.7
INFO:eufy_security.p2p.session:Trying discovery seed 18.223.127.200
Traceback (most recent call last):
  File "test_p2p.py", line 41, in <module>
    asyncio.get_event_loop().run_until_complete(main())
  File "/usr/lib64/python3.8/asyncio/base_events.py", line 616, in run_until_complete
    return future.result()
  File "test_p2p.py", line 29, in main
    async with station.connect() as session:
  File "/usr/lib64/python3.8/contextlib.py", line 171, in __aenter__
    return await self.gen.__anext__()
  File "/home/joep/Documents/joep/domotica/eufy/python-keshavdv/eufy_security/station.py", line 45, in connect
    raise EufySecurityP2PError(f"Could not connect to {self.name}")
eufy_security.errors.EufySecurityP2PError: Could not connect to eufy base

The IP address it tries to use seems correct: 192.168.0.248.
Any idea what else could be wrong here?

[keshavdv]

It seems like it's not getting past the initial discovery step at all. Can you pull the latest version, bump the logging level from INFO to DEBUG in the example and share another gist?

[joepadmiraal]

I did not see any new commits so I cloned the repo again just to be sure.
test_p2p.py already contains this line to set the log level:
logging.basicConfig(level=logging.DEBUG)
Is there anything I need to do myself to make it more verbose?

This is the output from after cloning again.
Looks pretty similar to me.

DEBUG:asyncio:Using selector: EpollSelector
INFO:eufy_security.api:Switching to another API_BASE: https://security-app-eu.eufylife.com/v1
------------------
Station Name: eufy base
Serial Number: T8010P2320020A43
DEBUG:eufy_security.station:Unable to process parameter "1266", value "0"
DEBUG:eufy_security.station:Unable to process parameter "1176", value "192.168.0.248"
DEBUG:eufy_security.station:Unable to process parameter "1236", value "1"
DEBUG:eufy_security.station:Unable to process parameter "1155", value "2"
DEBUG:eufy_security.station:Unable to process parameter "1135", value "0"
DEBUG:eufy_security.station:Unable to process parameter "1670", value "0"
DEBUG:eufy_security.station:Unable to process parameter "1265", value "1"
DEBUG:eufy_security.station:Unable to process parameter "1362", value "1"
DEBUG:eufy_security.station:Unable to process parameter "1253", value "0"
DEBUG:eufy_security.station:Unable to process parameter "1200", value "6"
DEBUG:eufy_security.station:Unable to process parameter "1043", value "0"
DEBUG:eufy_security.station:Unable to process parameter "1280", value "30"
DEBUG:eufy_security.station:Unable to process parameter "1140", value "1"
Station params: {1266: '0', 1176: '192.168.0.248', 1236: '1', <ParamType.GUARD_MODE: 1224>: 1, <ParamType.CAMERA_SPEAKER_VOLUME: 1230>: 26, 1155: '2', 1135: '0', 1670: '0', 1265: '1', <ParamType.CAMERA_UPGRADE_NOW: 1133>: 0, 1362: '1', 1253: '0', 1200: '6', 1043: '0', <ParamType.SCHEDULE_MODE: 1257>: 63, 1280: '30', 1140: '1'}
Camera params: DeviceType.STATION
INFO:eufy_security.p2p.session:Trying discovery seed 34.235.4.153
INFO:eufy_security.p2p.session:Trying discovery seed 54.153.101.7
INFO:eufy_security.p2p.session:Trying discovery seed 18.223.127.200
Traceback (most recent call last):
  File "test_p2p.py", line 42, in <module>
    asyncio.get_event_loop().run_until_complete(main())
  File "/usr/lib64/python3.8/asyncio/base_events.py", line 616, in run_until_complete
    return future.result()
  File "test_p2p.py", line 30, in main
    async with station.connect() as session:
  File "/usr/lib64/python3.8/contextlib.py", line 171, in __aenter__
    return await self.gen.__anext__()
  File "/home/joep/Documents/joep/domotica/eufy/python-keshavdv/eufy_security/station.py", line 45, in connect
    raise EufySecurityP2PError(f"Could not connect to {self.name}")
eufy_security.errors.EufySecurityP2PError: Could not connect to eufy base

[keshavdv]

Ah, you’re right, that is indeed all the useful log output for the moment. It seems like the initial discovery mechanism is slightly different, but I don’t have the hardware to be able to debug myself. If you are comfortable privately sharing some tcpdump samples from when you open the app from an AVD instance, I might be able to help.

[joepadmiraal]

Sure, that would be great.
I created a tcpdump.
How can I send it to you?

[keshavdv]

Uploading to https://www.dropbox.com/request/Nnq3yiKmzc9DhdgHESQT would work for me!

[asiridol]

@keshavdv Is there a documentation for P2P protocol spec? I like to port the library to c# but I have very little knowledge in Python.

[nonsleepr]

@asiridol No documentation whatsoever. The only docs is @keshavdv's code.

[asiridol]

@nonsleepr Thanks mate. After some research I have managed to get hold of the 32100 traffic. And reverse-engineered discovery step referencing @keshavdv 's code. One question. Where's the key used in discovery comes from? Is it hard-coded? I didn't see references to that when I was analyzing app code.

[nonsleepr]

@asiridol This is how the key is obtained.

[asiridol]

@nonsleepr Thanks a lot. I don't know how I missed that. May be I was expecting the discovery to complete before the actual authentication.

[multinet33]

Hello, i discover this thread that make me happy :) thank you all for the job.

I would like to automate the security mode from my domoticz (if possible using dzvents).

I already set up the connect sequence to get my token : OK
I already setup the dev_devs_list to get the list of devices : OK
-> I have in the return a lot of information like that (here is a partial extrat of my return
"station_conn": {
"station_sn": "manually removed",
"station_name": "manually removed",
"station_model": "T8002",
"main_sw_version": "2.1.0.5h",
"main_hw_version": "P1",
"p2p_did": "manually removed",
"push_did": "manually removed",
"ndt_did": "manually removed",
"p2p_conn": "manually removed",
"app_conn": "manually removed",
"binded": false,
"setup_code": "",
"setup_id": "",
"wifi_mac": "8C:85:manually removed"
},
"family_num": 0,
"member": {
"family_id": 19171,
"station_sn": "manually removed",
"admin_user_id": "manually removed",
"member_user_id": "manually removed",
"short_user_id": "0000",
"member_type": 2,
"permissions": 0,
"member_nick": "",
"action_user_id": "manually removed",
"fence_state": 0,
"extra": "",
"member_avatar": "",
"create_time": 1566489076,
"update_time": 1566489076,
"status": 1,
"email": "manually removed",
"nick_name": "manually removed",
"avatar": "https://d10z7gzu6c6vo4.cloudfront.net/users/*manually removed*",
"action_user_email": "manually removed",
"action_user_name": "manually removed"
},

Now I try to get the json response to the API all: https://security-app-eu.eufylife.com/v1/app/equipment/get_dsk_keys
in order to establish P2P connexion later

I use reqbin to test it and i put correctly the header with my token and then content with my station_sn

When I call the API I get a 200 return code (meaning url AND token are OK) but json contain no other information than that :
{
"code": 10000,
"msg": "Failed to request."
}

Can you help me ?

I got my token using this url : https://mysecurity.eufylife.com/apieu/v1/passport/login

thank you

[fullphat]

Any update on when floodlight cam Homebridge integration might be possible? Even if I could only turn the security lights on and off via HomeKit, that would be fantastic! 👍

[JanLoebel]

Hi everyone! Thanks for the amazing project and the things you all have already discovered. I've implemented a small client in node/typescript to be able to look further. If anyone is interested in helping to find out more about the protocol / structure and so on, feel free to contact me!

https://github.com/JanLoebel/eufy-node-client

Has anyone tried to access firebase to receive notifications? MQTT seems not to be supported anymore.

[JanLoebel]

I've created a frida script to disable ssl pinning, intercept and log a some of the traffic (HTTPS / P2P) and a wireshark dissector to get more information already in wireshark.

I've also tried to connect to FCM/GCM to receive push notifications but without any luck. I've tried to create a new "client" and register that with the register-push-token api-endpoint and open another session directly with the already registered push token from the running android app.

Does anyone know how the encryption for the P2P packages work that will send or received from the cloud services? The packages are completely different after the "standard" discovery method..

[nonsleepr]

@JanLoebel Mind sharing what you've got as a gist?

As for P2P exchange, there's another PR that handles that.

[JanLoebel]

@nonsleepr Thanks, I've posted already before all what I have (wirshark, frida, node-client, ...), in my repository: https://github.com/JanLoebel/eufy-node-client

The P2P exchange locally is handled by the PR I know, but for the Cloud P2P Part is only the discovery working. Sadly I can't easily post the requests because of the authentication/secrets etc.. I will check if I can easily hide/remove that from the logs and then upload also the communication.

Update: I got the push notifications working, checkout the repo.

[bachoo786]

It seems the protocol is still relatively unchanged apart from the initial discovery mechanism, so while it's at least considerably more difficult for an attacker to find an exposed device, it is still possible. With that said, I think it'd be good to start getting some stuff out in the open to make more progress on the P2P protocol analysis and hopefully get closer to being HA/homebridge compatible.

Hi @keshavdv

To run an RTSP stream from the eufy doorbell, the link that you have used is that the standard link? or would I have to find a different port in my case?

thanks.

[MaxWinterstein]

As I would love to have more features ending up in my HomeAssistant I digged trough other projects and found this one (which seems not to be mentioned here before):

https://github.com/bropat/ioBroker.eufy-security

Aside from battery status, which is cool, it seems like it is able to change at least the mode of the base station, which I would love!

[amosyuen]

I also ran into the login 10000 error code specifically in hubitat. Using curl it worked fine. I got it to work in hubitat by setting 'Content-Type: application/json' header. Interestingly curl worked without that header.

[89jd]

Was hoping to download videos from the base station, and wondered if anyone has advice on where to go?

Did some decompiling before finding this thread, and can see it uses the P2P connection to connect to base station, and that is where I should be able to download from the SDCard. Wondered if anyone has managed to do it yet?

I tried calling get_history_records_all on api, and that returns empty (assumedly this is from cloud storage). Is there an equivalent on P2P?

@keshavdv: have you made any progress since the PR? Would be happy to contribute / help out if I can

[JanLoebel]

@89jd I know that @bropat was working on it, but I don't know if he has finished that feature. Checkout https://github.com/bropat/ioBroker.eufy-security

[bropat]

@JanLoebel, @89jd

This feature is already implemented in the client library eufy-security-client (see here).
The ioBroker adapter already uses this library and also the download of a video (see here).
However, there is currently no documentation other than the "practical example" ioBroker.eufy-security.

[89jd]

@bropat Amazing. I have just been following the thread on the home assistant forum (that is what I am planning on integrating it into). So great work :). I did stumble upon the client library. Can you run the client directly as a micro-service? Just so I can interface directly?

[bropat]

@89jd

Can you run the client directly as a micro-service? Just so I can interface directly?

Unfortunately not, but there is here this project by @matijse, which provides an interface as a microservice via MQTT.
Unfortunately, however, the conversion to the new client library is still in progress here.

PS: @matijse, if you need help, let me know.

[JanLoebel]

@bropat I deprecated my project and referred yours :) Great work!

[bropat]

@JanLoebel ok, thanks :) if you want to contribute you are welcome ;) (or anybody else)

[89jd]

@bropat I am happy putting this as a question on your page, but just wanted to check, Is there a way to list all events on sdcard, and bulk download (like the MacOS app does)?

Thanks

[bropat]

@89jd Yes, but only if you use the client library and program it yourself. ;)

[89jd]

@89jd Yes, but only if you use the client library and program it yourself. ;)

That's fine! Any pointers to where the command to list the files is?

[bropat]

Any pointers to where the command to list the files is?

Good question, I checked now and saw that I haven't implemented that part (http api call) yet :P
With a little patience I will catch up in the next days.

[89jd]

Nice one, no huge rush, happy to help with the dev, if you have the api it should be hitting!

Out of interest, to get the file list, do you have to go via the eufy servers? Rather than through p2p directly?

[bropat]

Out of interest, to get the file list, do you have to go via the eufy servers? Rather than through p2p directly?

Yes, unfortunately it is.

[bropat]

@89jd

I have released the new version (0.7.2) which now includes the necessary HTTP Api calls.
The method you need is getVideoEvents or getAllVideoEvents.

Basically, here's what you need to do now:

1. get the following values from all videos using the HTTPApi method getAllVideoEvents:
   • station_sn
   • device_sn
   • storage_path
   • cipher_id
2. Open a P2P connection to the relativ station
3. use the Station method startDownload to download all videos one by one by using the parameters you got in the 1st call
4. you get the data of the respective video now over the event start_download
5. Process the data and save to file