Applying bytecode obfuscation techniques to programs written in an interpreted language

In an embodiment, a computer system configured to improve security of client computer interacting with server computers comprises one or more processors; a digital electronic memory storing a set of program instructions which when executed using the one or more processors cause the one or more processors to: process a first set of original instructions that produce a first set of outputs or effects; generate a first set of interpreter instructions that define a first interpreter; generate a first set of alternate instructions from the first set of original instructions, wherein the first set of alternate instructions is functionally equivalent to the first set of original instructions when the first set of alternate instructions is executed by the first interpreter; send, to the first client computer, the first set of alternate instructions and the first set of interpreter instructions.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to security techniques applicable to client/server systems, and relates more specifically to techniques for improving the security of client computers interacting with server computers through an intermediary computer using bytecode conversion techniques. SUGGESTED GROUP ART UNIT:2441; SUGGESTED

BACKGROUND

Browsers are powerful computer program applications that may request and execute instructions received from a web server to generate complex user interfaces that are presented to a user through one or more devices, such as a monitor or speakers. In response to input from a user, such as a mouse click indicating that the user selected an object defined in the instructions, such as a link, a browser may send a request based on the selected object to the web server. The request may be a request for data and/or include data to be processed by the web server.

Attackers may use software, often referred to as a “bot,” which imitates a browser by receiving instructions from a web server and generating requests based on those instructions. For example, a bot may receive a web page, gather data in one or more objects defined in the web page, and generate a request for another web page to gather additional data, as if a user using a browser was requesting a new web page. Also for example, a bot may generate and send a request with data assigned to one or more parameters to simulate a user submitting data to a web server through a browser.

Attackers may use bots to commit many types of unauthorized acts, crimes, or computer fraud, such as content scraping, ratings manipulation, fake account creation, reserving rival goods attacks, ballot stuffing attacks, password snooping, web site scraping attacks, vulnerability assessments, and stack fingerprinting attacks. As a specific example, a malicious user may cause a bot to traverse through pages of a web site and collect private and/or proprietary data, such as who is connected with whom on a particular social network site.

Web server administrators may wish to prevent malicious users from attacking the site, while allowing legitimate users to use the site as intended. However, determining which requests are generated by a legitimate user using a web browser and a malicious user using a bot may be difficult.

SUMMARY

While each of the drawing figures illustrates a particular embodiment for purposes of illustrating a clear example, other embodiments may omit, add to, reorder, and/or modify any of the elements shown in the drawing figures. For purposes of illustrating clear examples, one or more figures may be described with reference to one or more other figures, but using the particular arrangement illustrated in the one or more other figures is not required in other embodiments. Furthermore, while the instructions discussed in many example embodiments are HyperText Markup Language (“HTML”) and JavaScript instructions, in other embodiments, the instructions intercepted and generated may be any other standard and/or proprietary instructions configured to be executed by a client computer.

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention. Furthermore, words, such as “or” may be inclusive or exclusive unless expressly stated otherwise. A set of items may comprise one or more items.

1.0 General Overview

5.0 Process Overview5.1 Receiving Instructions from a Server Computer5.2 Determining Alternate Instructions5.2.1 Additional Example5.2.2 Generating Alternate Sets of Functionally Equivalent Code and Corresponding Interpreters5.3 Generating and Sending Alternate Instructions

6.0 Hardware Overview

7.0 Other Aspects of Disclosure

1.0 General Overview

In an embodiment, a computer system configured to improve security of client computers interacting with server computers, the computer system comprising: one or more processors; a digital electronic memory storing a set of program instructions which when executed using the one or more processors cause the one or more processors to: process a first set of original instructions that produce a first set of outputs or effects when executed by a first client computer; generate a first set of interpreter instructions that define a first interpreter; generate a first set of alternate instructions from the first set of original instructions, wherein the first set of alternate instructions is functionally equivalent to the first set of original instructions when the first set of alternate instructions is executed by the first interpreter; send, to the first client computer, the first set of alternate instructions and the first set of interpreter instructions, wherein the first set of interpreter instructions and the first set of alternate instructions, when executed by the first client computer, cause the first client computer to produce the first set of outputs or effects.

In an embodiment, a computer system configured to improve security of client computer interacting with server computers comprises one or more processors; a digital electronic memory storing program instructions which when executed using the one or more processors cause the one or more processors to: receive, from a server computer, a first set of instructions that define one or more objects and one or more operations, which when executed by a client computer operate on the one or more objects; determine that the first set of instructions comprises one or more particular instructions that are functionally equivalent to one or more first alternate instructions when executed by an interpreter; generate a second set of instructions that includes a set of interpreter instructions that define the interpreter, the one or more first alternate instructions, and the first set of instructions without the one or more particular instructions; send the second set of instructions to a remote client computer.

In an embodiment, the interpreter is a bytecode interpreter.

In an embodiment, the one or more first alternate instructions are bytecode instructions.

