Probe-based JavaScript engine type confusion exploit generation method and device

Abstract

The application provides a probe-based JavaScript engine type confusion exploit generation method and device, which comprises the following steps: obtaining a proof of concept, inputting the JavaScript engine of a networking device after inserting a data probe in the proof of concept, obtaining a log file of the running of the JavaScript engine, and the log file comprising an actual type and an expected type of given data; selecting given data with a different actual type and expected type as type confusion vulnerability data; reading a type confusion knowledge base to find an exploit statement matching the type of the type confusion vulnerability data, inserting the exploit statement into a type misuse point and a read-write freedom point, and converting the proof of concept after inserting the data probe into an exploit primitive; taking the exploit primitive as a basic exploit primitive, combining it with a supplementary exploit primitive in an expert knowledge base, and generating an exploit as a type confusion vulnerability detection result of the networking device.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a probe-based method and apparatus for generating JavaScript engine type obfuscation vulnerability exploits. Background Technology

[0002] Whether on microcomputers or portable mobile devices, web browsers are indispensable software, enabling people to access information from the Internet more conveniently. According to the 47th Statistical Report on Internet Development in China, the number of internet users in my country has reached 989 million. This demonstrates the enormous user base of browser users.

[0003] The JavaScript engine is a crucial component of a browser. Its function is to execute JavaScript scripts, providing users with a dynamic and interactive experience when browsing web pages. Besides browsers, JavaScript engines are widely integrated into other applications, such as PDF readers, Apple and Android apps, and IoT devices.

[0004] Therefore, ensuring the security of JavaScript engines is crucial. Otherwise, the vast majority of connected devices worldwide could be vulnerable to hacking, threatening the privacy and financial security of end users. However, JavaScript engines are precisely where security vulnerabilities are most likely to occur. As of 2019, over 2,300 bugs have been discovered in various JavaScript engines.

[0005] The main reasons why JavaScript engines have numerous security vulnerabilities and are susceptible to attacks include: First, in pursuit of ultimate performance, JavaScript engines are often implemented using non-memory-safe programming languages, such as C or C++. This makes them highly vulnerable to memory corruption vulnerabilities. Second, due to JavaScript's rich language features and the performance competition among major browser vendors, JavaScript engines have become highly complex software projects, increasing the probability of programming errors. Third, vulnerabilities found in JavaScript engines often provide powerful exploit primitives. This allows modern exploit mitigation techniques to be bypassed, enabling compromise of host processes using only a single vulnerability.

[0006] To find and promptly fix security vulnerabilities in software, techniques such as fuzzing and program analysis are commonly used to detect potential defects. These methods can identify a large number of software vulnerabilities. However, the number of software maintenance personnel is often limited. Faced with a large number of vulnerabilities, determining which should be fixed first becomes a challenge. The most intuitive idea is to prioritize fixing the most harmful vulnerabilities. However, determining the severity of a vulnerability often requires manual analysis, which consumes a significant amount of time and effort from software maintenance personnel. Therefore, the academic community has proposed automatic exploit generation technology.

[0007] This automated exploit generation technique uses a proof-of-concept (PoC) to trigger a vulnerability as input and runs the program under test. During this process, it automatically triggers the vulnerability and determines its type, affected objects, and scope. Furthermore, using the determined information and an understanding of the program under test, this technique modifies the PoC to expand its impact, achieving exploits that exceed the program's intended functionality. Software maintainers can then intuitively assess the vulnerability's severity based on the exploit, determining the priority of vulnerability remediation and effectively maintaining software security.

[0008] "Exploitation" refers to a specific input to a program. When the program executes that input (exploitation), it doesn't achieve the intended purpose of the program developer but instead produces other malicious behaviors. For example, the Chrome browser can have a type obfuscation vulnerability in its JavaScript engine. An attacker can trick a victim into visiting a webpage containing malicious code through the browser. The browser will then execute the malicious code. The malicious code exploits this vulnerability to gain control of the computer. It can steal data from the computer; or encrypt data on the computer and extort money from the user. Taking browser exploitation as an example: Browsers are for browsing the internet; "browsing the internet" is the intended purpose of the program developer; when the browser visits a malicious webpage, and that webpage executes, it steals data from the computer. "Stealing data" is a malicious act, and the "malicious webpage" is an example of exploitation.

[0009] Currently, academic research in the field of automated exploit generation primarily focuses on the Linux kernel and general-purpose binaries. Liang Z et al. proposed the K-LEAK framework. This framework treats the generation of information leak exploits in the Linux kernel as a data flow search problem. By modeling unexpected data flows caused by memory errors, K-LEAK can systematically search for data flow paths leading to information leaks in a progressive manner. Chen W et al. designed the KOOBE system to assist in analyzing OOB vulnerabilities in the Linux kernel. This system consists of several building blocks, including a novel capability-guided fuzzing tool for discovering hidden capabilities, and methods for combining capabilities to improve exploit success rates. Zhang B et al. proposed Scatter, which can generate exploitable heap layouts for heap overflows in general-purpose binaries in a primitive-free manner. The central component of Scatter is a fuzzing tool that uses a novel manipulation distance-guided fuzzing method, where the manipulation distance is the distance between the current object and the corrupted object in the heap layout space.

[0010] These achievements have led to some advancements in automated exploit generation techniques for the Linux kernel and general-purpose binary programs. However, no one in academia has yet proposed an automated exploit generation technique for JavaScript engines. JavaScript engines are widely used in various software applications, and security vulnerabilities in them have a massive impact. Although JavaScript engines are also binary programs, their codebase is enormous, and general-purpose binary exploit generation techniques cannot handle such a large volume of code. Furthermore, because JavaScript is a dynamically typed language, variable types are determined during runtime and may change as the code executes, significantly increasing the difficulty of engine development. Therefore, JavaScript engine vulnerabilities primarily focus on type obfuscation. Thus, we urgently need automated exploitation techniques for type obfuscation vulnerabilities in JavaScript engines. Summary of the Invention

[0011] The purpose of this invention is to automatically assess the harmfulness of a proof-of-concept, thereby effectively determining the priority of vulnerability remediation and ultimately maintaining software security. This invention proposes an automated exploitation method for JavaScript engine type obfuscation vulnerabilities based on data probes.

[0012] This invention also proposes a probe-based method for generating JavaScript engine type obfuscation exploits, such as... Figure 15 As shown, it includes:

[0013] In probe detection step S100, a proof of concept for detecting whether a networked device has a type confusion vulnerability is obtained. After inserting a data probe into the proof of concept, it is input into the JavaScript engine of the networked device to obtain the log file of the JavaScript engine running. The log file includes the actual type and expected type of the given data. The given data whose actual type and expected type are different is selected as the type confusion vulnerability data.

[0014] In vulnerability transformation step S200, by reading the type obfuscation knowledge base, an exploit statement matching the data type of the type obfuscation vulnerability is found, and the exploit statement is inserted into a type misuse point and a read / write freedom point. The proof of concept after inserting the data probe is transformed into an exploit primitive. The type misuse point is the program point in the JavaScript engine that uses the type obfuscation vulnerability data. There is a read / write freedom point before and after the type obfuscation point.

