Method and device for obfuscating code control flow

Abstract

For obfuscating a code control flow a computer-implemented method comprises - identifying functional blocks in a code to be obfuscated; - associating a label to each functional block; - associating at least one event identifier with each functional block; - creating a prologue function configured to contain a registration for the at least one event identifier of each functional block; and - creating an epilogue function configured to contain a deregistration for the event identifier of each functional block.

Description

[0001] METHOD AND DEVICE FOR OBFUSCATING CODE CONTROL FLOW

[0002] FIELD OF THE INVENTION

[0003] The present invention pertains to the field of software security. Specifically, it relates to techniques for obfuscating the control flow of computer code, making it more difficult for malicious actors to reverse engineer, analyze, or tamper with software applications.

[0004] BACKGROUND

[0005] Software security is a critical concern in today's interconnected world, where the distribution and execution of software applications often occur in untrusted environments. Malicious actors seek to reverse engineer and analyze software code to exploit vulnerabilities, steal sensitive data, or create unauthorized derivative works. To counter these threats, software developers employ various techniques, including code obfuscation.

[0006] Code obfuscation is a practice used to obscure the logic and control flow of a software application without altering its functionality. This technique aims to hinder reverse engineering attempts and thwart code analysis. Obfuscation methods typically operate at the binary or source code level and often focus on disguising the control flow of the program.

[0007] Traditional code obfuscation techniques, such as renaming variables, restructuring code, or adding redundant instructions, offer some level of protection against reverse engineering. However, they may fall short in addressing increasingly sophisticated attacks. Advanced attackers use techniques like dynamic analysis, control flow analysis, and symbolic execution to reveal the hidden logic and control flow of obfuscated code.

[0008] Thus, there exists a need for more effective methods of code obfuscation, specifically those that target the control flow of software applications. By introducing novel control flow obfuscation techniques, it is possible to enhance the security of software against a broader range of reverse engineering and tampering attacks.

[0009] SUMMARY

[0010] The present invention discloses a method for obfuscating the control flow of computer code. While the invention is defined in the independent claims, further aspects of the invention are set forth in the dependent claims, the drawings and the following description.

[0011] The method detailed in this patent application provides a comprehensive approach to control flow obfuscation, enhancing the security of software applications in a wide range of domains, including but not limited to cybersecurity, intellectual property protection, and software licensing.

[0012] According to an aspect, a computer-implemented method for obfuscating code control flow comprises the steps of: identifying functional blocks in a code to be obfuscated; associating a label to each functional block; associating at least one event identifier with each functional block; creating a prologue function configured to contain a registration for the at least one event identifier of each functional block; and creating an epilogue function configured to contain a deregistration for the event identifier of each functional block.

[0013] The combination of splitting the function into functional blocks and the use of an event- driven control flow provides an obfuscation of the code. An event-based programming enables the code to be decomposed and to no longer take the appearance of a procedural (i.e. sequential) code. The event identifier is preferably transported by an event. The event identifier enables a functional block to know which event it should respond to. The event may be generated by an event manager.

[0014] Preferably, the link or association between each functional block and the respective label is established in the Prologue. As the functional blocks do not directly indicate their inter-relation and next functional block for execution, a static analysis requires access to the prologue function to link a functional block to its predecessor and thus comprehend the structure of the obfuscated code control flow. The prologue function however can be kept separate from the functional blocks and may only be accessed when the obfuscated code is executed or when an event identifier is triggered.

[0015] Moreover, the event-based programming provides a base for performing at least one or several obfuscating methods to the control flow. Preferably, the step of identifying the functional blocks and / or the step of associating a label to each block is performed by the use of a parser. The parser can be used for identifying and creating functional blocks in the code.

[0016] The computer-implemented method may be for obfuscating code control flow to form an obfuscated code. In an embodiment, each functional block may be non-sequentially or randomly distributed in the obfuscated code. The computer-implemented method may comprise the step of scattering or distributing (non-sequentially or randomly) the functional blocks, e.g., such that in the obfuscated code the functional blocks are scattered, or are non-sequentially or randomly distributed.

[0017] In an embodiment, each functional block is comprised in an event block, and the event blocks are non-sequentially or randomly distributed in the code. Hence, the eventbased programming allows the functional blocks to be scattered throughout the code to achieve an obfuscation. Even if the events blocks are scattered in the code, they may still visually appear as grouped functions in the code. The event block preferably comprises the functional block, event label and the event identifier. The event identifier may serve as a sequence indicator for the event and determines the following function or functions to be executed.