In an embodiment, wherein as part of sending the second set of instructions to the remote client computer, executing the program instructions causes the one or more processors to obfuscate the bytecode instructions.

In an embodiment, wherein executing the program instructions causes the one or more processors to: generate, in memory, one or more data structures that are associated with the one or more objects and one or more operations; and determine, based on the one or more data structures, that the first set of instructions comprises one or more particular instructions that are functionally equivalent to one or more first alternate instructions when the one or more first alternate instructions are executed by an interpreter.

In an embodiment, wherein the one or more data structures describe at least one of: the syntax of the one or more objects and the one or more operations, or the semantics of the one or more objects and the one or more operations.

In an embodiment, wherein the one or more particular instructions are functionally equivalent to a plurality of alternative instruction sets, and wherein executing the program instructions causes the one or more processors to select the one or more first alternate instructions from the plurality of alternative instruction sets, prior to generating the second set of instructions.

A web browser may be a tool through which server-based application programs can provide client computers with content in a dynamic, custom UI. For example, in response to receiving a request for data from a web browser, a web server may respond with a set of instructions that define one or more objects with one or more object identifiers. The instructions may use the object identifiers to define how objects may be presented in a UI to enable human/computer interaction. For convenience of expression, a set of instructions may be referred to herein as a file and/or web page. A set of instructions, file, and/or web page need not have a particular type or extension, and need not be stored in persistent storage. For example, a web page may be generated dynamically based on one or more parameters. While some files may be identified as a particular type of file, such as an “HTML file” or “JavaScript file,” a file may include mixed content. For example, an HTML file may include HTML, JavaScript, Cascading Style Sheets (“CSS”), and/or any other standard and/or proprietary set of instructions. Furthermore, a file need not be a file stored in persistent storage.

In contrast, bots traverse web pages and/or web sites to retrieve data from, and/or submit data to, one or more web servers with little, if any, human/computer interaction. For example, in response to receiving a request for data from a bot, a web server may respond with a set of instructions. A bot may parse the instructions to collect data from, and/or to store data in, particular objects with particular object identifiers. A bot may also make requests based on an object identifier, such as the identifier for a text field input. However, unlike a browser, a bot need not execute the instructions that define how objects should be presented in a UI because the bot is built to operate with little, if any, human/computer interaction. Thus, a bot may be a functionally-limited browser. For example, a browser may include a JavaScript runtime environment, which executes JavaScript instructions that define how one or more objects are presented to a user. However, a bot need not include a JavaScript runtime environment because a bot need not present objects to a user.

An attacker may use object identifiers in various attacks, such as a man-in-the-browser attack. In a man-in-the-browser attack, malicious code may be injected in a web browser, which when executed may gather data that is entered by a user into particular fields with particular identifiers before the data is encrypted and sent to the intended recipient. For example, a user may enter account information into a web browser that is displaying a web page from the user's bank. The web page may be a login page to access the user's account information and funds. The malicious code may scan particular fields with particular identifiers in the web page to collect the user's account information before the user's account information is encrypted and sent to the user's bank. The malicious code may send the collected data from those fields to the attacker's computer.

Bytecode is a set of one or more instructions that are designed for efficient execution by a software interpreter rather than machine code that is designed to be executed by hardware alone or human-readable code that is designed for programmers to be able to readily read or modify. Unlike human-readable source code, such as HTML or JavaScript, bytecode may comprise compact numeric codes, constants, and references that may encode the result of parsing, compiling, or transpiling one or more sets of human-readable source code. Although human-readable source code may be represented by at least one series of bytecode, not all bytecode directly represents human-readable source code. Thus, it is difficult to de-compile bytecode in order to produce human-readable source code.

Bytecode conversion may be used to prevent and/or deter attacks. For example, human-readable JavaScript in a web page may define an original method, which when executed, submits a request to a server computer with data that includes a security token that the server computer may use to validate the request. An attacker may review the human-readable JavaScript, determine what the security token is, or how the original method generates the security code. The attacker may use the function to send one or more requests with purposefully incorrect or false data and a valid security token to the server computer. Additionally or alternatively, the attacker may create a new function that generates a valid security token according to the algorithm defined in the original method and sends a request with purposefully incorrect or false data and the valid security token to the server computer. Converting human-readable code or instructions into non-human readable bytecode, before the human-readable code is sent to a client computer, may prevent attackers from exploiting or simulating the functionality defined by human-readable code, and thus, prevent attackers from performing one or more various attacks, such as a denial of service (“DOS”) attack, credential stuffing, fake account creation, ratings or results manipulation, man-in-the-browser attacks, reserving rival goods or services, scanning for vulnerabilities, and/or exploitation of vulnerabilities.