[0015] Using the construction step S300, the exploit primitive is used as the basic exploit primitive and combined with the supplementary exploit primitives in the expert knowledge base to generate an exploit, which serves as the type confusion vulnerability detection result for the networked device.

[0016] The aforementioned probe-based JavaScript engine type obfuscation vulnerability exploit generation method,

[0017] The probe detection steps include:

[0018] The data probe marks the data collection points on the proof of concept in the form of function calls; the data probe is used to collect the actual type of a specific variable and the JavaScript engine's expected type for it.

[0019] The proof of concept is converted into an abstract syntax tree (AST), and the scope of each variable in the AST is analyzed to determine the scope range. For each variable, a data probe is inserted after each proof statement within that scope.

[0020] The probe detection steps include:

[0021] This log file is collected using the probe runtime support library;

[0022] After the probe is started, it outputs the context environment obtained by the probe, the location of the probe's PoC, and the specified information that needs to be obtained to the log file. When the probe runtime support library detects type-obfuscated vulnerability data in the log file, it will record it in detail. The recording continues until the proof of concept execution ends.

[0023] The aforementioned probe-based JavaScript engine type obfuscation vulnerability exploit generation method,

[0024] The vulnerability mitigation process includes:

[0025] The creation steps demonstrate the concept of creating an object o of type X.

[0026] The concept of using object o with actual type X before misuse of read-write steps is proven and does not interfere with the occurrence of type confusion.

[0027] The concept demonstrates reading and writing information about object o, but the JavaScript engine incorrectly uses methods of the expected type Y to manipulate object o.

[0028] If the read / write step is misused, the program continues to execute. The PoC reads and writes object o with the actual type X, and will not interfere with the occurrence of type confusion.

[0029] The read / write freedom point includes the read / write freedom point before misuse and the read / write freedom point after misuse; the read / write step before misuse is taken as the read / write freedom point before misuse, the misuse step is taken as the type misuse point, and the read / write step after misuse is taken as the read / write freedom point after misuse.

[0030] The vulnerability mitigation process includes:

[0031] Using the type verification data in the probe, locate the misuse point of the type, and determine the actual type and expected type of the misuse point; organize the data object type and obfuscation type of the read / write free point, and generate a type obfuscation information report including statement location, object type, obfuscation type, and memory read / write operation;

[0032] The construction steps include:

[0033] Based on the type of obfuscation information report, query the type of obfuscation knowledge base, construct the corresponding read / write primitives based on the query results, and fill them into the read / write free point through read / write operations to obtain the exploit primitives; wherein the type of obfuscation knowledge base contains primitives corresponding to each type of obfuscation situation;

[0034] Create an inline data object o, and internally forge an array buffer object fakebuf; fill the buffer address field of fakebuf with the arbitrary address addr to be read or written; use the exploit primitive to obtain a reference to fakebuf to create an array read / write object dataview; use the dataview function to generate an arbitrary address read / write primitive of the read / write address addr as a supplementary exploit primitive.

[0035] Create a function object f; use the supplementary exploit primitive to query the machine code memory address rwxAddr of function f; use the supplementary exploit primitive to modify the machine code corresponding to function f by writing to any address in the write primitive, and then generate a remote code execution exploit as the detection result of this type of obfuscation vulnerability.

[0036] The aforementioned probe-based JavaScript engine type obfuscation vulnerability exploit generation method includes the following exploit construction steps:

[0037] Based on the detection results of this type of obfuscation vulnerability, the severity of the vulnerability is assessed, thereby determining the priority of vulnerability remediation. The vulnerability with the highest priority is selected for remediation, and the networked device runs the remediated JavaScript engine to complete the specified task.

[0038] This invention also proposes a probe-based JavaScript engine type obfuscation exploit generation device, comprising:

[0039] The probe detection module obtains a proof of concept for detecting type confusion vulnerabilities in networked devices. After inserting a data probe into the proof of concept, it inputs it into the JavaScript engine of the networked device to obtain the log file of the JavaScript engine. The log file includes the actual type and expected type of the given data. The given data whose actual type and expected type are different is selected as the type confusion vulnerability data.

[0040] The vulnerability conversion module reads the type obfuscation knowledge base, finds the exploit statement that matches the data type of the type obfuscation vulnerability, inserts the exploit statement into the type misuse point and read / write freedom point, and converts the proof of concept after inserting the data probe into the exploit primitive; where the type misuse point is the program point in the JavaScript engine that uses the type obfuscation vulnerability data, and there is a read / write freedom point before and after the type obfuscation point;

[0041] Using the building module, this exploit primitive is used as the basic exploit primitive. It is then combined with supplementary exploit primitives in the expert knowledge base to generate an exploit, which serves as the type confusion vulnerability detection result for the networked device.

[0042] The aforementioned probe-based JavaScript engine type obfuscation vulnerability exploit generation device,

[0043] The probe detection module includes:

[0044] The data probe marks the data collection points on the proof of concept in the form of function calls; the data probe is used to collect the actual type of a specific variable and the JavaScript engine's expected type for it.

[0045] The proof of concept is converted into an abstract syntax tree (AST), and the scope of each variable in the AST is analyzed to determine the scope range. For each variable, a data probe is inserted after each proof statement within that scope.

[0046] The probe detection module includes:

[0047] This log file is collected using the probe runtime support library;

[0048] After the probe is started, it outputs the context environment obtained by the probe, the location of the probe's PoC, and the specified information that needs to be obtained to the log file. When the probe runtime support library detects type-obfuscated vulnerability data in the log file, it will record it in detail. The recording continues until the proof of concept execution ends.

[0049] The aforementioned probe-based JavaScript engine type obfuscation vulnerability exploit generation device,

[0050] The vulnerability conversion module includes:

[0051] The concept of creating a module demonstrates the creation of an object o of type X.

[0052] The concept of misusing the read-write module demonstrates that object o is used with the actual type X without interfering with the occurrence of type confusion.

[0053] The module was misused. The concept proved that the object o could be read and written, but the JavaScript engine incorrectly used methods of the expected type Y to manipulate the object o.

[0054] If the read / write module is misused, the program continues to execute. The PoC reads and writes object o with the actual type X, and will not interfere with the occurrence of type confusion.

[0055] The read / write free point includes the read / write free point before misuse and the read / write free point after misuse; the read / write module before misuse is taken as the read / write free point before misuse, the misuse module is taken as the type misuse point, and the read / write module after misuse is taken as the read / write free point after misuse.

[0056] The vulnerability conversion module includes:

[0057] Using the type verification data in the probe, locate the misuse point of the type, and determine the actual type and expected type of the misuse point; organize the data object type and obfuscation type of the read / write free point, and generate a type obfuscation information report including statement location, object type, obfuscation type, and memory read / write operation;

