A Friendly Framework for Hidding fault enabled virus for Java Based Smartcard

Abstract

Abstract. Smart cards are the safer device to execute cryptographic algorithms. Applications are verified before being loaded into the card. Recently, the idea of combined attacks to bypass byte code verification has emerged. Indeed, correct and legitimate Java Card applications can be dynamically modified on-card using a laser beam to become mutant applications or fault enabled viruses. We propose a framework for manipulating binary applications to design viruses for smart cards. We present development, experimentation and an example of this kind of virus.

The ultimate control flow transfer in a Java based smart card

“…As seen in the previous section, an applet that contains unchecked piece of code can be installed into the card and modified by an external fault injection (Razafindralambo et al, 2012). To succeed our attack on a Java Card smart cards with an embedded BCV, we installed an applet with the code shown in the Listing 10.…”

Heap $$\ldots $$ Hop! Heap Is Also Vulnerable

“…In [6], Bouffard et al described how to change the execution flow of an application after loading it into a Java Card. Recently, Razafindralambo et al [20] introduced a combined attack based on fault enabled viruses. Such a virus is activated by hitting with a laser beam, at a precise location in the memory, where the instruction of a program (virus) is stored.…”

Countermeasures Mitigation for Designing Rich Shell Code in Java Card

“…In [6], Bouffard et al described how to change the execution flow of an application after loading it into a Java Card. Recently, Razafindralambo et al [17] introduced a combined attack based on fault enabled viruses. Such a virus is activated by hitting with a laser beam, at a precise location in the memory, where the instruction of a program (virus) is stored.…”

“…As they know all the addresses of each method of the API, they could replace instructions of any method. In [17], they abuse the on board linker in such a way that the application is only made of tokens to be resolved by the linker. Knowing the mapping between addresses to tokens thanks to the previous attack, they have been able to use the linker to generate itself the shell code to be executed.…”