seemoo-lab / openhaystack

Build your own 'AirTags' 🏷 today! Framework for tracking personal Bluetooth devices via Apple's massive Find My network.

Home Page:https://owlink.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Binary releases for non Mac owners

dchristl opened this issue · comments

Hello,

first of all, thank you for your research and this great project.

As I understand it most of the features are independent of MacOS. The Apple device is only needed for the search party token, which is not available on other platforms (not even with AltServer on Linux).

So, as a non Mac owner, it seemed possible for me to run a webserver on a headless, dockerized MacOS just for fetching the position data. After some try outs it seems to work fine and I created a project with it. Do you have any problems with it or see any (legal) issues if I will provide some modified binaries of your project? This includes ESP32 firmware and the flutter app (web and Android).

My project is in an early alpha stage, but most of the stuff works already. My main goal is to provide a docker image with an installed MacOS where you just have to login with your AppleID and after that you can run this image headless on any server. The image will include a web server for the WebApp (the flutter app) and a python-webserver for the Android app. The Android app is just for convenience because you can use the web app. Changes to your code include:

  • Removing of unneeded parts (MacOS application and Mail-plugin)
  • Working Flutter Web-App
  • Possibility to change the locations server directly in the Flutter app
  • Some performance improvements for bunches of rotating/changing advertisement keys (stealth clones)
  • Battery optimizations and support for rotating keys in the ESP32 firmware
  • ESP32 modification for compilation with latest esp-idf

If you need to have more insights or screenshots, feel free to ask or check out the project Will be happy to hear from you.

Thank you,
Danny

Nice project. Just an opinion the fact that you list the other goal is to bypass apple anti stalking protection may not do well to this community as a whole. instead showcase maybe better worded. if we start making bypassing easier to not technically inclined people I am afraid we will force apple hand and we may loose access to this extremely useful tool. apple is already in the red with regular tags being used for stalking let not promote the use of unofficial tags for bypassing stalking protection. Beyond that Nice project especially if you get the flutter app working nicely.

Thank you for your feedback Itheras. I understand your point and you are right. I will remove all hints to this feature in the documentation before any release. I think, I will leave it in the code, but make it harder for non-developers to use it. In my opinion my project it is currently hard to use for stalking in general. I currently support ESP32 only and you can't get any AirTag-like devices for that and if you use a development board with an external battery the device get really huge. The cause is, beside all optimizations, the power usage is significant high. For me the use case is an anti-theft protection for my car. There you have a constant power source and don't warn any thief of your tracking device.

commented

I don’t think obfuscating features is the move here. I think in general that’s a bad practice

Also I don’t see any potential legal trouble by releasing the binary (other than the obvious Apple Terms of Service Violation that’s unavoidable no matter what you do)

I agree but is my opinion that promoting some of those functions should be done at the minimum. And thank you @dchristl I hope you can improve upon the flutter apps.

Thank you for your answers. I've already released a first alpha version.

 

@darthnithin

I'm not quite sure what you mean by obfuscating features. It is more an undocumented or hidden one. I've already removed all hints in the readme about it and added an undocumented switch inside the key generation. If you are familar with the function of the tracking feature, resp. OpenHaystack you will find it, but it's harder for normal end users to find and use it.

 

@Itheras

I will do my best with the flutter app, when spare time is available.

Sounds like a great idea. You can always redistribute or change our code / binaries. Just make sure that your repo does not contain a docker image with macOS. Even thought macOS is free these days, I guess Apple would not like that. But I'm not a lawyer.

Would love to see this. There are a lot of people (with me included), that have an iPhone but use some version of Linux as their main work station. In addition, I believe that it shouldn't be that difficult as they have similar architecture.

Hello @Sn0wfreezeDev

thank you for your answer. There is no image included, it uses the default one from sickcodes with slightly changed plist.

@lucaliceti
There is already a release at the project page with everything what is needed. The documentation is (nearly) coomplete, too. So, feel free to test it out. I'm currently running out of time, but I will spend more time in this project in the new future.

So, I've also been maintaining a fork of the flutter app, which has a series of improvements:

  • Performance improvement using a rust library to handle the P224 ECDH operations. It's working for Web (webassembly) and Android (iOS and mac shouldn't be so distant). The decryption process is at least 3x faster in my local tests (~4s in my phone and ~8s on web).
  • The API endpoint URL is not hardcoded anymore. There is a field in the settings where you can set your own server.
  • Bug fixes like Uint32 coordinates (instead of in32) and padding problems with the bigint conversion in the KDF function.
  • There is a working CI, which means you can download the compiled application right now (e.g. https://github.com/wangwillian0/openhaystack/actions/runs/4653488535).

Sorry I didn't see this thread earlier, I would've contributed directly to your repo. When I decided to create my own fork I found nothing alive on the list of forks of this repo and the PR page. I guess I skipped the issues page 😅

Hello @wangwillian0,

nice to hear that somebody is working on that project, too. My project is not a direct fork, because I bundle three different projects under one. Also the main goal is to avoid the usage of OpenHaystack application and webserver. So, our projects are not directly compatible (i.e. the use of a different webserver to fetch the reports). Although I have done the same things like you, there is always room for improvement and we can bundle our work.

Overlapping features:

  • API endpoint as property (but different endpoint and some chnages in the format)
  • UInt32-bugfixes for the web version (rolled back in the latest version, because pc-dart fixes the issue in the latest version)

Additional features of your project:

  • working CI
  • performance improvements with Rust

Additional features of my project (besides the different workflow and the independence of OpenHaystack):

  • Performance improvements on server site (i.e. filtering)
  • Additional property to fetch only latest or couple of days instead of all reports (also performance improvement)
  • Some bug fixes, removed depractions, ....
  • Usage and adaption of all dependent libraries (dependencies)

I will have a deeper look at your project, when I have time for that. I'm really interested in the webassembly part.

Kind Regards,
Danny

Just an update of my fork:

https://github.com/wangwillian0/openhaystack/releases/tag/v1.0.0

  • Vector map: smoother, faster and prettier map
  • Performance improvements: less than 2 seconds to decrypt 2000 history locations (even on your browser!)
  • Server endpoint as user preference: bring your own Openhaystack server without recompiling
  • Better history visualization: color encoded points
  • Web version: try it now at https://find.willian.wang/

Unfortunately, I dropped the Mac and IOS releases because I had no way of testing them (it shouldn't be very hard to add them again)