FIG. 1illustrates a modified HTML file, JavaScript interpreter file, and bytecode file generated from an original HTML document and an original JavaScript document according to an example embodiment. InFIG. 1, original HTML file110and original JavaScript file120are files comprising instructions that may be stored on, and/or generated by, a web server computer in response to a request from a browser executing on a client computer. A computer, such as the web server computer and/or an intermediary computer, with bytecode conversion logic may receive original HTML file110and original JavaScript file120, and generate modified HTML file130and bytecode file150. The computer may also generate bytecode interpreter140, which when executed by a browser with a JavaScript runtime environment on a client computer, can configure the runtime environment to interpret or execute bytecode file150. In an embodiment, bytecode interpreter140may be a set of JavaScript instructions. The bytecode conversion logic may send modified HTML file130, bytecode interpreter140, and bytecode file150to the browser on the client computer that originally requested original HTML file110. Logic may be hardware and/or software modules executed in concert with, and/or by, one or more computers, such as a web server computer, or a computer coupled to a web server computer.

InFIG. 1, original HTML file110comprises JavaScript source reference115. JavaScript source reference115may reference one or more files comprising additional instructions, such as original JavaScript file120. Original JavaScript file120may include one or more methods, such as JavaScript methods125and126, which comprise one or more instructions.

To hinder or prevent attackers from identifying the instructions defined in JavaScript methods125and126, the bytecode conversion logic may convert the instructions in method125and method126to bytecode. Modified HTML file130is an example HTML file that the bytecode conversion logic may generate in response to receiving original HTML file110. Modified HTML file130comprises interpreter reference135and bytecode instruction reference137. Bytecode instruction reference137may reference one or more files comprising one or more generated instructions, such as bytecode file150. Bytecode file150is an example bytecode file that the bytecode conversion logic may generate in response to receiving original JavaScript file120. Interpreter reference135may reference one or more files comprising interpreter instructions, such as bytecode interpreter140. Bytecode interpreter140may include one or more sets of bytecode interpreter instructions145, which may be used to interpret bytecode instructions155. Additionally or alternatively, modified HTML file130may include instructions defining bytecode interpreter140and bytecode instructions155.

4.0 Network Topology

FIG. 2illustrates a computer system comprising a browser, a web infrastructure, and an intermediary computer, which may be configured to generate a web page, convert one or more human-readable instructions in the web page into bytecode, and execute the bytecode instructions on a client computer, in an example embodiment. InFIG. 2, system200comprises web infrastructure205, client computer299, intermediary computer230, storage240, and configuration235distributed across one or more interconnected computer networks.

While each of the components listed above is illustrated as if running on a separate, remote computer from each other, one or more of the components listed above may be part of and/or executed on the same computer. For example, intermediary computer230, configuration235, storage240, and/or web infrastructure205may be executed on the same computer, local area, and/or wide area network. Additionally or alternatively, intermediary computer230may be a proxy server and/or layer for web infrastructure205. Additionally or alternatively, intermediary computer230may be in line between a router and web infrastructure205, such that intermediary computer230may intercept all network data sent to, and/or sent from, web infrastructure205over one or more protocols. Additionally or alternatively, intermediary computer230, and/or one or more modules and/or logic comprising intermediary computer230discussed herein, may be a software layer between, and/or executed on, web infrastructure205and/or a component of web infrastructure205. Additionally or alternatively, intermediary computer230, and/or one or more modules and/or logic comprising intermediary computer230discussed herein, may be part of a server-side application that responds to requests over one or more standard and/or proprietary protocols, such as Hypertext Transfer Protocol (“HTTP”) and/or any other protocol.

A “computer” may be one or more physical computers, virtual computers, and/or computing devices. As an example, a computer may be one or more server computers, cloud-based computers, cloud-based cluster of computers, virtual machine instances or virtual machine computing elements such as virtual processors, storage and memory, data centers, storage devices, desktop computers, laptop computers, mobile devices, and/or any other special-purpose computing devices. Any reference to “a computer” herein may mean one or more computers, unless expressly stated otherwise.

4.1 Web Infrastructure

Web infrastructure205may comprise one or more server computers that receive requests for data from users through one or more client computers, such as client computer299and/or intermediary computer230. Web infrastructure205may respond by sending data to the browser that sent the request. As illustrated inFIG. 2, the data sent from web infrastructure205may include one or more types of instructions, such as HTML, JavaScript, CSS, and/or any other standard or proprietary instructions. The one or more computers in web infrastructure205may, but need not, be owned and/or managed by one or more independent entities and may span across one or more computer networks, such as the Internet.

A server computer may be a computer that receives requests for data and responds with data. For example, a web server computer may be an HTTP-based computer that receives HTTP requests and responds with data comprising HTML and/or JavaScript instructions. Additionally or alternatively, a server computer may respond with data that references data on other server computer in, and/or outside of, web infrastructure205.

4.2 Intermediary Computer

Intermediary computer230may be an intermediary that may intercept instructions sent from web infrastructure205, parse and/or execute one or more of the intercepted instructions, modify the intercepted instructions, generate and/or add new instructions, and send the modified and/or new instructions to a client computer. For example, intermediary computer230may receive original HTML file110and original JavaScript file120, generate modified HTML file130and bytecode file150, and send modified HTML file130, bytecode interpreter140, and bytecode file150to browser295.

