Patent ID: 12210613

DETAILED DESCRIPTION

This disclosure provides various techniques to reduce the effectiveness of reverse engineering of computer programs. These techniques may be used singly or in various combinations, and it is contemplated that a several techniques used together will complement each other to provide robust protection that will be difficult to overcome. A computer device, system, or network that implements these techniques will have improved operation in that it will be more difficult to disrupt and provide greater security to data.

FIG.1shows an example system10. The system10includes a server14and a plurality of computer devices or client devices18connected via a computer network16. The client computer device18and server14are intended to communicate information with one another vis the computer network16.

The computer devices18may be operable by a plurality of users. The computer devices18may include notebook computers, smartphones, desktop computers, servers, or any other computer device operable by a user. And number of computer devices18may be provided.

The server14is used to communicate data with the computer devices18for an intended purpose. Examples of servers include messaging servers, email servers, web servers, database servers, hosting servers, social network servers, secure file servers, enterprise servers, and the like. Any number of servers14may be provided.

The computer network16may include a wide-area network (WAN), a local-area network (WAN), the internet, or a combination of such. The computer network16may provide wired and/or wireless connectivity.

An attacker computer device20, such as a man-in-the-middle attacker or spoofer, may attempt to impersonate a client computer device18, modify communications between a client computer device18and the server, modify program code exchanged between a client computer device18and the server14, eavesdrop, or otherwise disrupt communications. The attacker computer device20may be operated by a human, i.e., a hacker, but this type of threat is becoming less of a risk to modern secure systems. What is a greater risk is that the attacker computer device20may operate an autonomous program that attempts to probe and attack numerous computer devices18and servers14. Such programs may use artificial intelligence (AI) techniques to find holes in security, mimic programs at the computer devices18and/or server14, and perform similar attacks.

The techniques discussed herein aim to reduce the likelihood of success of the attacker computer device20, slow down the activities of the attacker computer device20, and/or thwart and confound potential attacks, so that the client computer devices18and server14may communicate in a secure and efficient manner, as intended.

FIG.2shows an example system22. The system22is substantially the same as the system10ofFIG.1, except as discussed below.

The system22includes a generator24for generating a plurality of different computer programs26,28that have the same general functionality. The generator24may be operated by a server connected to the computer network16.

Each computer program26,28is distributed to a different client computer device18. In this example, the computer programs26,28provide data communications functionality with the server14to achieve a desired functionality. However, the computer programs26,28are different and may be unique. As such, each computer device26,28may have a unique copy of the same general program.

The generator24generates the computer programs26,28and may also distribute the computer programs26,28to the client computer devices18. Alternatively, the generator24provides the computer programs26,28to the server14, which distributes the computer programs26,28to the client computer devices18. The generator24may include a program that is executed at the server14. The generator24may include separate server that is connected to the server14via a secure connection.

Program code that has an executable or other programmatic function may be used as a cryptographic key. This may allow a modification of the program code to be detected based on the result of the cryptographic process. For example, if a program is modified (even by changing one bit), its use as a key will very likely fail.

The computer programs26,28can be used a private keys in an asymmetric cryptographic scheme. Corresponding public keys30,32may be generated by the generator24and provided to the server14. The server14and each client computer device18thus possess a respective shared secret that can be used to verify that a computer program26,28has not been modified. The computer program26,28can itself provide communications functionality to the server14and cryptographic functionality to verify that its has not been modified.

For example, the server14may instruct a computer program26at a client computer device18to decrypt encrypted data using the computer program26as a key. The server14previously encrypted the data using the public key corresponding to the computer program26as private key. Hence, if the computer program26has not been modified, the computer program26can be used as the private key to successfully decrypt the data. If the computer program26has been modified, then decryption will most likely fail. As such, encrypted data communications can be implemented.

In other examples, the data is test data that the server14uses to verify the integrity of the computer program26. The computer device18should thereby provide the decrypted expected data to the server14, so that the server14can determine that the computer device18can be trusted. If the returned test data is not as expected, then the server14may determine that the computer program26has been modified. The server14can then take appropriate action, such as alerting the operator of the computer device18, blocking communications, and so on.

For example, an attacker20may intercept a copy of the computer program26and modify it, so as to insert eavesdropping code or other malicious code in an attempt to disrupt secure communications between the computer device18and the server14. The attacker20may try to modify the computer program26as operated by the computer device18, so that the computing device18may share secure information with the attacker20. However, since any modification of the computer program26will virtually always destroy the program's capability to act as the private key corresponding to the public key30held by the server14, such modification will prevent the decryption of data encrypted by the public key. Further, such modification is readily detectable by the server14.

