Originally published on Medium:
A logic bug, a cup of cold tea, and how curiosity quietly led me to my first big report.
☕ When Curiosity Took Over the Protocol
It was a quiet weekend evening. Logs on one side, Bluetooth tools open, and — as always — a hot cup of tea beside me.
But by the time I looked up again… the tea had gone cold.
And as someone from Assam, trust me — that’s a big deal.
But that day, curiosity won over everything.
For the past few weekends, I had been diving deep into how Android handles Bluetooth at a system level — especially around device pairing and communication flows.
While exploring how Bluetooth connections are initiated, how devices identify each other, and how permissions are set, I began experimenting with edge-case scenarios using standard tools and by reading parts of the Bluetooth stack code.
That’s when I spotted something interesting.
🔐 A Pairing That Skipped the Permission Part
While reviewing the codebase, I noticed that the logic handling "trusted" devices didn’t enforce any relationship with the "paired" status.
In other words, nothing ensured that a device had actually completed pairing before being allowed to become trusted.
That triggered an idea:
What if I skipped pairing entirely and directly invoked the trust logic?
So I set up a test using my laptop and an Android phone.
I simulated a scenario where the trust state was set without any successful pairing handshake.
To my surprise, the Android phone appeared in my laptop’s trusted list — even though the phone user had never approved any pairing request.
Once the phone appeared in the trusted list, I attempted a file transfer.
Instantly the Android phone displayed a notification:
"XYZ wants to send you a file via Bluetooth."
The user still had to accept or reject the transfer, but the key point was:
The pop-up appeared without any pairing ever being completed.
Even after disconnecting, the Android phone remained in my trusted list.
The next day, when I tried again while the phone was nearby, the same notification appeared again.
No pairing.
No confirmation steps.
Just a direct file transfer prompt.
🔍 Testing Across Devices
To confirm this wasn’t accidental behavior, I tested across multiple devices and Android versions.
Devices tested:
- Realme Narzo (Android 14, 15)
- Motorola G series (Android 12)
- Pixel devices and others (Android 11, 13)
Results were consistent:
- A device could be added to the trusted list without pairing
- File transfer prompts appeared without pairing approval
- The trusted status persisted even after disconnection
🧠 Root Cause (Code Logic)
After digging into the Bluetooth stack logic (BlueZ), the reason became clear.
The Paired flag is set only after successful key exchange during pairing.
The Trusted flag, however, is simply a policy toggle and can be set independently.
Example logic:
// Paired flag: only true after successful key exchange
void device_set_paired(struct btd_device *device, bool paired) {
device->paired = paired;
if (paired)
write_link_key(device);
}
// Trusted flag: can be set anytime, no pairing check
void device_set_trusted(struct btd_device *device, bool trusted) {
device->trusted = trusted;
write_trust(device);
}
The issue is simple:
Trusted does not verify Paired.
This allows a device to be marked trusted even when no valid pairing exists.
📩 Reporting to Google
After documenting the behavior across devices and Android versions, I submitted the findings to Google's Android & Google Devices Vulnerability Reward Program.
The Android Security team reviewed the report, validated the issue, and acknowledged it through their official process.
💰 Recognition
The report resulted in:
- Official recognition by the Android Security Team
- Classification as a moderate severity issue
- A bounty reward under the Android VRP
✦ A Quiet Milestone
This discovery started as a simple weekend experiment and turned into a meaningful security report.
Moments like this remind me why security research is so rewarding.
Sometimes all it takes is curiosity, persistence — and occasionally letting your tea go cold.
Disclaimer
This write-up reflects personal security research and observations. The issue was responsibly disclosed to the vendor. No exploit code or sensitive information is shared. The purpose of this article is educational awareness.
Top comments (0)