[0058] The utilization building module includes:

[0059] Based on the type of obfuscation information report, query the type of obfuscation knowledge base, construct the corresponding read / write primitives based on the query results, and fill them into the read / write free point through read / write operations to obtain the exploit primitives; wherein the type of obfuscation knowledge base contains primitives corresponding to each type of obfuscation situation;

[0060] Create an inline data object o, and internally forge an array buffer object fakebuf; fill the buffer address field of fakebuf with the arbitrary address addr to be read or written; use the exploit primitive to obtain a reference to fakebuf to create an array read / write object dataview; use the dataview function to generate an arbitrary address read / write primitive of the read / write address addr as a supplementary exploit primitive.

[0061] Create a function object f; use the supplementary exploit primitive to query the machine code memory address rwxAddr of function f; use the supplementary exploit primitive to modify the machine code corresponding to function f by writing to any address in the write primitive, and then generate a remote code execution exploit as the detection result of this type of obfuscation vulnerability.

[0062] The probe-based JavaScript engine type obfuscation exploit generation device, wherein the exploit construction module includes:

[0063] Based on the detection results of this type of obfuscation vulnerability, the severity of the vulnerability is assessed, thereby determining the priority of vulnerability remediation. The vulnerability with the highest priority is selected for remediation, and the networked device runs the remediated JavaScript engine to complete the specified task.

[0064] The present invention also proposes an electronic device, including the aforementioned probe-based JavaScript engine type obfuscation exploit generation device.

[0065] The electronic device is connected to an information device, which displays the evaluation results and uses user-defined display parameters, attributes, or artificial intelligence models to display specified information in the detection results of this type of obfuscation vulnerability.

[0066] The present invention also proposes a storage medium for storing a computer program of the probe-based JavaScript engine type obfuscation exploit generation method.

[0067] As can be seen from the above solutions, the advantages of the present invention are:

[0068] 1. Using data probes to detect type confusion vulnerabilities. Type confusion vulnerabilities refer to vulnerabilities caused by machine code interpreting data of type A as type B, such as interpreting an integer as a pointer. We call type A the actual type and type B the expected type. We collectively refer to the actual type and expected type as data bitype. A data probe is code that reads the actual type and expected type of given data D and stores them in a log file. This invention first inserts a data probe into the JavaScript proof of concept and its derived code, and uses it as input to run the JavaScript engine to obtain a log file containing the actual type and expected type. Then, analysis tools are used to compare each record containing the actual type and expected type for the given data D. If the actual type matches the expected type, it proves that type confusion has not occurred; if the actual type does not match the expected type, it proves that type confusion occurs with the given data D.

[0069] 2. By inserting exploit statements at type misuse points and read-write freedom points, type obfuscation vulnerabilities are transformed into exploit primitives. A type misuse point refers to a program point where type obfuscation occurs for a given data D, and data D is used. A read-write freedom point refers to a program point where type obfuscation does not occur for a given data D, and performing operations on the given data D does not cause the type obfuscation vulnerability to disappear. The inventors observed that there is a read-write freedom point before and after the type obfuscation point in the program execution trajectory. We call these the pre-misuse read-write freedom point and the post-misuse read-write freedom point, respectively. Exploit primitives are the basic elements for constructing exploit code. This invention transforms type obfuscation vulnerabilities into exploit primitives by inserting exploit statements at type misuse points and read-write freedom points. In this invention, there exists a type obfuscation knowledge base that records the correspondence between data dual types and exploit statements. If the type obfuscation knowledge base contains a specific entry, it means that the type obfuscation vulnerability corresponding to the data dual type of that entry can be transformed into an exploit primitive. Otherwise, it cannot be transformed into an exploit primitive. We read the type obfuscation knowledge base to find entries that match the type obfuscation vulnerability data in both types, and then use statements to insert type misuse points and read / write freedom points to transform the type obfuscation vulnerability into an exploit primitive.

[0070] 3. Utilize modularized expert knowledge to construct exploit primitives into exploits. Like exploits, exploit primitives have execution effects that exceed the program's expected functionality. However, by combining exploit primitives, the final exploit can be made more dangerous. Exploit primitives are divided into two types: basic exploit primitives and supplementary exploit primitives. To construct an exploit, basic exploit primitives are necessary. Basic exploit primitives are derived from type confusion vulnerabilities. Supplementary exploit primitives expand the scope of influence of basic exploit primitives. Supplementary exploit primitives are modularly stored in the expert knowledge base. By combining basic and supplementary exploit primitives in a patterned manner, we generate a more powerful exploit. Attached Figure Description

[0071] Figure 1 This is an overall flowchart of the present invention;

[0072] Figure 2 A flowchart illustrating the overall process of probe insertion;

[0073] Figure 3 Diagram of the probe compilation process;

[0074] Figure 4 For automatic analysis of flowcharts;

[0075] Figure 5 Extracting graphs for key nodes in type confusion;

[0076] Figure 6 Flowchart for type confusion pattern recognition;

[0077] Figure 7 This is a diagram showing the overall architecture of the automatic zoom tool.

[0078] Figure 8 Constructing a framework diagram for patterned primitives;

[0079] Figure 9 The data structure of an object and its pointer relationship diagram;

[0080] Figure 10 Memory layout diagram for allowing arbitrary address read and write of DataView;

[0081] Figure 11 Flowchart for constructing read / write primitives for arbitrary addresses;

[0082] Figure 12 A flowchart illustrating how a JavaScript engine can correctly execute a compiled function;

[0083] Figure 13 Construct a flowchart for remote code execution primitives;

[0084] Figure 14To construct a remote code execution flowchart;

[0085] Figure 15 This is a flowchart of the method of the present invention;

[0086] Figure 16 This is a block diagram of the device of the present invention;

[0087] Figure 17 This is a schematic diagram of the structure of the first electronic device of the present invention;

[0088] Figure 18 This is a schematic diagram of the application environment structure of the first electronic device of the present invention;

[0089] Figure 19 This is a schematic diagram of the structure of the second electronic device of the present invention.

[0090] Figure label:

[0091] 11-Probe placement tool;

[0092] 12-PoC with probe;

[0093] 13-Runtime probe data acquisition tool;

[0094] 14-Probe data;

[0095] 15-Automatic analysis tools;

[0096] 16-Automatic zoom tool;

[0097] 17- Utilizing primitives;

[0098] 18-Construction of patterned primitives;

[0099] 21-PoC;

[0100] 22-AST;

[0101] 23-AST with probe;

[0102] 24-PoC with markings;

[0103] 31-Probe;

[0104] 32 - Intermediate representation;

[0105] 33 - Assembly code;

[0106] 41-Type Confusion Point Filtering;

[0107] 42-Type obfuscation pattern recognition;

[0108] 43-Read / write free point type obfuscation information;

[0109] 52-Type X;

[0110] 51-Type Y;

[0111] 61-Type obfuscation mode;

[0112] 71-Read / write free point type obfuscation information;