[0018] The method may be applied to a plurality of functions in the code, and wherein functional blocks of the plurality of functions are randomly mixed together or distributed in the code (e.g., in the obfuscated code).

[0019] In an embodiment, the method further comprises the step of adding at least one additional functional block to the code, and wherein said additional functional block is excluded from the prologue. In such a way, there is at least one, preferably a plurality of functional blocks present in the function which are never called. The additional functional block makes it more difficult to determine which blocks are included in the function.

[0020] In an embodiment, the label is a random name unrelated to a function of the functional block and wherein the random name is stored in the prologue function.

[0021] Preferably, the prologue function is kept or stored separate from the control flow or the obfuscated code. Hence, the prologue function can be a separate functional block, linked to the functional blocks of the code. A “prologue function” may be understood to refer to the initial setup code that a function executes before the main operations of the function begin. It may be a set of instructions that prepares the runtime environment for the function, handling tasks essential for correct function execution, particularly for managing memory and ensuring the correct state. The prologue function typically refers to the initial set of actions or setup that occurs before the events are executed. It may establish the necessary environment for events to be processed. The prologue function may initialize event listeners or handlers, whereby the functional blocks that will respond to certain events are determined.

[0022] A “functional block” may be an instruction or a group of instructions indicating at least one code operation. The code operation may be configured to change at least one value, location or form of data. Additionally, or alternatively, the functional block may provide an input and / or output. Within the context of this application, the term “functional block” may be understood to refer to a function or a subroutine that performs a specific calculation or action. The function or subroutine may be referred to as an “operation” within the context of this application.

[0023] An “epilogue function” may be an end-function of the program. The epilogue may perform cleanup tasks as the function is exiting.

[0024] The term “event” may be understood to refer to an action that controls the control flow of a function or a program. An event can be triggered by the outcome / result from a functional block.

[0025] The term “label” can be defined as a unique identifier of the functional block. The label is stored in the prologue, which associates the labels and event identifiers. The label is linked to the functional block. The label is linked to the event identifier and responds to an event to which it is addressed.

[0026] The term “event identifier” may be understood to refer to a sequence identifier in an event-based software function. The event identifier is preferably comprised in the code in the event and associated with the functional block.

[0027] In various embodiments the label is a random name unrelated to a function of the functional block. The label may identify the functional block. It may be sent together with the event. The label is preferably sent by an event manager (also referred to as “event dispatcher”). In various embodiments, the step of identifying functional blocks comprises creating an abstract syntax tree of the code to be obfuscated; identifying individual statements in the abstract syntax tree; for each statement in the abstract syntax tree, identifying all predecessor statements and all successor statements; identifying statements that have a single predecessor statement and a single successor statement; identifying statements that have a single predecessor statement or a single successor statement; identifying statements that have no or at least two predecessor statements; identifying statements that have no or at least two successor statements; and for the identified statements identifying groups of successive statements such that every statement has a single successor statement in the group and / or is a last statement of the successive statements in the group, and every statement has a single predecessor statement in the group and / or is the first statement in the group; wherein the succession of statements is identified as one functional block. With respect to these embodiments, an abstract syntax tree is a representation of the abstract syntactic structure of text provided in a programming language. The functional blocks thus essentially consist of a chain of statements, where a first statement either has no predecessor, at least two predecessors or is a first statement because its preceding statement is a last statement in a preceding functional block. A last statement has no successor, at least two successors or is a last statement because its succeeding statement is a first statement in a succeeding block.

[0028] In various embodiments the code is provided in a programming language (e.g., JavaScript) that uses imperative programming and supports event-driven programming. This allows replacing connections between functional units by events.

[0029] In this way, when the obfuscated code is executed / run, asynchronous and / or recursive execution of the functional blocks may occur.

[0030] In various embodiments the registration of the prologue function comprises for each functional block at least one respective event identifier triggering that functional block.

[0031] In various embodiments the deregistration comprises removing an event identifier from the registration of the prologue function. This prevents keeping the relationships between the functional blocks and their triggering events decentralized. In various embodiments the method further comprises identifying a statement triggered by a call event, and identifying a block containing the statement triggered by the call event as a start block. The start block may implement the prologue.

[0032] In various embodiments the method further comprises identifying a statement triggering a program return as an end block. The end block may implement the epilogue.

