KR102494837B1 - Methods and apparatus for for detecting and decoding obfuscated javascript - Google Patents

Abstract

In the present specification, in a method for detecting JavaScript by a server, executing a process of an application program related to a non-executable file, detecting JavaScript included in the non-executable file based on the process of the application program, Executing JavaScript, debugging a host process for executing the JavaScript, and based on the host process, determining whether a library for executing the JavaScript is loaded, Based on the library being loaded, a breakpoint is set at the address of a function referred to to execute the JavaScript, and based on the execution of the breakpoint, the original text of the JavaScript is set. Extraction, and the JavaScript may be obfuscated JavaScript.

Description

Method for detecting and decrypting obfuscated JavaScript and device therefor

The present specification relates to a method and apparatus for detecting and decrypting obfuscated JavaScript that is difficult for humans to interpret.

Malicious file distribution methods using malware containing obfuscated JavaScript are generally detected by creating obfuscated signatures, but the detection rate is low, and JavaScript with behavior analysis bypass technology cannot be detected through behavior analysis.

More specifically, methods for detecting obfuscated JavaScript include static inspection and dynamic inspection methods.

Static scan is a scan that extracts and analyzes the data of a file without executing the file to be scanned to determine whether the file is malicious, and can be performed, for example, through anti-virus products. Static inspection (for example, signature) of obfuscated JavaScript can result in various obfuscation patterns with one JavaScript, so it is difficult to increase the detection rate because each must be responded to through a signature and can only be responded to known files.

Dynamic inspection is an inspection that determines whether a malicious behavior pattern is displayed by executing the inspection target file to record and analyze behavior data. For example, inspection in an isolated execution environment using sandbox (virtual machine) technology. You can monitor the behavior by executing the target file. Dynamic inspection for obfuscated JavaScript can detect suspicious behavior in non-executable files by executing obfuscated JavaScript. However, in order to evade behavior detection, the attacker executes the obfuscated JavaScript and delays execution (eg, action at a specified time, action after a certain time), behavior analysis environment detection before the decrypted original script causes malicious behavior. It is possible to circumvent behavioral analysis of dynamic inspection using various circumvention techniques such as evasion and evasion.

An object of the present specification is to propose a method and apparatus for securing and diagnosing the original text of JavaScript included in a non-executable file to increase the detection rate compared to existing static/dynamic detection methods.

The technical problems to be achieved by this specification are not limited to the above-mentioned technical problems, and other technical problems not mentioned are clear to those skilled in the art from the detailed description of the specification below. will be understandable.

One aspect of the present specification is a method for a server to detect JavaScript, comprising: executing a process of an application program related to a non-executable file; Detecting JavaScript included in the non-executable file based on the process of the application program; Executing the JavaScript and debugging a host process for executing the JavaScript; Based on the host process, determining whether a library for executing the JavaScript is loaded; setting a break point at an address of a function referenced to execute the JavaScript, based on the library being loaded; and extracting the original text of the JavaScript based on the execution of the breakpoint. Including, the JavaScript may be obfuscated JavaScript.

In addition, the step of extracting the original text of JavaScript may be based on a data extraction policy set in the register.

Also, the host process may include Wscript.exe.

Also, setting the break point may be based on loading the library into the host process.

Also, the library may include Jscript.dll.

Also, the breakpoint may be set at an address of a function referenced to execute the JavaScript in the library.

Also, a function referred to to execute the JavaScript may include a ScrFncObj::CALL function.

In addition, performing a static check on the original text of the JavaScript; may further include.

Another aspect of the present specification is a server for detecting JavaScript, comprising: a communication unit; Memory; and a processor functionally controlling the communication unit and the memory, wherein the processor executes a process of an application program related to a non-executable file, and based on the process of the application program, the Java included in the non-executable file. Detect script, execute the JavaScript, debug a host process for executing the JavaScript, and based on the host process, a library for executing the JavaScript is loaded. ), and based on the library being loaded, setting a breakpoint at the address of the function referred to to execute the JavaScript, and based on the execution of the breakpoint, The original text of the JavaScript is extracted, and the JavaScript may be obfuscated JavaScript.

