Using a Minew iBeacon slot as proof of concept (confused on formatting)

Open
#105 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Domain
embedded-iot

Research direction

The issue names no repository file or test. Start by examining the supplied OpenHaystack Base64 advertisement key alongside the Minew E8 and Beaconset+ iBeacon field limits; done would require establishing whether the formats can interoperate and documenting a workable mapping or the incompatibility.

Written by the indexing model from the issue text.

Description

question

Hello,

I have been given a mine iBeacon E8. It runs on an NRF52. The current firmware allows for the concept of slots, whereby it will round robin and advertise different formats in different slots. It would be nice to do some testing with these beacons whereby they will continue to broadcast their current iBeacon in slot 1, but I could use slot 3 to piggyback on openhaystack.

As a proof of concept I was hoping to be able to generate a key in Openhaystack, copy and paste that into via the Beaconset+ app and simply advertise it using the Minew E8.

The minew E8 supports the following Frame Types for broadcast:
UID (Instance ID of 12 NamespaceID of 20)
URL (Useless as it mandates the HTTP:(s)//
iBeacon (Minor, Major UUID 8 chars-4 chars-4 chars-4 chars-12 chars)

My question is, is there a way I can take the output from the copy advertisement key (base 64) and format it to fit in the iBeacon field.

The Minew is expecting a UUID format like:

466C6F4B-6948-6561-6C74-680154616701

My sample Base64 from Openhaystack as a byte array is:

0x7f, 0xad, 0x88, 0x77, 0xe, 0xcf, 0xde, 0xcd, 0xd, 0xb9, 0xf3, 0x8f, 0xef, 0xca, 0xe0, 0x83, 0x79, 0x5b, 0xe1, 0x5d, 0x7f, 0x45, 0x8c, 0x77, 0xa, 0x4b, 0x7d, 0x36

So formatted it would be

0x7f, 0xad, 0x88, 0x77, 0xe, 0xcf, 0xde, 0xcd (8)
0xd, 0xb9, 0xf3, 0x8f (4)
0xef, 0xca, 0xe0 0x83 (4)
0x79, 0x5b, 0xe1, 0x5d (4)
0x7f, 0x45, 0x8c, 0x77, 0xa, 0x4b, 0x7d, 0x36 (12)

Ok, but still too long to fit into the UUID format. So I took the base 64 advertisement key of
f62Idw7P3s0NufOP78rgg3lb4V1/RYx3Ckt9Ng==
and ran it through https://base64.guru/converter/decode/hex to give me a UUID equivalent in hex...

f62Idw7P3s0NufOP78rgg3lb4V1/RYx3Ckt9Ng==

becomes:

7fad88770ecfdecd0db9f38fefcae083795be15d7f458c770a4b7d36 (56 characters)

I suspect the problem is I am trying to fit a quart into a pint pot. i.e the UUID iBeacon format the Minew expects is shorter than the custom format apple broadcast for their AirTags.

Any pointers or ideas would be gratefully recieved.

Dominant language
Swift
Stars
13.6k
Forks
681
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from seemoo-lab/openhaystack

All issues in seemoo-lab/openhaystack

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.