-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement key cycling like FakeTag #2
Comments
I'm working on that and should be a relatively minor change, for now I don't see why that wouldn't work (but don't pin me down on it). |
Another nifty feature of FakeTag is that it uses the status byte to encode the detections (not needed here) and the battery status (potentially useful).
I just tested to be sure and I got back what I wrote in the status byte from apple's servers. |
Battery status would indeed be very handy, I did not see any code related to that in the SDK yet though (although I did not really search for it either). |
I was going to ask him but I thought it would be more fun to just try 😉 |
You can encode any data in the status byte, apple is using the first two bits for battery and the other bits for god knows what |
I've gained a lot of experience on https://github.com/biemster/st17h66_blinky and https://github.com/biemster/st17h66_RF, the key cycling should be relatively easy now (and is high on my list) |
Has there been any progress with this? Would also love this option so the potential thief doesn't know I'm tracking him |
It's still in design phase. I've come up with 2 easy solutions, but I'm still thinking of a 3rd proper one:
Solution 1 is dependent on the amount of RAM/ROM, and might still enable others to track you when they learn enough keys, solution 2 is not dependent on the amount of space, and only allows others to track you if they know this (very easy!) scheme. Preferred solution is 3) where the new key is derived in a cryptographic way, although I have to hone my crypto skills to figure out how to do that. People in this thread can vote if they like, I'll go with the preferred solution then when I get the time. In the meantime, it seems that the anti tracking measures are having difficulty finding the tags in the current implementation already, as reported by @vadimkozhin and others: #7 (comment) |
I vote for one of the east solutions first, with a flag on the flasher script to turn it off and on |
@biemster I don't quite understand what you mean by "Increment the public key by 1 (or n?) after every broadcast". |
That was not very clear indeed @dakhnod , I meant to add the curve generator to the public key, so the new point corresponds to EDIT: it's point doubling which is easy on the x coordinate actually, so my proposal is to add the public key point to itself, which then corresponds to |
@dakhnod ahh, got it. I think that's how AirTags do it. |
yeah it might require a couple extra API calls to figure out at which iteration the Tag is. |
I am failing to understand why this is requested so much. changing keys doesn't prevent iPhone detection . if someone tries to use it for stalking for example . checking if my neighbor is there by scanning for an id, changing the keys does noting since I just have to scan for a ble message that identifies as apple that comes and goes with a particular strength. it someone goes to the extent of having a ble scanner to see broadcasts It would immediately know something is up if a bag or bicycle or anything has a ble signal emanating from it no mater what id it sees. damn if I really want to track someone by using ble adv ids I might of well just keep an eye for their phone wifi probe requests for a particular wifi network. to be short changing the keys for a thief or person willing to use any type of wireless signal scanner doesn't nothing. they know its there and just by signal strength can tell where it is and to whom it belongs based on that info. I feel it just complicates things. I can go to a mailbox an see what addresses are using darknod device id not needed. I may just use vibration to prevent broadcast until there is no movement as a way not to trigger iPhone detection. if changing key are implemented in my view is just a way to be closer to apple implementation which if I understand correctly still defaults to single key broadcast after power failure. doing this poorly will be just spamming apples api. Genuinelly is there something I am not taking into account ? |
No anti theft device is effective 100%: a gps tracker can be jammed (illegally, but I doubt a thief worries about that), wifi and bluetooth can be jammed, cellular data can be jammed, etc. |
yes exactly that @olivluca, most thieves that are after anything smaller than a car will not be very sophisticated. And for me another concern is bulk bluetooth broadcast capture in places like malls etc. They should have a lot harder time tracking you too (at least using the tag) when the key is cycled. But yeah if someone is really after you or your stuff specifically, this will not help much. But then that someone probably has better means to get what they want then just following your bluetooth tag. |
Correct it just in my testing broadcasting a single key every 5 sec or rotating keys does nothing in terms of detection a iPhone will still trigger whit openhaystack based tags the sensitivity is decreased regardless of a static or changing key . unless we change the key with every broadcast that would will do something with the detection. but I see you point especially mass scanners . but again if example you use a malls wifi in reality not much is being done. i just wonder if the extra complexity is warranted for the gains. and Thanks I didn't think of those scenarios you are right. |
@Itheras you're saying even with key cycling an iPhone will trigger on the tag? I did not realize that (although original AirTags also cycle the keys ofcourse). Maybe we should run some experiments how quickly a key needs to be cycled before it triggers a detection? |
@biemster Correct if we cycle the key using the timings apple uses the detection doesn’t change much it already low with single adv. But i will imagine that cycling it faster will decrease detection rate. |
I don't know if this is still relevant https://positive.security/blog/find-you
|
So has this been looked into? Like @Itheras I don't see any use of changing keys if this does not have the purpose of hiding tags from iPhone users. I have made a puck.js to work as a clone and after carrying it 10 minutes with me on my bycicle, a message from Apple's "findmy" app showed up telling me that there might be an AirTag with me that I don't own. Obviously my little new friend. |
I have my doubts that key cycling will hide the tags from iphone users. I did not test this yet though (no iphone), so I would be delighted if you could test this out on your puck? |
Will try, I have my doubts as well. Actually, I don't know why the AirTags change key every 24 hours anyway. |
Great! that will be a nice test. The AirTags change key every now and then to avoid bluetooth sniffers to be able to track them I guess. |
Hello, the FakeTag project cycles through 100 keys, switching key every hour.
I prepared a pull request to implement the same functionality for an esp32-c3 I had lying around, but the prospect of having a self powered, cheap, tag is appealing.
Do you think it would be possible to implement the same functionality with the st17h66?
I have the tags my cart, I'm undecided if I can press "Checkout" 😉 (and I can even recycle the esp32 to program them 😁)
The text was updated successfully, but these errors were encountered: