Apple devices listen for BLE advertisements of a certain form to indicate a "Find My" network lost device. Apple 设备监听特定形式的 BLE 广告，以指示 "查找我的" 网络丢失的设备。
The lost device advertisements mainly contain the public key part of a key pair. 丢失设备广告主要包含密钥对中的公钥部分。
The public key does not fit in the in payload of the advertisements, so it is stuffed into the address field. Edit: Only 46 bits of the full 224 bit public key is stored in the address field. 公钥无法适应广告的有效负载，因此被填充到地址字段中。编辑：地址字段中仅存储完整 224 位公钥的 46 位。
In general anyone can make a "lost device" advertisement as demonstrated by OpenHayStack[1]. The requirement is the address field needs to be fully controllable. 一般来说，任何人都可以制作“丢失设备”广告，如 OpenHayStack[1]所示。要求是地址字段需要完全可控。
BLE advertisements have a header that indicates what kind of address is present (specified by 3 bits: Public, NRPA, RPA, Random Static). The lost device advertisements are supposed to be "Random Static", but the researchers found that Apple "Find My" listeners ("finders") will accept advertisements for any address type. BLE 广播具有一个头部，指示存在何种地址（由 3 位指定：公有地址、NRPA、RPA、随机静态）。丢失设备的广播应该是“随机静态”，但研究人员发现苹果的“查找我的”监听器（“查找者”）将接受任何地址类型的广播。
They use this fact to generate the private key part of a public key that matches an existing host adapter BLE address. The host adapter BLE address cannot generally be changed unless user has root/superuser privileges. This step is computationally expensive. However, private keys can be precomputed (rainbow tables) because a large chunk of the address is a manufacturer code (OUI). 他们利用这一事实生成与现有主机适配器 BLE 地址匹配的公钥的私钥部分。一般情况下，主机适配器 BLE 地址无法更改，除非用户具备 root/superuser 权限。这一步计算代价很高。然而，私钥可以预计算（彩虹表），因为地址中的一大部分是制造商代码（OUI）。
> Hold up, how are they generating a private key from a public key? > 等等，他们是如何从公钥生成私钥的？
They are not. They are generating a private/public key pair where the first 46 bits of the public key happen to match the victim's BLE address. 它们不是。它们正在生成一对私钥/公钥，其中公钥的前 46 位恰好与受害者的 BLE 地址匹配。
The find-my network then accepts beacons (encrypted with the attacker's private key) from this address, and stores it in iCloud to be retrieved by the attacker via the 46-bit prefix. 然后，find-my 网络接受来自该地址的信标（用攻击者的私钥加密），并将其存储在 iCloud 中，以便攻击者通过 46 位前缀进行检索。
Expensive computed public key first 46 bits == Victim's BLE address 昂贵的计算公钥前 46 位 == 受害者的 BLE 地址
The Apple FindMy system doesn't (or didn't) validate that the public key being broadcast had ever been manufactured or registered. So anyone with an iCloud account could query the Apple FindMy hashtable for the last observed encrypted payload, which contains the observed location generated by the nearby phone. Apple FindMy 系统没有（或者以前没有）验证广播的公钥是否曾被制造或注册。因此，任何拥有 iCloud 账户的人都可以查询 Apple FindMy 哈希表以获取最后观察到的加密负载，该负载包含由附近手机生成的观察到的位置。
If you have root on the victim's device, you don't need the expensive computation step. You just take a public/private keypair of your choice and reprogram the victim's Bluetooth hardware to broadcast that instead. 如果您在受害者的设备上具有 root 权限，则不需要昂贵的计算步骤。您只需选择一个公钥/私钥对，并重新编程受害者的蓝牙硬件以广播该密钥对。
No, they find the victim's MAC and generate a payload to broadcast from the victim's device, which will make the device appear to Apple devices as a genuine Airtag. Apple devices then upload location reports to Apple, and the attacker downloads them. No real Airtags are involved. 不，他们找到受害者的 MAC 地址并生成一个有效负载，从受害者的设备进行广播，这将使该设备在 Apple 设备上显得像一个真正的 Airtag。然后，Apple 设备将位置信息报告上传到 Apple，攻击者将其下载。不涉及任何真实的 Airtag。
They pregenerate the key pairs. The trojan sends the MAC to the server, and the server looks in its (precomputed) stash of key pairs, to find a public key that matches. 它们预生成密钥对。木马将 MAC 发送到服务器，服务器在其（预计算的）密钥对存储中查找以找到匹配的公钥。
They're brute-forcing the generation of a public key using random private keys. The exact private key doesn't matter. The full length of the generated public key doesn't even matter, only the first 46 bits. Since they only need to find a public key matching those 46 bits instead of the full 226 bits, that makes a brute force search possible. 他们正在使用随机私钥进行公钥的暴力生成。确切的私钥并不重要。生成的公钥的完整长度甚至不是重点，只有前 46 位重要。因为他们只需要找到一个与这 46 位匹配的公钥，而不是完整的 226 位，这使得暴力搜索成为可能。
Hm, interesting. 2^46 is only 70 trillion, so yeah, totally computationally feasible. So,
if i understand correctly, they only need a GPU to generate a database of 70 trillion private / public keys? Damn, not bad. 嗯，有趣。2^46 仅是 70 万亿，所以，是的，完全在计算上可行。那么，如果我理解正确的话，他们只需要一个 GPU 来生成一个包含 70 万亿个私钥/公钥的数据库？真不错。
could Android users in a place like NYC/LA/London create a mesh network of "virtual airtags" that virtually follow all the iPhones around the city advertising to each that it is mysteriously being followed endlessly? I would switch to Android to participate. (ok, that's my opsec, i'm already on Android. haha gotcha! that's my opsec, i actually have...) 是否可以让生活在纽约/洛杉矶/伦敦等地的安卓用户创建一个“虚拟空气标签”的网络，虚拟跟踪城市里所有的 iPhone，对每个 iPhone 宣传它正在被无休止地跟踪？我会为了参与而转向安卓。（好吧，那是我的安全操作，我其实已经在用安卓了。哈哈，让你抓到了！那是我的安全操作，实际上我有……）
It's not something I'd do, but there are a number of reasons people might do something like this, including: 这不是我会做的事情，但人们可能这样做的原因有很多，包括：
1. To demonstrate technical flaws, on a purely technical basis. 1. 仅在技术基础上展示技术缺陷。
2. As political action in opposition to surveillance or inadequate security measures. 2. 作为对监视或不充分安全措施的政治行动。
3. Interest in loose-knit collaborative systems with emergent effects that people can assemble together. 对人们可以共同组装的具有突现效果的松散协作系统的兴趣。
4. As a fun prank, not thinking enough about how it would affect other people. 4. 作为一个有趣的恶作剧，没有充分考虑这会对其他人产生怎样的影响。
5. The point being to hurt other people, and/or to feel power over them. (This is a thing, including by organized groups/clubs on the Internet, but I think it's a small minority, and doesn't apply to the commenter.) 5. 这个观点是伤害其他人，和/或感受到对他们的控制。(这是一种现象，包括网络上有组织的团体/俱乐部，但我认为这只是一小部分，并不适用于评论者。)
Incidentally, when I started skimming that comment, I thought it might be about organizing a non-proprietary, open network, for the same benefits as Apple users get, which could be great. 顺便说一下，当我开始浏览那条评论时，我以为它可能是关于组织一个非专有的、开放的网络，以便获得与 Apple 用户相同的好处，这将是很好的。
I use Apple and Android because I like gadgets and technology and software. I dislike anything proprietary. I am up for doing anything to undermine Apple's proprietary products. If Apple has a proprietary means of telling people they are being stalked by stalking devices that Apple also sells, yes, i will do anything to undermine it. And anyway, it's Apple stalking and telling people they are being stalked, not me. 我使用苹果和安卓，因为我喜欢小工具、技术和软件。我不喜欢任何专有的东西。我愿意做任何事情来破坏苹果的专有产品。如果苹果有一种专有手段告诉人们他们被苹果也销售的跟踪设备跟踪，是的，我会做任何事情来破坏它。而且，不管怎么说，是苹果在跟踪并告诉人们他们被跟踪，而不是我。
Would you be interested in creating a non-proprietary alternative for functionality people desire (with whatever technical and philosophical differences you want)? 您是否对创建一种非专有替代方案感兴趣，以满足人们所需的功能（根据您希望的任何技术和哲学差异）？
Maybe see it as undermining via creating what you see as good, rather than as destroying what you see as bad? 也许可以把它看作是通过创造你认为好的东西来削弱，而不是破坏你认为坏的东西？
That's certainly a more charitable interpretation of their comment than I gave it, perhaps I was unfair though I rather suspect the intent was closer to my reaction than your ideas 这无疑是对他们评论的更宽容的解读，或许我不太公正，不过我更怀疑他们的意图更接近于我的反应而不是你的想法
Text-based communication, especially informal comment text, are obviously pretty terrible at accurately conveying tone and intent. I like to adhere to the “assume good faith” maxim whenever possible, although that’s increasingly difficult in this polarized age of “Roman salutes.” Anyhow, I personally read their comment as something of a tongue-in-cheek chaotic neutral sort of curiosity. 基于文本的沟通，尤其是非正式的评论文本，显然非常糟糕，无法准确传达语气和意图。我喜欢在可能的情况下遵循“假设善意”的原则，尽管在这个“罗马敬礼”的极化时代，这越来越困难。无论如何，我个人将他们的评论视为一种调侃式的混乱中立的好奇心。
> "I like to adhere to the “assume good faith” maxim whenever possible" “我喜欢在可能的情况下遵循‘假设善意’的原则。”
That's generally my policy too, when I wrote the comment I felt confident that I wasn't missing a less mean-spirited interpretation that they may have meant instead, but it's possible my mood this evening clouded my judgement. If I was wrong, apologies to fsckboy 这通常也是我的原则，当我写下评论时，我感到自己没有错过他们可能意味着的较不刻薄的解释，但今晚我的情绪可能影响了我的判断。如果我错了，向 fsckboy 道歉。
Maybe an off-the-cuff idea, in curiosity and good-natured mischievousness, and then minutes later, while thinking it through, would realize, oh yeah, that could be bad, whew, sigh, and that's humbling. 也许只是一个随意的想法，出于好奇和友好的顽皮，然后几分钟后，在思考时，会意识到，哦，是的，那可能不太好，唉，叹气，这令人谦卑。
Then sometimes the thinking leads from there, maybe from a bad idea to a good idea, or maybe realizing a related thing in the world is also secretly bad, and can we address that. 然后有时思考从那里延伸，也许从一个糟糕的想法转向一个好想法，或者也许意识到世界上某个相关的事物也是秘密的不好的，我们能否解决这个问题。
At this point the best thing is mave sure this is well known. If he has the idea you can bet evil [china, north korea, russia... should come to mind] will too. If I do it I'm harmless but it forces apple to react. If evil does that they will also hide their tracks and so we are less likely to find out while they do their harm. 在这一点上，最好的事情是确保这一点广为人知。如果他有这个想法，那么你可以打赌邪恶 [中国，北朝鲜，俄罗斯……] 也会想到。如果我这样做，我是无害的，但这会迫使苹果做出反应。如果邪恶这样做，他们也会掩藏他们的踪迹，因此我们不太可能在他们造成伤害时发现。
An interesting thing to note from the article is that this isn't just a garden variety jailbreak/adversarial interoperability with a BLE protocol. It lets you turn someone else's device into an airtag, then track its location. 文章中有一个有趣的观点值得注意，那就是这不仅仅是一个普通的越狱/对抗性互操作 BLE 协议。它让你可以将别人的设备变成一个 airtag，然后追踪其位置。
> In addition, we appreciate the help from the Apple Security Team for their prompt responses and acknowledgement. Apple recently released patches in iOS 18.2, visionOS 2.2, iPadOS 17.7.3, 18.2, watchOS 11.2, tvOS 18.2, macOS Ventura 13.7.2, Sonoma 14.7.2, Sequoia 15.2 to fix the vulnerability. However, the attack remains effective as long as unpatched iPhones or Apple Watches are in the proximity of the computer running our trojan. 此外，我们感谢苹果安全团队的及时回应和确认。苹果最近在 iOS 18.2、visionOS 2.2、iPadOS 17.7.3、18.2、watchOS 11.2、tvOS 18.2、macOS Ventura 13.7.2、Sonoma 14.7.2、Sequoia 15.2 中发布了补丁以修复该漏洞。然而，只要未打补丁的 iPhone 或 Apple Watch 在运行我们木马的计算机附近，攻击仍然有效。
Seems like a pretty bad vulnerability to just hope 1.5B iPhones alone update soon enough. I know people still on iOS 17/16... All of them are now complicit. 似乎这是一种相当严重的漏洞，只希望 15 亿部 iPhone 能尽快更新。我知道还有人使用 iOS 17/16……他们现在全都变得同谋了。
But I'm happy to see my state represented in security research :) 但我很高兴看到我的州在安全研究中有所代表 :)
Actually, very much yes. The device to be tracked needs to be exploited somehow in order to run the code to advertise its existence via BLE. 实际上，非常需要。要被追踪的设备需要以某种方式被利用，以便运行代码通过 BLE 广告其存在。
FTA's "Architecture of nRootTag": FTA 的"Architecture of nRootTag":
> (1) The Trojan code runs on the computer to be tracked. (1) 木马代码在被追踪的计算机上运行。
Seems like a good way to physically pin down where a hacked computer may be located. Could be useful for people like ransomware authors who infect devices all over the world. 似乎是一个很好地物理定位被黑客攻击的计算机可能位置的方法。这对像勒索软件作者这样到处感染设备的人可能很有用。
Nothing new, really. Apple created a worldwide network of location scanning devices and this is just leveraging the power Apple already has. The genie is out of the bottle now, and live location tracking has become almost trivial. 没什么新鲜的。苹果创建了一个全球范围的定位扫描设备网络，这只是利用了苹果已经拥有的力量。魔 genie 已经放出，实时位置追踪变得几乎微不足道。
So, seeing how this is able to allow a device to be tracked without an alternative bluetooth stack: could the Find My network be (ab)used to geolocate devices without a GPS receiver? If a device broadcasts BLE packets and then queries its own location, that should give a pretty accurate location, shouldn't it? Might save some power if the 5G antenna is active already anyway, assuming there's an Apple user nearby. 所以，看到这能够让设备在没有替代蓝牙协议栈的情况下被追踪：Find My 网络是否可以被（滥用）用于没有 GPS 接收器的设备地理定位？如果一个设备广播 BLE 数据包然后查询自身位置，这应该能给出相当准确的位置，不是吗？如果 5G 天线已经处于活动状态，假设附近有一个苹果用户的话，这可能会节省一些电力。
I get that this is an attack, but if I could get this on my own non-apple bluetooth devices that would be really convenient. 我明白这是一次攻击，但如果我能在我自己的非苹果蓝牙设备上实现这一点，那将非常方便。
The problem with this exploit is it needs something on the device that sends out BLE packets. 这个漏洞的问题在于它需要设备上有能够发送 BLE 数据包的功能。
This is hardly the problem that it's made out to be. 这 hardly 不是被认为的问题。
Excellent PR team - every other site reporting makes it sound like they broke FmF. but with a process on the device the device has already been pwnd. 优秀的公关团队 - 其他所有网站报道都让人听起来像他们破坏了 FmF，但在设备上有一个流程，设备已经被 pwnd 了。
It's a matter of time before advertising SDKs within any ad-supported apps will start leveraging this to geolocate users without additional permissions. Especially for apps that already have location permissions (something as simple as a weather app) this will hardly be noticed. 在任何支持广告的应用中，广告 SDK 利用这一点进行用户地理定位只是时间问题，而不需要额外的权限。尤其是对那些已经拥有位置权限的应用（像天气应用这样的简单应用），这几乎不会被注意到。
>It's a matter of time before advertising SDKs within any ad-supported apps will start leveraging this to geolocate users without additional permissions. 在任何支持广告的应用程序中，广告 SDK 利用这一点来在不需要额外权限的情况下定位用户只是时间问题。
They still need bluetooth permissions, which is going to be sus for your average flashlight/weather/game app. 它们仍然需要蓝牙权限，这对普通的手电筒/天气/游戏应用而言会有些可疑。
>Especially for apps that already have location permissions (something as simple as a weather app) this will hardly be noticed. >特别是对于已经拥有位置权限的应用程序（例如天气应用程序），这一点几乎不会被注意到。
If the app already has location permissions, why would they need to pull off this attack? They get the user's location directly. 如果应用已经拥有位置权限，那么他们为什么还需要进行此攻击呢？他们可以直接获取用户的位置。
Won't work on iOS. An app cannot simply get the local MAC address on iOS. Privacy reasons. And trying all the (2^8)^3 options will also not work - for power reasons you'll be quickly throttled. 在 iOS 上无法工作。应用无法直接获取 iOS 上的本地 MAC 地址。出于隐私原因。尝试所有（2^8）^3 种选项也不会有效——出于功率原因，您会很快被限制。
You don't need MAC address - you just need the iPhone to broadcast specific BLE advertising packet/payload. 你不需要 MAC 地址 - 你只需要 iPhone 广播特定的 BLE 广告数据包/有效载荷。
Using Core Bluetooth API it is trivial, but you need to either:
a) create an app that does it and user has to download it
b) modify SDKs existing in apps (e.g. Ad SDKs) 使用 Core Bluetooth API 很简单，但您需要：a) 创建一个执行此操作的应用程序，用户必须下载它；b) 修改现有应用中的 SDK（例如，广告 SDK）。
Also turning app/phone into a "BLE beacon" is only possible when app running in the foreground (on iOS). 将应用程序/手机也变成“BLE 信标”仅在应用程序在前台运行时（在 iOS 上）才可能。
Please read the original source again. You need to KNOW (or guess) own mac address as it becomes a part of the key. 请再次阅读原始来源。您需要知道（或猜测）自己的 MAC 地址，因为它是密钥的一部分。
Knowing the MAC makes the attack reasonable - let's say 5 hours compute for 3080Ti. 知道 MAC 使得攻击变得合理 - 比如说 3080Ti 需要 5 小时的计算时间。
Not knowing the MAC makes it exponentially harder. You can still "guess" it, but the search-space is vast and that would take bazillion-years. 不知道 MAC 地址使得事情变得 exponentially harder。你仍然可以“猜测”它，但搜索空间非常广泛，这将需要数十亿年的时间。
So to attack iOS device:
- user has to download the app
- app has to broadcast fake BLE
- some other devices (e.g. Android/RasPi would need to pickup that MAC and pass it to you 所以要攻击 iOS 设备：- 用户必须下载这个应用 - 应用必须广播假 BLE - 其他一些设备（例如 Android/RasPi）需要拾取那个 MAC 并传递给你
- you need code execution on the victim device - 您需要在受害设备上执行代码
- you need internet connectivity - 你需要互联网连接
- you need bluetooth permission - 你需要蓝牙权限
- if the victim device has GPS itself, then this attack is pointless because you may as well just use that directly. - 如果受害者设备本身有 GPS，那么这次攻击毫无意义，因为你不如直接使用那个。
This won't really affect OpenHaystack in any meaningful way. The only additional thing this paper shows is that it is possible to brute-force the key necessary to broadcast a valid FindMy BLE message, without needing to change the advertised MAC address (which generally requires root privileges). If you wanted to turn your own devices into Airtags, you could just change the advertised MAC with root permissions to skip the brute-force step. 这不会以任何有意义的方式影响 OpenHaystack。该论文唯一额外展示的是，可以通过暴力破解必要的密钥来广播有效的 FindMy BLE 消息，而无需更改广告的 MAC 地址（这通常需要 root 权限）。如果您想将自己的设备变成 Airtags，您可以只需使用 root 权限更改广告的 MAC，以跳过暴力破解步骤。
For those who don't want their iPhone participating in the Find My network, from my understanding, turning off iCloud disables the sharing of BLE advertisements. 对于那些不想让他们的 iPhone 参与 Find My 网络的人，据我了解，关闭 iCloud 会禁用 BLE 广告的分享。
Nice. I have some Chipolo trackers but the tracking is pretty bad compared to air tags. Would this approach let me make them trackable via Apple's network too? 很好。我有一些 Chipolo 追踪器，但与 AirTags 相比，追踪效果相当差。这种方法能让我通过苹果的网络让它们可追踪吗？
Only if you manage to flash custom firmware on them. But there's already been many efforts on creating firmware for devices costing only a few bucks each, so that's probably easier. 只有在您成功刷入自定义固件后才能实现。但是，已经有很多努力在为每个仅花费几美元的设备创建固件，因此那可能更容易。
I wonder if Apple will keep this open out of the kindness of their heart. Or all these unintended uses will result in them locking down their network. 我想知道苹果是否出于善心会保持这种开放性。或者所有这些意想不到的使用会导致他们封闭自己的网络。
I guess all my Apple devices are looking for this and sharing it to Apple and wonder how much that data adds up. 我想我所有的苹果设备都在寻找这个并将其分享给苹果，不知道这些数据加起来有多少。
They already fixed it in recent updates, but many non-updated devices will remain around for quite a while. It’s not fixable server-side. 他们已经在最近的更新中修复了它，但许多未更新的设备将会存在相当长一段时间。这无法在服务器端修复。
... and an Apple Account with an SMS-verified telephone number. ... 和一个带有短信验证电话的苹果账户。
And of course by requesting a result, you're letting Apple know that your Apple Account cares about a particular Airtag. 当然，通过请求一个结果，您是在让苹果知道您的苹果账户关心某个特定的 Airtag。
All the FindMy anonymity claims go out the window as soon as you actually lose something and want to find it. It's only anonymous if you don't query the network. 所有 FindMy 的匿名性声明在你真正丢失某样东西并想找到它时就不复存在了。只有在你不查询网络时它才是匿名的。
Actual Airtags rotate their keys on a daily basis (when in lost mode), and Apple can't predict those keys. Theoretically they could tell that you're looking for a tag reported by devices x y and z, but the actual locations are encrypted. 实际的 Airtags 每天会轮换它们的密钥（在丢失模式下），而 Apple 无法预测这些密钥。理论上，他们可以知道你正在寻找由设备 x、y 和 z 报告的标签，但实际位置是加密的。
Does anyone know if the fix for this vulnerability removes the ability to use your own arbitrary BLE devices on the FindMy network? I haven't personally looked through the technical details of how that has been accomplished in the past, but it sounds up front like it might. 有谁知道这个漏洞的修复是否会移除在 FindMy 网络上使用自己任意 BLE 设备的能力？我个人并没有仔细查看过过去是如何实现的技术细节，但乍一听起来似乎会这样。
> This work was supported in part by the US National Science Foundation (NSF) under grants CNS-2304720, CNS-2310322, CNS-2309550, and CNS-2309477 本研究部分得到了美国国家科学基金会（NSF）的资助，资助编号为 CNS-2304720、CNS-2310322、CNS-2309550 和 CNS-2309477
People will still be finding these vulnerabilities. Just fewer of them, and fewer of them from within the United States, and fewer of them publishing the details publicly. 人们仍然会发现这些漏洞。只是发现的人数更少，来自美国的人数更少，公开发布详细信息的人数也更少。
My gut says a lot of vulnerabilities disclosed like this had probably already been found by those people that won’t disclose them publicly. Programs that expose these vulnerabilities, funded by countries that can afford it, are probably the biggest stopgaps keeping it mostly in the realm of sketchy nation-state intelligence agency shenanigans rather than organized crime with ransomware-gang-level technical savvy and terrorist organizations. The frustrating thing is that there’s no way you can guarantee that some future problem would have been prevented by a program like this — it’s just good societal-level stewardship of our communications infrastructure. People that consider it reasonable for regular people to defend themselves against things like this without societal support and guidance are delusional. Beyond that, if we think we’re going to maintain dominance in the digital space, removing our collective investment in figuring out what that entails based on a dubious assumption that private industry will pick up the slack unprompted is as penny wise and pound foolish as you get. 我直觉认为，像这样披露的许多漏洞可能早已被那些不会公开披露漏洞的人发现。那些暴露这些漏洞的程序，由能够负担得起的国家资助，可能是将其大部分保持在可疑国家情报机构阴暗行为领域而非拥有勒索软件团伙级技术熟练度和恐怖组织的有组织犯罪的最大权宜之计。令人沮丧的是，没有办法保证将来某个问题会被这样的程序预防——这只是我们通信基础设施的良好社会层面的管理。认为普通人可以在没有社会支持和指导的情况下为自己抵御这些事物是合理的人是妄想。此外，如果我们认为能够在数字领域保持主导地位，基于一个可疑的假设即私人行业会主动承担责任而撤回我们在弄清楚这涉及什么方面的集体投资，就如同只算小账而忘记大账一样愚蠢。
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.
Interesting. They seem to be abusing a hole where Apple wasn't confirming that the broadcast addresses were valid for tags (ie: "random static" addresses rather than public ones). 有趣。他们似乎在利用一个缺口，因为苹果并没有确认广播地址对于标签是有效的（即“随机静态”地址而不是公共地址）。
The BLE broadcast stores part of the lost message public key in the advertising message's address, and part of it in the payload -- they are just using a "normal" BLE address and then reverse-engineering a key from that. BLE 广播将丢失的消息公钥的一部分存储在广告消息的地址中，另一部分存储在有效负载中——它们只是使用“普通”的 BLE 地址，然后从中反向工程出一个密钥。
> The Find My network specification mandates the use of ran-
dom static addresses for advertising lost messages. However,
our research reveals that public addresses, resolvable private
addresses, and non-resolvable private addresses can also serve
this purpose without any issues. This implementation vulner-
ability is exploited by our attack to track Linux, Android, and
Windows systems. > Find My 网络规范要求使用随机静态地址来广播丢失消息。然而，我们的研究表明，公共地址、可解析的私有地址和不可解析的私有地址也可以在没有任何问题的情况下实现这一目的。我们的攻击利用这一实现漏洞来跟踪 Linux、Android 和 Windows 系统。
> Our work uncovered a vulnerability in the Find My ser-
vice that permitted all types of BLE addresses for advertis-
ing. Exploiting this vulnerability, we proposed a novel at-
tack, nRootTag, which transforms a Bluetooth device into an
“AirTag” tracker without requiring root privilege escalation.
By utilizing over a billion active Apple devices as finders,
the attack is able to accurately track user devices. Through
rainbow table-based offline key search or GPU-accelerated
online key search, an infected computer can be quickly turned
into a tracker. Notably, the online key search cost does not in-
crease as the number of tracked devices grows. The evaluation
shows that the attack is effective across various devices, in-
cluding desktops, laptops, smartphones, and IoT devices, and
worked on Linux, Windows, and Android platforms. We also
discussed how the attack could be extended to track Apple
devices. 我们的工作揭示了 Find My 服务中的一个漏洞，该漏洞允许所有类型的 BLE 地址用于广告。利用此漏洞，我们提出了一种新颖的攻击方式 nRootTag，它可以将蓝牙设备转变为“AirTag”跟踪器，而无需提升根权限。通过利用超过十亿的活跃 Apple 设备作为查找器，该攻击能够准确跟踪用户设备。通过基于彩虹表的离线密钥搜索或 GPU 加速的在线密钥搜索，受到感染的计算机可以迅速转变为跟踪器。值得注意的是，在线密钥搜索的成本并不会随着被跟踪设备数量的增加而增加。评估显示，该攻击在各种设备上都是有效的，包括台式机、笔记本电脑、智能手机和物联网设备，并且在 Linux、Windows 和 Android 平台上均可运行。我们还讨论了如何将该攻击扩展到跟踪 Apple 设备。
> they are just using a "normal" BLE address and then reverse-engineering a key from that. 他们只是使用一个“正常”的 BLE 地址，然后从中反向工程出一个密钥。
It's really clever - the BLE spec limits message size, so Apple uses the BLE address as part of the message (the first part of the public key). 这真的很聪明 - BLE 规范限制了消息大小，因此苹果将 BLE 地址作为消息的一部分（公钥的第一部分）。
But since the public address of a BLE chip has 24 bits of "Company ID" (similar to MAC addresses I guess?), and the registry records are public, they were able to precompute a bunch of public/private keypairs. 但是，由于 BLE 芯片的公共地址有 24 位"公司 ID"（我想这类似于 MAC 地址？），而注册记录是公开的，他们能够预先计算出一堆公钥/私钥对。
So whatever happened to Big Tech's eNd TO EnD enCRYptIOn? If I had to guess, this was an intentional backdoor that was just discovered. 所以大型科技公司的端到端加密发生了什么？如果我要猜测，这是一个刚被发现的故意后门。
这是我的简要总结：
Apple devices listen for BLE advertisements of a certain form to indicate a "Find My" network lost device.
Apple 设备监听特定形式的 BLE 广告，以指示 "查找我的" 网络丢失的设备。
The lost device advertisements mainly contain the public key part of a key pair.
丢失设备广告主要包含密钥对中的公钥部分。
The public key does not fit in the in payload of the advertisements, so it is stuffed into the address field. Edit: Only 46 bits of the full 224 bit public key is stored in the address field.
公钥无法适应广告的有效负载，因此被填充到地址字段中。编辑：地址字段中仅存储完整 224 位公钥的 46 位。
In general anyone can make a "lost device" advertisement as demonstrated by OpenHayStack[1]. The requirement is the address field needs to be fully controllable.
一般来说，任何人都可以制作“丢失设备”广告，如 OpenHayStack[1]所示。要求是地址字段需要完全可控。
BLE advertisements have a header that indicates what kind of address is present (specified by 3 bits: Public, NRPA, RPA, Random Static). The lost device advertisements are supposed to be "Random Static", but the researchers found that Apple "Find My" listeners ("finders") will accept advertisements for any address type.
BLE 广播具有一个头部，指示存在何种地址（由 3 位指定：公有地址、NRPA、RPA、随机静态）。丢失设备的广播应该是“随机静态”，但研究人员发现苹果的“查找我的”监听器（“查找者”）将接受任何地址类型的广播。
They use this fact to generate the private key part of a public key that matches an existing host adapter BLE address. The host adapter BLE address cannot generally be changed unless user has root/superuser privileges. This step is computationally expensive. However, private keys can be precomputed (rainbow tables) because a large chunk of the address is a manufacturer code (OUI).
他们利用这一事实生成与现有主机适配器 BLE 地址匹配的公钥的私钥部分。一般情况下，主机适配器 BLE 地址无法更改，除非用户具备 root/superuser 权限。这一步计算代价很高。然而，私钥可以预计算（彩虹表），因为地址中的一大部分是制造商代码（OUI）。
[1] https://github.com/seemoo-lab/openhaystack
reply