Systems, methods, and storage media for obfuscating a computer program by representing the control flow of the computer program as data

Abstract

Systems, methods, and storage media are disclosed for obfuscating a computer program by representing a control flow of the computer program as data that is not source code. Exemplary embodiments may: receive source code of a computer program; parse the source code; extract the control flow of the source code; represent at least a portion of the control flow as a control flow model using a mathematical modeling language; store the control flow model as control flow data that represents the control flow of the program and is non-executable code; and remove at least a portion of the control flow from the source code to thereby obfuscate the control flow of the source code and render the source code more resistant to tampering.

Description

Technical Field

[0001] The present disclosure relates to systems, methods, and storage media for obfuscating a computer program by representing the control flow of the computer program as data that is not executable code. Background Art

[0002] Computer software is typically written in a high-level language, which must be compiled into low-level object code in order to be executed on a computer or other processor. High-level computer languages use command terms that are closely similar to plain language, and thus can be easily understood by developers. Object code generally refers to machine-executable code, which is the output of a software compiler that transforms source code from human-readable code into machine-executable code.

[0003] The low-level structure of a software program is typically described in terms of its data flow and control flow. Data flow is a description of variables along with the operations performed on the variables. Control flow is a description of how to jump from block to block in a program during execution. For example, an If-Then-Else statement includes two operations to be performed on inputs and control flow, which directs the execution to one operation or the other based on a conditional variable.

[0004] Tampering refers to changing computer software in a way that violates the original author's intention. Conventionally, computer software programs have had limitations encoded therein, such as requiring password access, preventing copying, or only allowing the software to be executed a predetermined number of times or for a certain duration. However, since users can often access the software code, methods have been found to identify the code that manages these limitations. Once such encoding has been identified, an experienced user can overcome these program limitations by modifying the software code. In addition, it is difficult to prevent users from using tools such as debuggers to monitor the computer software while it is executing. This allows users to obtain the complete data flow and control flow.

[0005] Many attempts have been made to prevent attacks by "obfuscating" the code, such as making the organization of the software code more chaotic and thus more difficult to understand and modify. Software is commercially available to "obfuscate" the source in the code in such ways as:

[0006] • Globally replacing variable names with random strings. For example, each occurrence of the variable name "SecurityCode" can be replaced with the string "1xcd385mxc" so that it is more difficult for an attacker to identify the variable he is looking for;

[0007] • Deleting comments and other documentation; and

[0008] • Removing source-level structure indentation, such as the indentation of loop bodies, to make the loops more difficult to read.

[0009] In addition, it is known to obfuscate the control flow of a computer program. For example, U.S. Patent No. 5,748,741 describes a method of obfuscating computer software by artificially constructing a "complex wall". The "complex wall" is preferably a "cascade" structure, where each output depends on all inputs. The original program is protected by being merged with this cascade and by intertwining the two. The intention is to make it very difficult, if not impossible, for an attacker to separate the original program from the complex wall again, which is necessary for making changes to the original program. This method has limitations, such as large code expansion. The control flow of a program is one of the most important and readily available assets for understanding what the program is doing.

[0010] While conventional obfuscation techniques may attempt to hide the control flow of a program, the control flow statements still exist in the source code where they can be uncovered. In addition, the control flow of a program is a fixed asset that cannot be changed after the program has been deployed. Therefore, known mechanisms for obfuscating the control flow are not always effective.

[0011] As described above, it is desirable to prevent users from making small, purposeful changes to a computer program, such as overriding copy protection and timeouts in demonstration software. It is also necessary to protect computer software from reverse engineering, which can be used to identify valuable intellectual property contained within the software algorithm or model. For example, in hardware design, suppliers of application-specific integrated circuit (ASIC) cell libraries typically provide an exact software model corresponding to the hardware, enabling users to perform accurate system simulations. Since such disclosures typically provide enough detail to reveal the actual cell design, it is desirable to protect the contents of the software model.

[0012] Accordingly, there is a need for a method and system that make computer software more resistant to tampering and reverse engineering by removing the control flow from the executable code without introducing unrealistic overhead. Summary of the Invention

[0013] Embodiments described herein remove or hide source code related to the control flow and express the control flow as data that is not source code. For example, at runtime, this data can be used by an execution engine to determine the control flow of the program. Since the control flow statements in the source code are removed or hidden, it becomes very difficult, if not impossible, for an attacker to determine the control flow from the source code, and thus the software is more secure against attacks.

[0014] Some embodiments encode the control flow of a program as a modified Petri net, which is then represented as data that can be applied at runtime to execute the program. Petri nets are well-known models for describing various systems and will be described in more detail below. The embodiments described herein include novel processes for encoding the process flow of a computer program as a mathematical model, such as a Petri net, and for transforming the model into control flow data that is not source code. Since the control flow data represents the actual control flow, control flow statements in the source code can be removed, such that the source code of the program itself no longer has any control flow embedded therein.

[0015] When the control flow of a program is transformed into control flow data, a form of obfuscation is performed, effectively removing control flow statements from the program. This makes it more difficult for an attacker to reverse engineer the code. Since the control flow is transformed into data, many additional obfuscation possibilities can be applied to the control flow data, such as transforming or encoding the control flow data using existing encoding techniques (e.g., AES), or storing the control flow data away from the actual program.