FIG.3shows a method40of generating and distributing programs to be used as private keys for integrity checking. The method40may be implemented by instructions stored at a non-transitory computer-readable medium and operable by a processor. The method40may be performed by the generator24and/or server14.

At block42, a plurality of computer programs is generated using code and a source of randomization. The code may be written by a software programmer to fulfill an intended purpose. The code may be source code that is compiled, bytecode that is executable on a virtual machine, an executable file that is executable on a real machine, or an interpreted program that is executable by an interpreter. Block42may include salting the intended code with randomness and then compiling the salted code to obtain an instance of a computer program. This may be done any number of times to obtain different, and potentially unique, instances of the computer program.

The source of randomization may introduce randomness to different instances of the computer program by randomizing an instruction set, randomizing function/variable names, adding dummy functions/variables, modifying code without changing effect (e.g., changing “if x>10 then do something” to “if x<=10 then do nothing, else do something”), or similar.

As such different versions of the same program are generated. The different versions are functionality the same but are nonetheless different. The different versions may be unique. However, various different versions may be reused if the reduced security can be tolerated.

At block44, a plurality of public keys is generated using the plurality of computer programs as private keys. A private key and public key pair is thus generated and may be used for asymmetric cryptography to verify that a computer program has not been modified.

At block46, the plurality of computer programs may be distributed to different computer devices to provide for use in communications with a server or other functionality. The corresponding public keys may be provided to the server. In various examples, each end user receives a unique computer program or file, which is distinguishable from every other computer program or file that has been generated.

The functionality provided by the computer program may then be carried out. For example, in an encrypted communications example, messages are encrypted at the computer device using the computer program itself as the private key and then transmitted to the server. Incoming messages received from the server, and encrypted by the public key, are received and decrypted by the computer program which uses itself as the private key.

In other examples, the private key is held by the server and the computer program acts as a public key.

As shown inFIG.4, random information50may be combined with functional program code52to obtain various different or unique instances or versions of the program54. Each program instance54may be considered a private key and may be used to generate a corresponding public key.

Each computer program instance54, while different or unique in the sense of its generation, may perform the same function. For instance, an example of a computer program52may be an encrypted messaging platform, which may be supported by a server14(FIG.2). Each instance54of the program may perform the same messaging functionality (e.g., send and receive messages, store messages, insert attachments, etc.) with somewhat different code. Each computer program instance54may include bytecode that is executable on a virtual machine, an executable file that is executable on a real machine, or an interpreted program that is executable by an interpreter.

The above-described technique may be used to detect unauthorized modification to a program instance54. For example, a program instance54may be sent a query that is generated based on the corresponding public key56. The program instance54should be able to properly respond to the query using itself as the private key. Hence, if the program instance54cannot properly respond to the query, then the querying party may determine that the program instance54has been compromised. In the example of an encrypted communications system, it could be that a malicious user has modified the program instance54in an effort to hack the encrypted communications system. However, because the program instance54was modified, it cannot function as the expected private key. Failure of program instance54to be able to respond to a query based on the public key56informs the encrypted communications system that the program instance54can no longer be trusted.

FIG.5shows another technique that may be used to verify integrity of code in a computer program. This technique spreads programmatic operators or instructions among different lines of code. A method70that implements this technique may be performed at a computer program executed by a client computer device18, as shown inFIG.1. The method70may be implemented by instructions stored at a non-transitory computer-readable medium and operable by a processor. The method70may be performed by the client computer device18and, more specifically, by a virtual machine at the client computer device18.

Each lines of a computer program may include only a partial operator, in addition to any operands. A different line, such as a preceding line, may contain a key to complete the partial operator. The method70begins with such a program.

At block72, for the current line of code being executed, a preceding line of code is referenced. A key from the preceding line is obtained.

At block74, the obtained key is combined with the partial operator at the current line to obtain a complete operator.

At block76, the expected operation of the current line is carried out, using an operands present.

In the example below, a program snippet is written with partial operators “42” and “36” and operands “16” and “12.” Further included are keys “10” and “5.” As such, each line of code includes a partial operator, a key, and an operand, if appropriate.

42 10 16

36 5 12

