Issue with IOS 17

[shiprec]

Are you all seeing reporting issues from devices that have upgraded to IO17? I haven't seen any updates come through since my phone upgraded but when I go back to 16 it works fine.

[biemster]

I see you opened a similar issue in the openhaystack repo, but both of these projects have nothing to do with iOS. Can you elaborate exactly what works fine on 16?

[shiprec]

Apologies I wasnt sure where the right place would be to ask this. The FindMy network was working well using OpenHaystack, ie we were able to pull in location reports but I noticed as soon as my phone (and others) upgraded to IOS17, the updates from the airtag clones stopped coming in. I wasnt sure if you or others were seeing the same issue.

[biemster]

It's possible that apple ids connected to iOS17 require a different API to retrieve the reports. Do you have an error message of any kind from either openhaystack or the code in this repo?

[shiprec]

I will ask my partners to see if there are any error messages and get back to you.

[redex557]

I can kind of confirm this issue, without any specific proof to confirm it so this might be biased. Last week I spend some time setting up new nrf51 devices and testing some alternative firmware with key rotation. Some devices never showed up and one took multiple hours to get a single report. All this while (at least) two iPhones where close, both running the latest iOS 17 update.

[biemster]

That's very worrisome, maybe iOS17 can distinguish between real and cloned airtags?

[shiprec]

Yeh there are no error messages, we just aren't getting any reports from IOS 17 devices...

[biemster]

I'd like to keep this open if you don't mind, if future iOS and macOS devices know how to identify fake airtags this needs to be fixed if at all possible.

[biemster]

Also the pypush discord is reporting this issue

[Itheras]