[0033] In various embodiments at least one event identifier is expressed as an event value, the event value being a function of a value generated only during a runtime of the obfuscated code. As the event identifier is a function of the value only present at runtime, static analysis of the computer program is rendered more difficult.

[0034] According to a further aspect a computer-implemented method for running an obfuscated code control flow comprises calling a prologue function of an obfuscated code by registering at least two functional blocks and for each functional block at least one event identifier triggering the respective functional block; calling a start block of the obfuscated code; executing a respective functional block and generating a respective event identifier by finishing executing the respective functional block; calling a next functional block as a function of the respective event identifier; calling an end block and returning a result of the obfuscated code; deregistering all functional blocks by removing at least one event identifier from the registration of the prologue function.

[0035] In various embodiments the respective event identifier is determined by computation of an opaque predicate, the opaque predicate generating an event value through an expression including a value generated while running the obfuscated code.

[0036] According to a further aspect a data processing apparatus comprises means for carrying out the method of any previous embodiment.

[0037] According to a further aspect a computer program product comprises instructions which, when the program is executed by a computer, cause the computer to carry out the method of any previous embodiment.

[0038] Within the context of this application, a computer program is a set of instructions for a computer to execute on request. In various embodiments the computer program is prepared in a text based or visual programming language. In various embodiments, each computer program has several modules, some of the modules having several functions and code obfuscation is applied to at least some modules separately. In various embodiments, the functional blocks of the modules are grouped at random with functional blocks of other modules. In object oriented programming languages the term “method” is used instead of “function”.

[0039] In various embodiments, a microprocessor is configured to run a computer program and / or an obfuscated code according to the invention.

[0040] BRIEF DESCRIPTION OF THE FIGURES

[0041] Fig. 1 shows an example of a code flattening of a procedural code control flow as known in the prior art;

[0042] Fig. 2 is a schematic flowchart illustrating a transformation of a conventional code control flow into an obfuscated flowchart according to the invention;

[0043] Fig. 3 shows an embodiment of protecting an obfuscated flowchart;

[0044] Fig. 4a shows a flowchart of an obfuscated function during runtime; and

[0045] Fig. 4b shows a flowchart of a plurality of obfuscated functions during runtime according to another embodiment of the invention.

[0046] DETAILED DESCRIPTION

[0047] Fig. 1 shows a first and a second flowcharts of an exemplary transformation of a procedural control flow 1 of a program function 3 into a flattened code 10 (also referred to as “flattened program”), as known in the prior art. The illustrated flowcharts typically represent a separate function of a computer program but may also represent a full computer program.

[0048] Specifically, Fig. 1 , illustrates a traditional flattening of a control flow 1 , where the functional blocks 2 of the function stays within the same function, while a call sequence is managed by a switch case 36. As illustrated, the computer program or function comprises a plurality of elements comprising a plurality of functional blocks 2 (named A, B, C, D), a decision element 11 and terminals Start 40, End 42. Arrows indicate an order of operation between adjacent elements. The functional blocks A, B, C, D indicate at least one operation that changes at least one value, location or form of data, or that provides an input and / or output. It should be noted that the functional blocks in some examples are named A to D, however in the present disclosure, the number of functional blocks is not restricted and can be any number. The decision element 11 indicates a conditional operation that directs the program flow to either functional block C or functional block D. For example, the decision element 11 is a yes / no, true / false, equality or inequality test. Typical tests include whether a value is reached, is larger than a reference value or is even or odd. In further embodiments more than two results are provided, such that the program flow has several possible prongs 16 from which one is followed. In further embodiments the decision element 11 comprises a branch or a branch point (also referred to as a “prong” 16) directing the program flow to a functional block that has been processed previously, thus guiding the program flow in a loop.

[0049] The terminal Start 40 indicates a beginning of the computer program. The terminal Start 40 is invoked by a system to execute the computer program. The terminal Start 40 may also represent an interface allowing submission of one or more input values, input data and / or input data structures. In various embodiments the system is another computer program, an operating system and / or a manual operation or input.

[0050] The terminal End 42 indicates an ending of the computer program. The terminal End 42 terminates executing the function or the computer program. The terminal End 42 may return the control flow 1 to the system or to another computer program. Optionally, remaining other functions of the program may continue running. In various embodiments, the terminal End 42 returns a value, output data and / or an output data structure. This output data may be provided to another function in the program.