Intermediary computer230may be an HTTP or SPDY intermediary that intercepts, parses, executes, and/or processes HTML, JavaScript, and CSS instructions. Additionally or alternatively, intermediary computer230may intercept requests for data and/or instructions from a client application, generate a new HTTP request, and send the newly generated HTTP request to one or more HTTP and/or SPDY-based web servers. Additionally or alternatively, intermediary computer230may be an intermediary for any other standard and/or proprietary protocol. Furthermore, each of the components discussed herein, which intermediary computer230is comprised of, may be configured to perform any of the processes and/or methods discussed herein for any standard and/or proprietary protocol.

Intermediary computer230may be a server computer that one or more domain name servers or other elements of the domain name system (“DNS”) identify in DNS records as a destination network address associated with one or more internet domain names. Accordingly, intermediary computer230may receive requests sent to the one or more domains from a browser or bot. Based on using DNS to resolve the domain name in a request to a network address, intermediary computer230may forward the request, or a modified request, to a server computer in web infrastructure205.

InFIG. 2, intermediary computer230is programmed to send instructions to, and receive requests from, a particular type of client application: browser295. However, in an embodiment, intermediary computer230may be programmed to send instructions to, receive requests from, and/or open sockets with, browsers and/or bots.

FIG. 3illustrates a detailed view of an intermediary computer in an example embodiment. InFIG. 3, intermediary computer230comprises protocol client logic332, processing logic334, bytecode conversion logic336, and protocol server logic338. In an embodiment, each of the logical and/or functional unites of intermediary computer230may be implemented using any of the techniques further described herein in connection withFIG. 4. For example, the intermediary computer230may comprise a general-purpose computer configured with one or more stored programs which when executed cause performing the functions described herein for the intermediary computer, or a special-purpose computer with digital logic that is configured to execute the functions, or digital logic that is used in other computing devices. While the figures include lines that indicate various devices and/or modules being communicatively couple, each of the computers, devices, modules, storage, and configurations may be communicatively coupled with each other.

4.2.1 Protocol Client Logic

Protocol client logic332may intercept or receive data over any standard or proprietary protocol. For example, protocol client logic332may intercept or receive data over HTTP. Protocol client logic332may send one or more requests to a server computer, such as a computer is web infrastructure205.

4.2.2 Processing Logic

Processing logic334may process instructions intercepted or received by protocol client logic332, which causes processing logic334to generate one or more in-memory data structures that correspond to one or more objects. Processing one or more instructions may comprise parsing and/or executing the one or more instructions. After processing the instructions, processing logic334may notify bytecode conversion logic336to begin rendering instructions based on the one or more data structures.

Processing logic334may make requests for additional data. For example, if instructions received from protocol client logic332reference one or more instruction files, then processing logic434may request the one or more instruction files through protocol client logic432.

4.2.3 Bytecode Conversion Logic

Bytecode conversion logic336may generate a set of one or more bytecode instructions to replace one or more original instructions in original JavaScript file120. Bytecode conversion logic336may generate the one or more bytecode instructions based on the one or more data structures in memory.

Bytecode conversion logic336may render an alternate set of instructions based on the generated set of one or more bytecode instructions, such as modified HTML file130. Additionally or alternatively, bytecode conversion logic336may generate one or more instructions defining an interpreter to execute the generated bytecode instructions, such as bytecode interpreter140. Bytecode conversion logic336may send the alternate instructions to one or more client computers through protocol server logic338.

4.2.4 Protocol Server Logic

Protocol server logic338may receive the instructions generated by bytecode conversion logic336and send the generated instructions to client computer299. Protocol server logic338may receive requests from one or more client computers, such as client computer299.

Configuration242may be a database, a configuration file, and/or any other system that stores configurations: settings, preferences, and/or protocols. Configuration242may store more than one configuration for one or more web servers in web infrastructure205. For example, configuration235may include data that defines one or more bytecode grammar that indicate one or more rules for converting instructions to alternate instructions, for example converting from JavaScript instructions to bytecode. Additionally or alternatively, configuration235may include data that indicates whether particular web pages should be processed by processing logic334and/or modified by bytecode conversion logic336.

Configuration235may be modified by a user and/or administrator through one or more computers, such as intermediary computer230, a computer in web infrastructure205, and/or another computer not illustrated in system200.

Storage240may be a database, a configuration file, and/or any other system and/or data structure that stores data. InFIG. 2, storage240is illustrated as if a separate computer from intermediary computer230. Additionally or alternatively, storage240may be a data structure stored in memory on the one or more computers comprising intermediary computer230. Additionally or alternatively, storage240may, at least in part, be a data structure stored in shared memory between one or more intermediary computers. Additionally or alternatively, intermediary computer230may, at least in part, be stored in volatile and/or non-volatile memory.

Browser295may be a browser as described herein and executed on a client computer, such as client computer299. Additionally or alternatively, browser295may be a bot comprising one or more of the components traditionally found in a browser.

