JP2018525714A - Application simulation - Google Patents

Abstract

Certain embodiments described herein may be configured to identify an application, execute the application, record parameters for each function call of the application, and store the parameters recorded in the emulation table. Provide a device. The recorded parameters may include function calls, input parameters, and output parameters. The emulation table can be used to simulate the execution of an application without having to actually execute the application.

Description

[Cross-reference of related applications]
This application claims the benefit of and priority based on US patent application Ser. No. 14 / 752,911, filed Jun. 27, 2015, entitled “SIMULATION OF AN APPLICATION”, the entirety of which is incorporated herein by reference. Incorporated by reference.

  The present disclosure relates generally to the field of information security, and more specifically to application simulation.

  The field of network security is becoming increasingly important in modern society. The Internet allows interconnection of various computer networks around the world. In particular, the Internet provides a medium for exchanging data between various users connected to various computer networks via various types of client devices. While the use of the Internet has changed business and personal communications, it also allows malicious operators to gain unauthorized access to computers and computer networks, and the intentional or inadvertent disclosure of confidential information It is used as a means for

  Malicious software that infects a host computer (“malware”) can assist in theft of sensitive information from a company or individual associated with the host computer, propagation to other host computers, and / or distributed denial of service attacks It may be possible to perform any number of malicious operations, such as sending spam or malicious email from a host computer. Thus, important management issues remain to protect computers and computer networks from malicious and inadvertent exploitation by malicious software.

  In order to provide a more thorough understanding of the present disclosure and its features and benefits, reference is made to the following description, taken in conjunction with the accompanying figures. Like reference numbers represent like parts.

1 is a simplified block diagram of a communication system for application simulation according to an embodiment of the present disclosure. FIG.

1 is a simplified block diagram of a portion of a communication system for application simulation, according to one embodiment of the present disclosure. FIG.

1 is a simplified diagram of exemplary details of a communication system for simulation of an application, according to one embodiment of the present disclosure. FIG.

1 is a simplified diagram of exemplary details of a communication system for simulation of an application, according to one embodiment of the present disclosure. FIG.

6 is a simplified flowchart illustrating potential operations that may be associated with a communication system, according to one embodiment.

6 is a simplified flowchart illustrating potential operations that may be associated with a communication system, according to one embodiment.

1 is a block diagram illustrating an exemplary computing system arranged in a point-to-point configuration, according to one embodiment. FIG.

2 is a simplified block diagram associated with an exemplary ARM ecosystem system on chip (SOC) of the present disclosure. FIG.

FIG. 2 is a block diagram illustrating an example processor core, according to one embodiment.

  The figures in the drawings are not necessarily drawn to scale because their dimensions can be varied significantly without departing from the scope of the present disclosure.

