FR3045858A1 - METHOD FOR LOADING A SEQUENCE OF INSTRUCTION CODES, METHOD FOR EXECUTING A SEQUENCE OF INSTRUCTION CODES, METHOD FOR IMPLEMENTING AN ELECTRONIC ENTITY, AND ASSOCIATED ELECTRONIC ENTITIES - Google Patents

Abstract

A method of loading, within a memory (MEM) of an electronic entity (C), a sequence (APPL) of instruction codes executable by a virtual machine resident in the electronic entity (C) comprises the following steps: - detection of an instruction code contained in a predetermined list of instruction codes; converting a pair formed of the detected code and a code located in the sequence (APPL) to a predetermined relative position with respect to the detected code, into a distinct pair of codes according to a predetermined rule; - Writing the distinct pair in the memory (MEM) to replace the pair formed of the detected code and the code located at said relative position. A method of executing an instruction code sequence (APPL ') comprises, when reading an instruction code belonging to a predefined list, a step of converting a pair formed by the read code and by the code located at a predetermined relative position with respect to the read code, into a distinct pair of codes. A method implemented in an electronic entity and corresponding electronic entities are also described.

Description

Technical field to which the invention relates

The present invention relates to instruction code sequences executable by a virtual machine.

It relates more particularly to a method of loading a sequence of instruction codes, a method of executing a sequence of instruction codes, a method implemented in an electronic entity and associated electronic entities. The invention applies particularly advantageously in the case where one wishes to guard against attacks using unreachable code, as explained below.

Technological background

It is known, for example in the context of the so-called "Java Card" technology, to use a virtual machine implanted in an electronic entity (such as a microcircuit card) to load a sequence of instruction codes (for example as a .CAP file) in the electronic entity and execute this sequence of instruction codes.

In order to protect against certain attacks, it is known to check the sequence of instruction codes before it is executed. Such a check is generally performed outside the electronic entity, or, within the electronic entity itself, typically during the loading of the instruction code sequence.

As explained for example in the article "The Ultimate Control Flow Transfer in a Java Based Smart Card", by Guillaume Bouffart and Jean-Louis Lanet, in Computers & Security 2015, the current verification techniques do not make it possible to detect unreachable code (in English: "unreachable code"), namely instruction codes present in a part of a sequence where the control flow (in English: "control flow") never goes into normal operation.

Such unreachable code may, however, be executed when an attacker implements a fault attack that deviates from the normal command stream.

Object of the invention

In this context, the present invention proposes a method of loading, within a memory of an electronic entity, a sequence of instruction codes executable by a virtual machine resident in the electronic entity, characterized by the steps following: - detection of an instruction code contained in a predetermined list of instruction codes; converting a pair formed of the detected code and a code located in the sequence to a predetermined relative position with respect to the detected code, into a distinct pair of codes according to a predetermined rule; writing the distinct pair into the memory instead of the pair formed of the detected code and the code located at said relative position.

For the execution of a sequence thus loaded, it will be necessary, as explained below, to carry out a new conversion of the pair of instruction codes written in the memory. However, this new conversion will not be able to proceed correctly (and the execution may for example be interrupted) if an attacker tries to skip (in English: "s / c / p") the execution of one of the two codes. by means of an attack (such as a laser attack), for example in order to execute unreachable code as explained above. Subsequent execution is thus protected from such attacks.

According to other possible features that may be envisaged (without being limiting): the code situated at a predetermined relative position with respect to the detected code is a code contiguous, in the sequence, with the detected code; the contiguous code is the code preceding, in the sequence, the detected code; the predetermined list contains all the codes corresponding to an unconditional instruction for breaking the control flow; the codes of the sequence correspond to codes standardized according to a given specification (possibly a specification relating to a standard); the codes of the distinct pair correspond to unused codes according to said given specification; the conversion step comprises a step of reading, in a correspondence table, the distinct pair associated with the pair formed of the detected code and the code situated at said relative position; the conversion step comprises a step of applying an arithmetic function to the pair formed of the detected code and the code located at said relative position. The invention also proposes a method of executing a sequence of instruction codes by a virtual machine residing on an electronic entity, comprising the following steps: - if reading an instruction code belonging to a list predefined code, conversion, according to a predetermined rule, of a pair formed by the read code and the code located at a predetermined relative position with respect to the read code, into a distinct pair of codes comprising a first code and a second code ; execution by the virtual machine of an instruction defined at least in part by the first code. The instruction will therefore only be executed if the conversion step could, as is expected during normal operation, determine the first code (as well as the second code) on the basis of the pair formed by the read code and the code located at said relative position; the conversion will fail, however, if an attacker prevents the processing of one of these two codes in an attempt to execute unreachable code.

According to other possible features that may be envisaged (without being limiting): the code situated at said relative position is the code following the code read; the method comprises a step of execution, by the virtual machine, of another instruction defined at least in part by the second code; the other instruction is an instruction of unconditional breaking of the control flow; the first code and the second code correspond to standardized codes according to a given specification; the codes of the predefined list correspond to unused codes according to said given specification; the conversion step comprises a step of reading, in a correspondence table, the distinct pair associated with the pair formed by the code read and the code located at said relative position; the conversion step comprises a step of applying an arithmetic function to the pair formed by the code read and the code located at said relative position; the method comprises a step of verifying that the pair formed by the code read and the code located at said relative position is part of a set of possible pairs (i.e. in practice that the pair formed by the code read and by the following code is part of a pre-established list of pairs).

In case of failure of said verification, the implementation of an error processing function (including for example the non-volatile memory registration of an error code and / or the blocking) can be provided. any subsequent operation of the electronic entity and / or erasure of at least some data from the electronic entity). The invention also proposes a method implemented in an electronic entity comprising a charging method as described above and a method of execution as described above. The invention also proposes an electronic entity comprising a virtual machine, a memory and a loading module, within the memory, of a sequence of instruction codes executable by the virtual machine, characterized in that the module of loading is designed to detect an instruction code contained in a predetermined list of instruction codes, for converting a pair formed of the detected code and a code located in the sequence to a predetermined relative position with respect to the detected code, in a distinct pair of codes according to a predetermined rule, and for writing the distinct pair into the memory instead of the pair formed of the detected code and the code located at said relative position. The invention finally proposes an electronic entity comprising a virtual machine and a memory, characterized by an execution module designed to convert according to a predetermined rule, when reading in the memory of an instruction code belonging to a predefined list. codes, a pair formed by the read code and the code located at a predetermined relative position with respect to the read code, into a distinct pair of codes comprising a first code and a second code, the virtual machine being adapted to execute an instruction defined at least in part by the first code.

