Mass Scale Hijacking Threatens Rentable IoT

BlackHat Asia 2026 brought a blunt warning on Mass Scale Hijacking. Tsinghua University hardware researcher Hu Tian Shu, who goes by Mori Shu, showed how rentable IoT systems for shared bikes, scooters and EV chargers can be hijacked remotely at city scale.

The work covers 17 physical devices and 92 related mobile apps and mini apps, including 81 Chinese Android and WeChat mini programs plus 11 European iOS apps. A related USENIX Security 2024 paper from the same group reported 57 vulnerabilities in 28 products, with 24 enabling large-scale exploitation.

Why rentable IoT breaks differently

Rentable IoT is not smart home IoT behind a firewall. Devices sit in public, are centrally managed, and trigger physical actions like unlock and start-charge on backend command.

The architecture is simple and direct. App talks to backend, backend talks to a cellular IoT controller, controller drives the lock or contactor. That cloud control plane is physically consequential.

How the hardware gives itself away

Hu's team found exposed debug interfaces, extractable firmware, recoverable network traces and shared authentication keys hardcoded in firmware. The reverse engineering was easier than it should have been on multiple vendors.

The method is methodical and low-voltage. The team isolates the controller power domain and brings up only MCU, flash, clock and reset to observe boot and dump firmware without energizing high-voltage stages. Where live debug is locked, they go chip-off on NAND, eMMC or SPI flash or rebuild a minimal runnable environment in a socket.

Even chips without an obvious connector still expose UART, SWD or JTAG via hidden test pads and factory pins. One cellular chip allowed enabling debug logs via AT commands, which leaked internal payloads straight from the pin trace.

The phantom client and app-to-service abuse

Firmware extraction yields backend domains, protocol names, identifiers and credentials. The team re-implements the device protocol in Python and reuses recovered credentials to build phantom clients.

If the backend accepts the phantom, three impacts follow. State can be spoofed to mislead users and operators, real devices can be forced offline through connection conflicts, and billing can be desynchronized to allow free use.

The app side scales even faster. By reversing how 92 apps build requests and testing real QR codes with black-box API replays, the team found two buckets of flaws: abuse devices directly such as bypass payment or control another user's ride, and abuse other users such as leak data or hijack accounts.

Why short IDs turn one bug into a fleet bug

A short ID alone is not a vulnerability. It becomes one when it sits on the security boundary without proper authentication or authorization.

Three identifiers recur. User IDs for accounts, device serial numbers visible on QR codes, and internal device IDs used by firmware to connect to the IoT service. When any are sequential or guessable and the backend does not check who may act on what, enumeration plus an IDOR or weak shared key turns one exploit into thousands.

The data set shows how common that pattern is. App flaws with replayable requests affect both account and device control, and device impersonation works with device ID plus a shared key. Automation does the rest across a large fleet deployed in one city.

Live demos: from GeekPwn to Singapore to Shanghai

The talk includes two demos. The first is video from GeekPwn 2023, where the team started a charger session via the target app, recorded a device ID, fed it to a script, and then stopped and restarted charging remotely.

The second was live in Singapore. Hu selected Shanghai near People's Square in a Chinese charging provider's app, copied an available charger's ID into a script, and its map icon flipped from green to gray, indicating a disabled port. He argued the same technique could deny service across a city's network, and tests of 11 European bike and scooter apps showed similar problems.

Why this matters for EV and shared mobility operators

Public chargers combine payments, cellular connectivity, cloud management and grid-facing hardware. One disabled charger is support ticket. Thousands disabled is operational and reputational failure, and it lands as governments push EV adoption.

This is not isolated. Pwn2Own Automotive awarded multiple $60,000 bounties for EV charger exploits in Emporia, ChargePoint, Ubiquiti, Phoenix and JuiceBox units, including stack overflows and hard-coded keys. Tencent researchers have also shown CAN bus attacks against chargers. Hu's work links those device bugs to a systemic backend ID and authorization gap.

Vendors acknowledged the findings and worked on mitigations, but the pattern persists across categories. StartupHub.ai data shows how fragmented trust is in adjacent identity and data tooling, with our own StartupHub score at 9/100 trailing Eterny at 35/100 and Gretel.ai at 85/100, while Emberkeep and Legacynet both sit at 8/100. The market still lacks default, verifiable device identity.

The fix list is concrete and unglamorous. Unique per-device credentials and a hardware root of trust, server-side authorization on every app and device request, non-sequential unpredictable IDs, debug ports and AT log modes disabled in production, and abuse detection for enumeration and phantom connections. Without that, rentable IoT remains app-controlled infrastructure with consumer IoT security.