[0113] 72-Type Confusion Knowledge Base;

[0114] 73 - Primitive Construction;

[0115] 77-fakeObj AddrOf primitive;

[0116] 75-Construction of patterned primitives;

[0117] 81-Fakeobj primitives;

[0118] 84 - Read primitives at any address;

[0119] 82-Addrof primitives;

[0120] 83 - Construction of arbitrary address read / write primitives;

[0121] 85 - Write primitives to any address;

[0122] 86 - Construction of remote code execution;

[0123] 87 - Remote code execution;

[0124] 111 - Create an Object object o, and internally forge an ArrayBuffer object fakebuf;

[0125] 112 - Fill the `addr` field into the `backing_store` location of the `fakebuf` object;

[0126] 113 - Using the fakeobj and addrof primitives, obtain a fakebuf object;

[0127] 114 - Create a DataView object (DataView) using fakebuf;

[0128] 115 - Using DataView functions to generate arbitrary address read / write primitives;

[0129] 141 - Create a function object f;

[0130] 142 - Using an arbitrary address to read the machine code memory address rwxAddr of the primitive query function f;

[0131] 143 - Modify the RWX segment of function f using arbitrary address write primitives;

[0132] 144 - Execute function f;

[0133] 145 - Remote code execution;

[0134] S-100;

[0135] S-200;

[0136] S-300;

[0137] 161 - Probe detection module;

[0138] 162 - Vulnerability Conversion Module;

[0139] 163 - Utilizing building blocks;

[0140] A - First electronic device;

[0141] B-Probe-based JavaScript engine type obfuscation exploit generation device;

[0142] C-Data acquisition equipment;

[0143] D-Information display device;

[0144] 1000 - Second electronic device;

[0145] Ⅰ-Computational Unit;

[0146] II-ROM;

[0147] III-RAM;

[0148] N-bus;

[0149] V-Interface;

[0150] VI - Input Unit;

[0151] VII - Output Unit;

[0152] VIII - Storage medium;

[0153] IX - Communication Unit. Detailed Implementation

[0154] It should be noted that the processor described in this invention is the control center of an electronic device. It can be a single processor or a collective term for multiple processing elements. For example, it can be one or more central processing units (CPUs), application-specific integrated circuits (ASICs), or one or more integrated circuits configured to implement embodiments of this invention, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs).

[0155] Alternatively, the processor can perform various functions of the electronic device by running or executing software programs stored in memory, and by calling data stored in memory.

[0156] In a specific implementation, as one example, the processor may include one or more CPUs. Each of these processors may be a single-core processor or a multi-core processor. Here, "processor" can refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions). Electronic devices may include servers, desktop computers, laptops, smartphones, tablets, embedded computers, etc., where the embedded computer includes vehicles and robots, etc.

[0157] The memory is used to store the software program that executes the solution of the present invention, and the execution is controlled by the processor. For specific implementation methods, please refer to the above method embodiments, which will not be repeated here.

[0158] It should be noted that the structure of the electronic device shown in the accompanying drawings of this invention does not constitute a limitation thereof. The actual knowledge structure recognition device may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0159] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0160] It should also be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0161] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0162] It should also be understood that, in various embodiments of the present invention, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0163] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0164] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0165] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0166] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0167] To make the above-mentioned features and effects of the present invention clearer and easier to understand, specific embodiments are described below in conjunction with the accompanying drawings. This specification discloses one or more embodiments incorporating the features of the present invention. The disclosed embodiments are merely illustrative. The scope of protection of the present invention is not limited to the disclosed embodiments, but is defined by the appended claims.

[0168] like Figure 1As shown, this invention proposes an automated exploitation scheme for JavaScript engine type obfuscation vulnerabilities. The input to this invention is a proof-of-concept (PoC) that triggers the vulnerability. The proof-of-concept in this invention is a text file based on JavaScript code; this text file is used as input to run a probe deployment tool to obtain a PoC with probes.

[0169] This invention first uses a probe deployment tool to automatically insert data probes, resulting in a Proof of Concept (PoC) with probes. Then, a runtime probe data acquisition tool executes the proof of concept and acquires probe data. Next, this invention uses an automated analysis tool to automatically analyze the cause and type of vulnerabilities, followed by an automated amplification tool to enhance the proof of concept's capabilities. Next, it utilizes type obfuscation knowledge to construct exploit primitives, and finally performs patterned primitive construction and exploit (Exp) generation. Each module is described below.

[0170] Probe placement tool:

[0171] To collect runtime data associated with the Proof-of-Concept (PoC) location, probes need to be deployed within the PoC. On one hand, the probes need to accurately mark variable access points and variable validity points within the PoC. On the other hand, the probes must not interfere with normal program execution. The overall system workflow is as follows: Figure 2 As shown.

[0172] The probe needs to have its collection points labeled on the Proof-of-Concept (PoC). To facilitate parsing by the JavaScript engine, the probe is implemented using function calls. A data probe can be used to collect information about a specific JavaScript engine variable.

[0173] Data probes can be used to collect information about specific variables. For example, in a JavaScript engine, a marker probe can be written as probe(x), where x is the object being probed. For type obfuscation vulnerabilities, the system needs to collect both the actual type of x and the JavaScript engine's expected type for it.

[0174] Probes need to describe variable usage information within the Proof-of-Concept (PoC). To this end, the probe deployment tool converts the PoC into an Abstract Syntax Tree (AST) and analyzes this data structure to identify collectable locations and insert probes. To achieve this, the tool analyzes the scope of each variable in the PoC based on the AST, identifying the target variables where probes can be deployed. Simultaneously, the tool analyzes variable read and write operations on the AST, deploying object access probes before these operations to record them.

[0175] When inserting probes, the risk of cross-scope variable references needs to be considered. For example, in the following sample program, probing x within function b would result in a cross-scope reference. Since function b is passed as a return value by function a, its lifetime exceeds the lifetime of variable x. If x is probed within function b, the lifetime of x will be extended due to closure, further extending the lifetime of variables in function a, causing interference. For some Proof-of-Concepts (PoCs) that do not involve this mechanism, these disturbances are acceptable; however, if vulnerabilities exist due to scope analysis, such operations may cause the PoC to fail. Therefore, it is necessary to clearly define the probe's target and appropriately avoid cross-scope variable probing. Sample program:

[0176]

[0177] Probe runtime support library

[0178] To obtain probe-tagged data during the JavaScript engine's Proof-of-Concept (PoC) execution, a probe support library needs to be added. During JavaScript engine execution, the probe support library continuously monitors and records the engine state using probes from the PoC. When type obfuscation is detected, detailed logging is performed. Logging continues until the PoC execution concludes, ensuring a complete execution trajectory is obtained.

[0179] Without customizing the JavaScript engine, the marker probe is recognized as a function call named `probe`. In this case, the probe can be designed by adding a built-in function to the JavaScript engine. However, built-in function calls have strong side effects and can prevent the compiler's analysis within the engine. In this situation, the Proof-of-Concept (PoC) will be interfered with and may fail. Furthermore, the syntax design of object access probes cannot pass the lexical check of the JavaScript engine, so it's not possible to simply implement probes through functions. How to inject probe support without affecting the normal execution of the JavaScript engine becomes the design challenge of this system.