The optional features presented above in terms of method can also be applied to these electronic entities.

Furthermore, when the electronic entity comprises a processor, the loading module and / or the execution module can be implemented because of the execution of instructions (stored in the aforementioned memory or another memory) by the processor.

Detailed description of an example of realization

The following description with reference to the accompanying drawings, given by way of non-limiting examples, will make it clear what the invention consists of and how it can be achieved.

In the accompanying drawings: FIG. 1 schematically represents an electronic entity according to the invention; FIG. 2 is a logic diagram showing a method for loading an application in the electronic entity of FIG. 1; and FIG. 3 is a logic diagram showing a method of executing an application within the electronic entity of FIG. 1.

Figure 1 shows schematically an electronic entity according to the invention. The electronic entity is here a secure element, for example a microcircuit card C (possibly a universal integrated circuit card or U ICC for "Universal Integrated Circuit Card"). Such microcircuit card C is for example removably mounted in an electronic device such as a cell phone. In this case, it is generally a SIM card (for "Subscriber Identity Module"). The electronic entity could alternatively be another type of secure element, for example an integrated secure element (or eSE for "embedded Secure Element"). Such a secure element can be soldered within an electronic device such as A cellular phone can be an integrated universal integrated circuit card or eUlCC for embedded Universal Integrated Circuit Card. The electronic entity could also be an SD type card (for example an SD card, "secure microSD" or "microSD"), for example with a Java Card mask.

According to yet another variant, the electronic entity could be a personal computer or a transport card, for example. The electronic entity comprises a processor PROC, a memory MEM and at least one interface I.

The processor PROC is for example made in the form of a microprocessor.

The memory MEM here is a rewritable non-volatile memory. The electronic entity may comprise other memories (not shown), for example a random access memory.

At least some of the aforementioned elements can in practice be brought together in the same electronic circuit such as a microcontroller. The interface I allows the connection of the electronic entity to an external electronic device (such as a card reader equipping a cellular telephone) and the exchange of data between the electronic circuits (in particular the PROC processor) of the electronic entity and the external electronic device.