[0051] As illustrated in the left-hand image of figure 1 , a procedural code has a sequential control flow 1 with functional blocksoccurring one after the other before the flattening. Such a sequential control flow 1 may be in the form of the following example: function hanoi(n: number, A: tour, B: tour, C: tour): number { let nbPass = 0 (Functional block A) if (n === 1) { (Functional block B) trace('Disk ${n} from ${A} to ${B}' ) nbPass++ (Functional block C)

[0052] } else { nbPass += hanoi(n - 1 , A, C, B) trace('Disk ${n} from ${A} to ${B}') nbPass += 1 + hanoi(n - 1 , C, B, A) (Functional block D)

[0053] } return nbPass (Functional block E)

[0054] }

[0055] In order to flatten the code, and as illustrated in the right-hand side of figure 1 , a switch case operation 36 is added, the switch case operation 36 being configured to direct the program flow to a following operation (or functional block). The switch case operation 36 may be configured to receive an operation label 12 of a following functional block 2 and to direct the program flow to the operation 2 so labelled. In the example, each of the functional blocks C and D are configured to have the Switch case operation 36 direct the program flow to the functional block D.

[0056] According to the present disclosure, Fig. 2 schematically illustrates a further embodiment of a transformation of a code control flow 1 of a computer program into an obfuscated code. As shown in figures 2 to 4b, the process of transformation may be referred to as “build time” and is performed in multiple steps. The computer program in various embodiments is a function, a routine, subprogram, subroutine, or procedure, which terms are sometimes used interchangeably within the context of this specification.

[0057] For reference, the initial unobfuscated control flow flowchart 1 (on the top portion of Figure 2) comprises a connector CALL 30, functional blocks A, B, C, D and a connector RETURN 32. The functional blocks A, C, D represent processes, each comprising a set of operations that changes a value, a form, and / or a location of data.

[0058] As an initial step to obfuscate the computer program, the code can be flattened (also referred to hereinafter as “decomposed”) to form a decomposed program 10. The code decomposition (flattening) does not contain or contains few hierarchical or nested structures. This transforms the code into a linear, "flat" sequence of instructions. The code flattening may be limited to one function 3, or be applicable to a plurality of functions 3a, 3b (see fig. 4b) in the same program.

[0059] Preferably, every functional block 2 is provided with an operation label 12 (also referred as a functional block label). In the illustrated embodiments, the labels may be named A’, B’, C’, D’. In various embodiments, for every functional block 2 a label 12 of a following functional block is noted in connection with each functional block 2.

[0060] A functional block may comprise a decision and an operation label 12 of a following functional block 2 is indicated as a result of the decision. The flattened program 10 preferably comprises terminals Start 40, End indicating a beginning and an ending of the flattened program 10, respectively. The terminal Start 40 may advantageously represent an interface allowing submission of input to the flattened program 10. The terminal Start 40 may direct the program flow to a first operation 2 of the flattened program 10. In various embodiments, the terminal Start 40 provides a label 12 of the first operation 2.

[0061] A last functional block 2 may provide a sequence indicator 4 “End” to direct the program flow to the terminal End 42. The terminal End 42 terminates executing the computer program and may return the control flow to the system or to another computer program. In various embodiments, the terminal End 42 returns a value, output data and / or an output data structure. The flattened program 10 thus can be called in the same manner as the computer program without flattening and the flattened program 10 is configured to return to the system or to another computer program in the same manner as the computer program without flattening. The flattened program 10 thus is compatible with the system or other computer program in the same manner as the computer program without flattening.

[0062] For the exemplary computer program recited above, the code flattening thus generates a decomposed (flattened) program 10 as depicted in the lower flow chart of Fig. 2. In this embodiment, the decomposed program comprises functional blocks A, B, C, D corresponding to functional blocks A, B, C, D of the original function or computer program. The functional blocks A, B, C, D are further associated with a sequence indication 4 as to define which functional block 2 is to follow respectively after each preceding functional block 2 which has been executed. In the illustrated example, the functional blocks A, B, C, D are respectively associated with the sequence indications A”, B”, C”, D”.

[0063] In the depicted embodiment, the functional block B comprises additionally a mapping of the decision and is thus configured to also decide whether the program flow is to be directed to the functional block C or to the functional block D.

