Breaking Mobile-to-Device Logic: When BLE Access Falls Apart

Table of contents

Hey everyone 👋

Lately, I’ve been digging into mobile apps that interact with physical devices, like smart locks, BLE door readers, or NFC-based access systems.

These apps are fascinating because they blend software with hardware, and that means real-world consequences if something breaks. Like... people walking into buildings they shouldn't.

So in this issue, I want to share some attack paths, interesting tests, and observations that can help you break (or secure) apps that interact with the physical world.

Let’s get into it.

Sniff BLE Traffic Even Without Special Hardware

If you don’t have a dedicated BLE sniffer, Android gives you a nice trick:

Go to Developer Options → Enable Bluetooth HCI snoop log
This saves a log file at /sdcard/btsnoop_hci.log — pull it out and open it in Wireshark.

Once inside:

• Look for UUIDs and write characteristics used to send commands
• Try to identify a "door unlock" packet
• Repeat the same operation multiple times — does the payload change?
• If it doesn’t, you might be able to replay it using Python with something like bleak

✅ Test This: Capture and replay a BLE command to unlock the door
If it’s static and not signed, that’s a huge problem.

Reversing Custom BLE Protocols

A lot of vendors try to hide behind “proprietary protocols”, assuming nobody will figure them out. Spoiler alert: we will.

If you’ve got the APK:

• Drop it into Jadx, and search for characteristic UUIDs or BLE calls like writeCharacteristic()
• Look for payload formatting code — you might find it’s just base64-encoded JSON or a simple byte array with no real protection
• If the app builds a packet without any signature or cryptographic verification, that’s game over

Inspect: Is the reader validating anything? Or just accepting commands blindly?

What Happens When You’re Offline?

This is one of the most overlooked attack surfaces in physical access apps.

Let’s say the backend issued you a credential 3 days ago. What happens if your phone has been offline since then?

• Can you still open the door?
• Is there a local expiration? Usage counter?
• Can you modify local storage to reset state?

If the mobile app relies purely on remote revocation and doesn’t enforce local restrictions, you might still get in long after your access should’ve been revoked.

How Are Credentials Stored?

Even if credentials are issued securely, how they’re stored matters a lot.

Things to look at:

• Are they in the Keystore (Android) or Keychain (iOS)?
• Do they use secure access flags like kSecAttrAccessibleWhenUnlockedThisDeviceOnly?
• Are encrypted SharedPreferences really encrypted, or just obfuscated?

Anti-Frida Defenses (And Why They Usually Suck)

Apps like these often try to block tools like Frida or detect rooted devices.

If you read last week’s issue, you’ll remember we dove deep into how to bypass detection, dump classes, and trace hooks even on hardened apps
📌 If you missed it, check it out here

But here's a quick refresher:

• Use Magisk DenyList to hide root
• Attach Frida after launch instead of before (frida -U -n com.app)
• Try Frida Codeshare scripts like:
  • anti-frida-detection.js
  • hide_frida_gum.js
  • anti-root-bypass.js
• If you crash immediately, dump loaded classes and log suspicious method calls
• Trace native logic with frida-trace or analyze .so files with Ghidra or r2frida

These tricks often give you visibility into how the app generates BLE packets or validates stored credentials.

Other Cool Things to Try

A few more test ideas that don’t always get enough love

📡 Timestamp manipulation

If tokens expire locally, try changing the device clock
Does it allow extending the token’s lifetime?

🌍 Geo-fencing bypass

If the app checks location before allowing access, try using mock location to simulate valid zones.

⏱️ Multi-device race conditions

What happens if two devices try to use the same credential simultaneously?
Does the system de-sync, crash, or unlock both?

Wrapping Up

Apps that interact with physical devices are high-impact targets they sit at the intersection of mobile security, hardware protocols, and real-world consequences

The good news?
You can test a lot with just a rooted phone, Wireshark, and a bit of scripting

To recap

✅ Sniff BLE traffic with Android’s HCI snoop log
✅ Reverse how commands are built and look for replay attacks
✅ Explore offline behavior and revocation handling
✅ Inspect how credentials are stored
✅ Bypass anti-Frida and trace BLE logic
✅ Get creative — timestamps, location spoofing, race conditions... they all matter

Hope this gives you a strong base to start testing apps that control hardware around you

Thanks for reading, and see you next time
Stay sneaky out there 🕶️

Ruben

Chapters

Reversing Android Apps: Bypassing Detection Like a Pro

Previous Issue

arrow_upward