According to the embodiments of the present specification, the detection rate can be increased compared to the existing static/dynamic detection methods by securing and diagnosing the original text of JavaScript included in non-executable files.

Effects obtainable in the present specification are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description below. .

1 is a block diagram for explaining an electronic device related to the present specification.
2 is a diagram showing a server or client related to the present specification.
3 is an example of an abnormal input that can be applied to this specification
4 is an embodiment of a server to which this specification can be applied.
5 is an example of the original text of decrypted JavaScript to which this specification can be applied.
The accompanying drawings, which are included as part of the detailed description to aid understanding of the present specification, provide examples of the present specification and describe technical features of the present specification together with the detailed description.

Hereinafter, the embodiments disclosed in this specification will be described in detail with reference to the accompanying drawings, but the same or similar components are given the same reference numerals regardless of reference numerals, and redundant description thereof will be omitted. The suffixes "module" and "unit" for components used in the following description are given or used together in consideration of ease of writing the specification, and do not have meanings or roles that are distinct from each other by themselves. In addition, in describing the embodiments disclosed in this specification, if it is determined that a detailed description of a related known technology may obscure the gist of the embodiment disclosed in this specification, the detailed description thereof will be omitted. In addition, the accompanying drawings are only for easy understanding of the embodiments disclosed in this specification, the technical idea disclosed in this specification is not limited by the accompanying drawings, and all changes included in the spirit and technical scope of this specification , it should be understood to include equivalents or substitutes.

Terms including ordinal numbers, such as first and second, may be used to describe various components, but the components are not limited by the terms. These terms are only used for the purpose of distinguishing one component from another.

It is understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, but other elements may exist in the middle. It should be. On the other hand, when an element is referred to as “directly connected” or “directly connected” to another element, it should be understood that no other element exists in the middle.

Singular expressions include plural expressions unless the context clearly dictates otherwise.

In this specification, terms such as "comprise" or "having" are intended to indicate that there is a feature, number, step, operation, component, part, or combination thereof described in the specification, but one or more other features It should be understood that the presence or addition of numbers, steps, operations, components, parts, or combinations thereof is not precluded.

Also, the term “unit” used in the specification means a software or hardware component, and “unit” performs certain roles. However, "unit" is not meant to be limited to software or hardware. A “unit” may be configured to reside in an addressable storage medium and may be configured to reproduce on one or more processors. Thus, as an example, “unit” can refer to components such as software components, object-oriented software components, class components and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays and variables. Functionality provided within components and "parts" may be combined into fewer components and "parts" or further separated into additional components and "parts".

Also, according to one embodiment of the present specification, "unit" may be implemented as a processor and a memory. The term “processor” should be interpreted broadly to include general-purpose processors, central processing units (CPUs), microprocessors, digital signal processors (DSPs), controllers, microcontrollers, state machines, and the like. In some circumstances, “processor” may refer to an application specific integrated circuit (ASIC), programmable logic device (PLD), field programmable gate array (FPGA), or the like. The term "processor" refers to a combination of processing devices, such as, for example, a combination of a DSP and a microprocessor, a combination of a plurality of microprocessors, a combination of one or more microprocessors in conjunction with a DSP core, or any other such configuration. may also refer to

The term “memory” should be interpreted broadly to include any electronic component capable of storing electronic information. The term memory includes random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), programmable read-only memory (PROM), erasable-programmable read-only memory (EPROM), electrical may refer to various types of processor-readable media, such as erasable PROM (EEPROM), flash memory, magnetic or optical data storage, registers, and the like. A memory is said to be in electronic communication with the processor if the processor can read information from and/or write information to the memory. Memory integrated with the processor is in electronic communication with the processor.

As used herein, a "non-executable file" is a concept opposite to an executable file or an executable file, and means a file that is not itself executed. For example, the non-executable file may be a PDF file, a Korean file, a document file such as a word file, an image file such as a JPG file, a video file, a JavaScript file, and an HTML file, but is not limited thereto.

Hereinafter, with reference to the accompanying drawings, embodiments will be described in detail so that those skilled in the art can easily carry out the embodiments. In addition, in order to clearly describe the present disclosure in the drawings, parts irrelevant to the description may be omitted.

1 is a block diagram for explaining an electronic device related to the present specification.

