400 Bad Request error since last week

[CappyT]

Hi, I ported your script to python3 (I'm using MacOS Ventura on an HW hackintosh), but for a week now i got 400 bad request errors when I call apple endpoint /fetch.

Am I alone? Is there anyone else with this problem?

[dchristl]

Hi CappyT,

I'm not quite sure what you mean by ported to python 3, because the script is already ported and works on python 2 and 3. I use the six-compatibility library for this.

I can reproduce the 400 - Bad Request error with my code and with the original one from Biemster as well. So this should be a general problem. I couldn't find any informations about this and can't see what Apple has changed here. I can't try it out with the original OpenHaystack App, because this dosn't work on virtual Macs. I will check out the bugtrackers of the other projects and hope for a solution. If you found one feel free to give feedback for a faster solution.

Regards, Danny

[CappyT]

Hi @dchristl , Sorry, I must have confused this script with some other like the one from Biemster, which is in python 2.7.

I have access to a physical GPU-Accelerated Hackintosh and OpenHaystack app works for me, so I may help with that. Also because I wanted to do some fixes on the Android app (mainly the slowness when it fetches location data). Given the nature of the debugging involving very sensitive data I'd rather prefer if we get in touch on this one, publishing anisette data over the internet it's kinda risky.

From the initial debug i did, the problem could be related to these two headers:

• X-Apple-I-MD-RINFO: It's a static value, while my openhaystack proxy calculates it from anisette data (not sure on what it does, I did not look into it hard enough)
• User-Agent: It's completely absent from your code, it should report something like: "searchpartyd/1 device:os-version"

[dchristl]

Seems interesting, thank you for your research. I've browsed the openhaystack code a little bit and it seems there is an extra webservice call to get the Rinfo header. But I didn't see any hints to the user agent. Where did you find that information?

BTW. There are already some optimizations in the android app (multiple Ids at one call and decryption of history data in background) .

[CappyT]

I found that info on the original paper the team from openhaystack published: https://arxiv.org/pdf/2103.02282.pdf (look for table 4)

For the android app, I'm kinda interested in limiting the 5 most recent location as I'm not very interested in location history, and fetching and decrypting 2000 locations per tag (I have 20 of them) doesn't seem super useful to me

[CappyT]

A side note (might not be helpful) in the response header from apple you have this one: header: Apple-Originating-System: UnknownOriginatingSystem

So I vouch more for that user agent

[ak2k]

I don't run this yet, so can't cross-check anything on my end; however, I came across this recent issue and wondered if it could be related? https://github.com/biemster/FindMy/issues/20

[dchristl]

Thank you both for your research. I think the linked issue at biemster's project is the cause of this. I will test it out and will release an update next week, if it is solved

[dchristl]

Please check out the latest release, the issue is fixed there. It was indeed the single quote in the ids. Apple seems to have changed this. After I modified this to double quotes, it works like before.

Thanks @ak2k and @CappyT for your help and hints.