Is your software on dope? Formal analysis of surreptitiously "enhanced" programs

TL;DR

This paper introduces formal definitions to detect software doping, a phenomenon where manufacturers subtly alter software for dubious reasons, and demonstrates how existing verification techniques can be applied for analysis.

Contribution

It provides a hierarchy of formal definitions to identify doped software and shows how to apply existing verification methods like self-composition and model checking for detection.

Findings

Formal definitions effectively distinguish doped from clean software.

Verification techniques like self-composition can analyze doping.

Model checking of HyperLTL formulas aids in detection.

Abstract

Usually, it is the software manufacturer who employs verification or testing to ensure that the software embedded in a device meets its main objectives. However, these days we are confronted with the situation that economical or technological reasons might make a manufacturer become interested in the software slightly deviating from its main objective for dubious reasons. Examples include lock-in strategies and the $\mathrm{NO}_x$ emission scandals in automotive industry. This phenomenon is what we call software doping. It is turning more widespread as software is embedded in ever more devices of daily use. The primary contribution of this article is to provide a hierarchy of simple but solid formal definitions that enable to distinguish whether a program is clean or doped. Moreover, we show that these characterisations provide an immediate framework for analysis by using already existing verification techniques. We exemplify this by applying self-composition on sequential programs and model checking of HyperLTL formulas on reactive models.