When the electronic entity is a microcircuit card C as described herein (for example in the format defined by ISO / IEC 7816), the interface I may comprise a plurality of electrical contacts arranged at the outer surface of the card As a variant, the interface I could be made by non-contact communication means, for example in accordance with the ISO / IEC 14443 standard. The electronic entity (in this case the microcircuit card C) could comprise of two types. interface and use one or the other according to its mode of operation.

The memory MEM memorizes a first set of instructions designed to implement a loading module (or installer) LD.M when these instructions are executed by the processor PROC.

As explained below with reference to FIG. 2, the loading module LD.M makes it possible to receive an application AP P on the interface I, to process this application AP P to obtain a modified version APP 'and to memorize the version modified APP 'in MEM memory. The APP application is received as a sequence of executable instruction codes. For example, as part of the so-called "Java Card" technology, the APP application (commonly known as "applet") is received as a CAP file. In this same context, the instruction codes are defined on one byte (for which they are commonly referred to by the name "bytecode").

The memory MEM stores a second set of instructions designed to implement an execution module (or interpreter) EX.M when these instructions are executed by the processor PROC.

As explained further with reference to FIG. 3, the execution module EX.M makes it possible to read instruction codes in the memory MEM, to possibly process these codes as described below, and to implement the instructions. designated by these codes (after possible treatment).

The loading module LD.M and the execution module EX.M are for example part of a virtual machine, here a virtual machine according to the aforementioned "Java Card" technology.

FIG. 2 is a logic diagram showing a method for loading an application in the electronic entity of FIG. 1.

This method starts in step E2 at which the loading module LD.M receives via the interface I a sequence of instruction codes forming an APPL application, here in the form of a CAP file.

The sequence of instruction codes is then for example stored in a random access memory (not shown) associated with the processor PROC.

The method below is then implemented for each of the methods defined in the concerned .CAP file.

The loading module LD.M traverses the sequence of instruction codes until it detects a first instruction of unconditional breaking of the control flow (in English: "unconditional control flow breaK"). (Such a detection is carried out in practice in successively comparing each of the instruction codes of the sequence to the different codes corresponding to an instruction of unconditional breaking of the control flow.)

Unconditional termination instructions for the control stream include, for example, unconditional jump instructions (such as the "goto" instruction) and return instructions from a subroutine (such as the "sreturn" instruction). The instructions for unconditional termination of the control stream here (each followed by the corresponding instruction code in hexadecimal):

Goto (0x70); - Ret (0x72);

Areturn (0x77);

Sreturn (0x78);

Ireturn (0x79);

Return (0x7A);

Athrow (0x93);

Goto_w (0xA8).

The loading module can then determine in step E4 whether the first unconditional breaking command of the control flow is a return instruction (such as the "return" instruction in the context of the "Java CarcT" technology) and if no branch instruction (conditional or unconditional) was encountered.

If this is the case (such a return instruction being designed to terminate the method described by the .CAP file concerned, without the possibility of previous jump to another address), the method continues in step E6 at which the loading module LD.M replaces any instruction code until the end of the current method with a predetermined code, corresponding for example to a return instruction or a proprietary instruction with the effect, for example, of recovering the value d error, the incrementation of a counter or the deactivation of the card. Alternatively the use of an instruction without effect, such as the instruction "nop" is also possible.

In fact, any code present after a return instruction without a prior connection instruction necessarily corresponds to unreachable code (as explained in the introduction), which is thus eliminated by the step E6. If, on the other hand, it is determined in step E4 that the first unconditional instruction of the control flow is not a return instruction or if a branch instruction (conditional or unconditional) has been encountered, the process continues. in step E8 for processing the instruction of unconditional breaking of the control flow.

The loading module LD.M determines in step E8 the pair P formed (here in reverse order) by the code of the detected instruction y and the preceding code in the sequence of instruction codes x, and converts this pair P = (x, y) into a distinct pair F (P) according to a predetermined rule, here a bijection F. (According to a conceivable embodiment, the predetermined rule is known only to the electronic and variable entity of an electronic entity to a different electronic entity.)

We denote a and b the codes of the pair F (P).

Here it is provided that the codes a, b of the pair F (P) are unused codes of the set of instructions concerned (here that provided for the technology "Java Caret").

In the example described here of the "Java Card" technology, there are 187 standard instruction codes, 8 of which correspond to instructions for unconditional breaking of the control flow, and 69 unused instruction codes (instruction codes being defined on a byte as already indicated, there are 256 possible codes).