During execution, the partial operator “36” is combined with the key “10” from the preceding line of code. Combination of such may use any function, such as a logical operation (XOR, AND, OR), summation, or similar. For explanatory purposes, partial operator “36” and key “10” are added to obtain a true operator “46,” which is then executed on operand “12” to perform the intended function.

A sequence of lines of code thus configured provide security in the sense that each line depends on another line in order to obtain the correct operator. Any insertion or deletion of a line of code, so as to insert eavesdropping code or circumvent security measures, would disrupt the sequence and result in incorrect operators. A modification to an operator in line of code would also likely disrupt the sequence if the key in the other line is not also changed.

It should be noted that it is not necessary for a line to depend on an immediately preceding line, as it may instead depend a line that is two lines removed, three lines removed, or distant according to some deterministic function.

This technique may protect code from being maliciously or otherwise tampered with as a perpetrator would not be able to insert additional lines of code (or remove lines) into the entirety of the program, without disrupting the expected sequence of keys and partial operators.

Another technique is illustrated inFIG.6. The time taken to execute program operations may be used to detect whether the program has been compromised. This technique may be implemented by instructions stored at a non-transitory computer-readable medium and operable by a processor.

A computer program82is provided at a client computer device18. The computer program82interacts with another computer program84at a server14, so as to implement desired functionality, such as encrypted communications among other examples discussed herein. The client-side program82and server-side program84may communicate data86back and forth to provide the functionality.

The client-side computer program82may have know or measured time of execution for specific functions or other blocks of code. If the code is modified, then the time of execution may change significantly. As such, time of execution at the client computer device18may be used to determine whether the client-side computer program84has been modified.

Quantification of expected time of execution of various blocks of code may be performed by the server14or another secure computer device.

Time of execution for a block of code may depend on parameters provided to code and may also depend on the hardware and runtime environment. The server14may have a copy of the computer program82and may determine time of execution for the computer program82. The server14may simulate the hardware and runtime environment of the client-side computer program82and measure the time of execution of a block of code of the computer program82. The server14may also provide the same or similar parameters to its copy of the computer program82as the client computer device18provides, or is expected to provide, to the client copy of the computer program82. Hence, the server14can determine an expected time of execution for a portion of the computer program82.

Quantification of expected time of execution may be performed in real time, for example, at the server14, as the client is also executing the computer program82. Quantification of expected time of execution may be performed in advance.

In various examples, the computer program82is profiled for different hardware and runtime environments, different parameters, and/or other conditions that significantly affect time of execution. A matrix of times of execution may be constructed, from which the server14can look up an expected time of execution for a certain set of circumstances, when needed.

The computer program82at the client computer device18may measure and report to the server14time of execution for a block of code. The server14may compare the time of execution to an expected time of execution, as measured by server simulation or as previously quantified. If the actual reported time of execution deviates significantly from the expected, then the server14may determine that the computer program82at the client computer device18has been modified or otherwise compromised. A threshold deviation may be used, such as 10% off expected time, 20% off expected time, or similar.

The computer program82may report a time of execution as a duration, a timestamp, or other indication of duration of execution. In some examples, as shown inFIG.7A, the computer program82uses a timer or clock to measure duration of execution of a block of code and directly reports the duration104to the server14, in response to a request100from the server14to perform the computation102. In other examples, as shown inFIG.7B, the computer program82reports a start time110and an end time112of code execution, as timestamps, and the server14computes the duration taken. In still other examples, as shown inFIG.7C, the client-side computer program82reports a start time112for execution of the block of code, when execution is complete, and the end time may be computed by the server14based on the time T0 that the server14made the request and a known or measured latency for data communications between the server14and the computer device18. Latency may be taken as the difference between T0 and the start time116reported by the client-side computer program82and may be assumed to not change significantly during the process. That is, the request100made by the server14may be used to measure latency. In a similar example, as shown inFIG.7D, the client computer device18reports end time112, when the computation is complete, and the server14infers start time from time of request T0 and latency measured as the difference between the reported end time and the time that the server14received such. Some of these examples may require clock synchronization, or at least a known difference, between the server14and the client computer device18.

A reported timestamp or duration may be obfuscated, hashed, or encrypted.

For example, the server-side computer program84may instruct the client-side computer program82to perform a computation with a parameter provide by the server-side computer program84. The server-side computer program84may know or be able to compute the expected time of execution for the computation by the client-side computer program82. The client-side computer program82performs the computation and responds to the server-side computer program84. The response may include a duration for the computation that the server-side computer program84can compare to the expected duration of execution. Alternatively, the response may include a timestamp indicating the time that the client-side computer program82began the computation. The server-side computer program84may compute network latency from the difference between the received timestamp and the time that the server-side computer program84made the request. The server-side computer84may thus compute the duration of execution at the client-side computer program82by subtracting the round latency from the total roundtrip time. A similar computation may be performed if the client-side computer program82returns a timestamp indicating the end of the computation.

