A reference architecture for software protection

This paper describes the ASPIRE reference architecture designed to tackle one major problem in this domain: the lack of a clear process and an open software architecture for the composition and deployment of multiple software protections on software application

A Reference Architecture for Software Protection

This paper describes the ASPIRE reference architecture designed to tackle one major problem in this domain: the lack of a clear process and an open software architecture for the composition and deployment of multiple software protections on software applications

A Reference Architecture for Software Protection

This paper describes the ASPIRE reference archi-tecture designed to tackle one major problem in this domain: the lack of a clear process and an open software architecture for the composition and deployment of multiple software protections on software applications

Obfuscating Java Programs by Translating Selected Portions of Bytecode to Native Libraries

Code obfuscation is a popular approach to turn program comprehension and analysis harder, with the aim of mitigating threats related to malicious reverse engineering and code tampering. However, programming languages that compile to high level bytecode (e.g., Java) can be obfuscated only to a limited extent. In fact, high level bytecode still contains high level relevant information that an attacker might exploit. In order to enable more resilient obfuscations, part of these programs might be implemented with programming languages (e.g., C) that compile to low level machine-dependent code. In fact, machine code contains and leaks less high level information and it enables more resilient obfuscations. In this paper, we present an approach to automatically translate critical sections of high level Java bytecode to C code, so that more effective obfuscations can be resorted to. Moreover, a developer can still work with a single programming language, i.e., Java

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 article 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 several industrial use cases

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

On the impossibility of effectively using likely-invariants for software attestation purposes

Invariants monitoring is a software attestation technique that aims at proving the integrity of a running application by checking likely-invariants, which are statistically significant predicates inferred on variables’ values. Being very promising, according to the software protection literature, we developed a technique to remotely monitor invariants. This paper presents the analysis we have performed to assess the effectiveness of our technique and the effectiveness of likely-invariants for software attestation purposes. Moreover, it illustrates the identified limitations and our studies to improve the detection abilities of this technique. Our results suggest that, despite further studies and future results may increase the efficacy and reduce the side effects, software attestation based on likely-invariants is not yet ready for the real world. Software developers should be warned of these limitations, if they could be tempted by adopting this technique, and companies developing software protections should not invest in development without also investing in further research