[0016] When the control flow is extracted from a program, it can then be dynamically modified. It is no longer a fixed asset that cannot be changed after the program has been deployed. The modification can occur locally (self-modifying code) or on a server. The program can be distributed without control flow statements and the control flow data can be received later, such as at runtime or just before runtime, and / or through different channels when needed. This will become apparent to those skilled in the art from the following description.

[0017] One aspect of the present disclosure relates to a system configured to obfuscate a computer program by representing the control flow of the computer program as data that is not source code. The system may include one or more hardware processors configured by machine-readable instructions. The (one or more) processors may be configured to receive the source code of a computer program. The source code may include multiple computational functions of the program and the control flow of the program, and the control flow of the program defines the order in which the computational functions are executed. The (one or more) processors may be configured to parse the source code. The (one or more) processors may be configured to extract the control flow of the source code. The (one or more) processors may be configured to represent at least a portion of the control flow as a control flow model using a mathematical modeling language. The modeling language may include an event element for representing events that occur during the execution of the computer program, a condition element for representing conditions that occur during the execution of the computer program, and a composition of execution elements linked to portions of the source code for performing functions. Arcs may be used to link the event element with the condition element and the execution element. Tokens are associated with the condition element and the execution element to represent the state of the execution of the computer program. The (one or more) processors may be configured to store the control flow model as control flow data that represents the control flow of the program and is not executable code. The (one or more) processors may be configured to remove at least a portion of the control flow from the source code, thereby obfuscating the control flow of the source code and making the source code more resistant to tampering.

[0018] Another aspect of the present disclosure relates to a method for obfuscating a computer program by representing the control flow of the computer program as data that is not source code. The method may include receiving the source code of a computer program. The source code may include multiple computational functions of the program and the control flow of the program, and the control flow of the program defines the order in which the computational functions are executed. The method may include parsing the source code. The method may include extracting the control flow of the source code. The method may include representing at least a portion of the control flow as a control flow model using a mathematical modeling language. The modeling language may include an event element for representing events that occur during the execution of the computer program, a condition element for representing conditions that occur during the execution of the computer program, and a composition of execution elements linked to portions of the source code for performing functions. Arcs may be used to link the event element with the condition element and the execution element. Tokens are associated with the condition element and the execution element to represent the state of the execution of the computer program. The method may include storing the control flow model as control flow data that represents the control flow of the program and is not executable code. The method may include removing at least a portion of the control flow from the source code, thereby obfuscating the control flow of the source code and making the source code more resistant to tampering.

[0019] Another aspect of the present disclosure relates to a non-transitory computer-readable storage medium having instructions embodied thereon that are executable by one or more processors to perform a method for obfuscating a computer program by representing a control flow of the computer program as data other than source code. The method may include receiving source code of a computer program. The source code may include multiple computing functions of the program and a control flow of the program, the control flow defining an order in which the computing functions are executed. The method may include parsing the source code. The method may include extracting the control flow of the source code. The method may include representing at least a portion of the control flow as a control flow model using a mathematical modeling language. The modeling language may include an event element for representing events that occur during execution of the computer program, a condition element for representing conditions that occur during execution of the computer program, and a composition of execution elements linked to portions of the source code for performing functions. Arcs may be used to link the event element with the condition element and the execution element. Tokens are associated with the condition element and the execution element to represent a state of execution of the computer program. The method may include storing the control flow model as control flow data that represents the control flow of the program and is not executable code. The method may include removing at least a portion of the control flow from the source code to thereby obfuscate the control flow of the source code and render the source code more resistant to tampering.

[0020] These and other features and characteristics of the present technology, as well as the methods of operation and functions of the related elements of the structure and the combination of components and the economy of manufacture, will become more apparent upon consideration of the following description and the appended claims in reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals refer to corresponding parts in the various figures of the drawings. However, it should be clearly understood that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the present invention. As used in the specification and claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 Illustrates a computer architecture for obfuscating a computer program by representing a control flow of the computer program as data, according to one or more embodiments.

[0022] Figure 2 Is a flowchart of a method for obfuscating a computer program by representing a control flow of the computer program as data, according to one or more embodiments.

[0023] Figure 3 Illustrates an example of a conventional Petri net.

[0024] Figure 4is a high - level block diagram showing control - flow statements extracted from source code and embedded in a Petri net.

[0025] Figure 5a Shows an example of a template for mapping a While statement to a Petri net.

[0026] Figure 5b Shows an example of a template for mapping an IF - Then - Else statement to a Petri net.

[0027] Figure 5c Shows an example of a template for mapping a goto statement to a Petri net.

[0028] Figure 5d Shows another example of a template for mapping a goto statement to a Petri net.

[0029] Figure 6 Shows an example of specific code mapped to a Petri net.

[0030] Figure 7 The Figure 6 control - flow data of the Petri net is shown as an array.

[0031] Figure 8 Illustrates an example of the source code of a program that links to an execution element of a Petri net. DETAILED DESCRIPTION