5.0 Process Overview

In an embodiment, a data processing method may be configured to intercept or receive instructions from a server computer that are directed toward a browser, generate one or more alternate instructions that are executable by an interpreter, and render a second set of instructions comprising the alternate instructions and the interpreter. In an embodiment, if the request is valid, then the processing method may be configured to modify the request, send the modified request to a server computer, receive data from the server computer in response to the modified request, and/or send a response to a client computer. Various embodiments may use standard web protocols, such as HTTP, and/or standard web-based instructions, such as HTML and/or JavaScript. Additionally or alternatively, other standard and/or proprietary protocols may be used. Additionally or alternatively, other standard and/or proprietary instructions may be used.

5.1 Receiving Instructions from a Server Computer

FIG. 4illustrates a process for intercepting or receiving instructions from a server computer, generating new instructions, and sending the new instructions to the intended client, in an example embodiment. In step410, an intermediary computer receives a first set of instructions from a remote server computer. For example, protocol client logic332may receive instructions from web infrastructure205in response to a request from visitor browser295. The instructions may define one or more objects and one or more operations which operate on the objects. The instructions may comprise HTML, CSS, and/or JavaScript. As an example, protocol client logic332may receive original JavaScript file120and original HTML file110, and send original JavaScript file120to processing logic334.

5.2 Determining Alternate Instructions

In step420, the intermediary computer determines that one or more particular instructions are functionally equivalent to one or more first alternate instructions. An alternate set of instructions may be functionally equivalent to an original set of instructions if when executed, given a particular set of one or more inputs, the alternate instructions produce the same output(s) or effect(s) as the original instructions when executed given the same particular set of one or more inputs. The alternate instructions may be executed in the same execution environment as the original instructions. Additionally or alternatively, one or more of the instructions in the alternate instructions may be executed by an interpreter that is not used to execute the one or more original instructions. The alternate instructions may comprise bytecode.

Processing logic334may parse the received instructions prior to sending them to bytecode conversion logic336. Additionally or alternatively, processing logic334may generate one or more data structures representing the instructions in original JavaScript file120, and then send the one or more data structures to bytecode conversion logic336.

In an embodiment, processing logic334may parse the received instructions to generate a syntax tree for the received instructions. Additionally or alternatively, processing logic334may analyze the semantics of the received instructions and generate a data structure representing the semantics of the instructions. For example, processing logic may parse the received instructions and generate a semantic graph. Additionally or alternatively, processing logic334may perform type checking or scope checking on the received instructions.

For purposes of illustrating a clear example, assume that Snippet 1 is a method contained in original JavaScript file120.

Processing logic334may parse Snippet 1 to generate a syntax tree and/or a semantic graph. Processing logic334passes the one or more generated data structures to bytecode conversion logic336.

Bytecode conversion logic336may generate one or more alternate instructions based on the one or more generated data structures. The alternate instructions may comprise bytecode instructions, which when executed by an interpreter, are functionally equivalent to the received instructions. Additionally or alternatively, each line of the alternate instructions may be mapped to one or more characters, numbers, or symbols that form bytecode instructions which may be understood by a bytecode interpreter.

In the present example, bytecode conversion logic336receives data structures describing the syntax and the semantics of the function “func1” in Snippet 1. Bytecode conversion logic336may map the semantics to a set of one or more semantically equivalent instructions.

Based on the instructions described in Snippet 1, bytecode conversion logic336generates the alternate instructions illustrated in Snippet 2 below, which are functionally equivalent to the instructions in Snippet 1. When executed by an interpreter, the alternate instructions in Snippet 2 perform the same steps as those illustrated by Snippet 1.

The bytecode instructions may correspond to a particular set of characters. For example, the addition operator may correspond to the string “aa.” When the interpreter reads the string “aa,” it performs the addition operation. Additionally or alternatively, the particular interpreter reads additional bytes to use as arguments for the instructions. Additionally or alternatively, the particular interpreter receives additional parameters to use as arguments for the instructions.

Snippet 2 is a function that comprises alternate instructions which replace the addition operation in Snippet 1 with a call to an “interpreter” function. The “interpreter” function may be a bytecode interpreter associated with Snippet 2. The parameters for the “interpreter” function include the parameters for the addition operation in Snippet 1 and bytecode that corresponds to the addition operation.

In the present example, the alternate instructions in Snippet 2 correspond to the addition operation in function “func1.” In other embodiments, the alternate instructions may include instructions that define other portions of function “func1” including the entirety of function “func1.” Additionally or alternatively, the alternate instructions may include instructions that define one or more objects, data, structured data, parameters, classes, namespaces, functions, and etc. A call to a function defined in the alternate instructions may cause an interpreter to execute the alternate instructions. Additionally or alternatively, the alternate instructions may include a data structure that comprises bytecode instructions, as well as other information that the interpreter may use for executing the bytecode instructions. One or more bytecode instructions may be packed into a byte array, which can be encoded into a string. An interpreter may decode the string, unpack the byte array, and read the bytes in the byte array. For example, Snippet 3 illustrates bytecode which, when executed by an interpreter, defines a function “func1” from Snippet 1.

