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 ? (seemoo-lab/openhaystack#49 (comment)) I wonder what that byte is could he just be talking about the status byte or something different. And this other piece of information (seemoo-lab/openhaystack#225 (comment)) 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 (seemoo-lab/openhaystack#225 (comment)) 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.

[biemster]

Apple would force every AirTag (and all the clones!) to update to make them work like everyone is expecting?

I assumed from the comment that this is an easy procedure, and frankly this wouldn't be the first time a tech firm responds to "my [insert device] is not working" with "please press update".

But if your tags are all on 2.0.61 already @humpataa, I'm inclined to believe there are other devices close to @voidsquared that ruined the testing.

[humpataa]

iOS17.4 update doesn't seem to bring any changes. 🙄

[isibizi]

I think apple has find a away to block cloned tags :(

[shiprec]

@humpataa the manufacturer was able to get back to me. They were able to replicate the issue with multiple of their apple approved tags, based on your step by step instructions (thank you) I am pushing them to notify Apple to see what they say.

[isibizi]

@shiprec Manufacturer of licensed Tags, or cloned?

[shiprec]

@isibizi Manufacturer of licensed tags

[humpataa]

@shiprec

@humpataa the manufacturer was able to get back to me.

sounds good. what's the name of the company?

[shiprec]

@humpataa I am not sure I should share that publicly.

[humpataa]

okay, well let's hope it has some impact. and I hope it's some server side issue, Apple just needs to pull the lever and all will be smooth again ...

[supaeasy]

iOS17.4 RC: issue not fixed.

@shiprec you can use any AppleID for requesting any reports as long as you have the keys. The AppleID (iCloud) is only needed for encryption of traffic, Apple "items" (such as real or fake AirTags) are not bound to a specific AppleID.

Very recently I set up macless-headstack instead of openhaystack so I could throw out the macMini that I was running it on and I can definitely say that this is not true. I accidentally logged into anisette with another AppleID and got error messages when trying to fetch locations even though I correctly imported the .json File with my devices. It went flawlessly after I changed the AppleID account to the one I created the devices with. Actually I thought this should work as you described but can now tell it does not.

[humpataa]

are you using the python scripts for requesting reports?
the iCloud_decryptionkey must be created with the AppleID you want to use, of course.

[supaeasy]

I am using anisette and macless-haystack in docker and I guess it creates the key when I login with an appleID - right? I am not at home so I cannot tell where exactly iCloud_decryptionkey comes into play.

[humpataa]

I don't know macless / docker version. but I have definitely used different AppleIDs to get reports for the same devices.

[humpataa]

@humpataa I am not sure I should share that publicly.

Do you have updates from the company, have they been able to make contact with Apple?
I am still struggling to find an appropriate channel, tried chat, phone, forums, support – all don't seem (want) to be "responsible", cannot answer and cannot forward it to the right address. All my bug reports (feedback) have zero replies as well. Very annoying.

[shiprec]

@humpataa they said they would send it to Apple and let me know if there is any response. So far I haven't heard anything.

[supaeasy]

Could it have something to do with iOS17 new ability to share AirTags? Maybe they changed the way the reports are handled.

[Itheras]

Could it have something to do with iOS17 new ability to share AirTags? Maybe they changed the way the reports are handled.

nope. Regular airtag using apple findmy app gets no reports if there is no ios16 device around.

[isibizi]

iOS 17.4.1 has fixed this issue

[davesenior9]

Can confirm, upon updating my iPhone 15 to 17.4.1, I'm immediately getting updates from the device that I've previously received zero updates from.

[Systm21]

...our haystacked clonetags are also working normally?

[Itheras]

Everything is back to normal. but I believe something is being done differently with the status bit ios side but take it with a grain of salt i need to dig deeper. But yes everything is reporting again.

[isibizi]

...our haystacked clonetags are also working normally?

Yes it should working to.

[humpataa]

Can confirm, upon updating my iPhone 15 to 17.4.1, I'm immediately getting updates from the device that I've previously received zero updates from.

Same here: it really looks good since yesterday, however, I have the feeling that older devices (iOS < 16.7.6) still report quicker and more reliable?! But working again finally! 😍

Tested with 2 original AirTags, 2 official clones and several fake tags (status byte fully used, hint byte correctly set) – all fine.

There is an update for iOS16 as well, fixing the issue too I believe. Still waiting for technical details of the update, guess Apple is waiting for the rollout to reach enough people before sharing details.

[Cassander313]

Does anyone notice if this issue has now come back up since the new 17.5.1 role out in terms of detecting tags.

[doggyhaha]

Does anyone notice if this issue has now come back up since the new 17.5.1 role out in terms of detecting tags.

Can confirm, i'm on 17.6 and no report appears with the original HCI.py, i'm trying with the one from the PR but i had to patch it further more since it couldn't change ble addr

[doggyhaha]

Does anyone notice if this issue has now come back up since the new 17.5.1 role out in terms of detecting tags.

Can confirm, i'm on 17.6 and no report appears with the original HCI.py, i'm trying with the one from the PR but i had to patch it further more since it couldn't change ble addr

ok i managed to fix it (?) but idk how reliable this is, also it's very device specific and i dont know which edits are necessary.

gist url: https://gist.github.com/doggyhaha/37e61a03a07868942f64c343b29766c2
also had to build bdaddr (this one since bluez didn't have it included)

i run it with python HCI_fix.py -k "ADV_KEY" -i 33 (as root)
i used this script to get results
and used this script to generate the keys

i didn't try any other combination/script, i have an iphone 15 with ios 16, if i understood correctly the problem what that HCI.py couldn't change the MAC address on my device