[0064] The decomposed function (or program) 3, 10 further comprises terminals Start 40, End corresponding to the terminals Start 40, End of the original computer program. The terminal Start 40 of the flattened program 10 particularly contains a reference with the sequence indication 4, label A, to direct the program flow to the functional block A 2. The functional block D is particularly associated with a sequence indication 4 (reference) to the terminal End 42 to direct the program flow to the terminal End 42, to thus end the decomposed program. Alternatively, the End may be configured to return the control flow to the system or to another computer program. The call of the function 3 initiates the Start 40. The call function 30 is thus configured to trigger the start of the function 3. The call function 30 is not indicative of whether the function 3 is obfuscated or not.

[0065] In the depicted example, the functional block B comprises a decision element 11 processing a conditional operation that directs the program flow to either the functional block C or to the functional block D. An output of the functional block C is looped back to the decision element B. An output of the functional block D passes to the connector RETURN 32 to thus end the computer program and to return to a system or to another computer program which called the computer program. While the computer program is depicted as a flowchart corresponding to depictions in a visual programming language, the computer program can also be written and represented as a text-based computer program. In various embodiments the computer program is written in a language that uses an imperative programming style, and / or that supports an event- driven programming style. In various embodiments, the computer program is written in JavaScript.

[0066] The content of the functional blocks 2 is created in the initial code. Functional blocks 2 may thereafter be identified in particular using a parser. The parser creates an abstract syntax tree of the programming language used to prepare the computer code. This abstract syntax tree defines relationships and orders within the code or data. Examples for JavaScript are acornJS or babeIJS. On the abstract syntax tree individual statements are identified. For each statement, all predecessor statements and all successor statements are identified. For example, an addition has one successor which is the next statement, but a conditional statement such as an ‘if-then- else’ statement has two successors, chosen based on the conditional expression. A functional block 2 then is a succession of statements where any two adjacent statements are the only predecessor and only successor, respectively, of each other. Thus, any statement that has more than one predecessor (or non in the case of the first statement) marks the start of a functional block, any statement that has more than one successor (or non in the case of the return statement) marks the end of a functional block. The first and the last statements on the abstract syntax tree have no predecessor and successor, respectively.

[0067] For the present embodiment of the transformation, each functional block 2 receives a label 12. The label 12 is provided by the parser. Each label 12 is linked to a functional block 2 (or function) and takes the form of an identifier for the functional block 2 (or function). When the label 12 is called, the related functional block 2 (or function) is triggered and executed. In Fig. 2 the labels A, B, C, D are used.

[0068] In various embodiments (see Fig. 4b) the labels 12 are random names without implications regarding a function or order of the functional block 2 receiving the label 12. As the labels 12 are random, an attacker cannot easily identify a pattern in naming, which could help in reconstructing the original code. Figure 4b further illustrates an embodiment where a first function 3a and a second function 3b are randomly distributed together in the code. Additionally, the prologues 44a, epilogues 46a, 46b, the terminals start 40a, 40b, and the terminals end 42a, 42b are also randomly distributed in the code. In further embodiments, a next time the function is run, the obfuscated code 10 applies different random names to the functional blocks 2, such that reuse of previous attacks becomes harder. In various embodiments, random names are given to the functional blocks 2 each time the code is run. In such a way, previous attacks cannot be applied immediately. The random names may be applied during the build time of the obfuscated code, whereby different versions of the same function or program is generated. Hence, the obfuscation to the function or program may take different forms.

[0069] Each functional block 2 is additionally associated with an event identifier 4. Each event identifier 4 is an indication as to which functional block 2 is to be processed next. In various embodiments, the functional blocks 2 are scattered throughout the code so that their interrelation is not immediately conceivable from the order in which they are present in the obfuscated code 10. The functional blocks 2 may be scattered in the code by an algorithm, which is configured to displace the position of the event blocks. The algorithm may provide a shuffle function. The labels 12 are unique for the respective functional block 2.

[0070] A schematic example of an event-based code is illustrated here below. Notably, each event block is comprised between the { }, and visibly comprises a functional block and an event identifier. However, there is no label indicating the identity of the functional block. The link between the label and the functional block is stored in the Prologue function. async (context) => { (Functional block A) context. data. nbPass = 0 return 1 / / B”

[0071] }. async (context) => { (Functional block B) const { n } = context. data if (n === 1) return 2 / / C return 3 / / D

[0072] }. async (context) => { (Functional block C) const { n, A, B } = context. data if (context. data. nbPass === undefined) throw 'nbPass not initialized' tracefDisk ${n} from ${A} to ${B}') context. data. nbPass += 1 return 4 / / E

[0073] }. async (context) => { (Functional block D) const { n, A, B, C } = context. data if (context. data. nbPass === undefined) throw 'nbPass not initialized' context. data. nbPass += await Block.start(context. baseindex, n - 1 , A, C, B) tracefDisk ${n} from ${A} to ${B}') context. data. nbPass += 1 + await Block.start(context.baselndex, n - 1 , C, B, A) return 4 / / E

[0074] }. async (context) => { Functional block B const { nbPass } = context. data if (nbPass === undefined) throw 'nbPass not initialized' context. result = nbPass return

[0075] }

