Implement Google Find My #51
Comments
biemster
added
enhancement
|
For anybody working on this the specification seems to be here (https://developers.google.com/nearby/fast-pair/specifications/extensions/fmdn) |
|
This is very interesting.
Note: |
|
not sure yet. From that page, device manufacturers at least have to do a google NDA to ship a find my device compatible device, but that's pretty normal right? |
|
My question is if Google / Android phones are now reporting Apple's FindMy devices to their (or even Apple's) server as well. If Google isn't releasing info on how to request the data from their server, it probably needs to be hacked like it was done with Apple before. If Android now sends location reports to Apple's server it would enlarge the FindMy network instantly without the need to make any changes for Apple and us. |
|
Yea I'm fairly certain that's not happening. The google Find my Device network is separate. There are some architectural changes too. |
|
More info that people have started collecting here: seemoo-lab/openhaystack#210 |
|
Maybe helpful: from Nordic Semiconductor (manufacturer of nRF52840 - Multiprotocol Bluetooth 5.4 SoC supporting Bluetooth Low Energy, Bluetooth mesh, NFC, Thread and Zigbee) |
|
I added an esp32 micropython script that sends the FMDN advertisement as detailed in https://developers.google.com/nearby/fast-pair/specifications/extensions/fmdn#advertised-frames table 8. I have no clue yet how to compute the ephemeral id or how to retrieve the reports through the google api's yet, but it's a start! nRF Connect reports this as an Eddystone, with the ephemeral id as the data field. |
I just got some Chipolo tags, if you need me to scrape some data that might help, happy to do so. |
That would be great! Are you able to mitm proxy an android with the account your chipolos are registered on? |
|
chipolo review, https://youtu.be/3EAu08m5Lbc?feature=shared&t=285 |
I don't know if they improved meanwhile, but it's described here As I understand the specifications, the Ephemeral Key is just a random 32 bytes generated by the tag once. It doesn't have to be known by the smartphone or tag owner. It's then used as an AES key (ECB mode!) for encrypting a dumb message. This makes a pseudo random number ( I'm not sure I'm getting the logic here, it seems so stupid, I'm missing something. The dumb message (which is doubled to fit in 256 bits) is made of only 22 bits of actual changing data. There's seconds' timer counter whose 10 low bits are cleared (so only 22 bits useful in theory, but since it counts from 0, those are guessable quite easily). Technically, the counter actually update ~4 times per hour. Then you AES ECB encrypt it and get As for the ephemeral identity key, they say this, meaning that it's possible to fetch it if the tracker is not provisioned. In that case, everything is deterministic. If you ever intend to make a fully featured device (one that does support the provisioning process), then it means implementing this (which is, AFAIU, not very complex to compute, but probably more to implement the persistent state in flash, in your reversed engineered firmware) |
|
wow, thank you for your analysis! As it's done with the airtags it should be kept as simple as possible, ie
My guess is that they use randomness as IV during provisioning, just to prevent same bytes showing up in the air. ECB is normal if data is less than block size/packets are infrequent and they don't want to worry about keeping last state/losing packets. |
|
This could be interesting to you as well:
Note: I have not been able to query location reports from the server yet. This will be the hardest part, since it requires HTTPS and Firebase authentication with a private API from Google. |
|
The former repository is really useful, I didn't know it was possible to write crypto code over finite field that simply with python, always did it with C++ (and a not that simple interface). I've hard time figuring out what the second repo is actually doing (except making an HTTP request to I think this line is wrong however. While requesting location report is useful per se, it can be done actually with an Android phone meanwhile. Being able to have a tag that's speaking the right protocol so that an unmodified Android phone fills the location report's database at Google would confirm the protocol implementation in the tag is working. That would probably solve many problems already. |
|
Hey there, I verified the EID calculation with real trackers. It should be correct. What you seem to forget is that the timestamp and padding is not the EID. The EID is calculated by encryption using AES-ECB with the EIK and then projecting the result to the elliptic curve. Then, the EID is the x coordinate of this calculation, just like in my code. |
|
Ok, I don't know in fact what the tracker are doing, I don't have any. Here they say: Seems like, to me that the beacon time counter should be Once you know it, you can recreate this EID just by knowing the time distance with the last or first provisioning (since everything is known in the algorithm). So you can compute Rx from both side (tracker & consumer's smartphone) which is required for encrypting and decrypting the EID, as described here (since you can deduce Ry from Rx). So if you don't mask the low bits, you'll not find the expected Rx from the consumer's smartphone that'll mask them out. (It'll only be correct once every 1024 seconds, but since the clock are unlikely to be synchronized, I don't think the tracker will emit a report that'll be captured by a nearby phone at the exact moment when its time counter is 0 for the 10 low bits). |
|
Ah, now I know what you mean. It's true that the counter for the EID calculation only counts in multiples of 1024. Since all other code only called the EID calculation with multiples of 1024 as the offset value, this was not a problem. But you are right, this should be made more explicit in the code. |
|
Well, I think we talk about different acronyms (in their immense wisdom, they used E for both ephemeral and encrypted). Yet, it's missing the part that's masking the low 10 bits, as specified. It's not the encrypted ID yet, but it's required to compute the encrypted ID |
|
I've updated the file to make it more clear that only multiples of 1024 can be used. The file does specify the complete EID calculation. If you have more questions, please open an issue in my repository. |
|
I've done some digging into how the API works, perhaps it could be useful to you all. The reason that there's no data in the response to requests to the However, this may make using the API difficult. Libraries like push-receiver do allow for subscribing to push notifications for a FCM project, so might be useful here. A quick test using that library shows that using the app ID, project ID and API key from the Find Device app results in a push token, but this is only half the battle - the token still has to be sent to the server, which is a gRPC call that would need to be reverse engineered too. As for getting an auth token for the server in the first place, you'll need an AAS token and to make a request using the right scopes using this token. The token can only be obtained via the embedded setup, there's various implementations of this (such as Aurora Store's authenticator, Revanced's MicroG-RE, or my own Google Wallet plugin) My original intention for working with the API was to do some basic location history logging to compare it to Samsung's network. In the end, I just made an Xposed module that intercepts the data after the app has handled it. I've also done a lot of work in reversing Samsung's API, which is much easier to work with, that I'll write documentation for (useful for #65) when I release the project it's for - an app/mod that allows using Samsung's tags on non-Samsung devices. |
|
Hi Kieron, Thanks for your report! I've also looked into querying the location reports for the last week. I'll have to agree that working with Google's implementation is indeed very annoying. Nevertheless, I'm happy to report that I made a breakthrough yesterday. I am now able to log in with Firebase, get the required tokens, and receive the push notifications for the encrypted location reports in my own app. Root is not needed. To make everything work, I used microG as a base, and added rudimentary support for the Spot API to it. My plan is to now to extract only the needed parts from microG. The project is very large, it can take up to 40mins to compile 😅 If I have compiled a more simple version, I'll post it on my GitHub. I'll keep you updated. |
|
Just in case you haven’t noticed already: The whole location querying process is now implemented in my repository https://github.com/leonboe1/GoogleFindMyTools I’ve also implemented an iOS app which does the same thing. If anyone is interested in testing this app, write me a message. |
|
This is fantastic and a breakthrough. Could you please share some more information of this achievement?
|
Google just activated their own Find My network on Android this weekend. Details are still scarce, so let's collect all technical info needed to send the BLE advertisement and subsequently query this network here.
The BLE part can then be implemented here: https://github.com/biemster/st17h66_RF (and I will also finally put the Apple FindMy advertisement there then as well, so the chip can do both)
The text was updated successfully, but these errors were encountered: