A connected-device maker needed an attacker’s view of its lock before launch, both for its own release and because a customer required independent testing. Over a multi-week engagement, ioSENTRIX tested the device from the circuit board to the update channel.
These were logic flaws on a failure path, not known vulnerabilities, so an automated scanner had nothing to match them against. Finding them took reading the firmware source against the production binary and testing the hardware by hand.
Also found: a stack overflow on long card UIDs, UID cloning on legacy cards, a flash-read overflow, build paths in the binary and missing NULL checks in update handlers.
Two ways to open the lock without a trace, both closed and verified.
The firmware’s check for the expected card application used a bitwise OR, so every card passed it. When the MIFARE DESFire cryptographic step then failed, the firmware fell back to the card’s UID alone, an identifier read before any key is used.
Business impact. Card entry, the product’s core promise, could be defeated with a copied identifier instead of a stolen card.
There was no tamper detection. Inside, our testers found ways to drive the lock open directly, bypassing its processor, so no unlock event, log entry or alert reached the portal.
Business impact. A break-in by this route would leave no trace, for the customer or the maker.
The physical bypass methods are deliberately withheld from this publication.
We found that a copied card ID could open the door, and that anyone inside the enclosure could open it with nothing logged. The client rolled out fixes for every finding within 30 days, and ioSENTRIX retested each one.
10+ findings in total, including 2 High.
✓ Verification: All fixes rolled out within 30 days · verified by ioSENTRIX retest.
The encryption was sound. The way in was what the lock did when encryption failed.
The encryption was sound. The fallback was the way in.
It identifies a card. It does not prove the card is genuine.
Limit exposed interfaces and watch telemetry (ETSI EN 303 645, 5.6-3 and 5.10-1).
Details in this case study are anonymised and generalised. Methods that could harm other products are withheld.
A connected-device maker needed an attacker’s view of its lock before launch, both for its own release and because a customer required independent testing. Over a multi-week engagement, ioSENTRIX tested the device from the circuit board to the update channel.
A copied card ID was enough to open the door. Card entry, the product’s core promise, could be defeated with a copied identifier instead of a stolen card.
10+ findings in total, including 2 High.
All fixes rolled out within 30 days · verified by ioSENTRIX retest.
IoT and embedded device penetration testing, delivered by the ioSENTRIX hardware and firmware testers.