[0032] Will first describe the implementation at a very high level in conjunction with Figure 1 and Figure 2 . Figure 1 Illustrates a computer architecture 00 according to one or more embodiments, which is configured to obfuscate a computer program by representing the control flow of the computer program as data other than source code. In some embodiments, the architecture 100 may include one or more servers 102. The (one or more) servers 102 may be configured to communicate with one or more client computing platforms 104 according to a client / server architecture and / or other architectures. The (one or more) client computing platforms 104 may be configured to communicate with other client computing platforms via the (one or more) servers 102 and / or according to a peer - to - peer architecture and / or other architectures. A user may access the (one or more) servers 102 via the (one or more) client computing platforms 104.

[0033] One or more servers 102 may be configured by machine-readable instructions 106. The machine-readable instructions 106 may include one or more instruction modules stored as executable code in, for example, an electronic storage device 132. The instruction modules may include computer program modules. The instruction modules may include a source code receiving module 108, a source code parsing module 110, a control flow extraction module 112, a control flow representation module 114, a control flow model storage module 116, a section removal module 118, a matrix receiving module 120, a simulation performance module 122, a trigger detection module 124, an execution causing module 126, a data transformation module 128, and / or one or more of other instruction modules. Modules 106, 108, 110, 112, 114, 116, and 118 complete the process of obfuscating program code. Modules 120, 122, 124, and 126 are part of an execution engine 150 described in more detail below, which operates at runtime of the obfuscated code. While the modules of one or more servers 102 may be implemented on various processors distributed in various ways, the modules of the execution engine 150 generally execute at runtime of the obfuscated code and, in some embodiments, for reasons that become apparent below, are stored and executed on a processor remote from the processor executing the other modules.

[0034] The source code receiving module 108 may be configured to receive the source code of a computer program to be protected by obfuscating its control flow. The source code may be unprotected or may have previous obfuscation or other protection mechanisms. The source code may include multiple computational functions of the program and the control flow of the program, which defines the order in which the computational functions are executed.

[0035] The source code parsing module 110 may be configured to parse the source code in a manner described in more detail below. The control flow extraction module 112 may be configured to extract the control flow of at least a portion of the source code in a manner described below. For example, as described in detail below, templates may be used to identify the control flow of various known programming constructs such as if-then statements. The templates may be stored in the electronic storage device 132 or in an external resource 130.

[0036] The control flow representation module 114 may be configured to represent at least a portion of the control flow as a control flow model using a mathematical modeling language for expressing the system. The mathematical modeling language may be a modified Petri net. The modeling language may include a composition of event elements for representing events that occur during the execution of a computer program, condition elements for representing conditions that occur during the execution of a computer program, and execution elements linked to portions of the source code for performing functions. Arcs may be used to link the event elements with the condition elements and the execution elements. Tokens are associated with the condition elements and the execution elements to represent the execution state of the computer program.

[0037] The control flow model storage module 116 can be configured to store a control flow model as control flow data that represents the control flow of a program and is not executable code. The control flow data can be stored as one or more matrices. As a non-limiting example, the one or more matrices can include a matrix indicating inputs and outputs to transition elements, event elements, and condition elements to thereby represent arcs. The matrix can also include a matrix representing the state of the process at any given time. The control flow data can be stored in the electronic storage device 132 or in the external resource 130.

[0038] The partial removal module 118 can be configured to remove at least a portion of the control flow represented by the control flow data from the source code to thereby obfuscate the control flow of the source code and render the source code more resistant to tampering.

[0039] As part of the execution engine 150, the matrix receiving module 120 can be configured to receive one or more matrices and / or any other control flow data stored by the control flow model storage module. The matrix and / or other control flow data can be received by the execution engine 150 during the runtime or before the runtime of the computer program.

[0040] The simulation performance module 122 can be part of the execution engine 150, which is configured to perform a simulation of the control flow model based on the matrix and / or other control flow data, that is, to execute the control flow represented by the model. Performing a simulation of the control flow model based on the matrix can include determining the inputs and outputs of each transition in the model and determining the association of tokens with condition elements and execution elements at each of one or more times based on the matrix.

[0041] The trigger detection module 124 can be part of the execution engine 150, which is configured to detect the triggering of a specific execution element based on the association of a token with the execution element. The execution causing module 126 can be configured to cause the execution of the portion of the source code linked to the specific execution element.

[0042] The data transformation module 128 can be configured to transform data in one or more matrices before execution to further obfuscate the control flow of the program. Of course, the execution engine 150 can have a module for reversing the transformation before execution (such as at runtime).

[0043] Figure 2 Method 200 for obfuscating a computer program by representing the control flow of the computer program as data that is not source code is illustrated according to one or more embodiments. The operations of method 200 presented below are intended to be illustrative. In some embodiments, method 200 can utilize one or more additional operations not described and / or be completed without one or more of the operations discussed. Additionally, in Figure 2The order of operations of method 200 illustrated and described below is not intended to be limiting.

[0044] In some embodiments, method 200 may be implemented in one or more processing devices (e.g., digital processors, analog processors, digital circuits designed to process information, analog circuits designed to process information, state machines, and / or other mechanisms for electronically processing information) of (one or more) servers 102. The one or more processing devices may include one or more devices that execute some or all of the operations of method 200 in response to instructions electronically stored on an electronic storage medium. The one or more processing devices may include one or more devices configured by hardware, firmware, and / or software to be specifically designed for the execution of one or more operations of method 200.