Exemplary Embodiment
FIG. 1 is a simplified block diagram of a communication system 100 for application simulation, according to one embodiment of the present disclosure. The communication system 100 may include an electronic device 102, a cloud service 104, and a server 106. The electronic device 102 may include a processor 110, a memory 112, an operating system (OS) 114, and a security module 116. Security module 116 may include an emulation module 118. The emulation module may include an emulation table 120. Cloud service 104 and server 106 may each include a network security module 122, a training set 124, and a sandbox environment 126. The network security module 122 may include an emulation data assessor 146 and an emulation table 120. Electronic device 102, cloud service 104, and server 106 may each communicate using network 108.

  In an exemplary embodiment, communication system 100 may be configured to include a system that automatically models relevant simulation logic for a profiled operating environment using data mining and machine learning strategies. The communication system 100 identifies the application (eg, from the training set 124), executes the application, records the parameters for each function call of the application, and records the parameters recorded in the emulation table (eg, the emulation table 120). May be configured to store. The recorded parameters may include function calls, input parameters, and output parameters. In one example, the communication system 100 may evaluate the overall logging data and determine the most common combination of input to output parameter mapping for each system function. The communication system 100 can also exclude any parameters that do not affect the output of the called function. The emulation table may include a mapping table for each system function that can be interpreted at run time by the emulation module in the electronic device 102, and the emulation table may include a plurality of recorded parameters for a plurality of function calls.

  The elements of FIG. 1 may be coupled together through one or more interfaces that employ any suitable connection (wired or wireless), thereby providing a viable path for network (eg, network 108) communication. Furthermore, any one or more of these elements of FIG. 1 may be combined or removed from the architecture based on the needs of a particular configuration. The communication system 100 may include a configuration capable of transmission control protocol / Internet protocol (TCP / IP) communication for packet transmission or reception in a network. Communication system 100 may also operate in conjunction with User Datagram Protocol / IP (UDP / IP), or any other suitable protocol, as appropriate and based on specific needs.

  For purposes of illustrating certain exemplary techniques of communication system 100, it is important to understand communications that may be traversing the network environment. The following basic information may be considered as the basis by which this disclosure can be adequately explained.

  Some malware detection approaches rely heavily on the use of software emulation. That is, in order to determine whether a new software application contains potentially dangerous behavior, each malware scanner simulates the execution of the target file in a secure virtual emulation environment. The intent is to monitor both how the executed file affects the emulation environment, as well as what the post-emulation file will look like. For example, malicious Windows® executables are often run-time packed or obfuscated, and external obfuscated shells can be removed from the file only through emulation.

  In order to reasonably accurately simulate an environment such as a Windows OS or web browser, the system must simulate the system functions that the OS or browser exposes to software applications or script code. Currently this is done manually by malware researchers. For example, whenever any known malware makes a call to a particular system function, a researcher who develops detection of that malware family confirms that the emulation environment simulates that system function.

  This approach of manually authoring simulation of system functions is retroactive, error prone, and expensive. The only alternative known today is to license the original OS image and run the entire OS under emulation. This has a very clear limitation, first of all, its high performance cost. What is needed is a system and method that can be implemented as a manually authored simulation function, but at the same time generated by the use of data mining and machine learning.

  A communication system for application simulation as outlined in FIG. 1 can solve these problems (and others). The communication system 100 profiles a large training set of software applications in the original monitored real environment, tracks system calls that occur along with their input and output parameters, determines the most common combinations, It can be configured to calculate a generalized simulation model that can be used by the emulation component to simulate the execution of the application. The security module may analyze the simulated execution for signs of malicious behavior from the application. For example, a behavioral malware classification system using a Markov model of behavioral sequences can be used to analyze files related to malicious behavior.

  In one example, the communication system 100 may be executed securely on the original installation of the target operating environment, such as an application running Microsoft Windows® or Mozilla Firefox® browser, where the monitored application is A data mining environment can be included in which all system function calls made to the operating environment are recorded. The system allows the software application to run securely on the original installation of the target OS, such as a Microsoft Windows (registered trademark) or Mozilla Firefox (registered trademark) browser, and the monitored application or script is the OS or browser Enables a data mining environment where all system function calls made are recorded. For example, a monitored application or script may be recorded using kernel mode, user mode, browser DOM hook, and the like. The recorded data may include the name and library of the system function, the actual input parameters passed to the function, and the output parameters returned from the function.

  The machine learning component can then evaluate the recorded data and determine the most common combination of input to output parameter mapping for each system function. The system may also perform normalization to only those relevant parameters and generate a mapping table for each system function. Mapping tables can be sent to the emulation module, where at run time the emulation module interprets these mapping tables and checks if the list of table entries for input parameter conditions corresponds to the current simulation environment state. If so, an output operation encoded in the table entry may be performed. This process allows the application to be simulated without having to actually run the application.

  Further, the system can be configured to automatically determine general system calls and not wait for the actual malware sample to start with a particular call. Compared to O (m) for manually authored simulation logic, where m is the bytecode size, the performance characteristic for simulating a single system function is O (n), where n is the list size is there. In other words, assuming that both the list condition and the manual rule bytecode use an equivalent runtime interpreter, the use of machine learning generated system logic does not have an additional impact on performance. Although the initial one-time development cost for setting up the profiling back-end environment and supplying data mining output to the machine learning compiler is higher, once the process is established, the ongoing maintenance costs are relatively It does not take.

  Referring to the infrastructure of FIG. 1, a communication system 100 is shown according to an exemplary embodiment. In general, the communication system 100 may be implemented in a network of any kind or of any topology. Network 108 represents a series of points or nodes of interconnected communication paths for receiving and transmitting packets of information that propagate through communication system 100. The network 108 provides a communication interface between nodes, and can be any local area network (LAN), virtual local area network (VLAN), wide area network (WAN), wireless local area network (WLAN), metropolitan area network (MAN). ), Intranet, extranet, virtual private network (VPN), and any other suitable architecture or system that facilitates communication in a network environment, or any suitable combination thereof, wired and / or wireless communication Can be configured.

  In communication system 100, network traffic including packets, frames, signals, data, etc. may be transmitted and received according to any suitable communication messaging protocol. Suitable communication messaging protocols are the Open Systems Interconnection (OSI) model, or any derivative or variant thereof (eg, Transmission Control Protocol / Internet Protocol (TCP / IP), User Datagram Protocol / IP (UDP / IP)) may be included. Further, wireless signal communication over a cellular network may be provided in the communication system 100. Suitable interfaces and infrastructure may be provided to allow communication with the cellular network.

  As used herein, the term “packet” refers to a unit of data that can be routed between a source node and a destination node on a packet-switched network. The packet includes a source network address and a destination network address. These network addresses may be Internet Protocol (IP) addresses in the TCP / IP messaging protocol. As used herein, the term “data” refers to any type of binary, numeric, audio, video, text or script data that can be communicated from one point to another in an electronic device and / or network. Or any type of source code or object code, or any other suitable information in any suitable format. In addition, messages, requests, responses and queries are in the form of network traffic and can thus include packets, frames, signals, data, and the like.

  In an exemplary implementation, electronic device 102, cloud service 104, and server 106 are network elements, which are network appliances, servers, routers, switches, gateways, bridges, load balancers, processors, modules, or networks. It is intended to encompass any other suitable device, component, element or object operable to exchange environmental information. Network elements may receive, transmit and / or otherwise communicate data or information in any suitable hardware, software, component, module or object and network environment that facilitates their operation. A suitable interface may also be included. This may include appropriate algorithms and communication protocols that allow for effective exchange of data or information.

  With respect to the internal structure associated with communication system 100, each of electronic device 102, cloud service 104, and server 106 may include a memory element for storing information to be used in the operations outlined herein. . Each of electronic device 102, cloud service 104, and server 106 may be any suitable memory element (eg, random access memory (RAM), read only memory (ROM), erasable programmable ROM (EPROM), electrically erasable). Programmable ROM (EEPROM), application specific integrated circuit (ASIC), etc.), software, hardware, firmware, or any other suitable component, device, element or as appropriate and based on specific needs Information can be stored in the object. Any of the memory items described herein are to be interpreted as being encompassed within the broad term “memory element”. Further, information used, tracked, transmitted, or received in communication system 100 may be stored in any database, register, queue, table, cache, control list, or other storage structure. All of which can be referenced in any suitable time frame. Any such storage option may be included within the broad term “memory element” as used herein.

  In certain exemplary implementations, the functions outlined herein are logic encoded in one or more tangible media (eg, embedded logic provided in an ASIC, digital signal processor (DSP)) Instructions, software executed by a processor (potentially including object code and source code), or other similar machines, etc., which may include non-transitory computer-readable media. In some of these examples, the memory element can store data used in the operations described herein. This includes memory elements that can store software, logic, code, or processor instructions that are executed to perform the activities described herein.

  In an exemplary implementation, network elements of communication system 100, such as electronic device 102, cloud service 104, and server 106, may implement software modules (e.g., to implement or facilitate operations outlined herein) (e.g. Security module 116, emulation module 118, network security module 122, and emulation data assessor 146). These modules may be suitably combined in any suitable manner that may be based on specific configurations and / or provisioning needs. In exemplary embodiments, such operations may be performed by hardware implemented outside of these elements, or in hardware included within some other network device to achieve the intended functionality. Can be executed by Further, the modules may be implemented as software, hardware, firmware, or any suitable combination thereof. These elements may also include software (or reciprocating software) that can collaborate with other network elements to implement operations as outlined herein.

  Further, each of electronic device 102, cloud service 104, and server 106 may include a processor capable of executing software or algorithms for performing activities as described herein. The processor may execute any type of instruction associated with the data to implement the operations detailed herein. In one example, the processor can convert an element or thing (eg, data) from one state or thing to another state or thing. In another example, the activities outlined herein may be implemented in fixed logic or programmable logic (eg, software / computer instructions executed by a processor). The elements identified herein may be any type of programmable processor, programmable digital logic (eg, field programmable gate array (FPGA), EPROM, EEPROM), or digital logic, software, code, electronic instructions, or any of them An ASIC containing a suitable combination of Any of the potential processing elements, modules, and machines described herein are to be interpreted as encompassed within the broad term “processor”.

  The electronic device 102 may be a network element and includes, for example, a desktop computer, laptop computer, mobile device, personal digital assistant, smartphone, tablet, or other similar device. The cloud service 104 is configured to provide a cloud service to the electronic device 102. A cloud service can generally be defined as using computing resources provided as a service over a network such as the Internet. Typically, compute, storage, and network resources are provided in the cloud infrastructure, effectively shifting the workload from the local network to the cloud network. Server 106 may be a network element such as a server or a virtual server, and is a client, customer, endpoint or end point that wishes to initiate communication in communication system 100 over some network (eg, network 108). It may be associated with a user. The term “server” includes devices that are used to fulfill client requests and / or perform some computational tasks within the communication system 100 on behalf of a client. Although the security module 116 is depicted in FIG. 1 as being located on the electronic device 102, this is for illustrative purposes only. The security modules 116 can be combined or separated in any suitable configuration. Further, the security module 116 may be integrated with or distributed within another network that is accessible by the electronic device 102, such as the cloud service 104 or the server 106.

  Referring to FIG. 2, FIG. 2 is a simplified block diagram of a portion of a communication system 100 for application simulation, according to one embodiment of the present disclosure. The cloud service 104 (or server 106 or some other network element) may include a network security module 122, a training set 124, and a sandbox environment 126. The network security module 122 may include an emulation data assessor 146 and an emulation table 120. The emulation data assessor 146 may include a profiling module 128, a data mining module 130, a normalization and generalization module 132, and a conversion module 134.

  The training set 124 may include one or more applications that can be safely executed in the sandbox environment 126. The sandbox environment 126 may include an original installation of the target operating environment, such as a browser such as Microsoft Windows®, Mozilla Firefox®, or some other environment in which the application can operate. System function calls made by the monitored application in the sandbox environment 126 are recorded.

  Profiling module 128 may be configured to record data regarding each monitored call. The recorded data includes the name and library of the system function, the actual parameters passed to the system function (eg, the top of the stack), referred to as input parameters, and the function (eg, EAX) referred to as output parameters. Parameter) returned from the register. The data mining module 130 can be configured to evaluate the overall logging data and determine the most common combination of input to output parameter mapping for each system function. The normalization and generalization module 132 may be configured to exclude any parameters that do not clearly affect the output of the monitored function and break down only those parameters that are relevant. The conversion module 134 may be configured to convert the data from the normalization and generalization module 132 into data that may be included in the emulation table 120. The data in the emulation table 120 may include a mapping table for each system function that can be interpreted at runtime by the emulation module 118 in the electronic device 102, and given a respective set of input parameters, the system returns under simulation of the application. Enables quick retrieval of output parameters to be performed.

  Referring to FIG. 3, FIG. 3 is a simplified diagram of a portion of a communication system 100 for application simulation, according to one embodiment of the present disclosure. FIG. 3 illustrates a specific example of execution of a portion of an application in the sandbox environment 126. In the sandbox environment 126, the code 148 can be obtained from an application in the training set 124. Code may be executed within the sandbox environment 126 and may be allowed to execute. If the code is a function call, then the call is hooked and the arguments are recorded. For example, arguments from function calls in the system stack 150 can be determined and recorded. The data recorded for each function call may include the name and library of the system function, the actual parameters passed to the system function (eg, input parameters), and the parameters returned from the function (eg, output parameters). The recorded data can then be processed (eg, by data mining module 130, normalization and generalization module 132, and transformation module 134) and used to populate emulation table 120.

  Referring to FIG. 4, FIG. 4 is a simplified diagram of a portion of a communication system for application simulation, according to one embodiment of the present disclosure. The emulation table 120 may include a library column 136, a function column 138, an input parameter condition column 140, and an output parameter operation column 142.

  At runtime, the emulation module 118 accesses the emulation table 120 and checks whether the list of table entries for input parameter conditions corresponds to the current simulation environment setting, and if so, encodes within that table entry. Output operations may be performed. Input parameters may include variables, calls, system configurations, operating systems, file configurations, data structures, etc. The current simulation environment is the environment that the application will execute if the application is allowed to execute or execute. For proper simulation of application execution, the list of input parameter table entries should correspond to the environment that the application will execute if the application is allowed to execute or execute. For example, as illustrated in FIG. If the input parameter for the function “GetSomeHandleA” in dll is 8, then the output parameter or action is to write “22” to the stack [0] pointer and set EAX to 1 . mylib32. If the input parameter for the function “GetSomeHandleA” in dll is 32, then the output parameter or action is to write “0” to the stack [0] pointer and set EAX to 0. This simulates the emulation module 118 executing the application without having to actually execute the application, and data mining and automatic modeling of the associated simulation logic for the profiled operating environment. Allows the use of machine learning strategies.

  Referring to FIG. 5, FIG. 5 is an exemplary flowchart illustrating possible operations of a flow 500 that may be associated with simulation of an application, according to one embodiment. In one embodiment, one or more operations of flow 500 may be performed by emulation data assessor 146 and network security module 122. At 502, an application is received (or identified) by the system. For example, the application may be received from training set 124. Training set 124 may include a large batch of applications or processes, and the system may receive a randomly selected application from training set 124, a known malware sample from training set 124, or an administrator May select the application to be received. At 504, the application is allowed to run in a sandbox environment. For example, the application may be allowed to run in the sandbox environment 126. At 506, for each function call, parameters for the function call are determined and recorded. At 508, each function call and function call parameters are stored in an emulation table.

  Referring to FIG. 6, FIG. 6 is an exemplary flowchart illustrating possible operations of a flow 600 that may be associated with a simulation of an application, according to one embodiment. In one embodiment, one or more operations of flow 600 may be performed by emulation module 118. At 602, an application is received (or identified) by the system. For example, the application may be received from training set 124. At 604, an application simulation is performed using the emulation table. At 606, the simulated execution of the application is analyzed for the presence of malicious activity.

  FIG. 7 illustrates a computing system 700 deployed in a point-to-point (PtP) configuration, according to one embodiment. In particular, FIG. 7 shows a system where processors, memory, and input / output devices are interconnected by multiple point-to-point interfaces. In general, one or more of the network elements of communication system 100 may be configured in the same or similar manner as computing system 700.

  As illustrated in FIG. 7, the system 700 may include a number of processors, of which only two of the processors 770 and 780 are shown for clarity. While two processors 770 and 780 are shown, it should be understood that one embodiment of system 700 may include only one such processor. Each of the processors 770 and 780 may include a set of cores (ie, processor cores 774A and 774B, and processor cores 784A and 784B) for executing multiple threads of the program. The core may be configured to execute instruction code in a manner similar to that described above with reference to FIGS. Each processor 770, 780 may include at least one shared cache 771, 781. Shared cache 771, 781 may store data (eg, instructions) utilized by one or more components of processors 770, 780, such as processor cores 774 and 784.

  Processors 770 and 780 may include integrated memory controller logic (MC) 772 and 782 for communicating with memory elements 732 and 734, respectively. Memory elements 732 and / or 734 may store various data used by processors 770 and 780. In an alternative embodiment, the memory controller logic 772 and 782 may be discrete logic separate from the processors 770 and 780.

  Processors 770 and 780 may be any type of processor and may exchange data via point-to-point interface 750 using point-to-point (PtP) interface circuits 778 and 788, respectively. Processors 770 and 780 may exchange data with chipset 790 via individual point-to-point interfaces 752 and 754, respectively, using point-to-point interface circuits 776, 786, 794 and 798. Chipset 790 may exchange data with high performance graphics circuit 738 via high performance graphics interface 739 using interface circuit 792 which may be a PtP interface circuit. In an alternative embodiment, any or all of the PtP links illustrated in FIG. 7 may be implemented as a multidrop bus rather than a PtP link.

  Chipset 790 may communicate with bus 720 via interface circuit 796. Bus 720 may include one or more devices that communicate with it, such as bus bridge 718 and I / O device 716. Via the bus 710, the bus bridge 718 can communicate through a keyboard / mouse 712 (or other input device such as a touch screen, trackball, etc.), a modem, network interface device, or other computer network 760 It may communicate with other devices such as communication device 726 (such as a type of communication device), audio I / O device 714, and / or data storage device 728. Data storage device 728 may store code 730 that may be executed by processors 770 and / or 780. In alternative embodiments, any part of the bus architecture may be implemented with one or more PtP links.

  The computer system illustrated in FIG. 7 is a schematic diagram of one embodiment of a computing system that can be utilized to implement the various embodiments described herein. It will be appreciated that the various components of the system illustrated in FIG. 7 may be combined in a system on chip (SoC) architecture, or in any other suitable configuration. For example, the embodiments disclosed herein may be incorporated into systems that include mobile devices such as smart cellular phones, tablet computers, personal digital assistants, handheld game consoles, and the like. It will be appreciated that these mobile devices may be provided with a SoC architecture in at least some embodiments.

  Referring to FIG. 8, FIG. 8 is a simplified block diagram associated with an exemplary ARM ecosystem SOC 800 of the present disclosure. At least one exemplary implementation of the present disclosure may include the simulation features of the applications described herein, and the ARM component. For example, the example of FIG. 8 may be associated with any ARM core (eg, A-9, A-15, etc.). In addition, the architecture can be any type of tablet, smartphone (including Android (R) phones, iPhone (R)), iPad (R), Google Nexus (R), Microsoft Surface (R), personal It may be part of a computer, server, video processing component, laptop computer (including any kind of notebook), Ultrabook® system, any kind of touch input device, etc.

  In this example of FIG. 8, the ARM ecosystem SOC 800 includes a plurality of cores 806-807, an L2 cache control 808, a bus interface unit 809, an L2 cache 810, a graphics processing unit (GPU) 815, an interconnect 802, and a video codec 820. , And a liquid crystal display (LCD) I / F 825, which may be associated with a mobile industry processor interface (MIPI) / high resolution multimedia interface (HDMI) link that couples to the LCD.

  The ARM ecosystem SOC 800 includes a subscriber identification module (SIM) I / F 830, a boot read only memory (ROM) 835, a synchronous dynamic random access memory (SDRAM) controller 840, a flash controller 845, and a serial peripheral interface (SPI) master 850. Suitable power control 855, dynamic RAM (DRAM) 860, and Flash 865 may also be included. In addition, one or more exemplary embodiments may include one or more communication capabilities, interfaces and Bluetooth® 870, 3G modem 875, Global Positioning System (GPS) 880, and 802.11 Wi-Fi (registration). Trademark) 885 features.

  In operation, the example of FIG. 8 can provide processing power that enables various types of computing (eg, mobile computing, high-end digital homes, servers, wireless infrastructure, etc.) with relatively low power consumption. In addition, such an architecture can be used with any number of software applications (e.g., Android (R), Adobe (R) Flash (R) Player, Java (R) Platform Standard Edition (Java (R)). SE), Java® FX, Linux®, Microsoft Windows® Embedded, Symbian and Ubuntu, etc.). In at least one exemplary embodiment, the core processor may implement an out-of-order superscalar pipeline with a concatenated low latency level 2 cache.

  FIG. 9 illustrates a processor core 900 according to one embodiment. The processor core 900 may be a core for any type of processor, such as a microprocessor, embedded processor, digital signal processor (DSP), network processor, or other device that executes code. Although only one processor core 900 is illustrated in FIG. 9, the processor may alternatively include more than one of the processor cores 900 illustrated in FIG. For example, processor core 900 represents one exemplary embodiment of processor cores 774a, 774b, 784a, and 784b shown and described in connection with processors 770 and 780 of FIG. The processor core 900 may be a single thread core or, for at least one embodiment, the processor core 900 may include more than one hardware thread context (or “logical processor”) per core. In that respect, it may be a multi-threaded core.

  FIG. 9 also illustrates a memory 902 coupled to the processor core 900, according to one embodiment. Memory 902 may be any of a wide variety of memories (including various layers of the memory hierarchy) that are known or otherwise available to those skilled in the art. Memory 902 may include code 904 that may be one or more instructions to be executed by processor core 900. The processor core 900 may follow a program sequence of instructions indicated by code 904. Each instruction enters the front end logic 906 and is processed by one or more decoders 908. The decoder may generate as its output a micro-operation, such as a fixed-width micro-operation, in a predefined format, or other instruction, micro-instruction, or control signal that reflects the original code instruction. It's okay. Front end logic 906 also includes register renaming logic 910 and scheduling logic 912, which generally allocate resources and queue operations corresponding to instructions for execution.

  The processor core 900 may include execution logic 914 having a set of execution units 916-1 to 916-N. Some embodiments may include multiple execution units dedicated to a particular function or multiple function sets. Other embodiments may include only one execution unit, or may include one execution unit that can perform a particular function. Execution logic 914 performs the operation specified by the code instruction.

  After the execution of the operation specified by the code instruction is complete, the backend logic 918 can retire the code 904 instruction. In one embodiment, the processor core 900 allows out-of-order execution but requires in-order retirement of instructions. The retirement logic 920 may take various known forms (eg, a reorder buffer or the like). Thus, processor core 900 is at least in terms of outputs generated by decoders, hardware registers and tables utilized by register renaming logic 910, and any registers (not shown) modified by execution logic 914. Converted during execution of code 904.

  Although not illustrated in FIG. 9, the processor may include other elements on the chip along with the processor core 900, at least some of which are shown and described herein in connection with FIG. ing. For example, as shown in FIG. 7, the processor may include memory control logic along with the processor core 900. The processor may include I / O control logic and / or may include I / O control logic that is integrated with memory control logic.

  Note that for the examples provided herein, the interaction may be described with respect to two, three or more network elements. However, this is done for clarity and illustration purposes only. In certain cases, referring to only a limited number of network elements may make it easier to describe one or more of the functions of a given set of flows. It should be understood that the communication system 100 and its teachings are easily extensible and can accommodate numerous components, as well as more complex / high performance arrangements and configurations. Thus, the examples provided should be applied to a myriad of other architectures and should not limit the scope of the communication system 100 or prevent its extensive teaching.

  The operations in the flow diagrams described above (ie, FIGS. 5 and 6) illustrate only some of the possible correlation scenarios and patterns that may be performed by or are within the communication system 100. It is also important to note that Some of these operations may be deleted or removed where appropriate, or these operations may be modified or changed significantly without departing from the scope of the present disclosure. In addition, many of these operations are described as being performed concurrently or concurrently with one or more additional operations. However, the timing of these operations can be changed significantly. The flow of operation described above is provided for purposes of illustration and description. Great flexibility is provided by the communication system 100 in that any suitable arrangement, time series, configuration and timing mechanism may be provided without departing from the teachings of the present disclosure.

  Although the present disclosure has been described in detail with reference to particular arrangements and configurations, these exemplary configurations and arrangements can be significantly modified without departing from the scope of the present disclosure. Further, specific components may be combined, separated, eliminated, or added based on specific needs and implementations. Further, although the communication system 100 is illustrated with reference to certain elements and operations that facilitate the communication process, these elements and operations may be any suitable implementation that implements the intended functionality of the communication system 100. It may be replaced by architecture, protocol and / or process.

  Numerous other changes, alternatives, variations, modifications and modifications can be ascertained by those skilled in the art, and this disclosure is intended to embrace all such changes, alternatives, modifications, changes and modifications within the scope of the appended claims It is intended to be included as included. To assist the United States Patent and Trademark Office (USPTO), and to assist any reader of any patent issued under this application in interpreting the claims appended hereto, (A) Unless the word “means for” or “step for” is specifically used in a particular claim, it is present in the specification as of the filing date; Applicant does not intend to incorporate 35 USC 112, sixth paragraph in any of the appended claims, (b) by any statement in the specification, this disclosure is otherwise not attached It is desirable to note that applicants do not intend to be limited so that they are not reflected in the following claims.

