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]

@Itheras great! I'm not sure if I understand the rest of your comment though, I tried to explain my point of view that I find it unlikely that the keys are checked for validity now. That's your opinion too right? I highly suspect that we are missing a bob or a bit in our advertisement.

[Systm21]

Maybe @adamcatley can help us with our problem, themes like he is the right contact person for our problem.

If anyone can help us, it's him.

Reasearch from Adam

[malmeloo]

Do AirTags also expose the Find My service UUIDs while in separated state? I have a protocol spec from 2020 which says that the they must be exposed while in pairing state, but I don't think it says anything about it for the other states. It could be that those UUIDs are always exposed - how else do you get a lost airtag to make a sound? Maybe iOS 17 just adds an additional check to see whether those UUIDs are visible before uploading the report.

I've written a utility script here that scans for nearby devices and shows what are essentially all identifying data points, at least to my knowledge. I don't own any real AirTags myself, but it should include the UUIDs in its output. Maybe someone with a real tag can test it :)

[humpataa]

Do AirTags also expose the Find My service UUIDs while in separated state? I have a protocol spec from 2020 which says that the they must be exposed while in pairing state, but I don't think it says anything about it for the other states. It could be that those UUIDs are always exposed - how else do you get a lost airtag to make a sound? Maybe iOS 17 just adds an additional check to see whether those UUIDs are visible before uploading the report.

Interesting question. NRF Connect says a separated AirTag offers this:

Generic Access UUID: 0x1800 Generic Attribute UUID: 0x1801 UUID: 7dfc8000-7d1c-4951-86aa-8d9728f8d66c UUID: 7dfc7000-7d1c-4951-86aa-8d9728f8d66c UUID: 7dfc6000-7d1c-4951-86aa-8d9728f8d66c UUID: 7dfc9000-7d1c-4951-86aa-8d9728f8d66c

The 4 longer seem to be Apple specific services, may indeed be used to let the AirTag play a sound (see here). Wether they are essential to iOS17 for sending location packets needs to be tested.

[Systm21]

Apple Tags are a thing to have an Eye on, but i think the Cheap China "Works with Apple Find My" Tags are more interesting at this moment. The cheap ones do not have the UWB stuff and are better to research, i think.

[Systm21]

Interesting question. NRF Connect says a separated AirTag offers this:

Generic Access UUID: 0x1800 Generic Attribute UUID: 0x1801 UUID: 7dfc8000-7d1c-4951-86aa-8d9728f8d66c UUID: 7dfc7000-7d1c-4951-86aa-8d9728f8d66c UUID: 7dfc6000-7d1c-4951-86aa-8d9728f8d66c UUID: 7dfc9000-7d1c-4951-86aa-8d9728f8d66c

The 4 longer seem to be Apple specific services, may indeed be used to let the AirTag play a sound (see here). Wether they are essential to iOS17 for sending location packets needs to be tested.

Interesting point, what if someone adds cloned/randomized UUIDs to a fake tags, from the documentation the 9000 uuid should be the findmy identfier

[malmeloo]

Do AirTags also expose the Find My service UUIDs while in separated state? I have a protocol spec from 2020 which says that the they must be exposed while in pairing state, but I don't think it says anything about it for the other states. It could be that those UUIDs are always exposed - how else do you get a lost airtag to make a sound? Maybe iOS 17 just adds an additional check to see whether those UUIDs are visible before uploading the report.

Interesting question. NRF Connect says a separated AirTag offers this:

Generic Access UUID: 0x1800 Generic Attribute UUID: 0x1801 UUID: 7dfc8000-7d1c-4951-86aa-8d9728f8d66c UUID: 7dfc7000-7d1c-4951-86aa-8d9728f8d66c UUID: 7dfc6000-7d1c-4951-86aa-8d9728f8d66c UUID: 7dfc9000-7d1c-4951-86aa-8d9728f8d66c

The 4 longer seem to be Apple specific services, may indeed be used to let the AirTag play a sound (see here). Wether they are essential to iOS17 for sending location packets needs to be tested.

Interesting! The older protocol spec I found lists different UUIDs, but it does mention that they will change in an updated document. Is anyone willing to share a copy of the 2022 version?

Anyway, I'm hoping that simply exposing those UUIDs should be enough; if the rest of my doc is up-to-date then only one of those services should be accessible to non-owners of the device, and that one only allows for sound control which is an optional feature. Also, it's one thing to just receive broadcasts, but another to actually communicate with the device which would be far less reliable; therefore I think (hope) it's just a matter of tweaking the "public image" of the tag to match the official ones.