[0045] Operation 202 may include receiving the source code of a computer program. The source code may include multiple computational functions of the program and the control flow of the program, which defines the order in which the computational functions are executed. According to one or more embodiments, operation 202 may be performed by one or more hardware processors configured by machine-readable instructions, the machine-readable instructions including a module that is the same as or similar to source code receiving module 108.

[0046] Operation 204 may include parsing the source code. According to one or more embodiments, operation 204 may be performed by one or more hardware processors configured by machine-readable instructions, the machine-readable instructions including a module that is the same as or similar to source code parsing module 110.

[0047] Operation 206 may include extracting the control flow of the source code. According to one or more embodiments, operation 206 may be performed by one or more hardware processors configured by machine-readable instructions, the machine-readable instructions including a module that is the same as or similar to control flow extraction module 112.

[0048] Operation 208 may include representing at least a portion of the control flow as a control flow model using a mathematical modeling language. The modeling language may include an event element for representing events that occur during the execution of a computer program, a condition element for representing conditions that occur during the execution of a computer program, and a composition of execution elements that link to portions of the source code for performing functions. Arcs may be used to link the event elements with the condition elements and the execution elements, and tokens may be associated with the condition elements and the execution elements to represent the state of the execution of the computer program. According to one or more embodiments, operation 208 may be performed by one or more hardware processors configured by machine-readable instructions, the machine-readable instructions including a module that is the same as or similar to control flow representation module 114.

[0049] Operation 210 may include storing a control flow model as control flow data that represents the control flow of a program and is not executable code. According to one or more embodiments, operation 210 may be performed by one or more hardware processors configured by machine-readable instructions that include a module identical or similar to control flow model storage module 116.

[0050] Operation 212 may include removing at least a portion of the control flow from the source code to thereby obfuscate the control flow of the source code and render the source code more resistant to tampering. According to one or more embodiments, operation 212 may be performed by one or more hardware processors configured by machine-readable instructions that include a module identical or similar to partial removal module 118.

[0051] Before describing specific examples, some background information on Petri nets is provided. Figure 3 Illustrated is a relatively simple example of a conventional Petri net diagram. A Petri net, also known as a place / transition (PT) net, is a mathematical modeling language and graphical representation for describing a system. As Figure 3 illustrated, Petri net diagram 300 includes nodes 302 (referred to herein as "transition elements") that represent transitions in the process flow (i.e., events that may occur in the process) and are physically represented by bars. The "places" 302 of the Petri net (referred to herein as "condition elements") represent conditions of the process flow and are physically represented by circles. "Arcs" 306 represent which places (conditions) are preconditions and / or postconditions for which transitions. Arcs 306 are physically represented by arrows.

[0052] Arc 306 extends from condition element 304 to transition element 302, or vice versa. An arc never extends between condition elements 304 or between transition elements 302. Condition element 304 is referred to as an input condition element of the transition, from which the arc extends to transition element 302. A condition element is referred to as an output condition element of the transition element, from which the arc extends from the transition element to the condition element.

[0053] Graphically, a condition element 304 may include markings 308 called discrete amounts of “tokens”. Any distribution of tokens 308 over the condition element 304 will represent a configuration of a Petri net called a marking. In an abstract sense related to the Petri net graph, a transition element of the Petri net may fire if it is enabled, i.e., if there are sufficient tokens in all of its input condition elements. When a transition fires, it consumes the required input tokens and creates tokens in the output places of the transition. Firing is atomic, i.e., a single uninterruptible step. The firing rule of a transition can be characterized by subtracting from its input places the number of tokens equal to the multiplicity of the corresponding input arcs and accumulating at the output places the new number of tokens equal to the multiplicity of the corresponding output arcs. The flow of tokens 308 and the firing of transitions can be configured to model various systems.

[0054] The embodiments disclosed herein include a novel extension to the conventional Petri net. The extension is referred to herein as an “execution place” or “execution element”. An execution element has executable code associated with it by a link or other mechanism and triggers the execution of the associated code when the execution element is fired. An execution place is physically represented by a square herein. When a token arrives at an execution element in the Petri net, the Petri net execution halts and the code associated with the execution element is executed atomically. When the code execution is complete, the process may return to the Petri net execution. Thus, the Petri net can be used to determine the code flow, i.e., the next code block to be executed. This allows for further integration between the code and the Petri net representing the control flow of the code. Note that the executable code may include instructions for adding tokens from elements in the Petri net, or otherwise detecting and modifying the number of tokens in elements in the Petri net. For example, and an AddToken may be used such that the state of a running program can affect the flow of the program. In a sense, it is the only “if” required for the execution model. AddToken can be used to change the decision of the control flow based on the state of the running program.

[0055] The executable code associated with an execution element may be C code or any other suitable code that can be directly or indirectly executed by a computer processor. For example, the code may be any code that can indicate an action to be performed by a computer processor. Various mechanisms may be used to associate the code with the execution place.