The latency of communications of data86may be knowable or measurable.

The server14can thus compare an expected time of execution with an actual time of execution as reported by the client computer device18or as inferred from communications with the client computer device18, without the client computer needing to report a timestamp or duration. The server14can compensate for latency in communications of data86by, for example, subtracting a measured or approximate latency from a round trip communication initiated at the server14.

For example, the server14may instruct the computer program82at the client computer device18to compute a value with a given set of starting parameters. The server14may provide the same set of parameters to its copy of the computer program82and measure the time of execution to be, for instance, 150 ms. If the network latency is 100 ms from server14to computer device18and 100 ms back again, then the server14can expect a total time of 350 ms for the computer program82at the client computer device18to return the requested value. A threshold may be used to determine whether the actual total time, as measured by the server14, is within expected. For example, a threshold of 50 ms may be used. Hence, if the measure time is less than 300 ms or greater than 350 ms, then the server14may determine that the computer program82has been modified or compromised.

Network latency measurements can be time averaged, so that sudden changes in latency can be compensated.

The function or other block of code used to check duration of execution may be specifically designed to take a significant amount of time, so as to reduce error that may be introduced by fluctuations in latency, variance among different client computers18, and similar factors.

The function or other block of code used to check duration of execution may provide desired functionality to the computer program82. The code may be used to perform a function that takes significant time. The code may be purposely designed to take longer than necessary. The function or other block of code used to check duration of execution may be used for no other purpose than to verify integrity of the computer program82via duration of execution.

Another technique is illustrated inFIG.8. This technique hashes memory space used by a computer program and checks for discrepancies that may indicate modification of the computer program. A method120that implements this technique may be performed at a computer program executed by a client computer device18, as shown inFIG.1. The method120may be implemented by instructions stored at a non-transitory computer-readable medium and operable by a processor. The method120may be performed by the client computer device18and, more specifically, by a virtual machine at the client computer device18.

When a computer program is being executed, it may from time to time write data to memory (e.g., RAM, hard drive, etc.), at block122, to provide its intended functionality.

At block124, a hash can be computed for the memory space used to this store data. Any suitable hashing algorithm may be used, such as MD5, SHA-3, BLAKE2, CRC (cyclic redundancy check), or similar.

At block126, the current hash value is compared to a previous hash value for the same memory space. The comparison is made at a time after the current hash value and before the computer program would normally be expected to write data to the memory space. As such, the current and previous hashes values are expected to be identical. If the hashes are not identical, then it may be that the computer program has been modified to write data to memory outside the expected timeframe or it may be that its memory space is being written to by another program.

If the hash values are determined to be identical, at block128, then the program continues, at block130. If the hashes values are determined to be different, then the program may be halted, at block132, and/or other action may be taken in view of the likely unauthorized modification of the program.

This technique may provide protection against malicious tampering to program code or its memory space. By modifying the contents of the program's memory space, a malicious actor would therefore change the current hash. As such, the expected hash match would not occur and the program or its operator would be alerted to the problem.

The timing of blocks124and126with respect to the program's normal operations should be set so that no change to the memory space is excepted. Further, the memory space that is hashed may be the entire memory space used by the program, a subset of such memory space, or a block of memory that is selected randomly, perhaps at runtime, so as to reduce the cost of this check.

FIG.9shows a computer program134that includes instructions that may be executed by a processor or a virtual processor/machine to implement the technique discussed above.

The program134accesses a region of allocated memory136of a general-purpose memory138. The program writes140to allocated memory136to realize its functionality and computes142hashes144of the allocated memory136from time to time. Two or more hashes are computed at different times when the content of the allocated memory136is not expected to change. The program134compares time-adjacent hashes144and determines that unauthorized access the allocated memory136has occurred if the hashes144do not match. The program134continues its operations as long as hashes144match and may halt operation, raise an alert, or take other action.

FIG.10shows an example method300of verifying software code using modified hashes and is represented in the form of a flowchart. Method300can be performed using example system10.

