B-hyve Android App Analysis: An Exposed API Key and Device Commands

The most consequential result of this B-hyve app analysis wasn't buried in the device firmware. It was a Google Maps API key in the Android app's shipped bundle. At the time of testing, the key accepted requests to several Maps services outside the app.

The same bundle contained backend environment references and device-command schemas. Those are useful inputs to a security assessment, but they need a different interpretation: knowing where a service lives or how a command is formatted does not establish that an unauthenticated person can use it.

This article covers B-hyve Smart Home for Android, package com.orbit.orbitsmarthome, version 3.0.53, analyzed on June 5, 2026. The findings were reported to the vendor under a 90-day responsible disclosure timeline before publication. The API key and other sensitive values are not included here.

Scope and method

The work focused on the shipped APK. The app uses ClojureScript compiled for React Native, with application logic distributed as Hermes bytecode.

The analysis followed these steps:

1. Extract the installed APK over ADB.
2. Unpack it with apktool and decompile the Hermes bundle into a readable JavaScript representation.
3. Inspect the Android manifest for exported components and backup settings.
4. Review roughly 100 MB of recovered JavaScript for embedded credentials, service endpoints, and message definitions.
5. Cross-check those observations against the infrastructure references in the app.

This was primarily static analysis, with limited live requests to check the exposed API key. It did not include fuzzing or exploitation of live devices. The results below distinguish what was visible in the bundle from what was demonstrated against a service.

An API key usable outside the app

The bundle contained a Google Maps API key. During testing, requests using that key succeeded against the Geocoding, Static Maps, and Places APIs outside the Android app.

That matters because a key intended for one app can become a billing and quota problem if other people can use it. These checks demonstrated use outside the intended client; they did not establish actual third-party abuse, financial loss, or access to B-hyve user accounts. They also don't establish the key's current status months after the analysis.

An API key's presence in a mobile binary is not, by itself, the defect. Some client SDKs require keys that users can extract. The protection comes from restrictions appropriate to the API and client, not from keeping the binary difficult to read.

For Android SDK use, that can include package-name and signing-certificate restrictions, alongside restrictions on the APIs the key may call. Direct web-service calls need their own review: an Android restriction is not a universal fix for every Maps endpoint. Google's Maps Platform security guidance describes the supported combinations and recommends separating client-side and server-side usage.

Any remediation should account for deployed app versions. Restricting or rotating a production key without checking legitimate usage can break older clients.

Production and non-production backend references

The recovered code named production, release-candidate, and alpha environments. It also referenced several transports and storage services:

A mobile client has to know how to reach its backend. Production hostnames are therefore expected to be discoverable. Non-production references are worth reviewing because they identify additional environments to include in the assessment, not because an alpha hostname proves weaker security.

The next questions would be whether those environments are reachable, what credentials they accept, and whether test and production data are properly separated. This analysis did not establish unauthorized access to those services.

For release engineering, removing unused environment configuration is sensible housekeeping. It is not a substitute for authenticating requests and isolating environments.

Device-command schemas in the bundle

The JavaScript bundle included an OrbitPbApi protobuf schema as a string literal. Its message definitions covered network setup, settings changes, device resets, and firmware updates.

Several definitions deserve attention during follow-up testing:

• NetworkConnect includes a WiFi passphrase field.
• SetSettings includes a serverHostName field.
• ResetDevice describes a reset operation.
• Other messages describe the OTA firmware update protocol.

A second namespace, BhyveAgApi, included RadioConfigure messages with SSH and WiFi credential fields. Field definitions are not evidence that actual user credentials were embedded in the app.

The serverHostName field is particularly relevant to a device assessment. If accepted without adequate authorization, a backend-setting change could have serious consequences. The schema alone does not show that such a change is possible, who can request it, or what validation the device performs.

Removing readable schemas may reduce the convenience of reverse engineering, but command formats should not be treated as secrets. The controls worth testing are authorization, credential handling, permitted configuration changes, and firmware-update verification.

What the analysis does not establish

These observations apply to the analyzed Android version and the limited checks described above. They are not evidence about every B-hyve release or a complete assessment of the product.

In particular, this work did not demonstrate an account takeover, unauthorized irrigation control, a device accepting an attacker-selected backend, or installation of an unauthorized firmware image. It also did not quantify exposure through backend logs or cloud billing records.

This writeup does not assign formal severity scores. The API-key behavior and the visible protocol definitions have different evidentiary weight, and a rating should account for demonstrated impact and access prerequisites.

What to check in your own companion app

Start with the release artifact, not just the source tree. Unpack the same binary a customer receives and check what it contains.

• Review each embedded key. Identify its owner, permitted services, application restrictions, and expected usage. Check whether it works outside the intended client.
• Separate environments. Remove unused test configuration from release builds, and verify that non-production services cannot expose production data or accept credentials they shouldn't.
• Test sensitive commands at the receiving end. Settings changes, resets, network provisioning, and firmware updates need authorization and validation regardless of how much of the protocol is public.
• Include the app in release checks. Secret scanning and a software-component inventory should cover the mobile client as well as the device firmware.

The distinction is practical: a visible hostname might be normal, a visible schema might be necessary, and a key that permits unintended billable requests needs remediation. Treating all three as the same class of problem makes an assessment less useful.

Where the Cyber Resilience Act fits

The EU Cyber Resilience Act covers hardware and software products with digital elements, subject to its scope and exclusions. A connected-product assessment should consider the companion software and remote services it depends on, rather than stopping at the firmware. The exact regulatory treatment depends on how the product and software are supplied and used.

The European Commission's CRA overview gives the key dates: reporting obligations began applying on September 11, 2026, and the main obligations apply from December 11, 2027.

An exposed protocol definition is not automatically a CRA violation. The useful compliance question is whether the manufacturer has assessed the relevant risks and implemented appropriate controls. For more on preparation, see our CRA essentials guide.

Disclosure and remediation status

The findings were documented and reported to the vendor under a 90-day responsible disclosure timeline before this article was published. Sensitive values are withheld.

No vendor response, confirmed fix, or remediation retest is documented in this article. The observations describe the analysis date, not a claim that the same behavior remains present today.

References

• Google Maps Platform API security best practices
• European Commission: Cyber Resilience Act

If you're reviewing a connected product, our connected-product security assessments cover the device, companion app, and cloud interfaces together.