An interpreter may decode the string “aXbbpQwcd0aa,” unpack the byte array, and/or read the bytes in the byte array to execute the instruction(s) associated with each byte to define “func1” in Snippet 3 as if the execution environment, which is executing the interpreter, had executed the code in Snippet 1 defining function “func1.”

Additionally or alternatively, if execution of the original instructions would have returned a value or stored a value in a parameter, then execution of the alternate instructions using an interpreter also returns the same value or stores the value in the same parameter. In an embodiment, the interpreter receives a reference to one or more parameters that were passed as parameters to the original instructions. The interpreter may use the reference to retrieve the parameter value for the original instructions, or to store results in the passed parameter.

5.2.1 Additional Example

Representing a program as bytecodes makes it easier to obscure the behavior of the program. Human-readable source code may be represented by at least one series of bytecodes, but one or more series of bytecodes need not directly represent some human-readable source code. Accordingly, the process of “decompiling” a series of bytecodes, to produce equivalent human-readable source, can be extremely difficult, especially if the original compiler is designed to make decompilation difficult. For example, assume Snippet 4 is a method contained in original JavaScript file120.

Processing logic334may parse Snippet 4 to generate a syntax tree and/or a semantic graph. Processing logic334passes the one or more generated data structures to bytecode conversion logic336.

Bytecode conversion logic336may generate one or more alternate instructions based on the one or more generated data structures. For example, bytecode conversion logic336may generate following code in Snippet 5.

In Snippet 5, the lines are numbered differently from other snippets so that an instruction that references another instruction at a target location refers to the line number of the target instruction. For example, line 23 in Snippet 5 has a GOTO instruction that references line 2 in Snippet 5, “TARGET”.

Each line in Snippet 5 may be mapped to one or more characters, numbers, or symbols that form bytecode instructions which may be understood by a bytecode interpreter. A particular interpreter may expect each instruction in Snippet 5 to correspond to a particular number. For example, “PUSH_IMMEDIATE_INT” may correspond to the number14. When the particular interpreter reads the number14, it executes the “PUSH_IMMEDIATE_INT” instruction. Thus, when executed by an interpreter, the alternate instructions in Snippet 6 perform the same steps as those illustrated by Snippet 5.

Snippet 6 is a data structure that comprises bytecode instructions, as well as other information that the interpreter may use for executing the bytecode instructions. For example, the data structure in Snippet 6 comprises substructures “functions,” “objects,” and “scriptVarDecls.” “Objects” and “scriptVarDecls” are arrays that indicate the global variables and strings used when executing the bytecode instructions, as seen above in Snippet 5. In other embodiments, the alternate instructions generated by bytecode conversion logic may be stored in different formats or may not require use of a data structure.

The data structure in Snippet 6 comprises two “code” fields, each of which includes a set of bytecodes encoded as a base64 string. A corresponding interpreter can execute the first set of bytecodes on line 2, which causes the interpreter to define the global object “fold1,” as illustrated in the first section of Snippet 5. The interpreter can execute the second set of bytecodes on line 4, which causes the interpreter to define the behavior of the global object “fold1,” as illustrated in the second section of Snippet 5. Code, a runtime environment, or an interpreter may reference or call the global object or function “fold1” as if “fold1” had been defined using the code in Snippet 4.

In Snippet 6, the “functions” field is an array of one or more functions. For purposes of illustrating a clear example, the “functions” field defines a single function. Each function in the array comprises “code,” “parameters,” and “locals.” The “code” field on line 4 is an array of bytecodes stored as a base64-encoded string.

The “parameters” field on line 5 is an array of parameters. Each element in the array may be the name of the parameter. For example, the first element of the parameters array, 2, corresponds to the first parameter, “f”, on line 1 of Snippet 4. Therefore, “DEREF_LOCAL 2”, on line 11 of Snippet 5, retrieves the first parameter on line 1 of Snippet 4.

The “locals” field on line 6 is an array that indicates the local variables used in the function. In Snippet 6, the “locals” field includes variables zero through four because variables zero through four are referenced in the instructions in Snippet 5.

The “objects” field may include zero or more objects that may be used by the bytecode. For example, “length”, from line 5 of Snippet 5, is stored in the “objects” field. The bytecode on line 4 can include a reference or index to “length” in the “objects” field, instead of including “length” as a string in the bytecode.

The “scriptVarDecls” field identifies one or more variables that should be declared before the interpreter executes the bytecode. The one or more variables need not be defined, instantiated, or assigned one or more values or objects.

Execution of the alternate instructions using a corresponding interpreter may return the same value(s) or store the value(s) in the same parameter(s) as the original instructions if the original instructions were executed. The interpreter may use objects, variables, or references to retrieve data from, or store data to, one or more objects or variables.

5.2.2 Generating Alternate Sets of Functionally Equivalent Code and Corresponding Interpreters