At block305, software code on client device18is modified. The modifications (also known as mutations) will not impact the functionality of the software code itself and will not affect the user. Examples of modifications to the software code may include changing variable names, changing the spacing between lines of code, changing the calculation of variables that are not used and changing the order of functions within the code. The modification that is performed is chosen by the processor on the client device18at random. Once changes have been made, a hash is created from the software code at block307. Hashes are distinct to the software code itself, and any changes that have been made to the software code would mean a new hash.

At block310, the hash is sent from the client device to server14. Server14may contain a predetermined list of hashes, based off of the original software code. The predetermined list of hashes can be calculated, or they can be obtained through simulation of the software code going through changes. For example, when generating the predetermined list of hashes, the software code could be simulated, and would then be modified in the simulation to replace a variable name throughout the software code. The hash would then be saved to server14. Multiple different modifications would be simulated, and their corresponding hashes stored. This exercise would generate a list of hashes, which would then be able to be used for future verifications from client devices18.

At block315, the hash from the modified software code from client device18would then be compared to the predetermined list of hashes. If the hashes do not match, then at block X25, a negative response or a do not proceed signal is sent to the client device18, indicating to client device not to proceed with any transactions, as the client device may have been tampered with. In the alternative, should the software code be spoofed, and there is an attacker20trying to get access to the system by pretending to be the original client device18, then a negative response will be sent to the attacker20, and the software would not proceed.

If the hashes do match, then at block320a positive response or a safe to proceed signal is sent to client device18, and the software code continues to operate.

FIG.11shows an example block diagram of a non-transitory machine-readable storage medium350storing machine-readable instructions for client device18. In particular, the machine-readable instructions are executable by a processor on client device18. Generally, the storage medium350stores instructions to cause a processor to execute an example method of verifying software code using modified hashes. Specifically, the storage medium350includes modification instructions355, creation of hash instructions360, transmission of hash instructions365, and confirmatory response instructions370.

The modification instructions355when executed, cause a processor to modify the software code in the client device18. As indicated above, there are various examples of modification to the software code, and the type of modification is chosen at random.

The creation of hash instructions360when executed, cause a processor to create a hash out of the software code that has been modified. The transmission of hash instructions365when executed, cause a processor to send the hash instructions to server14.

The confirmatory response instructions370when executed, cause a processor to analyze the response received from server14. If a negative response is received, no action will be taken, and any pending transactions in the software may be halted. If a positive response is received, then pending transactions in the software will proceed. Until a response is received, any pending transactions in the software may be queued, but may not be processed.

FIG.12shows an example block diagram of a non-transitory machine-readable storage medium400storing machine-readable instructions for server14. In particular, the machine-readable instructions are executable by a processor on server14. Generally storage medium400stores instructions to cause a processor to execute an example method of verifying software code using modified hashes. Specifically, storage medium400includes comparison of hash instructions410and transmission of confirmatory response instructions415.

The comparison of hash instructions410when executed, cause a processor to take a received hash and compare it against the predetermined list of hashes. If there is a match, then a positive response is generated. If there is no match, then a negative response is generated. The response is sent by the processor when the transmission of confirmatory response instructions415is executed.

FIG.13shows an example system250. The system250is substantially the same as the system10ofFIG.6, except as discussed below.

A client computer device18operates a client-side computer program82and a server operates a server-side computer program84. The programs82,84cooperate to implement desired functionally, such as encrypted messaging or other functionality discussed elsewhere herein.

The programs82,84share a set of variables252. However, a larger set of variables254is used for communication between the programs. Moreover, a particular communication may only use a small subset of the larger set of variables254. The programs82,84share logic that controls the mapping of the larger set254to the actual variables used at any given time. Some of the larger set of variables254are not used by the programs82,84to implement the functionality and may be assigned arbitrary values. An attacker20eavesdropping on communications between the computer device18and the server14may be confounded by seeing different variables used at different times with little apparent consistency or rationale behind their use.

With reference toFIG.14, a program82,84includes core instructions260that implement the desired functionality. The program82,84further includes variable mapping logic262that maps a larger set of external variables254to internal variables252. External variables254are communicated via a computer network and therefore potentially exposed. Internal variables252are used by program82,84to implement the desired end-user functionality of the program82,84.

For any given communication, a subset264of external variables254may be used. The variable mapping logic262controls the subset264of external variables254used for any given communication, as well as the mapping of the subset264of external variables254to the internal variables252expected by the instructions260.