[0076] For the obfuscated code a prologue function Prologue 44 is created. The prologue function Prologue 44 is configured to register the associations of the labels 12 of the functional blocks 2 and their respective event identifier 4 (also referred to as sequence identifier). In various embodiments the prologue function Prologue 44 contains an entry of one functional block 2 and an event identifier 4 associated with this functional block 2. In such a way, the Prologue 44 defines the interrelation between the functional blocks 2. In various embodiments a functional block 2 is associated with more than one event identifier 4. In various embodiments the prologue function Prologue 44 is configured to be created separately from the functional blocks 2 being called for the first time. In various embodiments the prologue function Prologue 44 is created for more than one subroutine each having a separate connector CALL 30, respectively, so as not to be able to associate a set of functional blocks 2 with a particular subroutine. In various embodiments, an instance of EventEmitter of JavaScript is used. Particularly, EventEmitter is a design pattern that allows objects (also referred to as code, process, function or method) to emit named events and to subscribe to these events with callback functions. Hence, the events act as sequence indicators 4 in the code. The EventEmitter enables objects to emit named events and register listeners to respond to those events. When the event is emitted, the listeners execute in the order they were registered. Additionally, the EventEmitter is configured to identify events in the code. The EventEmitter is configured to subsribe to events it wants to receive. In various embodiments, the functional blocks 2 use EventEmitter to emit events using the EventEmitter. The event is then identified by a string (event name).

[0077] The functional blocks 2 are configured to process their function and upon completion provide an event identifier 4. The event identifier 4 is provided by the Event Emitter. In various embodiments, the event identifier 4 is a function of the process of the respective functional block 2. In various embodiments, the event identifier 4 is generated during processing of the respective functional block 2. In various embodiments the event identifier 4 is a result of a calculation and / or algorithm processed by the respective functional block 2. The provided event identifier 4 is passed to the prologue function 44 to determine a following functional block A, B, C, D 2.

[0078] In the depicted example of Fig. 2, the functional block A provides an event identifier for B, such that the functional block B becomes the next functional block. The functional Block B 2 is configured to generate an event identifier 4 for the functional blocks C or D. Depending on the process of the functional block B, an event identifier 4 for the functional block C or for the functional block D is generated. Consequently, the prologue 44 will pass the process flow either the functional block C or to the functional block D. In brief, the functional block C will generate an event identifier 4 for the process flow to loop back to the functional block B.

[0079] In various embodiments, the connector CALL 30 and the connector RETURN 32 are configured to allow the computer program being started once or several times and from several places during one execution of another program, including from other functions, and being branched back after the computer program being executed. In the depicted obfuscated code 10, the connector CALL 30 is configured to generate the event identifier 4 for the functional block A, such that the prologue 44 selects the functional block Aas the next functional block 2. The functional block D is configured to generate the event identifier 4 for the connector RETURN 32 such that the prologue 44 selects the connector RETURN 32. The connector RETURN 32 is configured to branch back the control flow to the other program.