There are therefore 1496 possible P pairs formed by a normalized code x and a normalized code y corresponding to an unconditional control flow breaking instruction. It is therefore possible to associate, with each of these possible pairs P, a pair (a, b) of unused codes by means of a bijection F (the number of such pairs of unused codes being equal to 4761).

According to a first conceivable embodiment, the association of each pair P = (x, y) with a given pair F (P) = (a, b) is stored in a correspondence table (stored for example in the memory MEM ).

According to a second conceivable embodiment, the pair F (P) = (a, b) is obtained by applying an arithmetic function to the pair P = (x, y).

For example, by associating an element i (x) of the set Ζιβ7 with each instruction code x, an element j (y) of the set Ze with each code y corresponding to an instruction of unconditional breaking of the control flow , and an element k (a) from the set Ζθθ to each unused code a, the pair F (P) = (a, b) associated with a pair P = (x, y) can be determined by the following operations: k (a) = INT {[i (x) + 187.j (y)] / 69}; k (b) = [i (x) + 187.j (y)] mod 69.

We noted above Zm the set of integers between 0 and (m-1).

The loading module LD.M then replaces, in the sequence of instruction codes, the pair P (whose second member has been detected therein corresponding to an unconditional instruction of breaking of the control flow) by the pair F (P ) obtained in step E8, which makes it possible to form a sequence of modified instruction codes AP PL '(step E10).

The loading module LD.M then continues its course of the sequence of instruction codes by searching for another code corresponding to an unconditional instruction for breaking the control flow (step E12).

If such a code is found, the method loops in step E8 for processing this new code corresponding to an unconditional instruction of breaking the control flow.

If, on the other hand, the end of the instruction sequence is traversed without encountering a new code corresponding to an instruction of unconditional breaking of the control flow, the load module LD.M proceeds to step E14 at the recording of the sequence of modified instruction codes APPL 'in the memory MEM.

An exemplary application of the method of FIG. 2 to a part of a sequence of instruction codes is described below: bspush 0x55 0x10 0x55 sstore_3 0x32 goto @ 0x4 0x70 0x4 sconst_0 0x3 (where it is shown on the left the instructions that correspond to this part of the sequence and to the right the corresponding instruction codes in hexadecimal).

The loading module LD.M traverses the sequence of instruction codes and detects the instruction goto (precisely the code 0x70) which is an instruction of unconditional breaking of the control flow (in step E4 if it is of the first such instruction, or in step E12 otherwise).

The loading module LD.M then converts (step E8) the pair P formed of the preceding code x = 0x32 and the detected code y = 0x70 into a pair F (P) = (a, b), with for example a = 0xC1 and b = 0xBB (the notation Ox introducing as above a number in hexadecimal).

The modified sequence obtained (in step E10) is thus the following: 0x10 0x55 0xC1 OxBB 0x4 0x3.

This sequence is stored in the memory MEM in step E14.

FIG. 3 is a logic diagram showing a method of executing the application APPL '(which corresponds to the sequence of instruction codes recorded during the process which has just been described with reference to FIG. 2) within the electronic entity of Figure 1.

As already indicated, such a method is here implemented by an execution module EX.M.

This method starts at step E20 at which the execution module EX.M (i.e. in practice the processor PROC) reads in the memory MEM a code CODn of the sequence of instruction codes APPL ' . (Note that it is possible in a variant that the sequence of instruction codes APPL 'is previously loaded into a random access memory, where the codes of this sequence are then successively read by the processor PROC.)

During the first pass to step E20, this code CODn is the first code of the sequence of instruction codes.

The execution module EX.M then determines in step E22 whether the read code CODn is part of a predefined list L of instruction codes (which here corresponds to all the codes used as the first member a of a pair F (P) when the pair P traverses the set of possible pairs P).

If not, the read CODn code is executed conventionally in step E24: it is normally either a normalized code corresponding to an instruction (that the execution module EX.M then implements as expected by the standard or specification concerned), or a parameter associated with a standard code processed at the previous iteration. If a normalized code is expected and the value of the code CODn read does not correspond to a normalized code, an error is detected and the execution of the code sequence is for example interrupted.

The process is looped in step E20 after treatment of the current code CODn.