[Other notes and examples]
Example C1, when executed by at least one processor, identifies an application, executes the application, records parameters for each function call of the application, and parameters recorded in the emulation table At least one machine-readable medium having one or more instructions that cause at least one machine-readable medium to execute.

  In Example C2, the subject of Example C1 may optionally include that the recorded parameters include function calls, input parameters, and output parameters.

  In Example C3, the subject matter of any one of Examples C1-C2 is that when the instruction is executed by at least one processor, the overall logging data is evaluated and the input-to-output parameter for each function call. Determining the most common combination of mappings may optionally include further causing at least one machine-readable medium to perform.

  In Example C4, any one subject of Examples C1-C3 is that the instruction excludes any parameter that does not affect the output of each function call when executed by at least one processor. Additional execution on a machine readable medium may optionally be included.

  In Example C5, the subject matter of any one of Examples C1-C4 may optionally include that the data in the emulation table includes a mapping table for each function call that can be interpreted at run time by the emulation module.

  In Example C6, the subject matter of any one of Examples C1-C5 may optionally include that the emulation table includes a plurality of recorded parameters for a plurality of function calls.

  In Example C7, the subject matter of any one of Examples C1-C6 is an optional instruction that causes at least one processor to further communicate the emulation table to the electronic device when executed by at least one processor. May be included.

  In Example C8, the subject matter of any one of Examples C1-C7 may optionally include the application running in a sandbox environment.

  In example A1, the device may include a network emulation module that identifies the application, executes the application, records the parameters for each function call of the application, and records the parameters recorded in the emulation table. Configured to store.

  In Example A2, the subject matter of Example A1 may optionally include that the recorded parameters include function calls, input parameters, and output parameters.

  In Example A3, the subject matter of any one of Examples A1-A2 is that the network emulation module further evaluates the overall logging data, and the most common combination of input to output parameter mapping for each function call. May optionally be configured to determine.

  In Example A4, the subject matter of any one of Examples A1-A3 may optionally further include the network emulation module further configured to exclude any parameters that do not affect the output of the function call.

  In Example A5, the subject matter of any one of Examples A1-A4 may optionally include that the data in the emulation table includes a mapping table for each function call that can be interpreted at run time by the emulation module.

  In Example A6, the subject matter of any one of Examples A1-A5 may optionally include that the emulation table includes a plurality of recorded parameters for a plurality of function calls.

  In Example A7, the subject matter of any one of Examples A1-A6 may optionally include the monitoring module further configured to communicate the emulation table to the electronic device.

  In Example A8, the subject matter of any one of Examples A1-A7 can optionally include the monitoring module being further configured to run the application in a sandbox environment.

  Example M1 is identifying an application on an electronic device and simulating the execution of the application using an emulation table, where the emulation table includes parameters for each function call of the application A method comprising:

  In example M2, the subject matter of example M1 may optionally include that the parameters include input parameters and output parameters.

  In Example M3, any one of the subjects of Examples M1-M2 may optionally include analyzing a simulation of application execution for the presence of malware.

  In Example M4, the subject matter of any one of Examples M1-M3 may optionally include that the data in the emulation table includes a mapping table for each function call that can be interpreted at run time by the emulation module.

  In Example M5, the subject matter of any one of Examples M1-M4 may optionally include that the emulation table was generated by the network element and communicated from the network element to the electronic device.

  In Example M6, the subject of any one of Examples M1-M5 is that the emulation table records the parameters for identifying the application, executing the application, and each function call of the application, It may optionally include what was generated by storing the parameters recorded in the table.

  In Example M7, the subject of any one of Examples M1-M6 is that the logging data is evaluated during the generation of the emulation table to determine the most common combination of input to output parameter mapping for each function call. It may optionally include what has been done.

  Example S1 is a system for application simulation that identifies an application, executes the application, records the parameters for each function call of the application, and stores the parameters recorded in the emulation table. A network emulation module configured to be included.

  In example S2, the subject of example S1 may optionally include that the recorded parameters include function calls, input parameters, and output parameters.

  Example X1 is a machine-readable storage medium that includes machine-readable instructions for implementing a method or implementing a device, as shown in any one of Examples A1-A8 or Examples M1-M7. Example Y1 is an apparatus that includes means for performing any of the exemplary methods M1-M7. In Example Y2, the subject of Example Y1 may optionally include means for performing a method including a processor and a memory. In Example Y3, the subject of Example Y2 may optionally include a memory that includes machine-readable instructions.

