arXiv subjects

Bart Coppens

Publications and source records attributed to Bart Coppens.

12 recordsLinked to original sources

arXiv2026

Empirical Studies on Adversarial Reverse Engineering with Students

Empirical research in reverse engineering and software protection is crucial for evaluating the efficacy of methods designed to protect software against unauthorized access and tampering. However, conducting such studies with professional reverse engineers presents significant challenges, including access to professionals and affordability. This paper explores the use of students as participants in empirical reverse engineering experiments, examining their suitability and the necessary training; the design of appropriate challenges; strategies for ensuring the rigor and validity of the research and its results; ways to maintain students' privacy, motivation, and voluntary participation; and data collection methods. We present a systematic literature review of existing reverse engineering experiments and user studies, a discussion of related work from the broader domain of software engineering that applies to reverse engineering experiments, an extensive discussion of our own experience running experiments ourselves in the context of a master-level software hacking and protection course, and recommendations based on this experience. Our findings aim to guide future empirical studies in RE, balancing practical constraints with the need for meaningful, reproducible results.

cs.SE↗

arXiv2024

reAnalyst: Scalable Annotation of Reverse Engineering Activities

This paper introduces reAnalyst, a framework designed to facilitate the study of reverse engineering (RE) practices through the semi-automated annotation of RE activities across various RE tools. By integrating tool-agnostic data collection of screenshots, keystrokes, active processes, and other types of data during RE experiments with semi-automated data analysis and generation of annotations, reAnalyst aims to overcome the limitations of traditional RE studies that rely heavily on manual data collection and subjective analysis. The framework enables more efficient data analysis, which will in turn allow researchers to explore the effectiveness of protection techniques and strategies used by reverse engineers more comprehensively and efficiently. Experimental evaluations validate the framework's capability to identify RE activities from a diverse range of screenshots with varied complexities. Observations on past experiments with our framework as well as a survey among reverse engineers provide further evidence of the acceptability and practicality of our approach.

cs.SE↗

arXiv2024

A Context-Sensitive, Outlier-Based Static Analysis to Find Kernel Race Conditions

Race conditions are a class of bugs in software where concurrent accesses to shared resources are not protected from each other. Consequences of race conditions include privilege escalation, denial of service, and memory corruption which can potentially lead to arbitrary code execution. However, in large code bases the exact rules as to which fields should be accessed under which locks are not always clear. We propose a novel static technique that infers rules for how field accesses should be locked, and then checks the code against these rules. Traditional static analysers for detecting race conditions are based on lockset analysis. Instead, we propose an outlier-based technique enhanced with a context-sensitive mechanism that scales well. We have implemented this analysis in LLIF, and evaluated it to find incorrectly protected field accesses in Linux v5.14.11. We thoroughly evaluate its ability to find race conditions, and study the causes for false positive reports. In addition, we reported a subset of the issues and submitted patches. The maintainers confirmed 24 bugs.

cs.SE↗

arXiv2023

Evaluation Methodologies in Software Protection Research

Man-at-the-end (MATE) attackers have full control over the system on which the attacked software runs, and try to break the confidentiality or integrity of assets embedded in the software. Both companies and malware authors want to prevent such attacks. This has driven an arms race between attackers and defenders, resulting in a plethora of different protection and analysis methods. However, it remains difficult to measure the strength of protections because MATE attackers can reach their goals in many different ways and a universally accepted evaluation methodology does not exist. This survey systematically reviews the evaluation methodologies of papers on obfuscation, a major class of protections against MATE attacks. For 571 papers, we collected 113 aspects of their evaluation methodologies, ranging from sample set types and sizes, over sample treatment, to performed measurements. We provide detailed insights into how the academic state of the art evaluates both the protections and analyses thereon. In summary, there is a clear need for better evaluation methodologies. We identify nine challenges for software protection evaluations, which represent threats to the validity, reproducibility, and interpretation of research results in the context of MATE attacks and formulate a number of concrete recommendations for improving the evaluations reported in future research papers.

cs.CR↗

arXiv2023

Design, Implementation, and Automation of a Risk Management Approach for Man-at-the-End Software Protection

The last years have seen an increase in Man-at-the-End (MATE) attacks against software applications, both in number and severity. However, software protection, which aims at mitigating MATE attacks, is dominated by fuzzy concepts and security-through-obscurity. This paper presents a rationale for adopting and standardizing the protection of software as a risk management process according to the NIST SP800-39 approach. We examine the relevant constructs, models, and methods needed for formalizing and automating the activities in this process in the context of MATE software protection. We highlight the open issues that the research community still has to address. We discuss the benefits that such an approach can bring to all stakeholders. In addition, we present a Proof of Concept (PoC) decision support system that instantiates many of the discussed construct, models, and methods and automates many activities in the risk analysis methodology for the protection of software. Despite being a prototype, the PoC's validation with industry experts indicated that several aspects of the proposed risk management process can already be formalized and automated with our existing toolbox and that it can actually assist decision-making in industrially relevant settings.

cs.SE↗

arXiv2020

Flexible Software Protection