[0080] In various embodiments of the obfuscated code 10, an epilogue function Epilogue 46 is created. The epilogue function 46 is configured to deregister entries. Hence, the epilogue function deregisters entries in the event manager, which have been registered by the prologue function. In various embodiments, the epilogue function 46 is configured to deregister all entries in the prologue function 44. In an advantageous embodiment, the epilogue function 46 is configured to deregister the prologue function 44 every time a control flow passes the connector RETURN 32 to thus end the function or computer program. Additionally, the epilogue function 46 may return a result in the control flow to a system or to another computer program. This allows the labels 12 and events to be deregistered and to take another visual appearance the next time the function is executed. In various embodiments, the epilogue function 46 is configured to deregister the prologue function 44 when the microprocessor is turned into a standby mode or is powered off. In an embodiment, the wherein the event identifier 4 is changed such that the event identifier 4 is different the following time the function is executed. This can be achieved with a random algorithm applied during build time. Fig. 3 shows a further step in view of Figure 2, and an embodiment of an additional obfuscation step, where the control flow is being further obfuscated. The prologue function Prologue 44, the epilogue function Epilogue 46, and the connector RETURN 32 are the same as described by reference to Fig. 2. In particular, the event identifiers 4 are generated in a manner providing an opacity protection 48. The opacity protection 48 hides the event identifier 4 generation from static analysis. The opacity protection 48 is an obfuscation method independent of our subject. Hence, an additional and independent obfuscation method is provided, which is separate from the nature of the event obfuscation. Generally, an event identifier 4 comprises or is generated from a predicate. An opacity protection 48 comprises hiding the predicate behind a runtime expression. For example, instead of explicitly indicating an event identifier 4 in a programming code of a functional block 2, the event identifier 4 is provided in a manner comprising a result of a calculation or an algorithm as a predicate. A trivial example of hiding the predicate ‘42’ would be to replace it with ’40 + 2’. However, more complex computations of predicates allowing to better hide constants are conceivable, such as using asynchronous computations, using mixed boolean arithmetic to hide operations, using server-side operations, cryptographic functions, etc. In various embodiments suspicious requests to generate predicates are provided with parameters causing incorrect execution of the obfuscated code for example leading to an incorrect result, a delay and / or an infinite loop. In various embodiments the event identifier 4 is generated by the respective functional block 2 only on the basis of parameters provided in the same functional block 2. In such a way, a plurality of event identifiers 4 is related to a unique and same function. For instance, each functional block 2 can be linked to a group of labels 12.

[0081] In various embodiments an event identifier 4 is generated on the basis of parameters provided by instances outside of the obfuscated code 20. In that case, the respective functional block 2 is configured to account for such change of the parameter while providing the same event identifier 4.

[0082] In various embodiments, an event may occur while the obfuscated code 20 is executed. If the event is generated by the obfuscated code 20 itself, in various embodiments the event is caught by the obfuscation and managed at a next wait present on a control flow path. If the event is external to the obfuscated code, the obfuscated code 20 is not concerned if the obfuscated code 20 only has a local context. If the event is external and the obfuscated code 20 only uses read-only global context, no problem will occur if the read-only global context is copied when the connector CALL 30 is processed. In various embodiments, an event identifier 4 is only generated on the basis of context from the functional block 2 generating the event identifier 4 and / or from read-only global context and the read-only global context is copied to a memory for the obfuscated code 20 when the connector CALL 30 is processed. If the event is external and the obfuscated code 20 uses a read / write global context, the respective functional block 2 is configured to account for such change of the context, and only provides a defined event identifier 4.

[0083] Fig. 4a shows the obfuscated code of the embodiment of Fig. 3 at runtime. Particularly, the obfuscated code is started at the connector CALL 30. Before or when the obfuscated code is started, the prologue function Prologue 44 registers the associations of the labels 12 of the functional blocks 2 and their respective event identifiers 4. The connector CALL 30 generates a specific event identifier. The prologue function Prologue 44 matches the event identifier 4 from the connector CALL 30 to a functional block 2. The matching is done before the respective functional block 2 is called by an event 14 from the event manager 28. The event identifier 4 of the connector CALL 30 presently relates to a functional block 2 (A in the illustrated example). An event manager evt 28 is configured to pass the control flow to the functional block 2 matching the respective event identifier 4. The event manager evt 28 passes the control flow to the functional block A 2. In various embodiments, the event manager 28 can listen for events using the so-called ‘on method’. The on- method means a functional block 2 can be called when a certain event 14 is received. When a functional block 2 provides the event identifier 4, a functional block 2 will be executed. In various embodiments the prologue function Prologue 44 lists functional blocks 2 for all event identifiers 4.

[0084] The functional block 2 (A in the illustrated example) operates and generates a next event identifier 4. In the illustrated example, the event identifier 4 is B. The prologue function Prologue 44 matches the next event identifier 4 to the functional block 2. The event manager evt 28 passes the control flow to the functional block 2.

[0085] In the illustrated example, the functional block B operates and provides a decision. The decision leads to generating either an event identifier 4 matching the functional block C or an event identifier 4 matching the functional block D. The event manager evt 28 passes the control flow to the respective functional block C or D. If the event manager evt 28 passes the control flow to the functional block C, the functional block C operates and generates a next event identifier 4. The prologue function Prologue 44 matches the next event identifier 4 to the functional block B. The event manager evt 28 passes the control flow to the functional block B.