The electronic device 100 includes a wireless communication unit 110, an input unit 120, a sensing unit 140, an output unit 150, an interface unit 160, a memory 170, a control unit 180, and a power supply unit 190. ) and the like. The components shown in FIG. 1 are not essential to implement an electronic device, so an electronic device described in this specification may have more or fewer components than those listed above.

More specifically, among the components, the wireless communication unit 110 is between the electronic device 100 and the wireless communication system, between the electronic device 100 and other electronic devices 100, or between the electronic device 100 and an external server. It may include one or more modules enabling wireless communication between Also, the wireless communication unit 110 may include one or more modules that connect the electronic device 100 to one or more networks.

The wireless communication unit 110 may include at least one of a broadcast reception module 111, a mobile communication module 112, a wireless Internet module 113, a short-distance communication module 114, and a location information module 115. .

The input unit 120 includes a camera 121 or video input unit for inputting a video signal, a microphone 122 for inputting an audio signal, or a user input unit 123 for receiving information from a user, for example , a touch key, a push key (mechanical key, etc.). Voice data or image data collected by the input unit 120 may be analyzed and processed as a user's control command.

The sensing unit 140 may include one or more sensors for sensing at least one of information within the electronic device, environmental information surrounding the electronic device, and user information. For example, the sensing unit 140 may include a proximity sensor 141, an illumination sensor 142, a touch sensor, an acceleration sensor, a magnetic sensor, and gravity. Sensor (G-sensor), gyroscope sensor (gyroscope sensor), motion sensor (motion sensor), RGB sensor, infrared sensor (IR sensor), finger scan sensor, ultrasonic sensor , optical sensor (e.g. camera (see 121)), microphone (see 122), battery gauge, environmental sensor (e.g. barometer, soil hygrometer, thermometer, radiation detection sensor) , a heat sensor, a gas sensor, etc.), and a chemical sensor (eg, an electronic nose, a health care sensor, a biometric sensor, etc.). Meanwhile, the electronic device disclosed in this specification may combine and utilize information sensed by at least two or more of these sensors.

The output unit 150 is for generating an output related to sight, hearing, or touch, and includes at least one of a display unit 151, a sound output unit 152, a haptic module 153, and an optical output unit 154. can do. The display unit 151 may implement a touch screen by forming a mutual layer structure or integrally with the touch sensor. Such a touch screen may function as a user input unit 123 providing an input interface between the electronic device 100 and the user and provide an output interface between the electronic device 100 and the user.

The interface unit 160 serves as a passage for various types of external devices connected to the electronic device 100 . The interface unit 160 connects a device equipped with a wired/wireless headset port, an external charger port, a wired/wireless data port, a memory card port, and an identification module. It may include at least one of a port, an audio input/output (I/O) port, a video input/output (I/O) port, and an earphone port. In response to the external device being connected to the interface unit 160, the electronic device 100 may perform appropriate control related to the connected external device.

Also, the memory 170 stores data supporting various functions of the electronic device 100 . The memory 170 may store a plurality of application programs (application programs or applications) running in the electronic device 100 , data for operating the electronic device 100 , and commands. At least some of these application programs may be downloaded from an external server through wireless communication. In addition, at least some of these application programs may exist on the electronic device 100 from the time of shipment for basic functions of the electronic device 100 (eg, incoming and outgoing calls, outgoing functions, message receiving, and outgoing functions). Meanwhile, the application program may be stored in the memory 170, installed on the electronic device 100, and driven by the control unit 180 to perform an operation (or function) of the electronic device.

The controller 180 controls general operations of the electronic device 100 in addition to operations related to the application program. The control unit 180 may provide or process appropriate information or functions to the user by processing signals, data, information, etc. input or output through the components described above or by running an application program stored in the memory 170.

In addition, the controller 180 may control at least some of the components discussed in conjunction with FIG. 1 in order to drive an application program stored in the memory 170 . Furthermore, the controller 180 may combine and operate at least two or more of the components included in the electronic device 100 to drive the application program.

The power supply unit 190 receives external power and internal power under the control of the controller 180 and supplies power to each component included in the electronic device 100 . The power supply unit 190 includes a battery, and the battery may be a built-in battery or a replaceable battery.