I'll see if I can get my hands on a 3rd party tag and have someone pair it for me in the coming days; I think the easiest way to go forward right now is to just clone the BLE address/payload of a real tag and work from there.

[Systm21]

I have read a lot the last hours, just about uuids and what they do... It seems, that they get randomly renewed by the Tag itself (not the identifier part). The good part in this is: The Server doesn't know the random payload of the uuid, so we can fill it with something valid, that comes from an active Airtag (or completely random maybe).

What I also thought about: in ios17 it was introduced that you can now share airtags between iphones. Maybe they need the UUID for this and the blocking of our tags was just a coincidence.

I mean, what interest would Apple have in willfully blocking us? Openhaystack was already big in the press in 2021 and nothing happened. Then there are the extremely cheap itags from the Far East. The licenses can't be that expensive if such a part is already available for ~€4. I'm not deliberately blocking a few tinkerers who are having fun with their findings. I mean, how many people should copy this?

By the way, there are also some people in the apple forum who can no longer find their original airtags after the update to ios17.

[humpataa]

I have tried adding UUID 7dfc9000-.... to the advertising. NRF Connect shows "Apple reserved service", so it is visible. Key advertising and hint byte looking good as well. Not getting noticeably better.

I am sure most (all?) chinese "clones" are not using Apple's network. I have some on my desk looking exactly like AirTags, but are just plain BLE devices, completely useless when they get out of range of the phone.

By the way, there are also some people in the apple forum who can no longer find their original airtags after the update to ios17.

That's what I thought: they may have really screwed it up. It still looks good for many, because old iOS are still around.

[Systm21]

I am sure most (all?) chinese "clones" are not using Apple's network. I have some on my desk looking exactly like AirTags, but are just plain BLE devices, completely useless when they get out of range of the phone.

U told us, that you have an Maginon Tag, this Tag also works with the network and i can give you 100% they all use the findmy network from apple. The Itags must be added in a bit different way, than the fancy airtag popup, but it works also... Not every from this cheap tags supports it, thats right. It must be advertised with "Works with Apple Find My".

please don't put so much hope in NRF Connect, I don't know if the results are really usable. It was just an idea and is completely unvalidated. It's possible that you won't be able to recreate airtags with it.

[humpataa]

Yeah, I use NRF Connect only to check devices. Cloning does not work properly (at least not enough to clone AirTags), so I have checked by altering the code I use with my tags The Maginon I mentioned is an official clone, but many of the chinese are not. You can check here.

[Systm21]

The Chinese ones are official too, so i wrote, that the licences cant be that expensive. They are cool, but not working with Android (as the original Airtags).

I've also seen, that Lenze is offering an FindMy SDK for their Chips, so it should not very difficult for the dealers.

[Itheras]

ok i cloned a Chinese official tag. Something really interesting happened. The cloned tag was visible to the find my app and marked as just seen as the original tag . The status bit was set to 0x20 the app sees this as full battery but reading all the documentation i thought it was supposed to be 0x10. Now the interesting part i left home and left the tag on top of my sonoma mac mini and i get no new reports. So find my updates only while in range. Now i will test with the original when i get back later today.

[Itheras]

@Systm21 yeah they actually offer a all in one solution st17h6x find my is really cheap

[humpataa]

So find my updates only while in range.

That is maybe because is no longer in "separated" mode. Your phone sees it because it is close. But interesting that a clone is considered as real.

Btw, status 0x20 is 0b00100000 ... so that is battery state "00" which means full (see spec excerpt somewhere above).

[Systm21]

@humpataa is your Maginon Tag activated? Can you post the UUID's to compare the difference, or better, can u tell us what the difference is? It must be activated, otherwise it is a different UUID

[Itheras]

@humpataa Definitely just separated mode. I copied the separated adv key from a Chinese but valid tag. I used that key to program a openhaystack tag. Using that separated key find my sees it but only while in range . If i am outside the home and there is no device below 17 or sonoma i dont get any updates in find my app.

[Systm21]

I have another researcher, it seems the uuid is not that random, as i thought.

D20 Forensics

[Systm21]

I told you about my suspicion that the locking out of our clones was possibly a coincidence, because they urgently need the feauture now for sharing the tags. This and Itheras' recent findings are now making more and more sense. The uuid is shuffled when the owner device is not nearby. This is why Itheras was able to recognize the clone as a valid tag. The owner device is nearby, it clones the UUID of the connected tag and passes the information on to the clone accordingly. Logically, the clone then behaves like the original.