[0180] To address the aforementioned issues, additional support libraries are needed for the JavaScript engine. This is achieved by converting the probes into an intermediate representation acceptable to the JavaScript engine during its lexical and syntax analysis phases, and then integrating the probes into the JavaScript compilation process. During compilation, the probes exist with low side effects and are compatible with most compilation optimizations. After compilation, the probes will exist as assembly code in the JavaScript engine's just-in-time (JIT) compiled code, or as function calls within the interpreted execution context, such as... Figure 3 The diagram shown illustrates the operation process of the runtime probe data acquisition tool.

[0181] This compilation process will trigger the probe when the Proof-of-Concept (PoC) is run. After the probe starts, it will acquire the current context, the location of the PoC, and the various information that needs to be obtained, and output them to a specific log file.

[0182] Automated analysis tools

[0183] The automated analysis tool uses probe data to organize key information from Proof-of-Concept (PoC), providing crucial data for amplifying vulnerability types. For type-obfuscated vulnerabilities, it performs targeted analysis on the obfuscated type and data to obtain read / write freepoint type obfuscation information. The overall flowchart is as follows: Figure 4 As shown:

[0184] Based on long-term research experience on JavaScript engine vulnerabilities, this invention abstracts the type obfuscation vulnerability pattern and extracts the key nodes of type obfuscation, resulting in the following process: 1. PoC creates an object o of actual type X; 2. PoC can freely use object o of actual type X without interfering with the occurrence of type obfuscation; 3. PoC reads and writes information about object o, but the JavaScript engine incorrectly uses methods of the expected type Y to operate on object o; 4. The program continues to execute, and PoC can freely read and write object o of actual type X without interfering with the occurrence of type obfuscation. In this process, we define the program position in process 2 as the read / write freedom point before misuse, the type misuse operation in process 3 as the type misuse point, and the program position in process 4 as the read / write freedom point after misuse, as follows. Figure 5 As shown, type confusion vulnerabilities must involve three processes in sequence: free read / write before misuse, type misuse, and free read / write after misuse. We will use these as characteristics of type confusion vulnerabilities for further analysis.

[0185] An object o can be a collection of simple data types. For example, in computers, integers and decimals are simple data types. These data can be stored using very little space; however, storing a large number of integers requires a large amount of space, which is equivalent to storing a large number of integers in a collection. In this case, we call this collection an object o.

[0186] By utilizing type verification data from the probe, we can locate type misuse points in the PoC (process 3) and simultaneously determine type X and type Y. Starting from the misuse point, we analyze the data flow dependencies forward and backward to find relevant variable usage points and match them with type obfuscation patterns to identify memory read / write statements that meet the restrictions. We define these memory read / write statements as read / write free points before and after misuse and record them in the vulnerability information. Finally, we organize the data object types and obfuscation types of the read / write free points to generate type obfuscation information, including statement location, object type, obfuscation type, and memory read / write operation, forming a type obfuscation information report, which is passed to subsequent modules along with the PoC for further exploitation. The type obfuscation pattern identification flowchart is as follows. Figure 6 As shown.

[0187] Automatic zoom tool

[0188] The automatic amplification tool amplifies type confusion vulnerabilities based on the results of automatic analysis tools. For example... Figure 7 The overall architecture diagram of the automatic zoom tool is shown below.

[0189] For type obfuscation vulnerabilities, the amplification tool takes read / write free points and type obfuscation information as input. It queries a type obfuscation knowledge base based on the type obfuscation information and selects the primitives to be constructed. The primitive construction module fills the read / write free points with read / write operations to implement specific primitives (FakeObj primitive, AddrOf primitive, etc.). After implementing the specific primitives, the patterned primitive construction module implements arbitrary address read / write primitives to form the final Exp. The specific process of type obfuscation amplification is described below.

[0190] This involved extensive research into JavaScript engine vulnerabilities and exploits, studying code snippets, analyzing and summarizing a large amount of type obfuscation knowledge, and storing it to form a type obfuscation knowledge base.

[0191] Type confusion amplification

[0192] The type obfuscation amplification module first queries the type obfuscation knowledge base based on the type obfuscation information to obtain the primitives to be constructed. The type obfuscation knowledge base records the primitives that can be constructed for different types of misuse. If an ObjectArray is misused as a FloatArray, the AddrOf primitive can be constructed using this type misuse; if a FloatArray is misused as an ObjectArray, the FakeObj primitive can be constructed using this type misuse. The complete type obfuscation knowledge base is as follows:

[0193] FloatArray ObjectArray Float Int InlineObject AuxSlotObject FloatArray - FakeObj AddrOf AddrOf ObjectArray AddrOf - AddrOf AddrOf Float FakeObj FakeObj - FakeObj FakeObj Int FakeObj FakeObj MissingValueExp - FakeObj FakeObj InlineObject AddrOf AddrOf - MemR / W AuxSlotObiect AddrOf AddrOf -

[0194] After querying the type obfuscation knowledge base, the amplification tool constructs corresponding primitives based on the query results. Here, we'll use the AddrOf and FakeObj primitives as examples. The AddrOf primitive can leak the address of a JavaScript object on the heap, enabling it to bypass ASLR. AddrOf is a function at the JavaScript language level, and its parameter is a JavaScript language-level object. The process of constructing the AddrOf primitive includes: First, determining the target object, i.e., which object's address we want to obtain; second, before misuse, reading and writing the object to an ObjectArray at the free point, so that the ObjectArray now contains one element that is the target object; at the type misuse point, the ObjectArray will be misused as a FloatArray, and the target object will be read from the FloatArray. The read value is a floating-point number, and type casting of the read floating-point number will yield the address of the target object.

[0195] FakeObj has the ability to forge JavaScript object data and thus manipulate the JavaScript engine. At the JavaScript language level, FakeObj is a function that takes the address of the object to be forged as its parameter and outputs a JavaScript language-level object with the same address as the parameter. The process of constructing the FakeObj primitive involves: converting any address to a floating-point number; before misuse, reading and writing the floating-point number to a FloatArray at the free point; at the misuse point, the FloatArray is misused as an ObjectArray, and the floating-point number in the ObjectArray is read. Since the ObjectArray will treat this floating-point number as the object address, it returns a forged object.

[0196] Patterned primitive construction and utilization generation

[0197] The last module of the JavaScript vulnerability exploitation system is the pattern primitive construction module, whose basic framework is as follows: Figure 8 As shown, this module amplifies the attack primitives generated by the preceding tools in a patterned manner until it generates an exploit capable of remote code execution. The input to this module should include the `Fakeobj` and `Addrof` primitives. When `Fakeobj` and `Addrof` are input, it is necessary to first construct an arbitrary address read / write primitive, and then construct the remote code execution primitive. The `Fakeobj` and `Addrof` primitives are basic exploit primitives, while the arbitrary address read / write primitive is a supplementary exploit primitive. The following sections will explain the functionality of this module from two aspects: "construction of the arbitrary address read / write primitive" and "construction of remote code execution."