To counter software reverse engineering or tampering, software obfuscation tools can be used. However, such tools to a large degree hard-code how the obfuscations are deployed. They hence lack resilience and stealth in the face of many attacks. To counter this problem, we propose the novel concept of flexible obfuscators, which implement protections in terms of data structures and APIs already present in the application to be protected. The protections are hence tailored to the application in which they are deployed, making them less learnable and less distinguishable. In our research, we concretized the flexible protection concept for opaque predicates. We designed an interface to enable the reuse of existing data structures and APIs in injected opaque predicates, we analyzed their resilience and stealth, we implemented a proof-of-concept flexible obfuscator, and we evaluated it on a number of real-world use cases. This paper presents an in-depth motivation for our work, the design of the interface, an in-depth security analysis, and a feasibility report based on our experimental evaluation. The findings are that flexible opaque predicates indeed provide strong resilience and improved stealth, but also that their deployment is costly, and that they should hence be used sparsely to protect only the most security-sensitive code fragments that do not dominate performance. Flexible obfuscation therefor delivers an expensive but also more durable new weapon in the ever ongoing software protection arms race.

cs.CR↗

arXiv2020

Man-at-the-End Software Protection as a Risk Analysis Process

The last years have seen an increase of Man-at-the-End (MATE) attacks against software applications, both in number and severity. However, MATE software protections are dominated by fuzzy concepts and techniques, with security-through-obscurity omnipresent in the field. This paper presents a rationale for adopting and standardizing the protection of software as a risk management process according to the NIST SP800-39 approach. We examine the relevant aspects of formalizing and automating the activities in this process in the context of MATE software protection. We highlight the open issues that the research community still has to address. We discuss the benefits that such an approach can bring to all stakeholders. In addition, we present a Proof of Concept (PoC) of a decision support system that automates many activities in the risk analysis methodology towards the protection of software applications. Despite still being a prototype, the PoC validation with industry experts indicated that several aspects of the proposed risk management process can already be formalized and automated with our existing toolbox, and that it can actually assist decision making in industrially relevant settings

cs.SE↗

arXiv2020

Resilient Self-Debugging Software Protection

Debuggers are a popular reverse engineering and tampering tool. Self-debugging is an effective technique for applications to defend themselves against hostile debuggers. In penetration tests on state-of-the-art self-debugging, we observed several opportunities through which it could be attacked, however. We therefore improved upon the existing technique, making it more resilient by introducing reciprocal debugging and making the transfers of control between protected application and self-debugger more stealthy. This paper presents the improved self-debugging design, and details our research efforts into realizing reciprocal debugging. In our evaluation we show that the improved design is significantly harder for attackers to defeat.

cs.CR↗

arXiv2020

Code Renewability for Native Software Protection

Software protection aims at safeguarding assets embedded in software by preventing and delaying reverse engineering and tampering attacks. This paper presents an architecture and supporting tool flow to renew parts of native applications dynamically. Renewed and diversified code and data belonging to either the original application or to linked-in protections are delivered from a secure server to a client on demand. This results in frequent changes to the software components when they are under attack, thus making attacks harder. By supporting various forms of diversification and renewability, novel protection combinations become available, and existing combinations become stronger. The prototype implementation is evaluated on a number of industrial use cases.

cs.CR↗

arXiv2019

Extended Report on the Obfuscated Integration of Software Protections

To counter man-at-the-end attacks such as reverse engineering and tampering, software is often protected with techniques that require support modules to be linked into the application. It is well-known, however, that attackers can exploit the modular nature of applications and their protections to speed up the identification and comprehension process of the relevant code, the assets, and the applied protections. To counter that exploitation of modularity at different levels of granularity, the boundaries between the modules in the program need to be obfuscated. We propose to do so by combining three cross-boundary protection techniques that thwart the disassembly process and in particular the reconstruction of functions: code layout randomization, interprocedurally coupled opaque predicates, and code factoring with intraprocedural control flow idioms. By means of an elaborate experimental evaluation and an extensive sensitivity analysis on realistic use cases and state-of-the-art tools, we demonstrate our technique's potency and resilience to advanced attacks. All relevant code is publicly available online.

cs.CR↗

arXiv2018

ΔBreakpad: Diversified Binary Crash Reporting

This paper introduces ΔBreakpad. It extends the Breakpad crash reporting system to handle software diversity effectively and efficiently by replicating and patching the debug information of diversified software versions. Simple adaptations to existing open source compiler tools are presented that on the one hand introduce significant amounts of diversification in the code and stack layout of ARMv7 binaries to mitigate the widespread deployment of code injection and code reuse attacks, while on the other hand still supporting accurate crash reporting. An evaluation on SPEC2006 benchmarks demonstrates that the corresponding computational, storage, and communication overheads are small.

cs.CR↗

arXiv2017

How Professional Hackers Understand Protected Code while Performing Attack Tasks

Code protections aim at blocking (or at least delaying) reverse engineering and tampering attacks to critical assets within programs. Knowing the way hackers understand protected code and perform attacks is important to achieve a stronger protection of the software assets, based on realistic assumptions about the hackers' behaviour. However, building such knowledge is difficult because hackers can hardly be involved in controlled experiments and empirical studies. The FP7 European project Aspire has given the authors of this paper the unique opportunity to have access to the professional penetration testers employed by the three industrial partners. In particular, we have been able to perform a qualitative analysis of three reports of professional penetration test performed on protected industrial code. Our qualitative analysis of the reports consists of open coding, carried out by 7 annotators and resulting in 459 annotations, followed by concept extraction and model inference. We identified the main activities: understanding, building attack, choosing and customizing tools, and working around or defeating protections. We built a model of how such activities take place. We used such models to identify a set of research directions for the creation of stronger code protections.

cs.SE↗