[0056] As described above, conventional source code is received and processed to remove or hide the control flow of the source code and represent the control flow in a Petri net. Figure 4This is illustrated at a very high level. The source code is parsed (as described in more detail below) to identify control flow statements (S1, S2, and S3 in this example), and the control flow statements are associated with the execution elements 400 of a properly configured Petri net (also described in more detail below). Multiple control flow statements can be optimized and folded into a single execution element 402.

[0057] Figure 5a The parsing of the code, the extraction of the control flow statements, and the representation as a Petri net are illustrated in more detail. The example of Figure 5 is based on the common do while loop statement of code 502. A do while loop is a control flow statement that executes the code block at least once and then repeats or does not repeat the block depending on a given condition. A do while consists of a procedure symbol and a condition. First, the code within the block is executed, and then the condition is evaluated. If the condition is true, the code within the block is executed again. This repeats until the condition becomes false. As shown in the example of Figure 5, statement S1 is executed when the condition Cond is true. When the condition Cond is no longer true, statement S1 terminates and the control flow continues to statements S2 and S3. As shown in Figure 5, the Petri net 500 has been constructed with statements S1, S2, and S3 in the execution elements and condition elements P1 and P2. The condition element P1 corresponds to Cond = true, and the condition element P2 corresponds to Cond = false. The flow of this Petri net can be explicitly expressed as the following steps:

[0058] 1. A token is added to "S1" because this is the start of the PN;

[0059] 2. When a token is added to S1, since it is an execution block, the code of S1 will execute;