At least some of the components may operate in cooperation with each other in order to implement an operation, control, or control method of an electronic device according to various embodiments described below. Also, the operation, control, or control method of the electronic device may be implemented on the electronic device by driving at least one application program stored in the memory 170 .

In this specification, the server (or cloud server) or client may include the electronic device 100, and the electronic device 100 may be collectively referred to as a terminal.

The terminal may communicate with an external server (or cloud server) or a client through a network connection.

2 is a diagram showing a server or client related to the present specification.

In this specification, a server (or cloud server) or a client may include a control unit 200 and a communication unit 230. The control unit 200 may include a processor 210 and a memory 220. The processor 210 may execute instructions stored in the memory 220 . The processor 210 may control the communication unit 230 . The memory 220 may include cache memory.

The processor 210 may control the operation of the server or client based on instructions stored in the memory 220 . A server or client may include one processor or may include a plurality of processors. When the server or the client includes a plurality of processors, at least some of the plurality of processors may be located at physically separated distances. In addition, the server or client may be implemented in various known ways without being limited thereto.

The communication unit 230 may include one or more modules enabling wireless communication between a server or client and a wireless communication system, between a server or client and another server or client, or between a server or client and an external server (terminal). there is. Also, the communication unit 210 may include one or more modules that connect a server or a client to one or more networks.

The controller 200 may control at least some of the components of the server or client in order to drive the application program stored in the memory 220 . Furthermore, the control unit 200 may combine and operate at least two or more of the components included in the server or client to drive the application program.

In this specification, the server may include a reversing engine or/and a CDR engine providing CDR services.

Reversing Engine

A reversing engine is an analysis/diagnostic engine that automates the reverse engineering (reversing) process for non-executable files. This is called reverse engineering, and through this, the server can learn about the principles and structure of software without source code by entering the assembly stage, which is a language that computers can execute. Using this, the server can know the structure of general software (for example, msoffice, pdf), malicious code behavior, and how to exploit vulnerabilities.

For example, the reversing engine may perform the following steps.

1. File analysis: As a step of analyzing the appearance of the non-executable file itself (eg, attribute, author, date of creation, file type), similar to general vaccine programs, maliciousness can be diagnosed only with the information of the non-executable file itself. can

2.Static analysis: This is a step of extracting and analyzing data in non-executable files to determine whether they are normal or malicious. Non-executable files are not executed, and internal data is extracted according to the file structure and analyzed for comparison to diagnose maliciousness. there is. This may be suitable for macros, URL extraction analysis, and the like.

3.Dynamic analysis: This is a step of analyzing behaviors while executing and monitoring non-executable files to determine whether they are malicious. It is easy to detect malicious behaviors using normal functions such as macros, hyperlinks, and DDE.

4. Debugging analysis: This is a step of analyzing vulnerabilities and exploits by executing and debugging non-executable files. Detecting vulnerabilities of applications using text, tables, fonts, pictures, etc. in documents, including macros, hyperlinks, and DDE suitable for doing

The reversing engine may include a debugging engine that may be used for debugging analysis. The debugging engine can diagnose vulnerabilities occurring in document input, processing, and output stages by using the debugging mode for the process of reading non-executable files. Vulnerability here refers to the use of errors and bugs that occur when an application program receives an unexpected value from the code (logic) developed by the application developer. Malicious document behavior such as remote code execution can be executed.

A debugging engine may include a debugger. A debugger is a tool for reverse engineering and can mean a program or process capable of breaking points in other target programs at the assembly level.

CDR engine (Contents Disarm and Reconstruction engine)

The CDR engine provides CDR services. The CDR service is a solution that disassembles non-executable files to remove malicious or unnecessary files, and creates new files by keeping the contents as identical as possible to the original.

In other words, CDR refers to a service that disarms and reconstructs contents in documents to create safe documents and provide them to customers. Here, the files to be harmless may be all non-executable files. Word files, Excel files, PowerPoint files, Hangul files, and PDF files may be exemplified as non-executable files. Content to be harmless may be active content. Examples of active content include macros, hyperlinks, and object linking and embedding (OLE).

3 is an example of an abnormal input that can be applied to this specification.