Additionally or alternatively, bytecode conversion logic336may generate a first set of bytecode instructions for a first interpreter to be used for executing the first set of bytecode instructions. As an example, in Snippet 2, the addition operation is represented in the bytecode instructions (“aa”) for a first interpreter. Other instructions may be represented by other sets of characters for the first interpreter. The characters are interpreted by the first interpreter to perform the instruction(s) indicated in Snippet 1. For a second interpreter, the addition operation may be associated with a different set of numbers, letters, and/or characters. Thus, for a second interpreter, bytecode conversion logic336may generate a second set of bytecode instructions different from the first set of bytecode instructions. Both the second set of bytecode instructions when executed by the second interpreter, and the first set of bytecode instructions when executed by the first interpreter, in a particular execution environment, are functionally equivalent to the original JavaScript instructions executed in the particular execution environment. For a particular set of JavaScript instructions, bytecode conversion logic336may generate a different version of the corresponding bytecode for each interpreter in a plurality of interpreters.

Additionally or alternatively, bytecode conversion logic336may select a bytecode interpreter from a plurality of bytecode interpreters for generating the bytecode instructions. The selection may be done randomly, or based on user configurations, for example, data stored in configuration235. For example, bytecode conversion logic336may determine that a particular set of JavaScript code is functionally equivalent to a first set of bytecode with a first interpreter and a second set of bytecode with a second interpreter. In response, bytecode conversion logic336use a random number generator to select the first set of bytecode or the second set of bytecode by using a random number generator. For purposes of illustrating a clear example, assume the random number generator returns a one, wherein zero is the index of the first alternate set of bytecode. Bytecode conversion logic336uses the random number to index into the plurality of functionally equivalent bytecodes and interpreters, and select the second set of bytecode and interpreter. Bytecode conversion logic336may replace the particular set of JavaScript code in a web page with the selected set of bytecode and the particular computer.

5.3 Generating and Sending Alternate Instructions

In step430, the intermediary computer generates a second set of instructions. The second set of instructions may comprise interpreter instructions that define an interpreter that executes the one or more alternate instructions, the one or more alternate instructions, and the first set of instructions without the particular instructions.

The one or more alternate instructions may comprise bytecode instructions. The interpreter instructions may comprise JavaScript instructions that define a JavaScript interpreter configured to execute the bytecode instructions. The second set of instructions may be generated by replacing one or more portions of JavaScript code from the first set of instructions with one or more bytecode instructions.

The second set of instructions may include a modified HTML file, such as modified HTML file130. The modified HTML file130may include a reference to a file containing the interpreter instructions, such as interpreter reference135, and a reference to a file containing the bytecode instructions, such as bytecode instruction reference137. Additionally or alternatively, modified HTML file may include the bytecode interpreter instructions and the bytecode instructions.

Additionally or alternatively, the intermediary computer may obfuscate the one or more alternate instructions. For the purpose of illustrating a clear example, assume the one or more alternate instructions comprise bytecode. The intermediary computer may obfuscate the bytecode using, for example, opcode shuffling or other bytecode obfuscation techniques.

In step440, the intermediary computer sends the generated, second set of instructions to the client computer. For example, bytecode conversion logic336may send the generated instructions to protocol server logic338. Protocol server logic338sends the generated instructions to visitor browser295, which was the originally intended recipient of the data received in step410.

6.0 Hardware Overview

Computer system500further includes a read only memory (ROM)508or other static storage device coupled to bus502for storing static information and instructions for processor504. A storage device510, such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to bus502for storing information and instructions.

7.0 Other Aspects of Disclosure

Using the networked computer arrangements, intermediary computer, or processing methods described herein, security in client-server data processing may be significantly increased. Polymorphic techniques discussed herein effectively reduce automated attacks. Consequently, one or more various attacks, such as a denial of service (“DOS”) attack, credential stuffing, fake account creation, ratings or results manipulation, man-in-the-browser attacks, reserving rival goods or services, scanning for vulnerabilities, or exploitation of vulnerabilities, are frustrated because object identifiers or polymorphic hooks may change over time.

Aspects of the subject matter described herein are set out in the following numbered clauses:

1. A computer system configured to improve security of client computers interacting with server computers, the computer system comprising: one or more processors; a digital electronic memory storing a set of program instructions which when executed using the one or more processors cause the one or more processors to: process a first set of original instructions that produce a first set of outputs or effects when executed by a first client computer; generate a first set of interpreter instructions that define a first interpreter; generate a first set of alternate instructions from the first set of original instructions, wherein the first set of alternate instructions is functionally equivalent to the first set of original instructions when the first set of alternate instructions is executed by the first interpreter; send, to the first client computer, the first set of alternate instructions and the first set of interpreter instructions, wherein the first set of interpreter instructions and the first set of alternate instructions cause the first client computer to produce the first set of outputs or effects when executed by the first client computer.

