New data is being returned

[Itheras]

Some Tags are now returning data that don't fall in the EC point or are invalid .

Never seen these before.

examples below

Failed to decode elliptic curve point: Invalid EC key. Data slice [5:62]: 0204974573496425429143fc57889425298283dc915e4fd6097dced968236b76dcf00db10aa989aac60196465b653089d4ef655a5c8a81a16d

Failed to decode elliptic curve point: Unsupported elliptic curve point type Data slice [5:62]: 010443ed3135cec20b7505c051ddac14d49ea611da82b32cdb8f306f0c0ce54e2652e61194e9208a9df0266265732df2834d87c4e3c93cc1ae

[humpataa]

Noticed that as well, it breaks the request_reports script when EllipticCurvePublicKey is called. Since it only breaks for certain keys I have put all the code there into try/except just ignoring them. Until someone finds a better solution.

[wangwillian0]

The problem is that there are new data coming with an extra byte at the beginning, specifically the byte 0x2b, which makes them have 89 bytes instead of the expected 88 bytes. Not sure why this is happening.

You can check the changes in my application (you are welcome to use it, there is a web interface too, it just needs to have the server running) https://github.com/wangwillian0/openhaystack/commit/ec25a53c16681ff2cac3de1db5471a61de54837f

[Itheras]

The problem is that there are new data coming with an extra byte at the beginning, specifically the byte 0x2b, which makes them have 89 bytes instead of the expected 88 bytes. Not sure why this is happening.

You can check the changes in my application (you are welcome to use it, there is a web interface too, it just needs to have the server running) wangwillian0/openhaystack@ec25a53

I tested a few things i believe is the second byte that needs to be removed. So if the length is 89 remove the second byte. that fixes it for me it, if i remove the first byte the timestamp goes wrong.

[wangwillian0]

I tested a few things i believe is the second byte that needs to be removed. So if the length is 89 remove the second byte. that fixes it for me it, if i remove the first byte the timestamp goes wrong.

My mistake, the extra byte is actually the fifth byte, which in my tests always corresponded to the byte 0x00. As the original Seemoo's paper:

In my tests, the sixth byte in the longer payloads have the same range of values as the fifth byte in ordinary payloads (confidence value), making the fifth the extra one.

[humpataa]

so I have added these two lines before from_encoded_point is called:

if len(data)>88:
    data = data[0:4] + data[5:]

seems to decode fine and doesn't crash anymore. question still is: why has this changed and why has it changed for a few keys only?

[faceless2]

See https://github.com/malmeloo/FindMy.py/issues/27 for the same issue

[bitbutbit]

This might help you: https://github.com/MatthewKuKanich/FindMyFlipper/issues/61#issuecomment-2065364739