Claims (25)

Being executed by at least one processor,
Running an application with multiple function calls in a sandbox environment;
Recording parameters for each function call of the application;
One or more instructions that cause the at least one processor to store the recorded parameters in an emulation table for later use in a simulation environment to simulate the execution of at least one of the function calls. A program comprising:   The program according to claim 1, wherein the recorded parameters include a function call, an input parameter, and an output parameter. Being executed by the at least one processor,
One or more instructions further causing the at least one processor to further evaluate the overall logging data and determine a general combination of input to output parameter mapping for each function call. The program according to claim 1 or 2. Being executed by the at least one processor,
4. The method of claim 1, further comprising one or more instructions that cause the at least one processor to further remove at least one parameter that does not affect at least one output of the function call. The program described in the section.   The program according to any one of claims 1 to 4, wherein the data in the emulation table includes a mapping table for each function call that can be interpreted by the emulation module at the time of execution.   The program according to any one of claims 1 to 5, wherein the emulation table includes a plurality of recorded parameters for a plurality of function calls. Being executed by the at least one processor,
The program according to any one of claims 1 to 6, further comprising one or more instructions that cause the at least one processor to further execute communicating the emulation table to an electronic device.   The emulation table is used to simulate the execution of the first function call in the simulation environment without the need to execute the first function call, and the plurality of function calls include the first function call. The program according to any one of claims 1 to 7. Run an application containing multiple function calls in a sandbox environment
Record the parameters for each function call of the application,
A network emulation module that stores the recorded parameters in an emulation table for later use in a simulation environment to simulate the execution of at least one of the function calls.   The apparatus of claim 9, wherein the recorded parameters include function calls, input parameters, and output parameters. The network emulation module further includes:
11. An apparatus according to claim 9 or 10, wherein the overall logging data is evaluated to determine a general combination of input to output parameter mapping for each function call. The network emulation module further includes:
12. Apparatus according to any one of claims 9 to 11, wherein parameters that do not affect the output of each function call are excluded.   The apparatus according to any one of claims 9 to 12, wherein the data in the emulation table includes a mapping table for each function call that can be interpreted by the emulation module at the time of execution.   14. The apparatus according to any one of claims 9 to 13, wherein the emulation table includes a plurality of recorded parameters for a plurality of function calls. The network emulation module further includes:
15. The apparatus according to any one of claims 9 to 14, wherein the emulation table is transmitted to an electronic device.   The emulation table is used to simulate the execution of the first function call in the simulation environment without the need to execute the first function call, and the plurality of function calls include the first function call. The device according to any one of claims 9 to 15. Identifying the application on the electronic device;
Simulating the execution of the application using an emulation table, the simulation table comprising parameters for each function call of the application.   The method of claim 17, wherein the parameters include input parameters and output parameters.   19. A method according to claim 17 or 18, further comprising analyzing the simulation of the execution of the application for the presence of malware.   20. The method according to claim 18 or 19, wherein the data in the emulation table includes a mapping table for each function call that can be interpreted at execution time by the emulation module.   21. A method according to any one of claims 18 to 20, wherein the emulation table is generated by a network element and communicated from the network element to the electronic device. The emulation table is
Running the application in a sandbox environment;
Recording the parameters for each function call of the application;
22. A method according to any one of claims 18 to 21 generated by storing the recorded parameters in the emulation table.   23. A method according to any one of claims 18 to 22, wherein during the generation of the emulation table, logging data was evaluated to determine a general combination of input to output parameter mappings for each function call. the method of. A system for simulating an application, the system comprising:
Run your application in a sandbox environment
Record the parameters for each function call of the application,
Comprising a network emulation module for storing the recorded parameters in an emulation table for later use in a simulation environment to simulate the execution of at least one of the function calls without having to execute the function call.
system.   The system of claim 24, wherein the recorded parameters include function calls, input parameters, and output parameters.

Images