[0086] If the event manager evt 28 passes the control flow to the functional block D, the functional block D operates and generates a next event identifier 4. The prologue function Prologue 44 matches the next event identifier 4 to the connector RETURN 32. The event manager evt 28 passes the control flow to the connector RETURN 32. The connector RETURN 32 branches back the control flow to the other program after the obfuscated code has been executed. In various embodiments, the connector RETURN 32 returns any results to the other program or system.

[0087] In various embodiments, the epilogue function Epilogue 46 deregisters entries in the event manager, which have been registered by the prologue function. In various embodiments, the epilogue function Epilogue 46 deregisters all entries. In various embodiments, the epilogue function Epilogue 46 deregisters the entries every time a control flow passes the connector RETURN 32 to thus end the obfuscated code and to return to a system or to another computer program. In various embodiments, the epilogue function Epilogue 46 deregisters the entries when the microprocessor is turned into a stand-by mode or is powered off. In various embodiments, the event identifiers 4 are removed from the EventEmitter instance.

Claims

CLAIMS1 . A computer-implemented method for obfuscating code control flow, the method comprising identifying functional blocks in a code to be obfuscated; associating a label to each functional block; associating at least one event identifier with each functional block; creating a prologue function configured to contain a registration for the at least one event identifier of each functional block; and creating an epilogue function configured to contain a deregistration for the event identifier of each functional block.

2. The method of claim 1 , wherein the steps of identifying the functional blocks and associating a label to each block is performed by the use of a parser.

3. The method of claim 1 or 2, wherein the functional block is included in an event block, and wherein the event block is non-sequentially or randomly distributed in the code.

4. The method of any one of the preceding claims, wherein the method is applied to a plurality of functions in the code, and wherein functional blocks of the plurality of functions are randomly mixed together in the code.

5. The method according to any one of the preceding claims, wherein the method further comprises the step of adding at least one additional functional block to the code, and wherein said additional functional block is excluded in the prologue.

6. The method of claim 1 , wherein the label is a random name unrelated to a function of the functional block and wherein the random name is stored in the prologue function.

7. The method of any one of the preceding claims, wherein identifying functional blocks comprises creating an abstract syntax tree of the code to be obfuscated; identifying individual statements in the abstract syntax tree; for each statement in the abstract syntax tree, identifying all predecessor statements and all successor statements;identifying statements that have a single predecessor statement and a single successor statement; identifying statements that have a single predecessor statement or a single successor statement; identifying statements that have no or at least two predecessor statements; identifying statements that have no or at least two successor statements; and for the identified statements identifying groups of successive statements such that every statement has a single successor statement in the group and / or is a last statement of the successive statements in the group, and every statement has a single predecessor statement in the group and / or is the first statement in the group; wherein the succession of statements is identified as one functional block.

8. The method of any preceding claim, wherein the code is provided in a programming language that uses imperative programming and supports event- driven programming.

9. The method of any preceding claim, wherein the registration of the prologue function comprises for each functional block at least one respective event identifier triggering that functional block.

10. The method of any preceding claim, wherein the deregistration comprises removing an event identifier from the registration of the prologue function.

11. The method of any preceding claim, further comprising identifying a statement triggered by a call event, and identifying a block containing the statement triggered by the call event as a start block.

12. The method of any preceding claim, further comprising identifying a statement triggering a program return as an end block.

13. The method of any preceding claim, wherein at least one event identifier is obfuscated and expressed as an event value, the event value being a function of a value generated only during a runtime of the obfuscated code.

14. The method according to the preceding claim, wherein the event identifier is changed such that the event identifier is different the following time the function is executed.

15. A computer-implemented method for running an obfuscated code control flow, the method comprising calling a prologue function of an obfuscated code by registering at least two functional blocks and for each functional block at least one event identifier triggering the respective functional block; calling a start block of the obfuscated code; executing a respective functional block and generating a respective event identifier by finishing executing the respective functional block; calling a next functional block as a function of the respective event identifier; calling an end block and returning a result of the obfuscated code; deregistering all functional blocks by removing at least one event identifier from the registration of the prologue function.

16. The method of claim 15, wherein the respective event identifier is determined by computation of an opaque predicate, the opaque predicate generating an event value through an expression including a value generated while running the obfuscated code.

17. A data processing apparatus comprising means for carrying out the method of any of claims 1-16.

18. A computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of any of claims 1-16.

Images