Open YupengLai4 opened 8 months ago
Hi, I've noticed that the alert feature isn't enabled. I really need this feature because I tend to leave it in some corner and then can't find it
(sigh). I've tried connecting to it with the official app and setting it to play alert , but that doesn't work. It only starts to play sound after I unlock it using the password.
Hi, I'm not sure what firmware you are using, but for Xtreme and Monumentum firmware, there is the option in the CFW settings (Interface - Lockscreen - Allow RPC while locked) to allow bluetooth connection while it is locked. Then, you can connect using the app and the alert should work without a problem. Hope that helps!
Hi, I was wondering how you got the 'Play Sound' alert to work. When I'm using it, all I get is 'AirTag Not Reachable'.
Hi, I was wondering how you got the 'Play Sound' alert to work. When I'm using it, all I get is 'AirTag Not Reachable'.
Hi, I wasn't talking about the Airtag alert feature, you can just use the alert from the Flipper Zero App. In my comment, I explained how to use the app even when the flipper is locked and then you can open the app and tap "Play Alert on Flipper"
Oh I see, sorry I misunderstood.
there is the option in the CFW settings (Interface - Lockscreen - Allow RPC while locked) to allow bluetooth connection while it is locked.
Thanks for reminding me! I also wanna use FindMy app to play alert so that it's more like a real AirTag. But if that is hard to achieve then never mind :)
This might be tricky as it requires a BLE connection, not just acting as a beacon. That said, if the pairing (w/ the spoofed MAC / keys etc) is tractable to implement, the rest should be fairly doable.
Communication is via L2CAP, per https://github.com/seemoo-lab/airtag/blob/main/woot22-paper.pdf. Entire sound-playing exchange as follows:
The raw L2CAP protocol for AirTags implements commands, as shown in Figure 5b. Each command has a one-byte opcode followed by a payload. If a command was received successfully, it is acknowledged. Some commands require a mutex. Mutexes are also implemented as a command, set before the command requiring a mutex and released afterward.
For example, playing a sound on the AirTag requires the following steps. First, a mutex is set by the iPhone and acknowledged by the AirTag. Then, a sound sequence command is sent to the AirTag, which selects from predefined sound samples within the firmware previously shown in Figure 4. Each sound section consists of 4 bytes: sound index, number of repetitions, offset within sound sample, and pause until next sound. Multiple sounds can be chained within the payload of one command. After transmission, the sound sequence is acknowledged. While the sound is playing, the AirTag regularly sends a status to the iPhone. Finally, the mutex is released.
Opcodes listed in the readme here; 14 = Set Mutex, 40 = Play Sound Sequence.
Any thoughts on the tractability of allowing paired communication @MatthewKuKanich? Out-of-scope for the app, or an easy addition?
On second thought, from my amateur understanding of BLE, I don't think this would be possible (at least without a vastly different approach). From the "Cloning Existing Tag" option, we only have the MAC & public key as captured. To actually handle a BLE connection, we would need the ECDH private key (& other params? IRK/ERK?) I believe — which, short of voltage glitching the AirTag & dumping the flash (?) or figuring out a way to imitate the initial AirTag-iCloud provisioning on the Flipper itself, we would not have. Would love to be proven wrong; I know next to nothing about BLE & how the key exchange / pairing / connection work so this is all wild speculation on my part.
From the "AirTag Key Generation" option, we do have the private key, but of course one can't use the native FindMy app. Would presumably allow for the same functionality to be implemented over OpenHaystack or the like though.
On second thought, from my amateur understanding of BLE, I don't think this would be possible (at least without a vastly different approach). From the "Cloning Existing Tag" option, we only have the MAC & public key as captured. To actually handle a BLE connection, we would need the ECDH private key (& other params? IRK/ERK?) I believe — which, short of voltage glitching the AirTag & dumping the flash (?) or figuring out a way to imitate the initial AirTag-iCloud provisioning on the Flipper itself, we would not have. Would love to be proven wrong; I know next to nothing about BLE & how the key exchange / pairing / connection work so this is all wild speculation on my part.
From the "AirTag Key Generation" option, we do have the private key, but of course one can't use the native FindMy app. Would presumably allow for the same functionality to be implemented over OpenHaystack or the like though.
Sorry for such a late reply. Currently this seems like too big of a task for the Flippers current BLE stack. The Flipper Zero has a 'lite' BLE stacked and is very stripped down due to flash size limitations. This limits the featureset (no sniffing/scanning, no master control). Things that may be needed to establish a pairing. I was able to successfully get battery level updating to work and will be updating the app soon with this functionality. Though that has to do with swapping bytes in the payload and not a direct connection to the FindMy ios app. I'd also love to be proven wrong, the resources are out there regarding the protocol and what data needs to be sent when. Just an issue of implementing on the current hardware.
Hi, I've noticed that the alert feature isn't enabled. I really need this feature because I tend to leave it in some corner and then can't find it
(sigh). I've tried connecting to it with the official app and setting it to play alert , but that doesn't work. It only starts to play sound after I unlock it using the password.