Hetian Shi (Tsinghua University) studied "rentable IoT": shared e-scooters and e-bikes, EV chargers, power banks, washing machines and other public devices you unlock with a QR code. These are centrally managed, public-facing and physically consequential. Across 17 physical devices and 92 mobile apps, the team found that flaws which look local (a debug port, a shared key, one broken API) become fleet-scale attacks because devices are identified by short, sequential IDs that can be enumerated. They call the effect IDScope. Findings: 23 vulnerabilities in 14 devices, 34 in 23 apps, 18 CVE/CNNVD/NVDB identifiers, with impacts from free charging and free rides to fleet-wide denial of service and account hijacking. All were responsibly disclosed.
Post 25 of my Black Hat Asia 2026 series. This is another IoT-scale story, complementary to TORCHLIGHT. I describe the architecture, the bug classes and the fixes, and I leave out device-specific procedures.
1. Why rentable IoT is different
A smart lock in your home affects you. A rentable device sits in public, is used by strangers, and is run from one backend that controls thousands or millions of units. Three properties raise the stakes:
- Public-facing: anyone can walk up, scan the QR code and interact.
- Centrally managed: one server holds the state of the whole fleet.
- Physically consequential: bugs cause real effects, such as unlocked scooters, energised chargers or lost revenue.
Architecturally there are four parts: the user app (often a WeChat mini-program in China), the backend server, a cellular IoT controller in the device (commands arrive over 4G/5G), and the physical lock or charger. A rental works like this: you scan a QR code containing the device serial number, the server checks your account and payment, finds the device by serial, authenticates the device connection using its device ID and key, then sends an unlock command.
Fig. 1 — The rentable-IoT chain: app, backend, controller, physical device.
2. Method: two phases
- Phase 1: find vulnerabilities in the device-to-server and app-to-server access control. Reverse the device protocols and app APIs, then test authentication and authorisation.
- Phase 2: test whether they scale. Check whether the flaw can be applied to other devices or users by enumerating identifiers.
The study scope: 17 physical devices (leading EV chargers, e-bike and phone-charging outlets, washing machines, a shared bicycle) and 92 apps (including 64 WeChat mini-programs or Android apps in China and 11 iOS e-scooter apps in Europe). Devices were bought lawfully or obtained with vendor cooperation, tested in controlled settings, and no live deployments or real users were targeted.
The threat model is modest: an attacker needs only a mobile app and, for hardware work, a limited number of devices. Four interfaces can be attacked: app to server (unauthenticated or unauthorised API calls), device to server (impersonating a device), the cellular network (intercepting traffic), and the local hardware.
3. Hardware: why reverse engineering is easy
Most devices had no hardware protections. Network messages were often unencrypted, debug ports were exposed or reachable, and firmware could be read. Even where no debug header was present, chip-level access (debug pads or, if read-protection was on, removing the memory chip) allowed recovery. The important idea is that the real barrier is not a missing header but whether the chip can still be physically reached and electrically reconstructed. Recovered firmware then exposes the message format, device IDs, secret keys and the backend endpoint, so hardware reverse engineering becomes the entry point to cloud reverse engineering.
A significant number of devices also hard-coded a common key shared by every unit. Once one device is opened, the fleet's authentication secret is known.
4. Phantom clients: becoming the device
With the protocol and keys recovered, the team wrote phantom clients: software that speaks the device's protocol and reconnects to the server pretending to be a real unit. That let them test whether the server properly authenticates and authorises device-originated requests. The hazards found:
| Hazard | What it means |
|---|---|
| State spoofing | Falsify a device's reported state, hindering users and operators |
| Device DoS | A phantom reconnect can push the real device off the server so it becomes unusable |
| Free use | Stop billing while the real device stays unlocked |
5. Companion-app flaws
Apps and mini-programs were reversed and black-box tested. Two families of problems appeared:
- Exploiting devices via APIs: vertical or horizontal privilege escalation, bypassing payment, and unauthorised device-control calls.
- Exploiting other users: accessing other users' profiles and devices, stealing private data, and hijacking accounts to rent or return devices.
A recurring root cause is the classic IDOR (insecure direct object reference): the API takes an identifier and returns or acts on that object without confirming the caller is allowed to.
6. IDScope: weak identifiers as the multiplier
Each bug alone might affect one device. Predictable IDs make it affect all of them. Three kinds of identifier appear in these products:
- User ID: distinguishes accounts. Many products leak them or use sequential numbers.
- Device serial number: printed in the QR code and sometimes typed by users to rent a specific device.
- Device ID: used by firmware to connect and register to the server, which authenticates the device with it.
Short, human-friendly numeric serials plus large fleets mean the ID space is small, so identifiers can be enumerated. Combine that with a broken authorisation check or a shared key and a local weakness becomes a fleet-wide one. Documented impact classes:
| Domain | Fleet-scale impact |
|---|---|
| EV charging | Free charging, fleet-scale denial of service, unauthorised charger manipulation |
| Shared mobility | Privacy leakage, account hijacking, unauthorised device control, free rides at scale |
The deck includes live demonstrations of unauthorised charger activation and persistent denial of service by forcing devices offline.
7. Why these weaknesses persist
The talk's discussion is refreshingly honest: the root cause is convenience over trust.
- Short IDs exist because humans read and type them.
- Common keys make provisioning and backend coordination simple: device credentials must exist in several places, which pushes vendors toward simplified key management.
- At fleet scale, these convenience choices become liabilities.
8. Defensive strategies
- Per-device credentials: unique keys, ideally rooted in secure hardware, never a fleet-wide shared key.
- Strong identifiers: long, random, non-sequential IDs. Keep the short human code separate from the authenticating secret.
- Object-level authorisation: every API checks that the caller may act on this device or user.
- Encrypt and authenticate device traffic so cellular messages cannot be read or forged.
- Lock down hardware: disable debug interfaces, enable read protection, encrypt firmware storage.
- Abuse detection: rate limits and anomaly detection. The authors also suggest decoy IDs interleaved among real IDs: if several decoys are touched, it triggers an enumeration alarm.
Responsible disclosure produced 23 device vulnerabilities across 14 devices and 34 app vulnerabilities across 23 apps, with 18 identifiers assigned.
Why does an ID matter so much?
If an attacker can guess or count identifiers, any per-device or per-user weakness can be repeated against every object. Unpredictable identifiers alone do not fix authorisation bugs, but they remove the easy path to scale.
What is a phantom client?
A software imitation of the device that speaks its protocol and holds its credentials, used to test whether the server truly authenticates devices.
Is hardware access really required?
For some findings yes, but many app-side flaws needed only the mobile app. The hardware work supplies protocol and key material that makes the backend testable.
What should operators of rentable devices do first?
Audit authorisation on every API, remove shared device keys, and move to unpredictable identifiers. Then add monitoring for enumeration.
Takeaways
- Rentable IoT is centrally controllable physical infrastructure, not just app-connected gadgets.
- Predictable identifiers are the scale amplifier that turns local bugs into fleet-wide attacks.
- Findings across 17 devices and 92 apps: 57 vulnerabilities and 18 assigned identifiers.
- Hardware access leaks protocol, keys and backend endpoints, which opens the cloud side.
- Fix identifiers, device identity and backend authorisation together, and add abuse detection such as decoy IDs.
References & further reading
- Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
- Official talk recording on YouTube — Black Hat channel.
- Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
- OWASP API1: Broken Object Level Authorization — the IDOR class at the heart of the app-side bugs.
- OWASP IoT project — IoT security guidance.
- CVE program — identifiers assigned for the disclosed issues.