Could this have something to do with this ? (https://github.com/seemoo-lab/openhaystack/issues/49#issuecomment-825186095) I wonder what that byte is could he just be talking about the status byte or something different. And this other piece of information (https://github.com/seemoo-lab/openhaystack/pull/225#issue-2023652959) I am testing this to see if there is any diference.

[biemster]

That's a great find @Itheras ! I was not aware of either of those, but they seem easy to implement. Having a micropython implementation is still high on my list, maybe it's time to finish that so I can easily experiment with these suggestions.

[Systm21]

@Itheras @biemster Are there any updates on this? it is noticeable that far fewer reports are coming in than before.

[biemster]

No updates yet on this, also I lack an iOS17 device to do any testing..

[loganmimaroglu]

I have been using OpenHaystack's HCI code for a RPi4B and have 2 iPhone 14 Pro Max's running iOS 17.1.2 and iOS 17.2.1 that I've placed near the device. I was getting, on average, 12 reports per 24 hours. I honestly thought this was quite bad but it is > 0.

The MR that @Itheras links to (https://github.com/seemoo-lab/openhaystack/pull/225#issue-2023652959) improved this quite a bit. The changes to the HCI code lead to me getting around 72 reports per 24 hours. This did change the transmission frequency from 2000 ms to 200 ms which I suspect could be the primary contributing factor... I will need to test more.

[Itheras]

Nothing on my end i dont have a computer with me until after the 25th but if someone can check i was reading apples documentation it says we should be setting the Hint byte to the value of the 5th byte of the mac address I believe we always setting the Hint byte to 0. Can someone check i am on mobile if not I'll check after Christmas 😅.

[loganmimaroglu]

Nothing on my end i dont have a computer with me until after the 25th but if someone can check i was reading apples documentation it says we should be setting the Hint byte to the value of the 5th byte of the mac address I believe we always setting the Hint byte to 0. Can someone check i am on mobile if not I'll check after Christmas 😅.

For the Lenze st17h66 source this appears to be true.

The HCI code I'm running also does this:

@staticmethod
def advertisement_template():
    adv = ""
    adv += "1e"  # length (30)
    adv += "ff"  # manufacturer specific data
    adv += "4c00"  # company ID (Apple)
    adv += "1219"  # offline finding type and length
    adv += "00"  # state
    for _ in range(22):  # key[6:28]
        adv += "00"
    adv += "00"  # first two bits of key[0]
    adv += "00"  # hint
    return bytearray.fromhex(adv)

[Itheras]

It appears there are more differences than we thought, and any one of these could be causing the issue. I’ve attached the expected content. @loganmimaroglu Thank you. Also great that you are seeing a positive result we should confirm if that is the actual fix.

[Systm21]

For the Lenze st17h66 source this appears to be true.

Have you tried this? will the tags then also be recorded again under ios17?

[Itheras]

@Systm21 Well there is 3 things to check the AdvertisementType, the status byte "the first 5bits have values that are expected" and the Hint that should not be 0. It seems changing advertising type had good results but we still need to confirm and the other 2 needs testing. I will test after the 25th i am on mobile now 😅. Merry Christmas everyone.

[Systm21]

That sounds like a solution, hopefully it won't affect the undercover mode of our tags. If it does, you can still keep the project alive. It would be a shame if it was already over before it had really started (where the first macless solutions are available).

[Itheras]

I think I can call this confirmed the problem is the advertisement type. would like if someone else can also confirm but we already have the same good results from @loganmimaroglu

[Systm21]

What exactly is this hint byte doing that seems to be the problem?

[Itheras]

@Systm21 I am not sure but it may be that is not the issue after all. I noticed a difference changing the advertisement type from unconnectable scannable undirected to connectable scannable undirected I have not tested the hint or status byte much still. we should look at all 3 factors to future proof I am just a little busy at the moment.

[biemster]

Isn't the increase @loganmimaroglu sees coming from the broadcast freq change to 5Hz?

[igrowstuff]

I have tried the linked HCI code using my RPI4 and I get no reports on my two iPhone 14 devices running 17.2.1. Only time I ever get any reports is if I turn the Bluetooth on, on my Mac.

[loganmimaroglu]

I have tried the linked HCI code using my RPI4 and I get no reports on my two iPhone 14 devices running 17.2.1. Only time I ever get any reports is if I turn the Bluetooth on, on my Mac.

I didn't even think about my Mac, oof. Let me test again...

[Itheras]

@biemster Yeah can confirm changing advtype has no effect i saw more reports because neibor had family visiting.

Now trying changing status and hint.

[Systm21]

I think it has something to do with our stealth mode. Apple is quite behind on the anti-stalking thing and I don't think they're going to completely change the basic system now.

[igrowstuff]

I think it has something to do with our stealth mode. Apple is quite behind on the anti-stalking thing and I don't think they're going to completely change the basic system now.

Maybe so. However I don't really understand why you would only enforce that on iOS 17. Other than the tag not being registered to an apple account the tags aren't stealth are they? Don't they just emulate a device in its separated state? The underlying system must be the same as it still works on older iOS and the latest macOS

[Itheras]

@igrowstuff Apple doesn't know if a tag is registered to an account or not. In function the lost mode advertising key tells apple nothing by design . It just gets uploaded. They must be doin a extra check with the data received that doesn't match what is expected.

[igrowstuff]

I have tried setting the hint to key[5] and modifying the status byte and can't seem to generate any other reports.

Maybe there is an updated protocol document available? If there is I do not have access to it

[humpataa]

No updated protocol document, date of last change is May 18, 2022.

[biemster]

@humpataa To comment on your edited message I doubt that ios17 has an extra check on the validity of the broadcasts it sees in terms of registered keys, since such a check is much easier implemented server side and would immediately work for all versions of ios and macos. The fact that only ios17 iphones (or also ipads?) are able to discern them leads me to believe there is something we are missing in the details of the BLE broadcast. I really hope that they are not also listening for the UWB stuff a real AirTag sends, because that will be very difficult to emulate.

[humpataa]

@biemster after thinking about all this again, I believe you are right: nothing has changed really, but iOS devices now obviously check something that hasn't been taken into account before. I am actually using the full Status byte and will try to stick to the document instead (using only bit 6-7 and keeping the others untouched). Same with the Hint: what does "Byte 5 of the Bluetooth address" mean? The MAC address? It is always set to 0 in my code ...

[igrowstuff]

I too thought about the UWB broadcasts. I don't think all third party authorised airtags have the UWB capability so would assume they would also break on iOS17

[humpataa]

Could someone point me to some document how AirTags make use of UWB? I have my doubts because I cannot find anything about this in FindMy network specification mentioned above.

[humpataa]

... using the full Status byte and will try to stick to the document instead (using only bit 6-7 and keeping the others untouched). Same with the Hint: what does "Byte 5 of the Bluetooth address" mean? The MAC address? It is always set to 0 in my code ...

To quote myself: I have checked what my real AirTag advertises (separated) and set that as fixed Byte 2 (0x08) and set Byte 26 (Hint) to MAC addresses last byte. The device is advertising for half an hour and it indeed showed up in reports again! Unfortunately, I cannot make sure it is my own iPhone (iOS17) "catching" it, since it is quite a close neighborhood here ...

[Systm21]

To check the UWB stuff: You can clone bluetooth beacons with "nrf connect" on android for example. does anyone have an airtag or official licensed product, that can be cloned and then remove the batterys? If the reports come in without a problem the UWB stuff doesn't matter.

I haven't had a close look at nrf connect yet, but it may be that it is better to play with the individual bytes than to permanently flash/reflash new tags.

[malmeloo]

To check the UWB stuff: You can clone bluetooth beacons with "nrf connect" on android for example. does anyone have an airtag or official licensed product, that can be cloned and then remove the batterys? If the reports come in without a problem the UWB stuff doesn't matter.

I haven't had a close look at nrf connect yet, but it may be that it is better to play with the individual bytes than to permanently flash/reflash new tags.

Android will randomize the BLE address when advertising, and since the public key is encoded in that address it will be different from the cloned airtag. That said, I think it should still be possible to fetch those reports if you know what address it is using, as you only need the hash of that public key; you just won't be able to decrypt them. Have you already tested this by any chance?

[Systm21]

I'm not into it that much, it was just an idea.

[malmeloo]

Ah gotcha, thought you'd tried it before. It's some interesting food for thought though, I would kill to have my phone act as a beacon...

[humpataa]

To check the UWB stuff: You can clone bluetooth beacons with "nrf connect" on android for example. does anyone have an airtag or official licensed product, that can be cloned and then remove the batterys? If the reports come in without a problem the UWB stuff doesn't matter.

Interesting idea! I have both Android and iPhone with NRF Connect installed. And an original AirTag, an official Clone (Maginon Smart Tag) and of course my fake tags. Maybe I'll find some time tomorrow.

Apart from that, I have checked recent update details of iOS and it seems they have indeed made some changes to FindMy, claiming security fixes of course. So I have updated my iPhone to the latest it offered (17.2.1), refreshed two of my devices: one with my older code, one as close to the specification as possible (bits and hint). Both show up in the reports, but again, I cannot make sure it is my own phone doing this ...

I haven't had a close look at nrf connect yet, but it may be that it is better to play with the individual bytes than to permanently flash/reflash new tags.

I am programming my devices using Espruino Javascript, so I don't have to flash all the time, makes it easy to try things.

[humpataa]

Tried cloning an AirTag using Android NRF Connect: it is not being recognised, at least FindMy app on iPhone cannot see it anymore (neither nearby nor separated). The advertising does not look good anyway, it uses a public key (cannot change) which surely doesn't match specification. I will try disabling bluetooth on my phone and see if there is someone around reporting my devices or it is depending on mine overnight.

[Systm21]

You told us, that you have a possible working Tag with ios17. How long does it take to retrieve the first reports? Maybe you can switch off your phone for a longer period to validate it... (Dont know if switching off bluetooth is enough)

[humpataa]

Must have been someone in the neighborhood. I have made several tests today, setting type (scannable / connectable), bits of status byte, correct hint byte, even disabled name and set advertising to 2000ms – just like a real AirTag. Having my phone (iOS17), a MacBook and an iMac around does not result in reports. As soon as I leave the office, drive a few miles, reports come up – my tags are recognised. So I guess with more and more iPhones updating reports will get fewer and fewer making fake tags useless. I'm out of ideas, still doubt it is UWB however.

[Itheras]

@humpataa yeah is definitely not related to UWB since I am testing with some find my compatible tags that don't use it and they work normally. I am starting to look into CSA mode.

[Systm21]

Is it maybe possible, that our keys can be filtered out somehow and then be locked out from the system?

[humpataa]

Is it maybe possible, that our keys can be filtered out somehow and then be locked out from the system?

My first idea was that newer iPhones send all the keys of their bound AirTags to the server. Even from older tags. That way, Apple's server now knows what reports to reject, because our tags never get registered. Older phones just keep sending without checking the validity first, resulting still in reports now and then. So our keys are not blocked, just not validated.

But as @biemster already said, this doesn't really make sense. It would make problems because every AirTag would need a different set of keys coming from the factory – and considering the high number of AirTags & certified clones, this sounds highly unlikely. Could be that AirTags generate their set of keys when activated (or even get them from the owners phone) and it sends them to the server to make them valid. But afair there is nothing about this in the technical specification making it unlikely as well.

Since they are working with Google to create a joint FindMy network, this might be a reason for changes. Something with recognising tags must have changed that hinders iOS17 to send locations.

OR – I doubt it, but still hope – it is just Apple's fault: they somehow screwed it up when adding latest AirTag features like sharing etc. – after all: are we REALLY SURE original AirTags still work with iOS17 phones? It may just seem so because there are enough older phones around. This could even make it hard to identify that iOS17 actually HAS a problem sending locations with ALL tags. It DEFINITELY has no problem recognising tags in general: I was testing key rotation around Christmas (already having iOS17) and my phone was telling me there may be some tag that does not belong to me, so the stalking alarm still works.

[biemster]

I think we already discussed this, but the only validated keys hypothesis should be fairly straightforward to test by having a fake tag sending out a working airtag's broadcast right? I know on android we cannot set the bluetooth mac anymore, but the ESP32, st17h66 or the linux hci script should be able to send out the exact public key.

We might not even need to own an airtag, but just catch one in the wild and wait for the key to roll and start sending that broadcast again. (if that works it will confuse the actual owner of the airtag though, so let's not go overboard with that)

I'm still quite convinced that any key blocking or validating would be done server side, and not through a software update on specific devices.

[Itheras]

@biemster I will test that today. but I am not sure how that would work how can they validate when most of the phones out there are old or in older software versions. newer phones won't have nothing to validate against since those older phones and firmwares don't upload the necessary information do even do a check . so anyone under ios17 would have findmy experience severely impacted as time goes on.