It would now be interesting to know what exactly changes in the payload of the uuid (owner nearby/not nearby) and to what extent we can randomize this. I hope we don't need a basic UUID from the server on which everything is based.

The fact that the faketag has not sent any reports could be explained by the fact that it is either currently being seen by your devices or is possibly outputting the uuid of "owner nearby". This may temporarily prevent further reports in order to minimize traffic in the find my network.

[Itheras]

Just want to make sure everyone understands. I removed the battery of the original tag to force lost mode then i copied the adv key. I then kept the original off and only the copy is broadcasting in lost mode the same way openhaystack work no uuids or anything just the adv. the find my app still tracks this tag like it was the original but only while in range. I will now do the same with the original if i can get report while away then definitely we are missing something if it behaves the same way then apple broke something mistakenly.

[Systm21]

You have to involve the UUID, im sure.

[Itheras]

Well i just ran the test with the original chinese but certified tag and no reports. The tag wont update in findmy unless i am in range or there is a phone under ios 17 nearby. Please someone else confirm but it seems ios 17 and up and sonoma are not uploading tag data at all for real or our tags. I ran this test many ways in my home theres is 2 iphones with ios17 and 1 sonoma computer while the registered phone is near there is updates if the tag is in lost mode "turning off the registered phone and then reinserting the battery on the tag" it goes silent i had to take the tag to a gas station after waiting for 2 hour of nothing and in 15 mins i got a new location update. Tested this with the real and with the cloned tag that only had the lost adv key same results on both. I think this is confirmed ios17 and sonoma are borked while dealing with tags in lost mode. I am going to try to catch the traffic from my mac to the upload server maybe idkey is uploaded but messed up in someway.

[Systm21]

I think the advertising Data is more interesting. Where can i get the documentation?

[humpataa]

You'll need a MFi developer account to access the documents.

I am also more and more convinced that iOS17 has a serious problem and it is not our fake tags. Can anyone check iOS17 network traffic if it is actually sending "finder reports" at all? The openhaystack paper says "finder devices" make POST requests to "https://gateway.icloud.com/acsnservice/submit" to deliver encrypted location reports about AirTags and other Apple devices (page 7).

[MrTalon63]

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.

I don't think it would a good move on Apple side, not only cheaper, FindMy compatible tags usually don't include them, UWB also has much lower range, especially in crowded spaces where the 24GHz signal can't pass through people nor bounce around them. It would effectively change airtags pickup range to 5m at best.

[Systm21]

It not belongs to UWB, the cheap and licensed Tags from China do not have any UWB stuff on board.

[MrTalon63]

So, currently, the most suspected culprits are UUIDs and sloppy job done by Apple engineers with IOS17 updates?

[Systm21]

Ios17 has got the feature with the sharing of airtags. If I interpret this correctly from the limited information I have, the UUID plays an important role in this. You have to research the UUID much further and preferably collect and compare recordings of several airtags or itags (licensed Cheap china Tags). I have compared this with the last months/versions of ios, there have always been problems with airtags and the ios updates. I don't see that there is a problem with the os right now.

[Itheras]

@Systm21 I tried using a genuine findmy compatible tag only with ios17 devices i got no reports. No sharing enabled. just a regular authorized third party findmy tag. I live in rural setting all phones around this tag are updated to ios 17 i turned off the phone that registered the tag and left 3 other devices on. Waited for hours no 1 report i have to drive 15 mins to a nearby gas station to start receiving updates.

[shiprec]

@Systm21 are you able to reach out to the manufacturer and ask them if they have an answer for why IOS17 doesnt work with their devices?

[Systm21]

Of course I can, but you can do it just as well. There is not one manufacturer, there are many. And to break that down to Lenze... I don't know what their SDK looks like and to what extent the manufacturers are involved. You can ask someone at Maginon etc., I don't have an iphone or tag, so I wouldn't ask for now.

[ngxson]

Not just these findmy-compatible (clone) tag that have problem. I recently receive much less update from my real Apple AirTag (before it was one report per ~6 hours, now it takes days per report). I started to wonder if apple actually has problem with their servers...

[Itheras]

I am really inclined to believe the problem is with ios17 and Sonoma. I see the same behavior not a single report from ios17 and Sonoma even with real 3rd party tags.

[Itheras]