In the case of the example of sequence part given above, the execution module EX.M thus proceeds to step E24 when it reads the code 0x10 (standard code corresponding to the bspush instruction), then the code 0x55 (expected parameter of the bspush instruction). If, on the other hand, it is determined in step E22 that the read code CODn is part of the predefined list L of instruction codes, the execution module EX.M (that is to say in practice the processor PROC) reads in step E26 the following instruction code CODn + i (in the memory MEM or, alternatively as already indicated, in a random access memory where the sequence of instruction codes APPL 'has been copied for a moment).

The execution module EX.M can then verify in step E28 that the pair (CODn, CODn + i) formed of the two successive codes (successively read in steps E20 and E26) corresponds to one of the pairs F ( P) possible (that is to say, to one of the pairs F (P) obtained when the pair P traverses the set of possible pairs).

If not, the sequence of codes read does not correspond to the sequence as recorded in step E14 described above. This problem comes for example from the fact that an attacker managed to pass (in English: "s / c / p") an instruction without it being taken into account, in order to reach an unreachable code area as described in the introduction. In this case, therefore, in step E30, an error processing is carried out, which ends, for example, the execution of the sequence of instruction codes APPL '.

If, on the other hand, the pair (CODn, CODn + i) formed of the two successive codes corresponds to one of the possible pairs F (P), the execution module EX.M converts in step E32 this pair (CODn, CODn + i) in a distinct pair (COD'n, COD'n + i) according to a predetermined rule, here by applying the inverse function F'1 of the bijection F used during the loading of the instruction code sequence APPL 'as described above.

So here we have (COD'n, COD'n + 1) = F1 [(CODn, COD "+ i)].

According to the first embodiment already mentioned above, the association of each pair P with a pair F (P) is stored in a correspondence table, which can therefore also be used (in the opposite direction) to determine the pair F ' 1 [(CODn, CODn + i)] from the pair (CODn, CODn + i).

According to a second conceivable embodiment, the pair F'1 [(CODn, CODn + i)] is obtained by applying an arithmetic function to the pair (CODn, CODn + i).

In the case given above where (a, b) = F [(x, y)] with: k (a) = INT {[i (x) + 187.j (y)] / 69}; k (b) = [i (x) + 187.j (y) j mod 69, the inverse function F "1 is for example implemented as follows: i (COD'n) = [k (CODn + i) + 69.k (CODn)] mod 187, j (COD'n + i) = INT {[k (CODn + 1) + 69.k (CODn)] / 187.

There are thus the two instruction codes initially present in the sequence of instruction codes APPL received in step E2 described above.

The codes COD'n, COD'n + i of the pair obtained by the conversion step E32 are then successively executed in a conventional manner.

In the example described here, the first code COD'n can be either a standardized code corresponding to an instruction (that the execution module EX.M then implements as provided by the standard or specification concerned), or a parameter associated with a previously processed standard code; the second code COD'n + i is in turn necessarily a code associated with an unconditional breaking command of the control flow (which will then be executed, possibly after reading the following code corresponding to a parameter associated with the code COD'n + i).

The method then loops to step E20 for reading the next code.

In the case of the instruction code sequence part given above by way of example, the execution module EX.M determines in step E22 that the code 0xC1 is part of the predefined list L, read by therefore in step E26 the following code OxBB, checks in step E28 that the pair (0xC1, OxBB) is a possible pair F (P), and then converts this pair (0xC1, OxBB) to the initial pair (0x32, 0x70) in step E32.

The execution module EX.M then executes the instruction sstore_3 (corresponding to the code 0x32), then the instruction goto @ 0x4 (after a new passage in the step E20 to read the next code 0x4).

In the example just described, the converted codes are contiguous codes in the sequence of execution codes. In general, it is possible to use a pair formed of a first code and a second code located at a predetermined relative position with respect to the first code (possibly not contiguous to the first code). During the execution, we can then temporarily store some codes before their execution. Indeed, if a first code is read and is part of the predefined list L of instruction codes and the second code of the pair is located m bytes further (the number m being predetermined), the execution module EX .M reads and temporarily stores the (intermediate) instruction codes located between the first code and the second code, reads the second code, converts the pair formed by the first code and the second code as described above into a third code and a fourth code, then execute the defined instructions (in that order) by the third code, the intermediate codes and the fourth code.

Claims (19)

1. Method for loading, within a memory (MEM) of an electronic entity (C), a sequence (APPL) of instruction codes executable by a virtual machine resident in the electronic entity (C) characterized by the steps of: - detecting (E4; E12) an instruction code contained in a predetermined list of instruction codes; - converting (E8) a pair formed of the detected code and a code located in the sequence (APPL) to a predetermined relative position with respect to the detected code, into a distinct pair of codes (F (P)) according to a predetermined rule; - Writing (E14) of the distinct pair (F (P)) in the memory (MEM) instead of the pair formed of the detected code and the code located at said relative position. The charging method according to claim 1, wherein the code located at a predetermined relative position with respect to the detected code is a code contiguous, in the sequence, with the detected code. 3. Loading method according to claim 2, wherein the contiguous code is the code preceding, in the sequence (APPL), the detected code. 4. Loading method according to one of claims 1 to 3, wherein the predetermined list contains all the codes corresponding to an unconditional breaking command of the control flow. The loading method according to one of claims 1 to 4, wherein the codes of the sequence (APPL) correspond to codes standardized to a given specification and in which the codes of the distinct pair (F (P)) correspond to unused codes according to said given specification. 6. Loading method according to one of claims 1 to 5, wherein the conversion step (E8) comprises a step of reading, in a correspondence table, the distinct pair associated with the pair formed of the detected code and code located at said relative position. The loading method according to one of claims 1 to 5, wherein the converting step (E8) comprises a step of applying an arithmetic function to the pair formed of the detected code and the code located at said position. relative. 8. A method of executing an instruction code sequence (APPL ') by a virtual machine residing on an electronic entity, comprising the following steps: - when reading an instruction code (CODn) belonging to to a predefined list (L) of codes, conversion (E32), according to a predetermined rule, of a pair formed by the read code (CODn) and by the code (CODn + i) located at a predetermined relative position with respect to the code read, in a distinct pair of codes including a first code (COD'n) and a second code (COD'n + i); - Execution (E34), by the virtual machine, of an instruction defined at least in part by the first code (COD'n). 9. The execution method according to claim 8, wherein the code located at said relative position is the code following the code read. 10. The execution method according to claim 8 or 9, comprising a step of execution, by the virtual machine, of another instruction defined at least in part by the second code (COD'n + i). 11. The execution method according to claim 8 or 9, wherein the other instruction is an unconditional command breaking command. 12. Method of execution according to one of claims 8 to 11, wherein the first code (COD'n) and the second code (COD'n + i) correspond to standardized codes according to a given specification and in which the codes of the predefined list (L) correspond to unused codes according to said given specification. 13. The execution method according to one of claims 8 to 12, wherein the conversion step (E32) comprises a step of reading, in a correspondence table, the distinct pair associated with the pair formed by the code. read and by the code located at said relative position. 14. The execution method according to one of claims 8 to 12, wherein the conversion step (E32) comprises a step of applying an arithmetic function to the pair formed by the code read and by the code located at said relative position. 15. The execution method according to one of claims 8 to 14, comprising a verification step (E28) that the pair formed by the read code (CODn) and the following code (CODn + i) is part of a set of possible pairs. 16. The execution method according to claim 15, comprising, in case of failure of said verification (E28), the implementation of an error processing function. 17. A method implemented in an electronic entity, comprising a charging method according to one of claims 1 to 7 and a method of execution according to one of claims 8 to 16. 18. Electronic entity (C) comprising a virtual machine, a memory (MEM) and a loading module (LD.M), within the memory (MEM), of a sequence (APPL) of executable instruction codes by the virtual machine, characterized in that the loading module (LD.M) is adapted to detect an instruction code contained in a predetermined list of instruction codes, for converting a pair formed of the detected code and a code located in the sequence (APPL) at a predetermined relative position with respect to the detected code, in a distinct pair of codes according to a predetermined rule, and for writing the distinct pair in the memory (MEM) instead of the pair formed of the code detected and code located at said relative position. 19. Electronic entity (C) comprising a virtual machine and a memory (MEM), characterized by an execution module (EX.M) designed to convert according to a predetermined rule, in case of reading in the memory (MEM) of an instruction code (CODn) belonging to a predefined list of codes, a pair formed by the read code (CODn) and by the code (CODn + i) located at a predetermined relative position with respect to the read code, in a pair distinct code comprising a first code (COD'n) and a second code (COD'n + i), the virtual machine being designed to execute an instruction defined at least in part by the first code (COD'n).