Referring to FIG. 3, when an application program receives an abnormal value (for example, when the input value exceeds the normal range of 2) through a non-executable file, the application program is changed into an execution flow unintended by the developer and is vulnerable. this can work. The debugging engine automatically debugs the document browsing process, sets a breakpoint at a specific point related to the vulnerability, checks a specific value related to the input value, determines whether the input value is a value that causes a vulnerability, and diagnoses whether the input value is malicious.

More specifically, the debugging engine can start debugging by identifying non-executable files and running an application to view them. When a module related to a document behavior is loaded while viewing a non-executable file, the debugging engine checks whether the module is an analysis target module, and if it is an analysis target, it can set a breakpoint at a designated address.

For example, a malicious non-executable file may have branching points at which an application program is terminated or branched into a flow in which no malicious activity occurs unless a specific condition such as an application version or an operating system environment is satisfied. The server can set a breakpoint at a divergence point that has been previously analyzed by an analyst and has this possibility.

In addition, the server may set conditions associated with a corresponding branching point to continuously execute the application program without terminating or lead to a flow in which a malicious action may occur.

If the process stops at the corresponding breakpoint while the process of the application program is running, the server may perform a step of detecting whether or not there is a vulnerability according to the detection logic and then storing the result in an analysis report.

The automated reversing engine included in the server can analyze and diagnose malicious non-executable files through a diagnosis algorithm researched and developed by an analyst by automatically performing and analyzing the above steps.

4 is an embodiment of a server to which this specification can be applied.

Referring to FIG. 4 , the server may include non-executable files and application programs (eg, MSOFFICE, Hancom Office, etc.) for executing non-executable files. For example, non-executable files may contain obfuscated JavaScript.

Obfuscation is a technique that consumes a lot of analysis resources by making executable code or script difficult to understand. For example, a rule to detect “cmd.exe /c calc”, a command that runs a calculator in Windows, can be configured to detect cmd and calc in a string. These detection rules cannot detect if the obfuscated command is “C^m^D^%2E^E^x^e^%20^/^c^%20^C^a^L^C” .

In order to solve this problem, in the present specification, the server may create an isolated virtual environment (Virtual Machine) for malicious code analysis and detect obfuscated JavaScript. For example, the virtual environment may include a Windows operating system.

The server executes the process of the application program related to the non-executable file in a debugging mode (S4010). For example, the server may execute a process for opening a non-executable file to be analyzed by an application program in a debugging mode (DEBUG_ONLY_THIS_PROCESS) using the CreateProcess API. Through this, the server can receive the debug event of the application program process.

In more detail, the server can execute the application process by passing the “DEBUG_ONLY_THIS_PROCESS” flag using the CreateProcess API.

The server detects JavaScript included in non-executable files based on the process of the application program (S4020). For example, a server can detect (obfuscated) JavaScript based on the application's process loaded into memory. In more detail, the server may detect JavaScript when the extension of the program executed by the application process is JS.

The server executes JavaScript and debugs a host process for executing JavaScript (S4030). For example, the server can debug the script execution host process, Wscript.exe, by executing a file with the extension JS. Wscript.exe is a process that serves as a JavaScript execution host so that JavaScript (eg, Javascript, VBScript, etc.) can be executed in the Windows operating system.

Based on the host process, the server determines whether a library for executing JavaScript is loaded (S4040). For example, the server can check whether Jscript.dll, the JavaScript execution engine, is loaded in the Wscript.exe process. In more detail, the server loads jscript.dll when JavaScript is executed through Wscript.exe, and Vbscript.dll is loaded when Vbscript is executed, through which each script engine is loaded and JavaScript can be executed.

Based on the fact that the library is loaded, the server sets a break point at the address of the function referenced to execute JavaScript (S4050). For example, the server can set a breakpoint at the address (offset) of the ScrFncObj::CALL function in Jscript.dll. To this end, the server may have an address of a function referenced to execute JavaScript.

The server extracts the original text of the JavaScript based on the execution of the breakpoint (S4060). For example, the server can generate deobfuscated JavaScript files with a defined data extraction policy (e.g., extract script text from memory pointed to by the EBX register (Extended Base Address Register)) when the host process passes the point of a breakpoint. The original text can be extracted. More specifically, based on the data extraction policy, the server secures the "original script size" at address EBX-1 (the address minus 4 from the EBX register), and obtains the "original script size" previously obtained at the memory address pointed to by the EBX register. ” can extract and save the original JavaScript.

