Engineering
Beyond the SDK
Reverse Engineering a Commercial Wearable to Access Proprietary Physiological Data
Engineering Case Study • Bluetooth Low Energy • Wearables
Built while developing Learnzy.
| Project Type | Engineering Case Study |
| Category | Reverse Engineering · Bluetooth Low Energy · Wearables |
| Built For | Learnzy |
| Author | Himanshu Gupta |
| Status | Prototype Complete |
| Part of | LearnzyLabs |
Executive Summary
This project did not begin as a reverse engineering project.
It began with a simple product requirement.
I needed continuous physiological data from a wearable device.
My initial instinct was to build the hardware myself. I spent weeks learning PCB design, breadboarding sensors, designing prototype boards, and understanding embedded electronics.
Eventually I realized I was solving the wrong problem.
Building hardware was only a small part of creating a wearable product. Manufacturing, miniaturization, testing, battery optimization, enclosure design, and certification were significantly larger challenges.
Instead of continuing down that path, I changed strategy.
Rather than building the hardware, I decided to buy an existing commercial device and focus on owning the data instead.
That decision ultimately led to reverse engineering the Bluetooth protocol of an OEM smart ring after the manufacturer’s SDK proved insufficient for my requirements.
The outcome was a custom Android application capable of discovering the ring, establishing BLE communication, decoding proprietary packets, streaming HRV data, extracting RR intervals, reading sleep stages, and exposing physiological measurements that were previously inaccessible through the official SDK.
Context
The original objective was straightforward.
I needed access to physiological measurements such as:
- Heart Rate
- Heart Rate Variability (HRV)
- RR Intervals
- Sleep Stages
- Battery Status
- Continuous Streaming
The obvious assumption was:
If I need wearable data, I should build a wearable.
That assumption drove the first phase of the project.
Phase One: Building the Hardware
I began learning embedded electronics from scratch.
Topics included:
- PCB Design
- Circuit Design
- Sensor Integration
- Embedded Components
- CAD Software
- PCB Fabrication
The first prototype used:
- ESP32 Xiao
- MAX30102
- ADXL345
- Temperature Sensors
- GSR Sensors
I designed prototype PCBs, ordered fabricated boards, and assembled early hardware prototypes.
flowchart TD
A[Research] --> B[Breadboard Prototype]
B --> C[PCB Design]
C --> D[PCB Fabrication]
D --> E[Hardware Prototype]
The Realization
Several weeks into development I realized something important.
Building a functioning PCB was not the difficult part.
The difficult parts were:
- Miniaturization
- Industrial Design
- Battery Optimization
- Waterproofing
- Manufacturing
- Reliability Testing
- Mechanical Engineering
I wasn’t trying to become a wearable hardware company.
I simply needed reliable physiological data.
That realization completely changed the direction of the project.
The Pivot
Instead of asking:
How do I build a wearable?
I asked:
Does somebody already manufacture one?
Evaluating Existing Hardware
I researched existing wearables.
| Option | Pros | Cons |
|---|---|---|
| Whoop | High quality · reliable | Expensive · closed ecosystem · no raw physiological access |
| Commercial smart rings | Compact · available | Proprietary SDK · limited access |
| OEM manufacturers | Direct hardware access · sample devices available | Documentation gaps · protocol ambiguity |
After searching multiple OEM catalogs and hardware marketplaces, I contacted several manufacturers directly.
Eventually I imported multiple sample smart rings for experimentation.
The New Bottleneck
Now I had the hardware.
The next challenge appeared immediately.
The SDK.
The manufacturer provided an Android SDK.
Initially this seemed ideal.
Unfortunately it only exposed a small subset of the available functionality.
The information I actually needed remained hidden behind proprietary Bluetooth communication.
The problem was no longer hardware.
It was protocol access.
Existing Solution
The obvious approach was to use the SDK exactly as intended.
flowchart TD
A[Ring] --> B[Official SDK]
B --> C[Limited Data]
That wasn’t sufficient.
I needed access beyond the SDK.
Alternative Approaches Considered
| Option | Decision | Reason |
|---|---|---|
| Accept SDK limitations | Rejected | Insufficient access |
| Find another wearable | Rejected | Most consumer devices expose similar limitations |
| Hire a reverse engineering specialist | Attempted | Despite multiple attempts, the protocol remained unresolved |
| Learn reverse engineering | Selected | Protocol access became the critical dependency |
Whiteboard Thinking
At this point I faced three options.
flowchart LR
A[Abandon Project] --- B[Hire Specialist]
B --- C[Learn Reverse Engineering]
C --> D[Selected]
The First Attempt
Like most beginners, I started by decompiling the application.
Everything looked important.
Thousands of classes.
Obfuscated code.
No obvious Bluetooth implementation.
Weeks passed with almost no progress.
The mistake wasn’t technical.
The mistake was trying to understand everything.
First Principles
I stepped away from the code and returned to the original question.
I wasn’t trying to understand the application.
I was trying to understand the protocol.
Those are very different problems.
Instead of asking:
What does this application do?
I started asking:
- Where is BLE initialized?
- Which classes establish the connection?
- Which services discover characteristics?
- Which packets request sleep data?
- Which packets stream HRV?
- Where are RR intervals parsed?
The search space became dramatically smaller.
Reasoning Process
Old approach:
flowchart TD
A[APK] --> B[Read Everything]
B --> C[Understand Everything]
C --> D[Impossible]
New approach:
flowchart TD
A[Desired Data] --> B[BLE Module]
B --> C[Connection Classes]
C --> D[Packet Parser]
D --> E[Characteristic Mapping]
E --> F[Protocol]
This change in thinking ultimately became one of the inspirations behind Reason.
Final Architecture
flowchart TD
A[OEM Smart Ring] --> B[Bluetooth Low Energy]
B --> C[Proprietary Packet Stream]
C --> D[Reverse Engineered Protocol]
D --> E[Android BLE Client]
E --> F[Packet Parser]
F --> G[Decoded Physiological Data]
G --> H[Research Dataset]
Prototype Application
The application intentionally had almost no visual design.
Its purpose was engineering validation, not user experience.
The prototype supported:
Device Discovery
- BLE scanning
- Device identification
- RSSI monitoring
Device Connection
- Pairing
- Connection management
- Battery status
- Session control
Continuous HRV Streaming
- Live HRV packets
- Continuous monitoring
- Session logging
Sleep Data Extraction
- Sleep stages
- Duration
- Deep Sleep
- REM
- Light Sleep
Raw Data Access
Successfully extracted:
- Heart Rate
- HRV
- RR Intervals
- Sleep Stages
- Battery Status
- Continuous Sensor Events
Engineering Decisions
| Decision | Reason |
|---|---|
| Stop building custom hardware | Hardware manufacturing was not the leverage point |
| Purchase OEM hardware | Commodity hardware already existed |
| Reject SDK limitations | Required data remained inaccessible |
| Learn reverse engineering | The protocol became the critical dependency |
| Build a dedicated Android prototype | Fastest environment for validating extracted packets |
Trade-offs
Advantages
- Full control over physiological data.
- Independence from SDK limitations.
- Rapid experimentation.
- Lower development cost.
- Reusable protocol knowledge.
Limitations
- Reverse engineering required significant time.
- Protocol changes could break compatibility.
- Device dependent.
- OEM firmware updates remain a risk.
What I Learned
This project completely changed how I think about engineering.
Initially I believed I needed to build the hardware.
Eventually I realized the hardware was not where the value existed.
The real value was understanding the communication protocol.
More importantly, I learned another lesson.
Reverse engineering is not about reading more code.
It’s about reducing uncertainty.
Once I stopped trying to understand the entire application and instead searched only for the specific components that could answer my questions, progress accelerated dramatically.
The project became less about reverse engineering software and more about designing a better reasoning process.
Future Direction
Potential future work includes:
- Automatic firmware compatibility detection
- Packet documentation
- Multi-device support
- Protocol abstraction layer
- Cross-platform BLE implementation
- Real-time physiological dashboards
Project Outcome
The final prototype successfully demonstrated that proprietary physiological data could be accessed without relying on the manufacturer’s SDK.
The project evolved from hardware prototyping into protocol ownership.
The most valuable outcome wasn’t the Android application or the decoded packets.
It was the realization that engineering leverage often comes from identifying which layer of the system actually matters.
I didn’t need to manufacture better hardware.
I needed to understand the language the hardware was already speaking.