[0060] 3. "cond" will be set according to the rule (true will add a token at P1, and false will add a token at P2;

[0061] 4. Depending on the location where the token has been added, a transition with P2 as the input S1 and P1 or S2 and P2 can be triggered;

[0062] 5. If S1 - P1 has a token, the transition will be triggered, removing the tokens from S1 and P1 and adding a token to S2;

[0063] 6. S2 is an execution block, and the code of S2 will execute and cond will place another token at P1 or S2.

[0064] Figure 5b A template that can be used to parse the If then else statement code 512 and the corresponding Petri net 510 is illustrated. Figure 5cIllustrates a template that can be used to parse the goto statement code 522 to create a Petri net 520. In a sense, S2 is an X code block. Figure 5d Illustrates another template for the code 526 linked to the Petri net 524. In this template, X and Y are goto labels. S2 represents a Y code block, and S3 represents an X block. Various templates can have a common combination of logical flow and corresponding predefined Petri net configurations. The templates can be stored in a database, for example, stored in the external resource 130. The corresponding code portions can be identified based on the parsing of the code in a known manner. For example, tools such as pycparser can be used to parse the code. The parsed conditions and statements can be mapped to the corresponding Petri net elements according to the mappings provided in the template. Of course, the code of a single application may be mapped to multiple Petri nets.

[0065] Figure 5b Illustrates a template that can be used to parse the If then else statement code 512 and the corresponding Petri net 510. Figure 5c Illustrates a template that can be used to parse the goto statement code 522 to create a Petri net 520. In a sense, S2 is an X code block. Figure 5d Illustrates another template for the code 526 linked to the Petri net 524. In this template, X and Y are goto labels. S2 represents a Y code block, and S3 represents an X block. Various templates can have a common combination of logical flow and corresponding predefined Petri net configurations. The templates can be stored in a database, for example, stored in the external resource 130. The corresponding code portions can be identified based on the parsing of the code in a known manner. For example, tools such as pycparser can be used to parse the code. The parsed conditions and statements can be mapped to the corresponding Petri net elements according to the mappings provided in the template. Of course, the code of a single application may be mapped to multiple Petri nets.

[0066] Figure 6 Illustrates a more specific example of code parsing and Petri net creation. The code received by Figure 6 the example is a program written for the common calculation of completing an iterative Fibonacci sequence, which has many practical applications. The C code is listed at 602. For example, based on known patterns that match the template, the C code 602 can be parsed and the control flow statements can be identified and extracted. Then a Petri net 604 can be created to match the extracted control flow. For example, a known control flow (such as do while) can be mapped to an equivalent Petri net template configuration in the database, and the appropriate code can be inserted into the execution elements of the template Petri net.

[0067] In Petri net 604, P0 is the start condition element, P2 and P4 are "guard" condition elements. P1, P3, and P5 are execution elements with executable code associated therewith (as indicated by the rectangular boxes of Petri net 604). T1, T2, T3, T4, and T5 are transition elements of Petri net 604. At the start of execution, a token is at P0. Depending on the conditions, when the Petri net is executed by the execution engine, tokens will be generated in P2 or P4, as described below.

[0068] In Petri net 604, P0 is the "start" place (or "element"). The flow starts by placing a token at P0. Then the execution engine 150 executes the flow "algorithm" on Petri net 604. The only transition that can be triggered is T1. Since the Petri net is non-deterministic, any transition that can be triggered is triggered. After T1 is triggered, the token in P0 is removed, and a token is created in P1. Since P1 is an execution element, the code associated with P1 will be executed. This code has the condition that can place a token in P2 or P4. Let's assume the token is in P2. Petri net 604 now has 2 tokens, one in P1 and one in P2. In this state, only T2 can be triggered (T2 has two inputs, P1 and P2). If the input elements of T3 have tokens then T3 has one, but there is no token at P3, which is the input of T3. So T2 will be triggered, and the tokens in P1 and P2 will be removed, and a token will be added in P3. Since P3 is an execution element, the code associated with P3 will be executed. This code also has the condition that can place a token into P2 or P4. Let's assume again that it is P2. Now there will be a token at P2 and a token at P3. The only transition that can be triggered is T3. T2 cannot be triggered because there is no token in P1, and T5 cannot be triggered because there is no token in P4. To trigger T3, the token in P2 is removed, and the token in P3 is removed, and a token is added in P3. Since this is an execution element, the associated code is executed, which places a token into P2 or P4. This is a "loop", so we will assume a token is added in P4. In this state, there is a token in P3 and a token in P4, and the only transition that can be triggered is T5. T3 cannot because there is no token in P2, and T4 cannot because there is no token in P1. Triggering T5 removes the tokens in P3 and P4 and adds a token in P5, and executes the code associated with T5. In this state, there is still a token at P5 and no other tokens, so the Petri net algorithm will terminate because there are no longer any transitions that can be triggered.

[0069] Figure 6The Petri net 604 can be represented by control flow data that can be stored on a computer-readable medium. Preferably, the control flow data is not executable code for facilitating further obfuscation of the control flow data, etc. In this example, the control flow data is converted into a set of matrices. Figure 7 is Figure 6 an example of the control flow data of the Petri net. In Figure 7 the example, the control flow data is stored as 3 matrices. Matrix 710 represents Figure 6 the input of each transition element of the Petri net 604. Along the x-axis of matrix 710 are each of the condition elements and execution elements P0...P5. Along the y-axis of matrix 710 are each of the transition elements T0...T5, where T0 is an unused transition. For example, examining the second row of matrix 710, it can be seen that transition T1 has a single input of P0, indicated by a 1 in the first column. The other columns are 0, which indicates that the other elements are not inputs to transition T1. The inputs for all other transitions in the Petri net 604 are indicated in a similar manner in the corresponding rows of matrix 710 ("1" for connection, and "0" for no connection). Figure 7 Matrix 720 of

[0070] Figure 8 records the output of each transition in a similar manner. Matrix 730 is a dynamic matrix that records the number of tokens at each element P0...P5. As described below, this matrix is updated over time by the execution engine 150. Figure 8 shows how the code of a program can be linked to the execution elements of a Petri net according to an embodiment. As Figure 8 shown, the control flow has been removed from the program and replaced by a "switch" statement and a call to the "excuteNet()" function that calculates the next execution element to run. This is only one example of a set of possible embodiments. The "executeNet()" function works with the matrices to set how the control flow is represented and executed.

[0071] In addition to the functions disclosed above, the execution engine 150 will receive the control flow data and return the next set of linked code to be executed. The execution engine 150 will loop around the transitions of the Petri net to see which one(s) need to fire, it will fire the first one it encounters, and it will update the token data such as Figure 7(columns in matrix 730). If a token arrives at an execution element to be executed, the execution engine 150 will return the ID of that element; otherwise, it will loop around to trigger the next transition. The execution routine of the execution engine 150 can be linked to the executable code in a manner similar to the Java Virtual Machine (JVM). Only one copy of the execution routine of the execution engine 150 is needed to execute any Petri net, that is, only one copy is needed for all programs with the extracted control flow. Therefore, the implementation has very little "code bloat" and is very efficient.

[0072] An example of the algorithm of the execution engine 150 is as follows:

[0073] • Scan the input array corresponding to the transition ( Figure 7 710 in);

[0074] • If there is a 1 for the element, i.e., the element is an input to the transition, look at the token array ( Figure 7 730 in) to see if there is a token at that element;

[0075] • Repeat for each element;

[0076] • If there is a token at each input corresponding to the transition, trigger the transition;

[0077] · For each input to the transition, remove the token corresponding to the input from the token array ( Figure 7 730 in);

[0078] · For each element in the output array ( Figure 7 720 in), set the value of the token in the token array to 1;

[0079] • If P is an execution element, execute the associated code, decrement the token in the input position, and increment the token in the output position;

[0080] • Loop around and repeat until no transition can be triggered (the "order" of checking which transition to "trigger" can be top-down, bottom-up, or random).

[0081] In some embodiments, one or more servers 102, one or more client computing platforms 104, and / or external resources 130 may be operably linked via one or more electronic communication links. For example, such electronic communication links may be established at least in part via a network such as the Internet and / or other networks. It should be understood that this is not intended to be limiting, and the scope of the present disclosure includes embodiments in which one or more servers 102, one or more client computing platforms 104, and / or external resources 130 may be operably linked via some other communication medium.

[0082] A given client computing platform 104 may include one or more processors configured to execute computer program modules. The computer program modules may be configured to enable a user associated with the given client computing platform 104 to interface with the system 100 and / or external resources 130, and / or to provide other functionality attributed herein to one or more client computing platforms 104. As a non-limiting example, a given client computing platform 104 may include one or more of a desktop computer, a laptop computer, a handheld computer, a tablet computing platform, a netbook, a smartphone, a gaming console, and / or other computing platforms. For example, one or more client computing platforms 104 may be associated with parties providing software code to be processed by the server 102 for enhanced security.

[0083] External resources 130 may include information resources external to the system 100, external entities participating in the system 100, and / or other resources. For example, external resources may include remote storage devices for templates disclosed herein or remote storage devices for control flow data. In some embodiments, some or all of the functionality attributed herein to the server 102 may be provided by resources included in the external resources 130.

[0084] One or more servers 102 may include an electronic storage device 132, one or more processors 134, and / or other components. One or more servers 102 may include communication lines or ports to enable information exchange with a network and / or other computing platforms. Figure 1 The illustration of one or more servers 102 in is not intended to be limiting. One or more servers 102 may include multiple hardware, software, and / or firmware components that operate together to provide the functionality attributed herein to one or more servers 102. For example, one or more servers 102 may be implemented by a cloud of computing platforms operating as one or more servers 102.

[0085] The electronic storage device 132 may include a non-transitory storage medium that stores information electronically. The electronic storage medium of the electronic storage device 132 may include a system storage device provided integrally (i.e., substantially immovably) with the server(s) 102 and / or a removable storage device removably connectable to the server(s) 102 via, for example, a port (e.g., a USB port, a FireWire port, etc.) or a drive (e.g., a disk drive, etc.). The electronic storage device 132 may include one or more of an optically readable storage medium (e.g., an optical disc, etc.), a magnetically readable storage medium (e.g., a magnetic tape, a magnetic hard disk drive, a floppy disk drive, etc.), a charge-based storage medium (e.g., an EEPROM, a RAM, etc.), a solid-state storage medium (e.g., a flash drive, etc.), and / or other electronically readable storage media. The electronic storage device 132 may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and / or other virtual storage resources). As described herein, the electronic storage device 132 may store software algorithms, information determined by the processor(s) 134, information received from the server(s) 102, information received from the client computing platform(s) 104, and / or other information that enables the server(s) 102 to function.