The internal variables252may be considered server variables in the case of the server-side computer program84and may be considered client variables in case of the client-side computer program82. Server-side and client-side variables need not be the same and need not correspond to any degree. Rather, the server-side and client-side internal variables252are used by the respective instructions260of the respective program84,82to implement the desired functionality.

The variable mapping logic262is similar in each of the programs82,84, in that the variable mapping logic262traverses the set of external variables254according to a predefined logic that is consistent between the programs82,84. In a simple example, the programs82,84may both have internal variables X and Y, which are to be communicated. The variable mapping logic262can therefore dictate that external variables A and B are to communicate the values of internal variables X and Y. The variable mapping logic262can further be configured to assign X to A and assign Y to B for odd numbered communications and assign Y to A and X to B for even numbered communications. The variable mapping logic262can further assign an arbitrary value (e.g., a random or dummy value) to an external variable C for every communication. As such, an eavesdropper will not be able to readily tell what are the true values of X and Y unless it also knows whether the particular communication is odd or even. Further, the eavesdropper will not know how to handle variable C and may ascribe importance to it when none is warranted.

The variable mapping logic262may follow a deterministic pseudo-random pattern that is initialized by a seed. The seed may be shared between the programs82,84during a secure exchange, such as a physically local communication or an out-of-band communication. An example deterministic pseudo-random pattern uses a communication session identifier to identify a subset264of external variables254as well as the mapping to the internal variables252.

External variables254that at different times map to the same internal variable252may differ in name. As such, an attacker may identify two or more apparently different variables that the program82,84actually considers to be the same.

FIG.15shows a method270that implements this technique. The method270may be performed at a computer program82,84. The method270may be implemented by instructions stored at a non-transitory computer-readable medium and operable by a processor. Blocks272,274are performed by the device performing the outgoing communication, whether that device is a client computer or a server. Blocks276-280are performed by the device performing the incoming communication, whether that device is a client computer or a server.

At block272, an internal variable is mapped to an external variable according to a predefined logic282.

At block274, the external variable is communicated to the other device, via a computer network.

Blocks272,274may be repeated indefinitely as a sequence of communications is made for first, second, and additional external variables. The same internal variable may be mapped and re-mapped to different external variables any number of times.

At block276, the external variable is received by the device.

At block278, the received external variable is mapped to an internal variable according to predefined logic282, which may be the same as or correspond to the predefined logic that selected the external variable for transmission.

At block280, the internal variable is used to perform an operation to carry out the desired functionality.

Blocks277-280may be repeated indefinitely as a sequence of communications is received. The same internal variable may be mapped and re-mapped to different external variables any number of times.

The method270is described with respect to unidirectional communications. However, the same or similar method270may be used for the opposing direction of communication to enable bidirectional communication.

FIG.16shows an example diagram of obfuscating software code by setting up a labyrinth of potential paths for the calculation of variables, where depending the use case, system flags, and the value of variables, either a correct value or an incorrect value may be returned, allowing for server14to determine whether or not the software code has been tampered with, or if attacker20is present.

The following is an example of the operation of obfuscating software code. Each block inFIG.16represents a function. Functions take in variables, change the variables according to the code in the function, and then provide an output of the variables with new values. Functions may also be limited in which other functions they pass variables to. InFIG.16, the lines represent the possible paths in which functions can pass variables to other functions. The dotted lines represent the correct path that variables are passed, in which to get an expected result. Server14has an algorithm that can calculate the expected result based on a number of input variables.

When variables are available, they are run through the functions within the software code starting at block450. As they progress through each function, depending on the environmental conditions surrounding the software, such as system flags, or particular use cases, the variables will be passed from one function to another until it reaches the end and no more calculations are possible. The results are then passed back to server14for verification.

If the results do not match the values calculated by server14, then it is possible that attacker20is the computer that is running the software code, and has just returned incorrect values, as it is not running the same environmental conditions, system flags or use cases as computer devices18.

If the variables are calculated correctly, and follow the dotted lines from block450to block455, then the results would match server14, and computer devices18are running software code that has not been tampered with, and there is no attacker20in the system.

Other embodiments of this form of obfuscation are available, and may not mimic the structure of the example structure inFIG.16.

Various techniques discussed herein are particularly suitable for use with programs written in languages, such as JavaScript, that tend to have source code that may be readily obtained by an attacker.

Any of the techniques discussed herein may be used alone or in any suitable combination.

It should be recognized that features and aspects of the various examples provided above can be combined into further examples that also fall within the scope of the present disclosure. In addition, the figures are not to scale and may have size and shape exaggerated for illustrative purposes.