mirror of
https://github.com/d4rken-org/capod.git
synced 2026-09-15 02:36:12 -04:00
darken
cc99ad59ab
On at least one vendor stack the address handed up by the BLE scan callback and the identity key stored for a profile disagree on octet order: the key resolves the address only when its octets are reversed. Identity resolution then fails on every advertisement, so no frame is attributed to the profile and the case popup, connection popup, encrypted 1% battery granularity and session reconnection all go with it. RPAChecker gains resolve(), which reports the order that resolved. The standard-order attempt is unchanged and ungated, so no currently-resolving device can start failing. The reversed attempt only runs when the reversed form carries the resolvable-private-address type marker (top bits 01), which skips roughly three quarters of the extra comparisons for generic random addresses. verify() is now a thin wrapper over resolve(). Address parsing is validated explicitly: exactly six components, each in 0..255. A seven-component string used to be silently mis-sliced, and "15A:..." truncated to a valid octet — both cases could resolve. The failure log no longer prints the identity key. A malformed address or key wrote an identity-tracking secret into exactly the debug logs users mail to support; the event and its level stay, the key is reduced to its length and the address goes through redactedForLogs(). The history lookup that recovers a device by key now skips candidates bound to a different profile. A 24-bit forward collision could already select the wrong history; attempting two orders roughly doubles that exposure. Test vectors are synthetic and derived from the key already committed in RPACheckerTest. Two of them are complementary: one has an RPA-shaped reversed form that fails the hash (proving the comparison runs), the other has a reversed form that resolves cryptographically but carries marker 00 (proving the gate runs).