[0086] The processor(s) 134 may be configured to provide information processing capabilities in the server(s) 102. Accordingly, the processor(s) 134 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Although the processor(s) 134 are Figure 1Shown as a single entity herein, but this is for illustrative purposes only. In some embodiments, the processor(s) 134 may include multiple processing units. These processing units may be physically located within the same device, or the processor(s) 134 may represent the processing functionality of multiple devices operating in concert. The processor(s) 134 may be configured to execute modules 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, and / or 128, and / or other modules. The processor(s) 134 may be configured to execute modules 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, and / or 128, and / or other modules by software; hardware; firmware; some combination of software, hardware, and / or firmware; and / or other mechanisms for configuring processing capabilities on the processor(s) 134. As used herein, the term "module" may refer to any component or collection of components that performs the functionality attributed to the module. This may include one or more physical processors, processor-readable instructions, circuits, hardware, storage media, or any other component during the execution of processor-readable instructions.

[0087] It should be understood that although modules 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, and / or 128 are Figure 1The figure shows an implementation within a single processing unit, in an embodiment where one or more processors 134 include multiple processing units. One or more of modules 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, and / or 128 may be implemented remotely from other modules. The description of the functionality provided by the various modules 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, and / or 128 described below is for illustrative purposes and is not intended to be limiting, since any of modules 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, and / or 128 may provide more or less functionality than described. For example, one or more of modules 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, and / or 128 may be eliminated, and some or all of their functionality may be provided by other modules among modules 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, and / or 128. As another example, one or more processors 134 may be configured to execute one or more additional modules that may perform some or all of the functionality attributed to one of modules 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, and / or 128.

[0088] Although the present technology has been described in detail for purposes of illustration based on the currently considered most practical and preferred embodiments, it is to be understood that such details are for that purpose only and that the technology is not limited to the disclosed embodiments, but rather is intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it is to be understood that the present technology contemplates, to the extent possible, that one or more features of any embodiment may be combined with one or more features of any other embodiment.

Claims

1. A system configured to obfuscate a computer program by representing the control flow of the computer program as control flow data that is not source code, the system comprising: One or more hardware processors configured by machine-readable instructions to: Receive source code of a computer program, the source code including a plurality of computational functions of the program and the control flow of the program, the control flow of the program defining an order in which the computational functions are executed; Parse the source code; Extract at least a portion of the control flow of the source code; Represent at least a portion of the control flow as a control flow model using a mathematical modeling language, the mathematical modeling language including an event element for representing events that occur during execution of the computer program, a condition element for representing conditions that occur during execution of the computer program, and a composition of execution elements linked to portions of the source code for performing functions, wherein arcs are used to link the event elements with the condition elements and the execution elements, and wherein tokens are associated with the condition elements and the execution elements to represent the state of execution of the computer program; Store the control flow model as control flow data representing the control flow of the program, wherein the control flow data is not executable code; and Remove at least a portion of the control flow from the source code to thereby obfuscate the control flow of the source code and render the source code more resistant to tampering.

2. The system of claim 1, wherein the control flow data is stored as one or more matrices.

3. The system of claim 2, wherein the one or more matrices include at least one matrix that indicates inputs to transition elements, event elements, and condition elements and outputs of the transition elements, the event elements, and the condition elements to thereby represent the structure of the control flow model.

4. The system of claim 2, wherein the one or more matrices include a matrix that indicates the association of tokens with the condition elements and the execution elements at one or more times during execution of the computer program.

