During police investigations, the possibility of extracting coordinates data of a vehicle without relying on GPS is vital because the targets may know about possible bugs using this technology and take action against them. To this aim, extracting non-encrypted data from the Controller Area Network (CAN) provides a valid solution for officers. Indeed, CAN exchanges non-encrypted data, including physical information about the car’s movement. In this paper, we present On Path Diagnostic - Intrusion & Inference (OPD-II), a novel path inference attack leveraging a physical car model and a map matching algorithm to infer the path driven by a car based on CAN bus data. Unlike available attacks, our approach only requires the attacker to know the initial location and heading of the victim’s car and is not limited by the availability of training data, road configurations, or the need to access other victim’s devices (e.g., smartphones). We implement our attack on a set of four different cars and a total number of 59 tracks in different road and traffic scenarios. We achieve an average 95.75% accuracy in reconstructing the coordinates of the recorded path by leveraging a dynamic map matching algorithm that outperforms other state-of-the-art proposals while removing their set of assumptions.

The focus on rapid software delivery inevitably results in the accumulation of technical debt, which, in turn, affects quality and slows future development. Our primary aim is to discover how companies keep their codebases maintainable and how code improvements might be automated. Method: we investigate Meta practices by collaborating with engineers on code quality (via action research) and by analyzing rich source code change history using mixed-methods to reveal a range of practices used for continual improvement of the codebase. Results: Code improvements at Meta range from completely organic grass-roots done at the initiative of individual engineers, to regularly blocked time and engagement via gamification of Better Engineering (BE) work, to major explicit initiatives aimed at reengineering the complex parts of the codebase or deleting accumulations of dead code. Over 14% of changes are explicitly devoted to code improvement and the developers are given "badges" to acknowledge the type of work and the amount of effort. Based on the interactions with development teams we suggest metrics to help prioritization of code improvement efforts. Finally, our models of the impact of reengineering activities revealed substantial improvements in quality and speed and reductions in code complexity. Overall, code improvement activities are relatively effort intensive yet simple enough to be prime targets for automation.