The server performs a static check on the original text of JavaScript (S4070).

In the present specification, since the server performs static inspection on the extracted original text, the detection rate can be increased compared to the static inspection on the obfuscated JavaScript, and the detection rate can be increased by securing the original text before the dynamic inspection bypass technique is executed.

5 is an example of the original text of decrypted JavaScript to which this specification can be applied.

Referring to FIG. 5 , the server may decrypt the obfuscated JavaScript and extract the original text of the JavaScript.

For example, the offset of the breakpoint set by the server is 0x75C58276 (5020), which may be the execution point of the ScrFncObj::CALL function. To this end, the server may have an offset of a breakpoint previously analyzed by an analyst set. If Jscript.dll is loaded when starting debugging in the debugging engine, the server can call the set offset value and set a breakpoint. Also, since the address of the ScrFncObj::CALL function may vary depending on the version of Jscript.dll, it may be differently set and updated according to an analyst's prior analysis.

The server can check the “Original script size” (0xD716) stored in the EBX register address (5010) minus 4 (eg, 0x03F9004C - 4 = 0x03F90048 ). The server can extract the original text of JavaScript by extracting the amount of data from the memory pointed to by the EBX register (0x03F9004C (5010)) to obtain the original text of JavaScript, and save the original text of JavaScript as a file so that it can be used as a detection policy (for example, For example, the signature) can be compared to detect maliciousness.

The above specification can be implemented as computer readable code on a medium on which a program is recorded. A computer-readable medium includes all types of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable media include Hard Disk Drive (HDD), Solid State Disk (SSD), Silicon Disk Drive (SDD), ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. , and also includes those implemented in the form of a carrier wave (eg, transmission over the Internet). Accordingly, the above detailed description should not be construed as limiting in all respects and should be considered illustrative. The scope of this specification should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of this specification are included in the scope of this specification.

In addition, although services and embodiments have been described above, this is only an example and does not limit the present specification, and those skilled in the art to which this specification belongs will not deviate from the essential characteristics of the present service and embodiments. It will be appreciated that various modifications and applications not exemplified above are possible. For example, each component specifically shown in the embodiments can be modified and implemented. And differences related to these modifications and applications should be construed as being included in the scope of the present specification as defined in the appended claims.

Claims (9)

In the method for the server to detect JavaScript,
Executing a process of an application program associated with a non-executable file;
Detecting JavaScript included in the non-executable file based on the process of the application program;
Executing the JavaScript and debugging a host process for executing the JavaScript;
Based on the host process, determining whether a library for executing the JavaScript is loaded;
setting a break point at an address of a function referenced to execute the JavaScript based on the loading of the library in the host process; and
extracting the original text of the JavaScript based on the execution of the breakpoint and the data extraction policy set in the register;
Including,
The JavaScript is obfuscated JavaScript,
The break point is
It is set to the address of a function referenced to execute the JavaScript in the library,
The function referenced to execute the JavaScript is
A detection method, including the ScrFncObj::CALL function.
delete According to claim 1,
The host process
Detection method, including Wscript.exe.
delete According to claim 1,
The library
A detection method, including Jscript.dll.
delete delete According to claim 1,
performing a static check on the original text of the JavaScript;
Further comprising a, detection method.
In a server for detecting JavaScript,
communications department;
Memory; and
A processor functionally controlling the communication unit and the memory;
The processor
A host for executing a process of an application program related to a non-executable file, detecting JavaScript included in the non-executable file based on the process of the application program, executing the JavaScript, and executing the JavaScript Debugging a (host) process, determining whether or not a library for executing the JavaScript is loaded based on the host process, and based on the loading of the library in the host process, Set a breakpoint at the address of a function referenced to execute JavaScript, extract the original text of the JavaScript based on the execution of the breakpoint and the data extraction policy set in the register,
The JavaScript is obfuscated JavaScript,
The break point is
It is set to the address of a function referenced to execute the JavaScript in the library,
The function referenced to execute the JavaScript is
A server, containing the ScrFncObj::CALL function.

Images