5. The system of claim 2, wherein the mathematical modeling language is a modified Petri net.

6. The system of claim 5, wherein the one or more hardware processors are further configured by machine-readable instructions to: Receive the one or more matrices by an execution engine; Perform a simulation of the control flow model by the execution engine based on the matrices; Detect, by the execution engine, a trigger of a particular execution element based on the association of the tokens with the execution element; Cause execution of a portion of the source code linked to the particular execution element.

7. The system of claim 6, wherein performing a simulation of the control flow model based on the matrices includes determining, for each of the one or more times, the association of tokens with condition elements and execution elements based on the matrices.

8. A method of obfuscating a computer program by representing the control flow of the computer program as data that is not source code, the method comprising: Receiving source code of a computer program, the source code including a plurality of computational functions of the program and a control flow of the program, the control flow of the program defining an order in which the computational functions are executed; Parsing the source code; Extracting at least a portion of the control flow of the source code; Representing at least a portion of the control flow as a control flow model using a mathematical modeling language, the mathematical modeling language including an event element for representing an event occurring during execution of the computer program, a condition element for representing a condition occurring during execution of the computer program, and a composition of execution elements linked to portions of the source code for performing functions, wherein arcs are used to link the event element with the condition element and the execution elements, and wherein tokens are associated with the condition element and the execution elements to represent a state of execution of the computer program; Storing the control flow model as control flow data representing the control flow of the program, wherein the control flow data is not executable code; and Removing at least a portion of the control flow from the source code to thereby obfuscate the control flow of the source code and render the source code more resistant to tampering.

9. The method according to claim 8, wherein the control flow data is stored as one or more matrices.

10. The method according to claim 9, wherein the one or more matrices include a matrix that indicates inputs to transition elements, event elements, and condition elements to thereby represent a structure of the control flow model.

11. The method according to claim 9, wherein the one or more matrices include a matrix that indicates an association of tokens with the condition element and the execution element at one or more times during execution of the computer program.

12. The method according to claim 9, wherein the mathematical modeling language is a modified Petri net.

13. The method according to claim 12, further comprising: Receiving, by an execution engine, the one or more matrices; Performing, by the execution engine, a simulation of the control flow model based on the matrices; Detecting, by the execution engine, a triggering of a particular execution element based on the association of the tokens with the execution element; and Causing execution of a portion of the source code linked to the particular execution element.

14. The method according to claim 13, wherein performing the simulation of the control flow model based on the matrices includes determining, for each of the one or more times, the association of the tokens with the condition element and the execution element based on the matrices.

15. A non-transitory computer-readable storage medium having instructions embodied thereon that are executable by one or more processors to perform a method for obfuscating a computer program by representing a control flow of the computer program as data that is not source code, the method including: Receiving source code of a computer program, the source code including a plurality of computational functions of the program and a control flow of the program, the control flow of the program defining an order in which the computational functions are executed; Parsing the source code; Extract at least a portion of the control flow of the source code; Represent at least a portion of the control flow as a control flow model using a mathematical modeling language, the mathematical modeling language including an event element for representing an event occurring during execution of the computer program, a condition element for representing a condition occurring during execution of the computer program, and an execution element portion linked to the source code for performing a function, where arcs are used to link the event element with the condition element and the execution element, and where tokens are associated with the condition element and the execution element to represent the state of execution of the computer program; Store the control flow model as control flow data representing the control flow of the program and not executable code; And Remove at least a portion of the control flow from the source code to thereby obfuscate the control flow of the source code and render the source code more resistant to tampering.

16. The computer-readable storage medium according to claim 15, wherein the control flow data is stored as one or more matrices.

17. The computer-readable storage medium according to claim 16, wherein the one or more matrices include a matrix that indicates inputs to transition elements, event elements, and condition elements to thereby represent the structure of the control flow model.

18. The computer-readable storage medium according to claim 16, wherein the one or more matrices include a matrix that indicates the association of tokens with the condition elements and the execution elements at one or more times during execution of the computer program.

19. The computer-readable storage medium according to claim 16, wherein the mathematical modeling language is a modified Petri net.

20. The computer-readable storage medium according to claim 19, wherein the method further includes: Receiving, by an execution engine, the one or more matrices; Performing, by the execution engine, a simulation of the control flow model based on the matrices; Detecting, by the execution engine, the triggering of a particular execution element based on the association of the token with the execution element; and Causing execution of the portion of the source code linked to the particular execution element.

21. A method for executing a program that has been obfuscated by representing the control flow of a computer program as data that is not source code, at least a portion of the control flow of the source code having been extracted and represented as a control flow model using a mathematical modeling language, the mathematical modeling language including an event element for representing an event occurring during execution of the computer program, a condition element for representing a condition occurring during execution of the computer program, and an execution element portion linked to the source code for performing a function, where arcs are used to link the event element with the condition element and the execution element, and where tokens are associated with the condition element and the execution element to represent the state of execution of the computer program, the method including: Receiving the control flow model as control flow data representing the control flow of the program and not executable code; Performing a simulation of the control flow model based on the control flow data; Detect the triggering of a specific execution element based on the association of the token with the execution element; and Cause the execution of the portion of the source code linked to the specific execution element.

Images