You cannot connect to the bluetooth MAC addresses. I think you assumed something here...
I don't know if the people in the documentary tested it, but I have tested it. It gives you the general message that you cannot connect to the device. Why don't you try it in a crowded place to confirm it instead of just theorizing?
I get your logic, but you judge doctors as technicians... "Why can't a doctor understand bluetooth like a 10-year-old kid?" Perhaps because they don't have the experience in this field.
You are too quick to judge, and you conclude that it is fake and made with dumb people?
I guess I was quick to judge you... My mistake. Thanks for helping me fix my error.
If you think people that do experiments that actually prove things are "dumb", then count me in this group. I certainly am not as "smart" as you are, that's for sure.
Damn... You give a dog a bone and they bite your head off immediately...
Just FYI, you have presented no proof or an actual test with your theory. That's why you're a conspiracy theorist, and I am a conspiracy researcher. Wow... that's perhaps a new record for people that let me down faster with their lack of facts... Theorize all you want, buddy. I will still go ahead and stick with facts, tests, and proofs. What a waste of my time...
You cannot connect to the bluetooth MAC addresses. I think you assumed something here...
That exactly how BLE devices work.
They run kismet. Kismet is only for linux. They don't have special hardware BLE sniffers like Ubertooth or nRF24 based one to sniff on established connections. So they have a list of BLE adresses retirned by linux HCI. This list contains addresses of devices you could connect to. If you see address in that list - you could connect to it.
Say, you use bluetoothctl (basic linux BT utility, you have it out of the box on any popular linux distribution).
you do
[bluetooth]# scan on
[bluetooth]# menu scan
[bluetooth]# clear
[bluetooth]# transport le
[bluetooth]# back
then you get list of BLE devices around. Same what kismet will show.
[NEW] Device <BTADDR>
Then you coudl do with <BTADDR> in form of 00:11:22:33:44:55
[bluetooth]# pair <BTADDR>
[bluetooth]# menu gatt
[bluetooth]# list-attributes <BTADDR>
You will get a list of attributes BLE device expose and some additional info like device class, name and so on.
somehting like that:
Device <BTADDR> (public)
Name: <somename>
Alias: <somealias>
Paired: yes
Trusted: yes
Blocked: no
Connected: yes
LegacyPairing: no
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
UUID: Battery Service (0000180f-0000-1000-8000-00805f9b34fb)
UUID: Human Interface Device (00001812-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (3dda0001-957f-7d4a-34a6-74696673696d)
Then you could read and even write some attributes. Every attribute have UUID, most UUIDs are predefined and you could find how to read and interpret them.
And so on.
It gives you the general message that you cannot connect to the device.
You can't connect to regular Bluetooth device if it is already connected or paired. BLE devices are different. In the list they show you could be only devices that ready for connection. Because to find BLE devices that already connected you need special hardware they clearly don't have.
Why don't you try it in a crowded place to confirm it instead of just theorizing?
I did. And it's exactly how BLE work.
"Why can't a doctor understand bluetooth like a 10-year-old kid?" Perhaps because they don't have the experience in this field.
Well, they somehow installed and get kismet working. It is a sophisticated tool, mostly for hackers, and they have enough expirience to use it. But somehow they don't have a clue what BLE is, what they see in kismet and how to connect and get info from BLE devices.
You can't do that properly with phone. Nor iPhone, nor android have corresponding BT tools to do that. But you could properly do it with linux PC.
I just dumped you evidence with my BLE mini-keyboard. For obvious reasons I hide only BT address, name and alias.
I don't have any other BLE devices around.
You could also easily find linux BLE howto's and check it by yourself. Basically you don't need to install and tune kismet, you could use bluetoothctl of hcitool+gatttool
If you see BLE address in scan results you could connect to it.
Wait a second...
You cannot connect to the bluetooth MAC addresses. I think you assumed something here...
I don't know if the people in the documentary tested it, but I have tested it. It gives you the general message that you cannot connect to the device. Why don't you try it in a crowded place to confirm it instead of just theorizing?
I get your logic, but you judge doctors as technicians... "Why can't a doctor understand bluetooth like a 10-year-old kid?" Perhaps because they don't have the experience in this field.
You are too quick to judge, and you conclude that it is fake and made with dumb people?
I guess I was quick to judge you... My mistake. Thanks for helping me fix my error.
If you think people that do experiments that actually prove things are "dumb", then count me in this group. I certainly am not as "smart" as you are, that's for sure.
Damn... You give a dog a bone and they bite your head off immediately...
Just FYI, you have presented no proof or an actual test with your theory. That's why you're a conspiracy theorist, and I am a conspiracy researcher. Wow... that's perhaps a new record for people that let me down faster with their lack of facts... Theorize all you want, buddy. I will still go ahead and stick with facts, tests, and proofs. What a waste of my time...
That exactly how BLE devices work.
They run kismet. Kismet is only for linux. They don't have special hardware BLE sniffers like Ubertooth or nRF24 based one to sniff on established connections. So they have a list of BLE adresses retirned by linux HCI. This list contains addresses of devices you could connect to. If you see address in that list - you could connect to it.
Say, you use bluetoothctl (basic linux BT utility, you have it out of the box on any popular linux distribution).
you do
then you get list of BLE devices around. Same what kismet will show.
Then you coudl do with <BTADDR> in form of 00:11:22:33:44:55
You will get a list of attributes BLE device expose and some additional info like device class, name and so on.
somehting like that:
Then you could read and even write some attributes. Every attribute have UUID, most UUIDs are predefined and you could find how to read and interpret them.
And so on.
You can't connect to regular Bluetooth device if it is already connected or paired. BLE devices are different. In the list they show you could be only devices that ready for connection. Because to find BLE devices that already connected you need special hardware they clearly don't have.
I did. And it's exactly how BLE work.
Well, they somehow installed and get kismet working. It is a sophisticated tool, mostly for hackers, and they have enough expirience to use it. But somehow they don't have a clue what BLE is, what they see in kismet and how to connect and get info from BLE devices.
It's impossible.
Why don't you prove that with a test?
I understand that you write a lot, but can't you just prove that as the documentary proves that?
You have a phone and bluetooth, right? Where is your evidence?
You can't do that properly with phone. Nor iPhone, nor android have corresponding BT tools to do that. But you could properly do it with linux PC.
I just dumped you evidence with my BLE mini-keyboard. For obvious reasons I hide only BT address, name and alias. I don't have any other BLE devices around.
You could also easily find linux BLE howto's and check it by yourself. Basically you don't need to install and tune kismet, you could use bluetoothctl of hcitool+gatttool
If you see BLE address in scan results you could connect to it.
So no real evidence, just more text?
I provided a documentary, another person's test, another documentary.
You just want others to believe your words without any proof. You and I are not the same.