[0198] Construction of arbitrary address read / write primitives

[0199] Once the vulnerability exploitation system has the capabilities of the Fakeobj and Addrof primitives, it can use them to construct arbitrary address read and write primitives.

[0200] The arbitrary address read / write primitive is constructed using DataView and ArrayBuffer objects. To explore the ability to perform arbitrary address read / write using DataView objects, we first need to understand the normal data access process of DataView: First, an ArrayBuffer object `arrbuf` is added to the language source code by the system as a data buffer, and then a DataView object is added based on `arrbuf`. The data structures of each object and their pointer relationships are as follows: Figure 9 As shown: the `buffer` field of the `DataView` object is a pointer to `arrbuf`, and the `backing_store` field of the `arrbuf` object is a pointer to a data block. The data block stores the array elements of the `ArrayBuffer`. Theoretically, the engine can control the location of data accessed by the `DataView` by changing the value of `backing_store` in the script. However, under normal circumstances, this field cannot be changed by the user, thus preventing the construction of arbitrary address read / write primitives. So, how can we bypass this? We can use the `Fakeobj` and `Addrof` primitives.

[0201] We first define the interfaces `read(addr)` and `write(addr, value)` for arbitrary address read / write primitives. The `read` function takes a user-specified address as its parameter `addr` and its function is to leak the content at that address. The `write` function takes a user-specified address as its parameter `addr` and `value` as the value to be written. Its function is to write `value` to the memory location specified by `addr`. Figure 10 As shown, the system creates an object `o` in the script and forges an `ArrayBuffer` object `fakebuf` inside it. `addr` is written to the `backing_store` field of `fakebuf`, and the `buffer` of the `DataView` is set to the forged `fakebuf`. At this point, the system can use the script to read the memory unit specified by `addr` using `dataview.getBigUint64(0,true)`.

[0202] The construction of arbitrary address read / write primitives is summarized, and the process is as follows: Figure 11As shown: The input is the primitives Fakeobj and Addrof, and the output is an arbitrary address read / write primitive. The steps include: (1) Create an Object o in the JavaScript engine and forge an ArrayBuffer object fakebuf inside it; (2) Fill addr into the backing_store position of the fakebuf object; (3) Use the primitives fakeobj and addrof to obtain the forged fakebuf object; (4) Use fakebuf to create a DataView object dataview; (5) Use the functions of dataview to generate an arbitrary address read / write primitive.

[0203] Construction of remote code execution

[0204] Once an automated exploit system possesses arbitrary address read / write primitives, it can use them to perform remote code execution. Remote code execution is implemented using JavaScript function objects. To explore the implementation process of remote code execution, we first need to understand the normal execution flow of a compiled function by a JavaScript engine, which is as follows: Figure 12 As shown.

[0205] First, the system adds a function `f` to the source code and calls `f`. When the JavaScript engine executes this script, it first creates a function object `f` in memory and compiles it. When executing the function call, the JavaScript engine automatically looks up the stored function machine code memory address `rwxAddr` based on the data structure of the function object `f`, and jumps the control flow to that address for execution.

[0206] The above describes how the system constructs remote code execution primitives. Figure 12 As shown, the system first inserts a function `f` into the source code. Next, it uses an arbitrary address read primitive to simulate querying the machine code memory address `rwxAddr` of function `f`, and then uses an arbitrary address write primitive to modify the contents of the `RWX` segment of function `f` to `ShellCode`. Finally, it calls the function `f` in the source code to transfer control flow to the `RWX` segment. This method cleverly bypasses the DEP defense mechanism, achieving the effect of remote code execution.

[0207] The construction of remote code execution is summarized, and its process is as follows: Figure 14 As shown: the input is an arbitrary address read / write primitive, and the output is a remote code execution primitive. The steps include: (1) creating a function object f; (2) using the arbitrary address read primitive to query the machine code memory address rwxAddr of function f; (3) using the arbitrary address write primitive to modify the RWX segment of function f; (4) executing function f.

[0208] The following are system embodiments corresponding to the above method embodiments. This embodiment can be implemented in conjunction with the above embodiments. The relevant technical details mentioned in the above embodiments are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the above embodiments.

[0209] like Figure 16 The present invention also proposes a probe-based JavaScript engine type obfuscation vulnerability exploit generation device B, which includes:

[0210] The probe detection module 161 obtains a proof of concept for detecting whether a networked device has a type confusion vulnerability. After inserting a data probe into the proof of concept, it inputs it into the JavaScript engine of the networked device to obtain a log file of the JavaScript engine running. The log file includes the actual type and expected type of the given data. The given data whose actual type and expected type are different is selected as the type confusion vulnerability data.

[0211] The vulnerability conversion module 162 reads the type obfuscation knowledge base, finds the exploit statement that matches the data type of the type obfuscation vulnerability, inserts the exploit statement into the type misuse point and read / write freedom point, and converts the proof of concept after inserting the data probe into the exploit primitive; wherein the type misuse point is the program point in the JavaScript engine that uses the type obfuscation vulnerability data, and there is a read / write freedom point before and after the type obfuscation point;

[0212] Using the construction module 163, the exploit primitive is used as the basic exploit primitive and combined with the supplementary exploit primitives in the expert knowledge base to generate an exploit, which serves as the type confusion vulnerability detection result for the networked device.

[0213] The aforementioned probe-based JavaScript engine type obfuscation vulnerability exploit generation device,

[0214] The probe detection module includes:

[0215] The data probe marks the data collection points on the proof of concept in the form of function calls; the data probe is used to collect the actual type of a specific variable and the JavaScript engine's expected type for it.

[0216] The proof of concept is converted into an abstract syntax tree (AST), and the scope of each variable in the AST is analyzed to determine the scope range. For each variable, a data probe is inserted after each proof statement within that scope.

[0217] The probe detection module includes:

[0218] This log file is collected using the probe runtime support library;

[0219] After the probe is started, it outputs the context environment obtained by the probe, the location of the probe's PoC, and the specified information that needs to be obtained to the log file. When the probe runtime support library detects type-obfuscated vulnerability data in the log file, it will record it in detail. The recording continues until the proof of concept execution ends.

[0220] The aforementioned probe-based JavaScript engine type obfuscation vulnerability exploit generation device,

[0221] The vulnerability conversion module includes:

[0222] The concept of creating a module demonstrates the creation of an object o of type X.

[0223] The concept of misusing the read-write module demonstrates that object o is used with the actual type X without interfering with the occurrence of type confusion.

[0224] The module was misused. The concept proved that the object o could be read and written, but the JavaScript engine incorrectly used methods of the expected type Y to manipulate the object o.