I have installed a separate certificate in to my Sonoma Mac to decrypt all https traffic I have not seem a single request to (https://gateway.icloud.com/acsnservice/submit) in 2 days I have been looking at the traffic.

[humpataa]

I have installed a separate certificate in to my Sonoma Mac to decrypt all https traffic I have not seem a single request to (https://gateway.icloud.com/acsnservice/submit) in 2 days I have been looking at the traffic.

Have you seen traffic to URL https://gateway.icloud.com/acsnservice/fetch? This one is used to get reports about devices by FindMy app (and openhaystack).

Do you have a phone with iOS16 at hand to check if that one uses the submit / fetch URL?

I have tried watching traffic using Fiddler and I can see the phone making contact to Apple's server to get data about the "friends" tab in FindMy app. But it says "FindMy service unavailable" a few seconds later when it tries to fetch data about devices. When I disable Fiddler proxy, everything is good again. So Fiddler seems to block these requests and I am not sure why ...

[humpataa]

I have installed a separate certificate in to my Sonoma Mac to decrypt ...

Oh btw, this is an iMac or a MacBook? I don't think these submit "finder reports", only iPhones and iPads do.

[Systm21]

@humpataa Are you sure about that? They send out the Findmy signal, just like all other devices and have an internet connection. I would be surprised if they don't forward it to the network.

[humpataa]

@humpataa Are you sure about that? They send out the Findmy signal, just like all other devices and have an internet connection. I would be surprised if they don't forward it to the network.

@Systm21: Yes I am very sure about that. I have a MacBook running Monterey and an iMac running Ventura and only when I switch on bluetooth on my older iPhone iOS16 all locations of devices (original AirTag, official clone and fake tags) get updated.

I have tried watching traffic using Fiddler and I can see the phone making contact to Apple's server to get data about the "friends" tab in FindMy app. But it says "FindMy service unavailable" a few seconds later when it tries to fetch data about devices. When I disable Fiddler proxy, everything is good again. So Fiddler seems to block these requests and I am not sure why ...

@Itheras To quote myself: the reason for not seeing requests to submit / fetch URL as mentioned above maybe because the devices and the FindMy app use "certificate pinning". Adding a trusted certificate to watch HTTPS traffic is not sufficient, the original specific certificate is needed.

Added a couple days later: So I have tested a iOS16 and a iOS17 iPhone with an Apple AirTag and with a fake tag. Both phones are contacting Apple's server gateway.icloud.com on a regular basis (bluetooth turned on, display off, doing "nothing", just laying beside the tags) for hours. They make contact every few minutes, iOS16 at least every 20 minutes, iOS17 at least every 10 minutes. Because of "certificate pinning" I cannot say what URL they request.

However: when iOS16 is on, I get regular reports for my fake tag and regular updates in FindMy app for the original AirTag (on a third phone far away to be "separated" and not connected with my Apple-ID). When I turn on iOS17 phone near the tags instead, no data is getting updated: for neither device.

Trying to get our openhaystack tags working with iOS17 is a waste of time as long as it obviously doesn’t even work with original AirTags. I have filed a bug report, but have no idea how / if / when Apple will consider this a serious problem.

[ngxson]

@humpataa Thanks for the update, I was wondering why my original Apple AirTag report much less frequently than before. Turns out iOS 17 broke the whole FindMy system, which is clearly a bug from Apple.

Conspiracy theory: Maybe a planned obsolescence before the announcement of AirTag 2?

[CappyT]

@humpataa Thanks for the update, I was wondering why my original Apple AirTag report much less frequently than before. Turns out iOS 17 broke the whole FindMy system, which is clearly a bug from Apple.

Conspiracy theory: Maybe a planned obsolescence before the announcement of AirTag 2?

Knowing the company we're dealing with, wouldn't be surprised.

[MrTalon63]

IIRC there was something said by a known person about AirTag 2nd gen releasing last year (2023) with a new U2 chip, but due to rather small production quantities, it was pushed to 2025. At the same time, I would see why Apple would do that I want to believe that most users recognize what's up. Unfortunately, there aren't any good alternatives, I think Google would be the only company that could launch something similar with support hardcoded into Android.

[shiprec]

Trying to get our openhaystack tags working with iOS17 is a waste of time as long as it obviously doesn’t even work with original AirTags. I have filed a bug report, but have no idea how / if / when Apple will consider this a serious problem.

@humpataa was any other progress made on this?

[humpataa]

No update. I have upgraded to iOS 17.3 and developer beta before. No change. No response from Apple.

[shiprec]

I asked one of the manufacturers of findmy tags to test and see if they saw the same results. See below but the summary is that they were able to prove the findmy is working with IOS17 with multiple types of of their tags...

From Manufacturer: I'd like to update you our engineer made the below tests. Step 1. There are 3 iphone devices (2 ios16 phone, 1 ios17 phone), and Tag1 which is named "Test" was bound with one of the ios16.

Step 2. The ios16 phone which bind Tag1 is kept by the developer in the R&D centre, far away ( around 100~120m) with Tag1 which is close the another ios16 phone. The developer can find ios16 phone with Tag1 location updated.

Step 3. We put ios17 phone beside the Tag1, and they both are keeping still for around 3 hours. Then the developers checked the ios16 phone which is also still about the location information and found no location updated. The initial judgment is that they have been separated for a long time, and the Tag1 has been in a static state for long. According to FIND MY to judge the status of the iphone device and Tag1/Tag2 tags (pls kindly see the picture as below for your ref), if iphone device and Tag1 are close to each other again, it will take a certain amount of time to establish connection. During this period, there may be server response and network problems during the process of initiating the connection, resulting in failure to connect, so the location information will be not updated in time)

Step 4. Based on the results of the "above step 3", we continue to test whether Tag2 location updates will appear on the originally bound iOS16 phone when the Tag2 is close to iOS17. This time, we used the originally bound iOS16 phone to unbind it from the device and re-establish the binding relationship (as mentioned in the step 3, leaving it alone for too long will prevent the phone and tag from quickly re-establishing a connection. Therefore, Choose the method of unbinding and rebinding (for the convenience of testing), and then the iOS16 mobile phone was taken home by A tester, the Tag2 and ios17 phone was taken home by B tester. The separation distance is more far than the separation in the step 2. After around 20 minutes, the location of the Tag2 was updated on the iOS16 phone. At the same time, the iOS17 phone close to the Tag2 also reminded the owner that the FIND MY device was following (see the picture below for details).

[Itheras]

I tested the same . Again all functionality works except lost mode on ios 17. The way to test this is to pair a tag remove the phone that paired the tag from the vicinity then remove the tag battery bring the ios 16 phone put the battery on the tag. Since the battery was removed it will be immediately in lost mode then wait to see a report on the phone that pair the tag . Repeat with ios 17 remove the battery from the tag bring the ios 17 phone and move the ios 16 away put the battery back and test again. If done so correctly and there is no other phones around the last seen will only update with the ios 16 phone not the ios 17 one.

[humpataa]

Sorry, I can hardly understand what the chinese guys actually did. Are there devices with iOS16 somewhere around or in the neighbourhood? Any iPads? It proofs nothing.

No need to bind, unbind, remove batteries or anything, just try this:

1. This needs to be done in a "remote" environment, no other Apple iPhones or iPads being in bluetooth distance!
2. Get an iPhone with iOS16.x installed, enable bluetooth, ensure internet access.
3. Get an AirTag registered to someone else who is away at least 200 m (the AirTag must be in "lost" mode). She / he watching his phone (FindMy) having internet.
4. Get an iPhone with iOS17.x installed, disable bluetooth, ensure internet access.
5. Put both phones right beside the friends AirTag.
6. Let your friend WhatsApp you whenever the status of his AirTag gets updated. This will happen every couple of minutes.
7. Turn off bluetooth on iOS16, turn on bluetooth on iOS17.
8. You will no longer get messages from your friend because the status of his AirTag will not update. For hours. For days. Until you enable bluetooth on your iOS16 phone again.

If you see updates with only your iOS17 being on: let the friend send you the position of the AirTag – it will not be the location of your iOS17 but of someone nearby, easy to double check this way!

I am 100% sure it is one of the following problems:

• iOS17.x does not send report packages at all OR
• report packages from iOS17.x devices are not stored correctly on server OR
• server does not send out reports originating from iOS17.x when requested by FindMy app

[Itheras]

I agree @humpataa is one of those 3 issues you mentioned. About the battery removal is just a fast way to enter lost mode without waiting.

[humpataa]

Apple has not replied to my bug feedback. I am trying to raise attention to this issue in several forums, including Apple's, so more people will file bug reports to wake Apple up. I can somehow understand that many don't "care" because they don't see the problem (because of many iOS16 devices, things don't look bad). But this thing is really serious and the FindMy network is getting weaker and weaker every day as more and more old devices get switched off or updated.

[Systm21]

@humpataa Maybe you should write to a few mac or iphone/apple news sites who can test it themselves and then publish articles accordingly.

There are certainly sites that reach a lot of users.

It's easy for the editors to test what you've found out.

[Systm21]

Is there anything new on this subject?