2. The computer system of Clause 1, wherein the first interpreter is a bytecode interpreter and the first set of alternate instructions comprises one or more bytecodes.

3. The computer system of any Clause 1-2, wherein: the set of program instructions cause the one or more processors to process the first set of original instructions by generating, in memory, one or more data structures based on the first set of original instructions; and the first set of alternate instructions is generated based on the one or more data structures.

4. The computer system of any Clause 1-3, wherein the one or more data structures include an abstract representation of the first set of original instructions.

5. The computer system of any Clause 1-4, wherein the abstract representation of the first set of original instructions identifies one or more semantics of the first set of original instructions.

6. The computer system of any Clause 1-5, wherein: the set of program instructions causes the one or more processors to generate a second set of interpreter instructions and a second set of alternate instructions; the second set of alternate instructions and the second set of interpreter instructions are functionally equivalent to the first set of alternate instructions and the first set of interpreter instructions; the second set of alternate instructions is different than the first set of alternate instructions; the second set of interpreter instructions is different than the second set of interpreter instructions.

7. The computer system of any Clause 1-6, wherein: the first set of interpreter instructions associates a first bytecode with a particular operation; the second set of interpreter instructions associates a second bytecode with the particular operation; the first bytecode is different than the second bytecode; the first set of alternate instructions include the first bytecode and the second set of alternate instructions includes the second bytecode.

8. The computer system of any Clause 1-7, wherein executing the set of program instructions causes the one or more processors to receive the first set of original instructions from a server computer over one or more computer networks.

9. The computer system of any Clause 1-8, wherein the set of program instructions cause the one or more processors to: process a second set of original instructions that produce a second set of outputs or effects when executed by a second client computer, wherein the second set of original instructions are different than the first set of original instructions; generate a second set of interpreter instructions that define a second interpreter; generate a second set of alternate instructions from the second set of original instructions, wherein the second set of alternate instructions is functionally equivalent to the second set of original instructions when the second set of alternate instructions is executed by the second interpreter; send, to the second client computer, the first set of alternate instructions and the first set of interpreter instructions, wherein the first set of interpreter instructions and the first set of alternate instructions, when executed by the second client computer, cause the second client computer to produce the second set of outputs or effects.

10. The computer system of any Clause 1-9, wherein the first interpreter and the second interpreter are different interpreters with different instruction sets.

11. The computer system of any Clause 1-10, wherein the set of program instructions cause the one or more processors to: process a first set of JavaScript code that produce a set of outputs or effects when executed by a JavaScript runtime environment on a first client computer; generate a second set of JavaScript code that defines a bytecode interpreter; generate a set of bytecode from the first set of JavaScript code, wherein the set of bytecode is functionally equivalent to the first set of JavaScript code when the set of bytecode is executed by the bytecode interpreter; send, to the first client computer, the set of bytecode and the second set of JavaScript code that defines the bytecode interpreter, wherein the set of bytecode and the second set of JavaScript code that defines the bytecode interpreter cause the first client computer to produce the set of outputs or effects when executed by the first client computer.

12. The computer system of any Clause 1-11, wherein the set of program instructions cause the one or more processors to: one or more processors; a digital electronic memory storing a set of program instructions which when executed using the one or more processors cause the one or more processors to: receive, from a server computer, a first set of instructions that define one or more objects and one or more operations, which when executed by a client computer operate on the one or more objects; determine that the first set of instructions comprises one or more particular instructions that are functionally equivalent to one or more first alternate instructions when the one or more first alternate instructions are executed by an interpreter; generate a second set of instructions that includes a set of interpreter instructions that define the interpreter, the one or more first alternate instructions, and the first set of instructions without the one or more particular instructions; send the second set of instructions to a remote client computer.

13. The computer system of any Clause 1-12, wherein the interpreter is a bytecode interpreter.

14. The computer system of any Clause 1-13, wherein the one or more first alternate instructions comprise a set of bytecode instructions.

15. The computer system of any Clause 1-14, wherein executing the set of program instructions causes the one or more processors to modify the set of bytecode instructions prior to sending the second set of instructions to the remote client computer.

16. The computer system of any Clause 1-15, wherein executing the set of program instructions causes the one or more processors to: generate, in memory, one or more data structures that are associated with the one or more objects and the one or more operations; and determine, based on the one or more data structures, that the one or more particular instructions are functionally equivalent to the one or more first alternate instructions when the one or more first alternate instructions are executed by the interpreter.

17. The computer system of any Clause 1-16, wherein the one or more data structures describe at least one of: a syntax of the one or more objects and the one or more operations, or one or more semantics of the one or more objects and the one or more operations.

18. The computer system of any Clause 1-17, wherein the one or more particular instructions are functionally equivalent to a plurality of alternative instruction sets, and wherein executing the set of program instructions causes the one or more processors to select the one or more first alternate instructions from the plurality of alternative instruction sets prior to generating the second set of instructions.

19. A method comprising one or more steps of any Clause 1-18.

20. A computer system performing one or more steps of any Clause 1-18.