[0225] If the read / write module is misused, the program continues to execute. The PoC reads and writes object o with the actual type X, and will not interfere with the occurrence of type confusion.

[0226] The read / write free point includes the read / write free point before misuse and the read / write free point after misuse; the read / write module before misuse is taken as the read / write free point before misuse, the misuse module is taken as the type misuse point, and the read / write module after misuse is taken as the read / write free point after misuse.

[0227] The vulnerability conversion module includes:

[0228] Using the type verification data in the probe, locate the misuse point of the type, and determine the actual type and expected type of the misuse point; organize the data object type and obfuscation type of the read / write free point, and generate a type obfuscation information report including statement location, object type, obfuscation type, and memory read / write operation;

[0229] The utilization building module includes:

[0230] Based on the type of obfuscation information report, query the type of obfuscation knowledge base, construct the corresponding read / write primitives based on the query results, and fill them into the read / write free point through read / write operations to obtain the exploit primitives; wherein the type of obfuscation knowledge base contains primitives corresponding to each type of obfuscation situation;

[0231] Create an inline data object o, and internally forge an array buffer object fakebuf; fill the buffer address field of fakebuf with the arbitrary address addr to be read or written; use the exploit primitive to obtain a reference to fakebuf to create an array read / write object dataview; use the dataview function to generate an arbitrary address read / write primitive of the read / write address addr as a supplementary exploit primitive.

[0232] Create a function object f; use the supplementary exploit primitive to query the machine code memory address rwxAddr of function f; use the supplementary exploit primitive to modify the machine code corresponding to function f by writing to any address in the write primitive, and then generate a remote code execution exploit as the detection result of this type of obfuscation vulnerability.

[0233] The probe-based JavaScript engine type obfuscation exploit generation device, wherein the exploit construction module includes:

[0234] Based on the detection results of this type of obfuscation vulnerability, the severity of the vulnerability is assessed, thereby determining the priority of vulnerability remediation. The vulnerability with the highest priority is selected for remediation, and the networked device runs the remediated JavaScript engine to complete the specified task.

[0235] like Figure 17 As shown, the present invention also proposes a first electronic device A, which includes the aforementioned probe-based JavaScript engine type obfuscation exploit generation device B.

[0236] like Figure 18 As shown, the first electronic device A can also be connected to the data acquisition device C and the information display device D via wired or wireless information transmission schemes. The data acquisition device C is used to acquire proof of concept, and the information display device D is used to display the type confusion vulnerability detection results obtained by the present invention.

[0237] Information display device D can process and organize the data output by the first electronic device A based on an information display mechanism to improve the readability of the data. This information display mechanism can be manually preset, for example, visualizing the data output by the first electronic device A. It can present the user with specified key information, such as news updates or system information, based on user-defined display parameters and / or attributes. Display parameters could be, for example, the data range to be displayed, and display attributes could be, for example, the font, color, or whether scrolling is enabled. This allows the user to access this information more quickly without having to navigate to secondary pages or scroll through pages, saving user effort. Alternatively, this information display mechanism can be an artificial intelligence (AI) display model, which can learn the user's key information interests based on previous usage habits, such as viewing time, number of clicks, and number of edits, and then automatically present the user with rich and necessary key information.

[0238] In another embodiment, the present invention also proposes a storage medium VIII for storing a computer program for generating the aforementioned probe-based JavaScript engine type obfuscation vulnerability exploit. It should be understood that the storage medium in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0239] Figure 19A schematic block diagram of a second electronic device 1000 that can be used to implement embodiments of the present invention is shown. The second electronic device 1000 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The second electronic device 1000 can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein. The second electronic device 1000 may be the same as or different from the first electronic device A.

[0240] The second electronic device 1000 includes a computing unit I, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory II (ROM) or a computer program loaded from storage medium VIII into random access memory (RAM) III. The RAM III may also store various programs and data required for the operation of the device 1000. The computing unit I, ROM II, and RAM III are interconnected via bus IV. An input / output (I / O) interface V is also connected to bus IV.

[0241] Multiple components in the second electronic device 1000 are connected to I / O interface V, including: input unit VI, such as a keyboard, mouse, etc.; output unit VII, such as various types of displays, speakers, etc.; storage medium VIII, such as a disk, optical disk, etc.; and communication unit IX, such as a network card, modem, wireless transceiver, etc. Communication unit IX allows the second electronic device 1000 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0242] The computing unit I can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of computing unit I include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit I executes the various methods and processes described above, such as method steps S100-S300. For example, in some embodiments, the method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage medium VIII. In some embodiments, part or all of the computer program may be loaded and / or installed on device 1000 via ROM II and / or communication unit IX. When the computer program is loaded into RAM III and executed by computing unit I, one or more steps of the methods described above may be performed. Alternatively, in other embodiments, computing unit I may be configured to execute methods by any other suitable means (e.g., by means of firmware).

[0243] Although embodiments of the present invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. They can be applied to various fields suitable for the present invention. For those skilled in the art, other modifications can be easily made. Therefore, without departing from the general concept defined by the claims and their equivalents, the present invention is not limited to the specific details and illustrations shown and described herein.

Claims

1. A method for generating exploits for JavaScript engine type obfuscation vulnerabilities based on probes, characterized in that, include: The probe detection step involves obtaining a proof of concept for detecting type confusion vulnerabilities in networked devices. After inserting a data probe into the proof of concept, it is input into the JavaScript engine of the networked device to obtain the log file of the JavaScript engine. The log file includes the actual type and expected type of the given data. Select given data whose actual type differs from the expected type as type confusion vulnerability data; The vulnerability transformation step involves reading the type obfuscation knowledge base, finding an exploit statement that matches the data type of the type obfuscation vulnerability, inserting the exploit statement into a type misuse point and a read / write freedom point, and transforming the proof of concept after inserting the data probe into an exploit primitive. The type misuse point is the program point in the JavaScript engine that uses the type obfuscation vulnerability data, and there is a read / write freedom point before and after the type obfuscation point. Using the construction steps, this exploit primitive is used as the basic exploit primitive. It is then combined with supplementary exploit primitives in the expert knowledge base to generate an exploit, which serves as the type confusion vulnerability detection result for the networked device. The vulnerability conversion steps include: The creation steps demonstrate that this concept creates an object o of type X. The concept of using object o with actual type X before misuse of read-write steps is proven and does not interfere with the occurrence of type confusion. The concept demonstrates reading and writing information about object o, but the JavaScript engine incorrectly uses methods of the expected type Y to manipulate object o. If the read / write step is misused, the program continues to execute. The PoC reads and writes object o with the actual type X, and will not interfere with the occurrence of type confusion. The read / write freedom point includes the read / write freedom point before misuse and the read / write freedom point after misuse; the read / write step before misuse is taken as the read / write freedom point before misuse, the misuse step is taken as the type misuse point, and the read / write step after misuse is taken as the read / write freedom point after misuse. The vulnerability mitigation process includes: Using the type verification data in the probe, locate the misuse point of the type, and determine the actual type and expected type of the misuse point; organize the data object type and obfuscation type of the read / write free point, and generate a type obfuscation information report including statement location, object type, obfuscation type, and memory read / write operation; The construction steps include: Based on the type of obfuscation information report, query the type of obfuscation knowledge base, construct the corresponding read / write primitives based on the query results, and fill them into the read / write free point through read / write operations to obtain the exploit primitives; wherein the type of obfuscation knowledge base contains primitives corresponding to each type of obfuscation situation; Create an inline data object o, and internally forge an array buffer object fakebuf; fill the buffer address field of fakebuf with the arbitrary address addr to be read and written; use the exploit primitive to obtain a reference to fakebuf to create an array read and write object dataview; use the dataview function to generate an arbitrary address read and write primitive of read and write address addr as a supplementary exploit primitive; Create a function object f; use the supplementary exploit primitive to query the machine code memory address rwxAddr of function f; use the supplementary exploit primitive to modify the machine code corresponding to function f by writing to any address in the write primitive, and then generate a remote code execution exploit as the detection result of this type of obfuscation vulnerability.

