Android and iOS

Why timing-based checks are fragile

Code tampering, account abuse, data exposure and client manipulation.

Threats and abuse1 min readEditorial methods

Execution-time deviations can indicate interference, but limited hardware, load and system behavior can produce similar effects. Timing alone should not determine that an attack occurred.

Evaluation approach

CPU load, thermal throttling, background work and power-saving modes change latency. One threshold should not be applied identically across all devices.

Application example

Compare delays on an older device or in low-power mode with those observed during authorized laboratory interference.

Limits and considerations

Slowness alone is not evidence of a debugger or hooking.

The gap between checking and using data

A resource can change between verification and use. Preserve the relationship between the data assessed by a security decision and the data actually processed. A much earlier clean-environment result should not be carried into every later operation.

Fresh assessment near sensitive operations and server-side transaction binding can help. If content changes during a retry, earlier approval must not remain valid. Cover concurrent and delayed flows as well as a normal single request.

Checks and decisions

  • Create device cohorts
  • Vary load conditions
  • Use multiple signals

Treat timing as supporting evidence rather than a definitive verdict.

Sources

The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.