Tracking down private resolvable addresses

[Matthew K]

Hi, there~~ Just noticed that there are codes for the Android nRF connect.

github.com/.../Android-nRF-Connect

Using that code, I wish to create my personal sniffer that can track nearby arbitrary BLE devices without pairing/bonding

using the Github code and my Nexus 5 phone (Android 6.0).

So I have some questions!

1) Considering this past question 

devzone.nordicsemi.com/.../resolving-private-resolvable-addresses

is it not possible to resolve the private resolvable address unless I have the bonding information or the IRK?

In other words, I do have to at least pair/bond to a device if I want to resolve the device's private resolvable address?

2) 

• 11:  Static
• 01:  Non-resolvable
• 00:  Resolvable

I searched the address types. Are these 2-bit fields shown from the advertising packet?

Or which bit-fields contain this address type?

I was curious whether I can determine whether the advertising device uses a public/resolvable/random address by sniffing the advertising packet.

3) I couldn't find one but have anyone found an Android SDK that can get the bonding information or the IRK?

Thanks a million!

[tesc]

Hi,

I do not have an answer to 3), but:

1) The resolvable random address can only be resolved using the IRK. You will get the IRK as part of bonding.

2) Figuring out if the address is a known resolvable random address can only be done by checking against the list of known IRKs. Our SoftDevices does this automatically, providing in the advertising report event a flag peer_addr.addr_id_peer signalling if it is a resolved address. The two-bit fields that you refer to are actually part of the address itself. For the fourth type of address, "Public Device Address", those two bits are the two most significant bits of the company_id part of the address.

Regards,
Terje

[Aleksander Nowakowski]

Hello,

On Android it is the system that manages bonding. No bonding information, none of the keys, are available. There is no API to get this kind of data from the phone. The only methods related to bonding are createBond(), added in API 19 (KitKat) and removeBond() (which has to be invoked with reflections).

Also, scanning returns only 48 bits of Bluetooth address, so you are loosing the public-private address type information. Without it you don't know the address type, as it may be public address and those types you wrote don't apply.

On bonded devices the getAddress() method returns resolved address if it could have been resolved, at least I think so.

Besides, the code of nRF Connect is not available (for Android and iOS), as stated on the GitHub page you pointed to. If you want, you may write a plugin to nRF Connect for PC. COde for this app is available on GitHub: https://github.com/NordicSemiconductor/pc-nrfconnect-ble

[Matthew K]

Thanks for your reply!

Just to recap, without bonding with a peripheral,

there is no way to tell it is the same peripheral or not after the private resolvable address has changed, right?

[Matthew K]

Thanks for your reply!

Just to recap, without bonding with a peripheral,

there is no way to tell it is the same peripheral or not after the private resolvable address has changed, right?

[tesc]

Hi,

That is correct. The whole purpose of the resolvable address is that only bonded devices will know what device it is. It is a privacy feature, so that the device cannot be tracked.

Regards,
Terje