2. The probe-based JavaScript engine type obfuscation vulnerability exploit generation method as described in claim 1, The probe detection steps include: The data probe completes the annotation of collection points on the proof of concept in the form of function calls; This data probe is used to collect the actual type of a specific variable and the JavaScript engine's expected type for it; The proof of concept is converted into an abstract syntax tree, and the scope of each variable in the abstract syntax tree is analyzed to obtain the scope range. For each variable, insert a data probe after each proof of concept statement within that scope; The probe detection steps include: This log file is collected using the probe runtime support library; After the probe is started, it outputs the context environment obtained by the probe, the location of the probe's PoC, and the specified information that needs to be obtained to the log file. When the probe runtime support library detects type-obfuscated vulnerability data in the log file, it will record it in detail. The recording continues until the proof of concept execution ends.

3. The method for generating JavaScript engine type obfuscation vulnerability exploits based on probes as described in claim 1, characterized in that, The construction steps include: Based on the detection results of this type of obfuscation vulnerability, the severity of the vulnerability is assessed, thereby determining the priority of vulnerability remediation. The vulnerability with the highest priority is selected for remediation, and the networked device runs the remediated JavaScript engine to complete the specified task.

4. A probe-based JavaScript engine type obfuscation vulnerability exploit generation device, characterized in that, include: The probe detection module obtains a proof of concept for detecting type confusion vulnerabilities in networked devices. After inserting a data probe into the proof of concept, it inputs it into the JavaScript engine of the networked device to obtain the log file of the JavaScript engine. The log file includes the actual type and expected type of the given data. Select given data whose actual type differs from the expected type as type confusion vulnerability data; The vulnerability conversion module reads the type obfuscation knowledge base, finds the exploit statement that matches the data type of the type obfuscation vulnerability, inserts the exploit statement into the type misuse point and read / write freedom point, and converts the proof of concept after inserting the data probe into the exploit primitive; where the type misuse point is the program point in the JavaScript engine that uses the type obfuscation vulnerability data, and there is a read / write freedom point before and after the type obfuscation point; Using the building module, this exploit primitive is used as the basic exploit primitive. It is then combined with supplementary exploit primitives in the expert knowledge base to generate an exploit, which serves as the type confusion vulnerability detection result for the networked device. The vulnerability conversion module includes: The concept of creating a module demonstrates the creation of an object o of type X. The concept of misusing the read-write module demonstrates that object o is used with the actual type X without interfering with the occurrence of type confusion. The module was misused. The concept proved that the module could read and write information about object o, but the JavaScript engine incorrectly used methods of the expected type Y to manipulate object o. If the read / write module is misused, the program continues to execute. The PoC reads and writes object o with the actual type X, and will not interfere with the occurrence of type confusion. The read / write free point includes the read / write free point before misuse and the read / write free point after misuse; the read / write module before misuse is taken as the read / write free point before misuse, the misuse module is taken as the type misuse point, and the read / write module after misuse is taken as the read / write free point after misuse. The vulnerability conversion module includes: Using the type verification data in the probe, locate the misuse point of the type, and determine the actual type and expected type of the misuse point; organize the data object type and obfuscation type of the read / write free point, and generate a type obfuscation information report including statement location, object type, obfuscation type, and memory read / write operation; The utilization building module includes: Based on the type of obfuscation information report, query the type of obfuscation knowledge base, construct the corresponding read / write primitives based on the query results, and fill them into the read / write free point through read / write operations to obtain the exploit primitives; wherein the type of obfuscation knowledge base contains primitives corresponding to each type of obfuscation situation; Create an inline data object o, and internally forge an array buffer object fakebuf; fill the buffer address field of fakebuf with the arbitrary address addr to be read and written; use the exploit primitive to obtain a reference to fakebuf to create an array read and write object dataview; use the dataview function to generate an arbitrary address read and write primitive of read and write address addr as a supplementary exploit primitive; Create a function object f; use the supplementary exploit primitive to query the machine code memory address rwxAddr of function f; use the supplementary exploit primitive to modify the machine code corresponding to function f by writing to any address in the write primitive, and then generate a remote code execution exploit as the detection result of this type of obfuscation vulnerability.

5. The probe-based JavaScript engine type obfuscation vulnerability exploit generation device as described in claim 4, The probe detection module includes: The data probe completes the annotation of collection points on the proof of concept in the form of function calls; This data probe is used to collect the actual type of a specific variable and the JavaScript engine's expected type for it; The proof of concept is converted into an abstract syntax tree, and the scope of each variable in the abstract syntax tree is analyzed to obtain the scope range. For each variable, insert a data probe after each proof of concept statement within that scope; The probe detection module includes: This log file is collected using the probe runtime support library; After the probe is started, it outputs the context environment obtained by the probe, the location of the probe's PoC, and the specified information that needs to be obtained to the log file. When the probe runtime support library detects type-obfuscated vulnerability data in the log file, it will record it in detail. The recording continues until the proof of concept execution ends.

6. The probe-based JavaScript engine type obfuscation vulnerability exploit generation device as described in claim 4, characterized in that, The utilization building module includes: Based on the detection results of this type of obfuscation vulnerability, the severity of the vulnerability is assessed, thereby determining the priority of vulnerability remediation. The vulnerability with the highest priority is selected for remediation, and the networked device runs the remediated JavaScript engine to complete the specified task.

7. An electronic device, characterized in that, Includes the probe-based JavaScript engine type obfuscation exploit generation apparatus as described in any one of claims 4-6.

8. The electronic device as claimed in claim 7, characterized in that, The electronic device is connected to an information device, which is used to display the detection results of this type of obfuscation vulnerability. The information display device is used to display specified information in the detection results of this type of obfuscation vulnerability using user-set display parameters, attributes, or through an artificial intelligence model.

9. A storage medium for storing a computer program that executes the probe-based JavaScript engine type obfuscation exploit generation method of any one of claims 1-3.

Images