WO2014185165A1 - 情報処理装置、および、情報処理方法 - Google Patents

情報処理装置、および、情報処理方法 Download PDF

Info

Publication number
WO2014185165A1
WO2014185165A1 PCT/JP2014/058952 JP2014058952W WO2014185165A1 WO 2014185165 A1 WO2014185165 A1 WO 2014185165A1 JP 2014058952 W JP2014058952 W JP 2014058952W WO 2014185165 A1 WO2014185165 A1 WO 2014185165A1
Authority
WO
WIPO (PCT)
Prior art keywords
library function
log
information processing
data
program
Prior art date
Application number
PCT/JP2014/058952
Other languages
English (en)
French (fr)
Inventor
裕平 川古谷
誠 岩村
剛男 針生
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to EP14797772.2A priority Critical patent/EP2988242B1/en
Priority to CN201480028447.8A priority patent/CN105210077B/zh
Priority to US14/891,588 priority patent/US10129275B2/en
Priority to JP2015516986A priority patent/JP6023317B2/ja
Publication of WO2014185165A1 publication Critical patent/WO2014185165A1/ja

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425Traffic logging, e.g. anomaly detection
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55Detecting local intrusion or implementing counter-measures
    • G06F21/552Detecting local intrusion or implementing counter-measures involving long-term monitoring or reporting
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55Detecting local intrusion or implementing counter-measures
    • G06F21/56Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/566Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45545Guest-host, i.e. hypervisor is an application program itself, e.g. VirtualBox
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416Event detection, e.g. attack signature detection
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2101Auditing as a secondary aspect

Definitions

  • the present invention relates to an information processing apparatus and an information processing method.
  • the dynamic analysis includes a network behavior analysis type dynamic analysis that monitors a packet transmitted by malware to the outside (see Patent Document 1).
  • information such as communication destination, port number, protocol, and payload performed by malware can be acquired.
  • important information for understanding the behavior of malware may be observed in the payload portion. For example, if the machine name, user information, information on the contents of a confidential file, and the like are described as they are in the payload portion, it can be determined that the malware has a behavior of transmitting the confidential information of the infected terminal to the outside.
  • malware obfuscates the data and outputs it outside the analysis environment machine
  • the original meaning of the data is identified even if the output data is viewed I can't.
  • the analyst manually performs static analysis the contents of the data that is obfuscated can be grasped theoretically, but static analysts only require special skills. Instead, it takes a considerable amount of time for the analysis, resulting in high-cost work.
  • the present invention aims to solve the above-described problems and to specify the original information of the data by dynamic analysis even when the data is obfuscated by a program such as malware and output to the outside. .
  • the information processing apparatus of the present invention is an information processing apparatus that specifies a library function called to generate output data, and generates an analysis log of a program to be monitored.
  • Library function execution monitoring that captures a library function called by the monitored program and sets a tag for uniquely identifying the library function call in the output data from the library function for each call of the library function
  • a log search unit for specifying a library function called for generation.
  • the original information of the data can be specified by dynamic analysis.
  • FIG. 1 is a diagram illustrating the overall configuration of the information processing apparatus.
  • FIG. 2 is a diagram illustrating an outline of processing of the information processing apparatus.
  • FIG. 3 is a diagram illustrating a functional configuration of the virtual machine.
  • FIG. 4 is a diagram illustrating an example of information stored in the shadow memory.
  • FIG. 5 is a diagram illustrating an example of information stored in the shadow disk.
  • FIG. 6A is a diagram illustrating an example of a log when a taint tag is propagated between library functions.
  • FIG. 6B is a diagram illustrating an example of a log when a new taint tag is set for each library function.
  • FIG. 7 is a flowchart illustrating a procedure in which the virtual machine accumulates logs related to input and output to the library function.
  • FIG. 8 is a flowchart illustrating a procedure in which the log search unit of the host OS specifies the library function that generated the obfuscated data.
  • FIG. 9 is
  • FIG. 1 is a diagram illustrating the overall configuration of the information processing apparatus. As illustrated in FIG. 1, the information processing apparatus includes hardware 1, host OS 2, virtual machine software 3, and virtual machine 10.
  • the hardware 1 is an electronic circuit or a peripheral device constituting the information processing apparatus, and is, for example, a memory, a CPU (Central Processing Unit), or the like.
  • the host OS 2 is an OS serving as a base for operating the virtual machine, and is executed using the hardware 1.
  • the virtual machine software 3 is software that provides a virtual machine using the hardware 1, and operates the virtual machine 10 here. For example, the virtual machine software 3 allocates a virtual disk, virtual physical memory, virtual CPU, and the like to the guest OS to operate the virtual machine.
  • the virtual machine 10 is, for example, an emulator-type virtual machine, and is a virtual machine that executes various processes by operating a guest OS using a virtual disk, virtual physical memory, virtual CPU, or the like provided from the virtual machine software 3.
  • Information processing apparatus for example, an emulator-type virtual machine, and is a virtual machine that executes various processes by operating a guest OS using a virtual disk, virtual physical memory, virtual CPU, or the like provided from the virtual machine software 3.
  • FIG. 2 is a diagram illustrating an outline of processing of the information processing apparatus.
  • the information processing apparatus monitors a program (malware) to be analyzed for behavior in the virtual machine 10. Then, the information processing apparatus monitors the behavior of the program, and generates and outputs a log regarding the input and output of the library function called by the program.
  • a program malware
  • the information processing apparatus monitors the behavior of the program, and generates and outputs a log regarding the input and output of the library function called by the program.
  • the library function is a function that is called when the program is executed, such as an API (Application Programming Interface), a system call, or a local function.
  • This library function is included in the guest OS.
  • the library function is described as an example of Win32API, but is not limited to this.
  • the log generated by the information processing apparatus includes, for example, a library function (for example, library functions A, B, C,..., N), input data to the library function, output data from the library function, and the like. It is information to show.
  • the information processing apparatus sets a taint tag (tag) for uniquely identifying this library function call in the output data from the library function.
  • the information processing apparatus operates a program to be analyzed for behavior and performs taint analysis. That is, the information processing apparatus operates a program whose behavior is to be analyzed, and when data having a taint tag is passed as an operand to an instruction executed by the virtual CPU, the taint tag is added to the execution result data of the instruction. To propagate. As a result, the information processing apparatus also sets the taint tag set by the information processing apparatus to the input data to the library function called from the program.
  • the information processing apparatus operates a program to be analyzed for behavior for a predetermined period, generates and outputs logs related to input and output of library functions, and accumulates logs.
  • obfuscated data some obfuscated data (obfuscated data)
  • the library function for example, library function A
  • the user of the information processing apparatus can identify what type of information is the original information in generating the obfuscated data from the characteristics of the library function. .
  • the data output in the present embodiment is, for example, a case where data is output from a machine (virtual machine 10) operating a program to be analyzed to the outside via a network, a hard disk, a semiconductor memory, a DVD, a CD. -Including the case of outputting to the outside by writing to a recording medium such as a ROM.
  • FIG. 3 is a diagram showing a functional configuration of the virtual machine.
  • the virtual machine 10 includes a virtual physical memory 10a, a shadow memory 10b, a virtual disk 11a, a shadow disk 11b, a virtual CPU 12, and a virtual HW controller 18.
  • the virtual physical memory 10a is a virtual memory realized by allocating a predetermined area in the physical memory of the information processing apparatus as a memory used by the guest OS operating on the virtual machine 10.
  • the virtual physical memory 10a stores programs and data read from the virtual disk 11a by the virtual CPU 12.
  • the shadow memory 10b is a data structure that holds the value of the taint tag set for the value on the virtual physical memory 10a.
  • FIG. 4 is a diagram illustrating an example of information stored in the shadow memory.
  • the shadow memory 10 b stores “virtual physical memory address” and “taint tag” in association with each other.
  • the “virtual physical memory address” is position information indicating a storage position on the virtual physical memory 10a
  • the “taint tag” is an identifier set for data output as a result of executing each library function.
  • FIG. 4 shows that the taint tag “11” is assigned to the program code to be monitored stored in the addresses “0000 to 0200” of the virtual physical memory 10a. Further, it indicates that the taint tag “05” is given to the monitoring target data stored in the addresses “0310 to 0350” of the virtual physical memory 10a. Note that the numerical values shown in FIG. 4 are merely examples, and the values are not limited.
  • the virtual disk 11a is a virtual disk realized by allocating a predetermined area in the physical disk of the information processing apparatus as an area used by the guest OS operating on the virtual machine 10.
  • the virtual disk 11a stores a program to be executed by the virtual CPU 12, data to be processed by the program, and the like.
  • the virtual disk 11a includes a log storage unit 110 that stores a log related to the input and output of the library function in a predetermined area.
  • the shadow disk 11b is a data structure that holds the value of the taint tag set for the value on the virtual disk 11a.
  • FIG. 5 is a diagram illustrating an example of information stored in the shadow disk.
  • the shadow disk 11b stores “virtual disk address” and “taint tag” in association with each other.
  • the “virtual disk address” is position information indicating the storage position on the virtual disk 11a
  • the “taint tag” is an identifier for identifying the monitoring target.
  • the 2-bit information of the “taint tag” is “1”, it indicates that the data to be monitored is the code of the program.
  • the virtual CPU 12 in FIG. 3 is a virtual CPU realized by assigning a predetermined processing capability of a physical CPU included in the information processing apparatus as a CPU used by the guest OS operating in the virtual machine 10.
  • the virtual CPU 12 includes a shadow register that holds a taint tag held by the virtual CPU 12.
  • the virtual CPU 12 includes a program execution unit 13, a determination unit 14, a library function execution monitoring unit 15, and a taint analysis unit 17, and executes various processes using these.
  • the program execution unit 13 executes a program stored in the virtual disk 11a. For example, the program execution unit 13 reads out an execution target program from the virtual disk 11a, expands it in the virtual physical memory 10a, and executes it.
  • the determination unit 14 determines whether or not the executed program is a monitoring target.
  • Various known methods can be used as a method for determining whether or not the executed program is a monitoring target.
  • the name of a program to be monitored can be specified in advance, and it can be determined whether or not it is a monitoring target based on whether or not the program loaded in the virtual physical memory 10a matches the program specified in advance. Further, when the program is scanned and an instruction specified as a monitoring target is included, it can be determined as a monitoring target.
  • the virtual HW controller 18 controls data transmission / reception between the virtual disk 11a and the virtual physical memory 10a and between the shadow disk 11b and the shadow memory 10b.
  • the virtual HW controller 18 stores the program read from the virtual disk 11a by the program execution unit 13 in the virtual physical memory 10a.
  • the virtual HW controller 18 stores data read from the virtual physical memory 10a by a program or the like in the virtual disk 11a.
  • Such a virtual HW controller 18 includes a taint information propagation unit 18a that performs propagation of a taint tag.
  • the taint analysis unit 17 propagates the taint tag to the instruction execution result based on the taint tag propagation rule when the data in which the taint tag is set is passed to the instruction to be executed by the virtual CPU 12 (specifically, the program execution unit 13).
  • the virtual CPU 12 specifically, the program execution unit 13.
  • the taint information propagation unit 18a propagates the taint tag between the shadow disk 11b and the shadow memory 10b as data is read and written between the virtual disk 11a and the virtual physical memory 10a. For example, when the virtual HW controller 18 stores data read from the virtual physical memory 10a by the program to be monitored in the virtual disk 11a, a taint tag of the read data on the shadow memory 10b is associated with this. Store on the shadow disk 11b.
  • a rule for propagating the taint tag when a machine language instruction is executed in the virtual CPU 12, an arithmetic operation instruction with one or more operands, a logical operation instruction, a data movement instruction, or a data copy instruction is executed. When a value having a taint tag is passed to one of the operands, the taint tag is also set at a location where the instruction execution result is stored.
  • This rule varies depending on the implementation, but when the result of instruction execution depends on the read value, it is composed of basic rules such as propagating the taint tag. As for what is handled, an operation involving propagation of a taint tag is performed.
  • the library function execution monitoring unit 15 captures the execution of the library function called by the program to be monitored, generates a log related to input and output to the library function (hereinafter abbreviated as “log” as appropriate), and outputs it. Further, the library function execution monitoring unit 15 sets a taint tag for uniquely identifying a call to the library function in the output data from the library function when generating the log.
  • the execution of the library function is captured twice when the library function is called from the instruction of the program to be analyzed and when the library function is called and then returns to the program instruction.
  • a method using a process ID, a thread ID, a memory address range, or the like can be considered.
  • a method of directly rewriting the binary to place a hook or breakpoint, or a method of using a hardware breakpoint can be considered.
  • the return address can be grasped by looking at the return address stored in the stack and the return address stored in a specific register. . It is also possible to find the instruction that called the library function and to return the instruction next to the instruction. If the address to be restored can be grasped, the instruction for the address to be restored can be obtained by registering the address for the hook, breakpoint, and address comparison in the same manner as described above. Capture what has been done.
  • the library function execution monitoring unit 15 grasps the argument input to the library function based on the argument information of the library function, and is input as the argument to the library function. Data and a taint tag set in the data are acquired, and information in which these are associated is output as a log (program analysis log).
  • the argument information of the library function is acquired from, for example, the one describing the prototype declaration of the library function.
  • it is obtained from a library function source code, a header file provided in an SDK (software development kit), a library function document, or the like.
  • the library function execution monitoring unit 15 performs the following processing when the return to the program is captured after the library function is called. First, the library function execution monitoring unit 15 distinguishes arguments output from the library function based on the argument information of the called library function, and sets a taint tag for data output from the library function. Then, the library function execution monitoring unit 15 outputs information associating the output data with the taint tag set in the data as a log.
  • FIG. 6A is a diagram illustrating a log when a taint tag is propagated between library functions.
  • FIG. 6B is a diagram illustrating a log when a new taint tag is set for each library function.
  • the logs are arranged in chronological order and become newer as they go down.
  • the log includes information indicating whether the log is input to the called library function ([prev]) or output ([post]) and the function of the library function.
  • the name, information indicating whether the argument to the library function is input (IN) or output (OUT), the data of the argument, and the value of the taint tag set in the data are shown.
  • each log has time-series information indicating in what order the logs are called.
  • This log includes the library function name, the module name including the library function, the PID, TID, the caller address, the return address, the time information, and the address pointed to by the instruction pointer as accompanying information of the library function call. (EIP) may be included.
  • This log is referenced when the log search unit 16 specifies the library function that generated the obfuscated data.
  • An example of a procedure for the log search unit 16 to specify the library function that has generated the obfuscated data using the log illustrated in FIGS. 6A and 6B will be described later.
  • the host OS 2 includes a log search unit 16 and a log storage unit 110 outside the virtual machine 10.
  • the host OS 2 holds the log search unit 16 and the log storage unit 110 outside the virtual machine 10 because the log and the log search process are visible from the monitoring target program running in the virtual machine 10. This is to prevent this from happening.
  • the log search unit 16 refers to the taint tag set in the output data (obfuscated data) from the virtual machine 10 and the log accumulated in the log storage unit 110, and depends on data input / output between library functions. Following the relationship, the library function that generated the output data from the virtual machine 10 is specified. Details of the log search unit 16 will be described later.
  • the log storage unit 110 stores the log (see FIGS. 6A and 6B) output by the library function execution monitoring unit 15.
  • the log storage unit 110 associates the log output at the time of calling the library function with the log output at the time of return from the library function, the function name of the called library function, log time series information, each library It is assumed that this is performed based on information indicating the order in which functions are called. Further, the association here may use the relationship between the address at which the library function is called and the restored address, PID, TID, or the like.
  • FIG. 7 is a flowchart illustrating a procedure in which the virtual machine accumulates logs related to input and output to the library function.
  • the program execution unit 13 of the virtual machine 10 loads the execution target program from the virtual disk 11a to the virtual physical memory 10a (S11).
  • the determination unit 14 determines whether or not the loaded program is a program to be monitored (S12). In addition, the determination part 14 complete
  • the library function execution monitoring unit 15 determines whether or not the library function is called by the program. (S13).
  • the library function execution monitoring unit 15 determines that the library function has been called by the program (Yes in S13), the called library function, the data input as an argument to the library function, and the data And the information in which these are associated are output as a log to the log storage unit 110 (S14). On the other hand, when the library function execution monitoring unit 15 determines that the library function is not called (No in S13), the process returns to S13.
  • the library function execution monitoring unit 15 determines that the called library function has returned to the program (Yes in S15), it sets a taint tag in the data output from the library function (S16). That is, the library function execution monitoring unit 15 distinguishes arguments output from the library function based on the argument information of the called library function, and sets a taint tag for data output from the library function.
  • the library function execution monitoring unit 15 acquires the called library function, the data output from the library function, and the taint tag set in the data, and uses the information associating them as a log. And output to the log storage unit 110 (S17).
  • the library function execution monitoring unit 15 determines that the program execution by the program execution unit 13 has ended (Yes in S18), the library function execution monitoring unit 15 ends the processing. On the other hand, if the program has not ended yet (No in S18), the process returns to S13.
  • the virtual machine 10 captures the call of the library function by the program to be monitored, and accumulates logs relating to data input to the library function and data output from the library function.
  • FIG. 8 is a flowchart illustrating a procedure in which the log search unit of the host OS specifies the library function that generated the obfuscated data.
  • the log search unit 16 refers to the log accumulated in the log storage unit 110 and finds a library function that outputs the data to the outside of the virtual machine 10 (obfuscated data). (S21). For example, the log search unit 16 traces the log accumulated in the log storage unit 110 in the reverse direction of the time series based on the taint tag in which the obfuscated data that has been set is set, and obtains a library function that outputs the data. locate.
  • the log search unit 16 refers to the log accumulated in the log storage unit 110, and there is data passed (input) to the library function found in S21 (Yes in S22), and If a taint tag is set in the passed data (Yes in S23), the taint tag of the data is acquired (S24).
  • the log search unit 16 searches the log accumulated in the log storage unit 110, and specifies the library function that generated the data set with the taint tag acquired in S24 (S25). For example, the log search unit 16 sets the taint tag acquired in S24 from among the logs stored in the log storage unit 110 from the library function log temporally preceding the library function found in S21. Identify the library function that generated the data. And the log search part 16 performs the process after S22 with respect to the library function specified by S25.
  • the log search unit 16 refers to the log accumulated in the log storage unit 110 and there is no data passed (input) to the library function found in S21 (No in S22), or If no taint tag is set in the passed data (No in S23), the process proceeds to S26. And the log search part 16 specifies the said library function as a function which produced the obfuscation data (S26).
  • the information processing apparatus identifies the library function that generated the obfuscated data. If the library function can be identified, the user of the information processing apparatus can estimate the original information data of the obfuscated data from the characteristics of the library function.
  • the library function that generated the obfuscated data can be identified as a library function that reads the contents of a file, the file name, file path, owner information, attribute information attached to the file, etc. It is possible to estimate what kind of data the data (original information) read by the library function is.
  • a library function can be identified as a function that reads the contents of a registry, the registry key and subkey information of that registry, the process that created or registered the registry file and registry key, etc.
  • the type of original information can be estimated. By estimating the type of the original information in this way, the user of the information processing device can easily estimate what information is leaked to the outside due to the malware.
  • the specification is performed based on the log obtained by the dynamic analysis of the program. There is no cost. That is, the user of the information processing apparatus can estimate what kind of data the original information of the obfuscated data output to the outside is without costing. In addition, you may perform estimation of the data of above-described original information by the estimation part with which an information processing apparatus is provided.
  • the information processing apparatus may acquire information regarding the output destination (communication destination). For example, when it is estimated that the obfuscated data is information related to confidential information in the system, the data transmission destination may be labeled as the transmission destination of the information leakage data and monitored in the information processing apparatus. .
  • the log search unit 16 can specify that the library function that generated the data sent by send is GetComputerName, and the user of the virtual machine 10 estimates that the data sent by send is a computer name. can do.
  • the log search unit 16 specifies a library function using a log having a different taint tag value for each library function as shown in FIG. 6B, it is performed as follows.
  • the library function specified by the log search unit 16 may be a library function (for example, GetComputerName in FIGS. 6A and 6B) obtained by processing the original information of the obfuscated data, or until the obfuscated data is output. May be all library functions called (eg, GetComputerName, memcpy, send in FIGS. 6A and 6B). Further, the log search unit 16 obtains information (for example, send ⁇ memcpy ⁇ GetComputerName) indicating the dependency relationship between the library functions called until the obfuscated data is output, data used in each library function, and the like. You may make it output together. By doing in this way, it becomes easy for the user of the virtual machine 10 to estimate what kind of data the original information of the obfuscated data is.
  • a library function for example, GetComputerName in FIGS. 6A and 6B
  • the library function execution monitoring unit 15 may set a taint tag in the data when the taint tag is not set in the data output by the library function when returning from the library function in the program. Good. Then, the library function execution monitoring unit 15 may output the output data from the library function and the taint tag to the log storage unit 110 as a log.
  • the library function execution monitoring unit 15 when the taint tag is set in the output data from the called library function, the library function execution monitoring unit 15 outputs the tag set in the output data from the library function to the log when generating the log. On the other hand, when the taint tag is not set in the output data from the library function, the library function execution monitoring unit 15 sets a tag for uniquely identifying this library function call and outputs it to the log. .
  • the log search unit 16 can identify the library function that generated the original information of the obfuscated data by tracing the taint tag of the log.
  • the library function execution monitoring unit 15 has described the case where the execution is detected when returning from the library function to the analysis target program, and the taint tag is set in the output data from the library function, but the present invention is not limited to this.
  • the library function execution monitoring unit 15 may watch the operation of writing the instruction in the library function to the virtual physical memory 10a, and set the taint tag each time the writing occurs. That is, the library function execution monitoring unit 15 may set a taint tag for the output data from the library function in a lump when returning from the library function, and writing to the virtual physical memory 10a occurs in the library function. A taint tag may be set each time.
  • the virtual machine 10 may use a process type virtual machine that uses Binary Instrumentation to virtualize only a specific process, or is not a virtual machine monitor that operates as an application, but Xen or KVM (Kernel-based). Virtualization such as mounting a host OS and a virtual machine monitor in the same layer, such as Virtual Machine, may be used. Further, for virtualization implementation, HW (hardware) support such as Intel (registered trademark) -VT (Virtualization Technology) may be used.
  • the log search unit 16 may determine in advance which argument taint tag is used for searching based on the library function declaration and prototype information in the log search in S25 of FIG. In this way, the log search unit 16 can efficiently search for a log even when a plurality of arguments are given as input values (input data) to the library function. It is possible to improve the specific accuracy when specifying the function.
  • the search target argument may be specified for each library function, or it may be specified which input argument is to be traced according to the output argument of the library function.
  • all or part of the processes described as being automatically performed can also be performed manually.
  • all or any part of each processing function performed in each device may be realized by a CPU and a program analyzed and executed by the CPU, or may be realized as hardware by wired logic.
  • [program] It is also possible to create a monitoring program in which the processing executed by the information processing apparatus is described in a language that can be executed by a computer. In this case, when the computer executes the monitoring program, the same effect as in the above embodiment can be obtained. Further, the monitoring program may be recorded on a computer-readable recording medium, and the monitoring program recorded on the recording medium may be read by the computer and executed to execute the same processing as in the above embodiment.
  • FIG. 9 is a diagram illustrating a computer that executes a monitoring program.
  • the computer 1000 includes, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These units are connected by a bus 1080.
  • the memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012.
  • the ROM 1011 stores a boot program such as BIOS (Basic Input Output System).
  • BIOS Basic Input Output System
  • the hard disk drive interface 1030 is connected to the hard disk drive 1090.
  • the disk drive interface 1040 is connected to the disk drive 1100.
  • a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100, for example.
  • a mouse 1110 and a keyboard 1120 are connected to the serial port interface 1050.
  • a display 1130 is connected to the video adapter 1060.
  • the hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094.
  • the monitoring target program described in the above embodiment is stored in, for example, the hard disk drive 1090 or the memory 1010.
  • the monitoring program is stored in, for example, the hard disk drive 1090 as a program module in which a command executed by the computer 1000 is described.
  • a program module in which commands executed by the program execution unit 13, the determination unit 14, the library function execution monitoring unit 15, and the log search unit 16 are described is stored in the hard disk drive 1090.
  • data used for information processing by the monitoring program is stored as, for example, hard disk drive 1090 as program data.
  • the CPU 1020 reads out the program module and program data stored in the hard disk drive 1090 to the RAM 1012 as necessary, and executes each procedure described above.
  • program module and program data related to the monitoring program are not limited to being stored in the hard disk drive 1090, but are stored in, for example, a removable storage medium and read out by the CPU 1020 via the disk drive 1100 or the like. Also good. Alternatively, the program module and program data related to the monitoring program are stored in another computer connected via a network such as a LAN (Local Area Network) or a WAN (Wide Area Network), and are transmitted by the CPU 1020 via the network interface 1070. It may be read out.
  • a network such as a LAN (Local Area Network) or a WAN (Wide Area Network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Virology (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Debugging And Monitoring (AREA)

Abstract

 マルウェア(プログラム)の挙動を監視し、プログラムによるライブラリ関数の呼び出しごとに、呼び出されたライブラリ関数の識別情報、ライブラリ関数への入力データと、ライブラリ関数からの出力データ、および、出力データを一意に特定するためのテイントタグを対応付けて示したログを生成する。そして、情報処理装置からの出力データに設定されたテイントタグと、ログとを参照し、ライブラリ関数間で入出力されるデータの依存関係を辿り、情報処理装置からの出力データを生成したライブラリ関数を特定する。

Description

情報処理装置、および、情報処理方法
 本発明は、情報処理装置、および、情報処理方法に関する。
 マルウェア等の解析対象の実行ファイルの挙動を解析するために、その実行ファイルを解析環境において実際に動作させ、その挙動ログを取得する動的解析が利用される。動的解析には、マルウェアが外部へ送信するパケットを監視するネットワーク挙動解析型の動的解析がある(特許文献1参照)。
 これらネットワーク挙動解析型の動的解析では、マルウェアが行う通信先、ポート番号、プロトコル、ペイロードの情報等が取得できる。場合によっては、マルウェアの挙動を理解するための重要な情報がペイロード部分に観測されることもある。例えば、マシン名やユーザ情報、機密ファイルの中身の情報等がそのままペイロード部分に記載されていた場合、そのマルウェアが感染端末の機密情報を外部に送信する挙動を持っていると判断できる。
 しかしながら、近年のマルウェアの多くは、通信データに暗号化、圧縮等の難読化が施されている場合が多い。このような場合、ネットワーク挙動解析型の動的解析で観測できるパケットのペイロード部分からは、送信されているデータの内容を知ることができないので、マルウェアの挙動を理解できなくなってしまう。
 このような場合、マルウェアの実行ファイルを静的解析し、送信しているデータの内容を特定する方法がある。この方法は、解析者が手動でマルウェアの実行ファイルを逆アセンブルし、命令を読み解くことでマルウェアの挙動を把握する方法である。しかしながら、マルウェアの静的解析は非常にコストが高く、大量の実行ファイルを解析するのには向いていない。
特許第4755658号公報
 上記のように、マルウェアの動的解析において、マルウェアがデータを難読化し、解析環境マシンの外部に出力している場合、その出力されたデータを見ても、そのデータの本来の意味を特定することができない。また、一方で解析者が手動で静的解析すれば、理論的には難読化されているデータの内容を把握することはできるが、静的解析には解析者に特別なスキルが必要なだけではなく、解析にかなりの時間を要する等、コストの高い作業になってしまう。
 そこで、本発明は、前記した問題を解決し、マルウェア等のプログラムによりデータが難読化されて外部に出力される場合でも、そのデータの元情報を、動的解析で特定することを課題とする。
 前記した課題を解決するため、本発明の情報処理装置は、出力データを生成するために呼び出されたライブラリ関数を特定する情報処理装置であって、監視対象のプログラムの解析ログを生成する際、前記監視対象のプログラムが呼び出すライブラリ関数を捕捉し、前記ライブラリ関数の呼び出しごとに、前記ライブラリ関数の呼び出しを一意に識別するためのタグを、前記ライブラリ関数からの出力データに設定するライブラリ関数実行監視部と、前記ライブラリ関数からの出力データを含む解析ログを記憶するログ記憶部と、前記ログ記憶部に記憶された解析ログに設定されたタグをキーとして、当該情報処理装置からの出力データを生成するために呼び出されたライブラリ関数を特定するログ探索部とを備える。
 本発明によれば、マルウェア等のプログラムによりデータが難読化されて外部に出力される場合でも、そのデータの元情報を、動的解析で特定することができる。
図1は、情報処理装置の全体構成を示す図である。 図2は、情報処理装置の処理の概要を示す図である。 図3は、仮想マシンの機能構成を示す図である。 図4は、シャドウメモリに記憶される情報の例を示す図である。 図5は、シャドウディスクに記憶される情報の例を示す図である。 図6Aは、各ライブラリ関数間でテイントタグが伝搬される場合のログの例を示す図である。 図6Bは、ライブラリ関数ごとに新しいテイントタグを設定する場合のログの例を示す図である。 図7は、仮想マシンがライブラリ関数への入力および出力に関するログを蓄積する手順を示すフローチャートである。 図8は、ホストOSのログ探索部が、難読化データを生成したライブラリ関数を特定する手順を示すフローチャートである。 図9は、監視プログラムを実行するコンピュータを示す図である。
[第1の実施形態]
[全体構成]
 以下、本発明を実施するための形態(実施形態)について説明する。図1は、情報処理装置の全体構成を示す図である。図1に示すように、情報処理装置は、ハードウェア1、ホストOS2、仮想マシンソフトウェア3、仮想マシン10を有する。
 ハードウェア1は、情報処理装置を構成する電子回路や周辺機器であり、例えば、メモリ、CPU(Central Processing Unit)等である。ホストOS2は、仮想マシンを動作させる基盤となるOSであり、ハードウェア1を用いて実行される。仮想マシンソフトウェア3は、ハードウェア1を用いて仮想マシンを提供するソフトウェアであり、ここでは、仮想マシン10を動作させる。例えば、仮想マシンソフトウェア3は、仮想ディスク、仮想物理メモリ、仮想CPU等をゲストOSに割当てて、仮想マシンを動作させる。
 仮想マシン10は、例えば、エミュレータ型の仮想マシンであり、仮想マシンソフトウェア3から提供された仮想ディスク、仮想物理メモリ、仮想CPU等を用いてゲストOSを動作させて、各種処理を実行する仮想的な情報処理装置である。
 この情報処理装置の処理の概要を、図2を用いて説明する。図2は、情報処理装置の処理の概要を示す図である。情報処理装置は、仮想マシン10内で、挙動の解析対象となるプログラム(マルウェア)を監視する。そして、情報処理装置は、プログラムの挙動を監視し、このプログラムにより呼び出されるライブラリ関数の入力および出力に関するログを生成し、出力する。
 ライブラリ関数は、プログラムの実行にあたり呼び出される関数であり、例えば、API(Application Programming Interface)、システムコール、ローカル関数等である。このライブラリ関数は、ゲストOS内に含まれる。また、以下の説明において、ライブラリ関数は、Win32APIである場合を例に説明するが、これに限定されない。
 また、情報処理装置により生成されるログは、例えば、ライブラリ関数(例えば、ライブラリ関数A,B,C,…,N)、そのライブラリ関数への入力データ、そのライブラリ関数からの出力データ等、を示す情報である。ここで、情報処理装置は、ログ生成時、ライブラリ関数からの出力データに、このライブラリ関数の呼び出しを一意に識別するためのテイントタグ(タグ)を設定する。
 一方で、情報処理装置は、挙動の解析対象となるプログラムを動作させ、テイント解析を行う。すなわち、情報処理装置は、挙動の解析対象となるプログラムを動作させることにより、テイントタグが設定されたデータが仮想CPUで実行する命令にオペランドとして渡された場合、この命令の実行結果のデータにテイントタグを伝播させる。これにより、情報処理装置は、プログラムから呼び出されたライブラリ関数への入力データにも、情報処理装置により設定されたテイントタグが設定されることになる。
 このような解析環境下で、情報処理装置は、所定期間、挙動の解析対象となるプログラムを動作させ、ライブラリ関数の入力および出力に関するログの生成および出力を行い、ログを蓄積していく。
 その後、情報処理装置が、何らかの難読化されたデータ(難読化データ)を出力した場合、このデータに設定されたテイントタグと、前記したログに含まれるテイントタグとを参照することで、ライブラリ関数間で利用されているデータの依存関係を辿り、難読化データを生成したライブラリ関数(例えば、ライブラリ関数A)を特定する。このようにライブラリ関数が特定できれば、情報処理装置のユーザは、そのライブラリ関数の特性等から、難読化データの生成にあたり、どのような種類の情報が元情報となっているかを特定することができる。
 なお、本実施形態における、データの出力とは、例えば、解析対象のプログラムを動作させているマシン(仮想マシン10)からネットワークを介して外部へ出力する場合や、ハードディスク、半導体メモリ、DVD、CD-ROM等の記録媒体への書き込みにより外部へ出力する場合も含む。
[仮想マシンの構成]
 次に、図1に示した仮想マシンの構成を説明する。なお、ハードウェア1、ホストOS2、仮想マシンソフトウェア3については、一般的な構成と同様の構成を有するので、詳細な説明は省略する。なお、以下の説明において監視対象のプログラムは、予め仮想ディスク11aに格納され、テイントタグが設定されているものとする。
 図3は、仮想マシンの機能構成を示す図である。図3に示すように、仮想マシン10は、仮想物理メモリ10a、シャドウメモリ10b、仮想ディスク11a、シャドウディスク11b、仮想CPU12、仮想HWコントローラ18を有する。
 仮想物理メモリ10aは、情報処理装置が有する物理メモリにおける所定領域を仮想マシン10で動作するゲストOSが使用するメモリとして割り当てることで実現された仮想的なメモリである。例えば、仮想物理メモリ10aは、仮想CPU12によって仮想ディスク11aから読み出されたプログラムやデータを記憶する。
 シャドウメモリ10bは、仮想物理メモリ10a上の値に対して設定されたテイントタグの値を保持するデータ構造体である。
 ここで、シャドウメモリ10bの一例を説明する。図4は、シャドウメモリに記憶される情報の例を示す図である。図4に示すように、シャドウメモリ10bは、「仮想物理メモリのアドレス」と「テイントタグ」とを対応付けて記憶する。「仮想物理メモリのアドレス」は、仮想物理メモリ10a上の格納位置を示す位置情報であり、「テイントタグ」は、各ライブラリ関数の実行の結果出力されたデータに対して設定された識別子である。
 図4の場合、仮想物理メモリ10aのアドレス「0000~0200」に格納されている監視対象のプログラムコードに対して、テイントタグ「11」が付与されていることを示す。また、仮想物理メモリ10aのアドレス「0310~0350」に格納されている監視対象のデータに対して、テイントタグ「05」が付与されていることを示す。なお、図4に示した数値等は、あくまで例示であり、値等を限定するものではない。
 仮想ディスク11aは、情報処理装置が有する物理ディスクにおける所定領域を仮想マシン10で動作するゲストOSが使用する領域として割り当てることで実現された仮想的なディスクである。例えば、仮想ディスク11aは、仮想CPU12が実行対象とするプログラムや、プログラムの処理対象となるデータ等を記憶する。この仮想ディスク11aは、前記したライブラリ関数の入力および出力に関するログを記憶するログ記憶部110を所定領域に備える。
 シャドウディスク11bは、仮想ディスク11a上の値に対して設定されたテイントタグの値を保持するデータ構造体である。
 ここで、シャドウディスク11bの一例を説明する。図5は、シャドウディスクに記憶される情報の例を示す図である。図5に示すように、シャドウディスク11bは、「仮想ディスクのアドレス」と「テイントタグ」とを対応付けて記憶する。「仮想ディスクのアドレス」は、仮想ディスク11a上の格納位置を示す位置情報であり、「テイントタグ」は、監視対象であることを識別する識別子である。また、ここでは、「テイントタグ」の2ビット情報が「1」である場合には、監視対象のデータがプログラムのコードであることを示す。
 図3の仮想CPU12は、情報処理装置が有する物理CPUにおける所定処理能力を仮想マシン10で動作するゲストOSが使用するCPUとして割り当てることで実現された仮想的なCPUである。この仮想CPU12は、この仮想CPU12が保持しているテイントタグを保持するシャドウレジスタを備える。この仮想CPU12は、プログラム実行部13、判定部14、ライブラリ関数実行監視部15、および、テイント解析部17を有し、これらによって各種処理を実行する。
 プログラム実行部13は、仮想ディスク11aに記憶されるプログラムを実行する。例えば、プログラム実行部13は、仮想ディスク11aから、実行対象のプログラムを読み出して仮想物理メモリ10aに展開し、実行する。
 判定部14は、実行されたプログラムが監視対象か否かを判定する。実行されたプログラムが監視対象であるか否かを判定する手法は、公知の様々な手法を用いることができる。例えば、予め監視対象のプログラム名等を指定しておき、仮想物理メモリ10aに展開されたプログラムが予め指定したプログラムと一致するか否かによって、監視対象か否かを判定することもできる。また、プログラム内を走査し、監視対象として指定される命令を含んでいる場合に、監視対象と判定することもできる。
 仮想HWコントローラ18は、仮想ディスク11aと仮想物理メモリ10aとの間、シャドウディスク11bとシャドウメモリ10bとの間のデータ送受信を制御する。例えば、仮想HWコントローラ18は、プログラム実行部13が仮想ディスク11aから読み出したプログラムを仮想物理メモリ10aに格納する。また、仮想HWコントローラ18は、プログラム等によって仮想物理メモリ10aから読み出されたデータを仮想ディスク11aに格納する。このような仮想HWコントローラ18は、テイントタグの伝搬を実行するテイント情報伝搬部18aを有する。
 テイント解析部17は、テイントタグが設定されたデータが仮想CPU12(具体的にはプログラム実行部13)で実行する命令に渡された際、テイントタグの伝搬ルールに基づいてテイントタグを命令の実行結果に伝搬させる。プログラム実行部13で実行する命令にテイントタグが設定されたデータが渡されるとは、具体的には、命令のオペランドで渡された値がテイントタグを保持している場合である。
 テイント情報伝搬部18aは、仮想ディスク11aと仮想物理メモリ10aとの間でのデータの読み書きに伴い、シャドウディスク11bとシャドウメモリ10bとの間でテイントタグを伝搬させる。例えば、仮想HWコントローラ18が、監視対象のプログラムによって仮想物理メモリ10aから読み出されたデータを仮想ディスク11aに格納するとき、これに伴い、シャドウメモリ10b上の当該読み出されたデータのテイントタグをシャドウディスク11b上に格納する。
 なお、テイントタグを伝搬させるときのルールとしては、仮想CPU12において機械語命令が実行される際、1つ以上のオペランドを伴う算術演算命令、論理演算命令、データ移動命令、データコピー命令の実行の際に、オペランドの1つにテイントタグを持った値が渡された場合、その命令実行結果を保存する箇所にもテイントタグを設定する。このルールは実装により異なるが、命令実行の結果が、読み込まれた値に依存している場合、テイントタグを伝搬させるといった基本的なルールにより構成され、仮想CPU12の命令のうち何かしらの形でデータを扱うものに関してはテイントタグの伝搬を伴う動作が行われるものとする。
 ライブラリ関数実行監視部15は、監視対象のプログラムが呼び出すライブラリ関数の実行を捕捉し、このライブラリ関数への入力および出力に関するログ(以下、適宜「ログ」と略す)を生成し、出力する。また、ライブラリ関数実行監視部15は、ログの生成にあたりライブラリ関数からの出力データには、このライブラリ関数の呼び出しを一意に識別するためのテイントタグを設定する。なお、このライブラリ関数の実行の捕捉は、解析対象のプログラムの命令からライブラリ関数が呼ばれた時と、ライブラリ関数が呼ばれた後、プログラムの命令へ復帰する時の2回行われる。
 ここで、監視対象のプログラムにより実行されるライブラリ関数の実行を捕えるためには、次の点を考慮する必要がある。
(1)監視対象のプログラムをどのように判断するか。
(2)ライブラリ関数が実行されたということをどのように捕えるか。
(3)ライブラリ関数から監視対象のマルウェアのコードに復帰したということをどのように捕えるか。
(1)に関しては、プロセスID、スレッドID、メモリアドレスの範囲等を用いる方法等が考えられる。(2)に関してはバイナリを直接書き換えてフックやブレークポイントを配置する方法や、ハードウェアブレークポイントを利用する方法が考えられる。また、バイナリ変換を利用し、読み込んだ命令の仮想アドレスが予め把握しているライブラリ関数が配置されるべきアドレスと一致しているかを比較することで、ライブラリ関数の命令の実行を捕える方法等が考えられる。
 (3)に関しては、(2)でライブラリ関数の実行を捕えたときに、スタックに積まれているリターンアドレス、特定のレジスタに格納されているリターンアドレス、を見ることで復帰するアドレスが把握できる。また、ライブラリ関数を呼び出した命令を見つけ出し、その命令の次の命令を復帰するアドレスだとすることも可能である。復帰するアドレスが把握できた場合、そのアドレスに対して、上記で述べた手法と同様の方法で、フックやブレークポイント、アドレス比較のための登録を行うことで、その復帰されるアドレスの命令が実行されたことを捕える。
 ライブラリ関数実行監視部15は、監視対象のプログラムからライブラリ関数の実行を捕捉した場合、そのライブラリ関数の引数情報に基づいて、ライブラリ関数に入力される引数を把握し、ライブラリ関数に引数として入力されるデータと、そのデータに設定されているテイントタグとを取得し、これらを対応付けた情報をログ(プログラムの解析ログ)として出力する。
 なお、ライブラリ関数の引数情報は、例えば、そのライブラリ関数のプロトタイプ宣言が記載されているものから取得される。例えば、ライブラリ関数のソースコード、SDK(ソフトウエア開発キット)で提供されているヘッダファイル、ライブラリ関数のドキュメント等から取得される。
 また、ライブラリ関数実行監視部15は、ライブラリ関数が呼び出された後、プログラムへの復帰を捕捉したとき、以下の処理を行う。まず、ライブラリ関数実行監視部15は、呼び出されたライブラリ関数の引数情報に基づいて、ライブラリ関数から出力される引数を区別し、ライブラリ関数から出力されるデータに対し、テイントタグを設定する。そして、ライブラリ関数実行監視部15は、出力されるデータと、そのデータに設定したテイントタグとを対応付けた情報をログとして出力する。
[ログの例]
 ここで、図6Aおよび図6Bを用いて、ライブラリ関数実行監視部15が出力するログの例を説明する。図6Aは、各ライブラリ関数間でテイントタグが伝搬される場合のログを例示した図である。図6Bは、ライブラリ関数ごとに新しいテイントタグを設定する場合のログを例示した図である。なお、図6Aおよび図6Bにおいてログは、時系列順に並べられ、下に行くに従い新しいログとなっている。
 ログは、図6Aおよび図6Bに示すように、呼び出されたライブラリ関数への入力時に関するログ([prev])か出力時に関するログ([post])かを示す情報と、そのライブラリ関数の関数名と、そのライブラリ関数への引数が入力(IN)か出力(OUT)かを示す情報と、その引数のデータと、そのデータに設定されたテイントタグの値とが示される。なお、図6Aおよび図6Bにおいて図示を省略しているが、各ログはどのような順で呼び出されたかを示す時系列情報を持つ。
 なお、このログには、そのライブラリ関数の呼び出しの付随情報として、ライブラリ関数名、そのライブラリ関数を含むモジュール名、PID、TID、呼び出し元アドレス、リターンアドレス、時間情報、命令ポインタが指しているアドレス(EIP)等を含めてもよい。
 このログは、ログ探索部16が、難読化データを生成したライブラリ関数を特定する際に参照される。ログ探索部16が、図6Aおよび図6Bに例示したログを用い、難読化データを生成したライブラリ関数を特定する手順の例については、後記する。
 なお、図3に示すように、ホストOS2は、仮想マシン10外に、ログ探索部16およびログ記憶部110を備える。このように、ホストOS2が、ログ探索部16およびログ記憶部110を、仮想マシン10外に保持するのは、仮想マシン10内で動く監視対象のプログラムから、ログや、ログの探索処理が見えてしまうことを防止するためである。ログ探索部16は、仮想マシン10からの出力データ(難読化データ)に設定されたテイントタグと、ログ記憶部110に蓄積されたログとを参照し、ライブラリ関数間で入出力されるデータの依存関係を辿り、仮想マシン10からの出力データを生成したライブラリ関数を特定する。このログ探索部16の詳細は、後記する。
 ログ記憶部110は、ライブラリ関数実行監視部15により出力されたログ(図6Aおよび図6B参照)を記憶する。なお、ログ記憶部110における、ライブラリ関数の呼び出し時に出力したログと、ライブラリ関数からの復帰時に出力したログとの対応付けは、呼び出されたライブラリ関数の関数名、ログの時系列情報、各ライブラリ関数がどのような順で呼び出されたかを示す情報等により行われるものとする。また、ここでの対応付けは、ライブラリ関数を呼び出したアドレスと復帰したアドレスの関係性や、PID、TID等を用いてもよい。
[仮想マシンの処理手順]
[ログの蓄積手順]
 次に、図7を用いて仮想マシン10の処理手順を説明する。まず、仮想マシン10がライブラリ関数への入力および出力に関するログを蓄積する手順を説明する。図7は、仮想マシンがライブラリ関数への入力および出力に関するログを蓄積する手順を示すフローチャートである。
 仮想マシン10のプログラム実行部13は、実行対象のプログラムを仮想ディスク11aから仮想物理メモリ10aにロードする(S11)。
 そして、判定部14は、ロードされたプログラムが監視対象のプログラムか否かを判定する(S12)。なお、判定部14は、ロードされたプログラムが監視対象のプログラムではないと判定した場合(S12のNo)、処理を終了する。
 一方、判定部14は、ロードされたプログラムが監視対象のプログラムであると判定した場合(S12のYes)、ライブラリ関数実行監視部15は、そのプログラムによりライブラリ関数の呼び出しがあるか否かを判定する(S13)。
 そして、ライブラリ関数実行監視部15が、当該プログラムによりライブラリ関数の呼び出しがあったと判定したとき(S13のYes)、呼び出されたライブラリ関数と、そのライブラリ関数に引数として入力されるデータと、そのデータに設定されているテイントタグとを取得し、これらを対応付けた情報をログとして、ログ記憶部110へ出力する(S14)。一方、ライブラリ関数実行監視部15がライブラリ関数の呼び出しがないと判定したときは(S13のNo)、S13へ戻る。
 S14の後、ライブラリ関数実行監視部15は、呼び出されたライブラリ関数から当該プログラムへ復帰したと判定すると(S15のYes)、そのライブラリ関数から出力されるデータにテイントタグを設定する(S16)。つまり、ライブラリ関数実行監視部15は、呼び出されたライブラリ関数の引数情報に基づいて、そのライブラリ関数から出力される引数を区別し、ライブラリ関数から出力されるデータに対してテイントタグを設定する。
 S16の後、ライブラリ関数実行監視部15は、呼び出されたライブラリ関数と、そのライブラリ関数から出力されるデータと、そのデータに設定したテイントタグとを取得し、これらを対応付けた情報を、ログとして、ログ記憶部110へ出力する(S17)。
 そして、ライブラリ関数実行監視部15は、プログラム実行部13によるプログラムの実行が終了したと判定すると(S18のYes)、処理を終了する。一方、まだプログラムが終了していなければ(S18のNo)、S13へ戻る。
 このようにして、仮想マシン10は、監視対象のプログラムによりライブラリ関数の呼び出しを捕捉し、そのライブラリ関数へのデータ入力およびそのライブラリ関数からのデータ出力に関するログを蓄積する。
[ライブラリ関数の特定手順]
 次に、図8を用いて、ホストOS2のログ探索部16が、ログ記憶部110に蓄積されたログを探索し、難読化データを生成したライブラリ関数を特定する手順を説明する。図8は、ホストOSのログ探索部が、難読化データを生成したライブラリ関数を特定する手順を示すフローチャートである。
 まず、ログ探索部16は、ログ記憶部110に蓄積されたログを参照して、仮想マシン10の外部へ出力されたデータ(難読化データ)について、当該データを外部へ出力したライブラリ関数を見つける(S21)。例えば、ログ探索部16は、出力された難読化データを設定されたテイントタグを元に、ログ記憶部110に蓄積されたログを時系列の逆向きに辿って、当該データを出力したライブラリ関数を見つける。
 S21の後、ログ探索部16は、ログ記憶部110に蓄積されたログを参照して、S21で見つけたライブラリ関数に渡された(入力された)データが存在し(S22のYes)、かつ、渡されたデータにテイントタグが設定されていれば(S23のYes)、当該データのテイントタグを取得する(S24)。
 S24の後、ログ探索部16は、ログ記憶部110に蓄積されたログを探索し、S24で取得したテイントタグが設定されたデータを生成したライブラリ関数を特定する(S25)。例えば、ログ探索部16は、ログ記憶部110に蓄積されたログのうち、S21で見つけたライブラリ関数より時系的に前にあるライブラリ関数のログの中から、S24で取得したテイントタグが設定されたデータを生成したライブラリ関数を特定する。そして、ログ探索部16は、S25で特定したライブラリ関数に対し、S22以降の処理を実行する。
 一方、ログ探索部16は、ログ記憶部110に蓄積されたログを参照して、S21で見つけたライブラリ関数に渡された(入力された)データが存在しない場合(S22のNo)、または、渡されたデータにテイントタグが設定されていない場合(S23のNo)、S26へ進む。そして、ログ探索部16は、当該ライブラリ関数を、難読化データを生成した関数として特定する(S26)。
 このようにして、情報処理装置は、難読化データを生成したライブラリ関数を特定する。そして、ライブラリ関数が特定できれば、情報処理装置のユーザは、そのライブラリ関数の特性から、難読化データの元情報のデータを推定することができる。
 例えば、難読化データを生成したライブラリ関数が、あるファイルの中身を読み取るライブラリ関数であると特定できた場合、そのファイルのファイル名、ファイルパス、所有者情報、そのファイルにつけられた属性情報等から、そのライブラリ関数で読み取られたデータ(元情報)がどのような種類のデータかを推定することができる。他にも、例えば、ライブラリ関数が、レジストリの内容を読み取る関数であると特定できた場合、そのレジストリのレジストリキーやサブキーの情報、そのレジストリのファイルやレジストリキーを作成した、または登録したプロセスを特定することで、元情報の種類を推定することができる。このように元情報の種類を推定することで、情報処理装置のユーザは、マルウェアによりどのような情報が外部に漏洩したかを推定しやすくなる。
 また、このような情報処理装置によれば、難読化データを生成したライブラリ関数の特定を行う際、プログラムの動的解析にて得られるログを元に特定を行うので、静的解析のようなコストはかからない。つまり、情報処理装置のユーザは、大きなコストをかけることなく、外部に出力された難読化データの元情報がどのような種類のデータかを推定することができる。なお、前記した元情報のデータの推定は、情報処理装置の備える推定部により行ってもよい。
 なお、情報処理装置は、難読化データが外部に出力された際、その出力先(通信先)に関する情報を取得しておいてもよい。例えば、難読化データがシステム内の機密情報に関する情報であると推定される場合、情報処理装置において、そのデータの送信先を情報漏洩データの送信先としてラベル付けし、監視するようにしてもよい。
[ライブラリ関数の特定の例]
 ここで、ログ探索部16が、ログ記憶部110に蓄積されたログを用い、難読化データを生成したライブラリ関数を特定する手順の例について説明する。ここでは、図6Aに示したログを用いる場合を例に説明する。
 例えば、ログ探索部16は、図6Aに示すログのうち、send(…,引数2:IN:’yamada’:tag=0x1,…)を起点として、tag=0x1を生成したライブラリ関数を探すと、[post]GetComputerNameが見つかる。これにより、ログ探索部16は、sendで送られたデータを生成したライブラリ関数は、GetComputerNameであると特定でき、仮想マシン10のユーザは、sendで送られたデータは、コンピュータ名であると推測することができる。
 一方、ログ探索部16が、図6Bに示したような、ライブラリ関数ごとにテイントタグの値が異なるログを用いてライブラリ関数を特定する場合は以下のようにして行う。
 例えば、ログ探索部16は、図6Bに示すログのうち、send(…,引数2:IN:’yamada’:tag=0x2,…)を起点として、tag=0x2を生成したライブラリ関数を探すと、[post]memcpyが見つかる。次にログ探索部16は、[post]memcpy の入力時のログを見ると、[prev] memcpy,引数1:OUT, 引数2:IN:’yamada’:tag=0x1であるので、tag=0x1を生成したライブラリ関数を探すと、[post]GetComputerNameが見つかる。これにより、ログ探索部16は、sendで送られたデータを生成したライブラリ関数はGetComputerNameであると特定する。
 なお、ログ探索部16が特定するライブラリ関数は、難読化データの元情報を処理したライブラリ関数(例えば、図6Aおよび図6BにおけるGetComputerName)であってもよいし、その難読化データを出力するまでに呼び出されたライブラリ関数すべて(例えば、図6Aおよび図6BにおけるGetComputerName,memcpy,send)であってもよい。また、ログ探索部16は、その難読化データを出力するまでに呼び出されたライブラリ関数同士の依存関係を示す情報(例えば、send←memcpy←GetComputerName)や、各ライブラリ関数で用いられたデータ等を併せて出力するようにしてもよい。このようにすることで、仮想マシン10のユーザは、難読化データの元情報がどのようなデータであるかを推定しやすくなる。
[第2の実施形態]
 また、前記した実施形態においてライブラリ関数実行監視部15は、プログラムにおいてライブラリ関数からの復帰時に、このライブラリ関数が出力したデータにテイントタグが設定されていなかった場合、当該データにテイントタグを設定してもよい。そして、ライブラリ関数実行監視部15は、このライブラリ関数からの出力データと、テイントタグとをログとして、ログ記憶部110に出力するようにしてもよい。
 つまり、ライブラリ関数実行監視部15は、呼び出されたライブラリ関数からの出力データにテイントタグが設定されている場合、ログ生成にあたり、このライブラリ関数からの出力データに設定されるタグをログに出力する。一方、ライブラリ関数実行監視部15は、ライブラリ関数からの出力データにテイントタグが設定されていない場合、ログ生成にあたり、このライブラリ関数の呼び出しを一意に識別するためのタグを設定し、ログに出力する。
 このようにすることで、例えば、ライブラリ関数が、暗号化や難読化の処理を行う関数であった場合、このようなライブラリ関数による処理により、このライブラリ関数へ入力されたデータに設定されていたテイントタグが消滅してしまったときでも、次に処理を行うライブラリ関数への入力データにテイントタグを伝播させることができる。これにより、ログ探索部16は、ログのテイントタグを辿ることで、難読化データの元情報を生成したライブラリ関数を特定することができる。
[その他の実施形態]
 また、ライブラリ関数実行監視部15は、ライブラリ関数から解析対象のプログラムへ復帰する際にその実行を捉え、このライブラリ関数からの出力データにテイントタグを設定する場合について説明したがこれに限定されない。例えば、ライブラリ関数実行監視部15がライブラリ関数内の命令の仮想物理メモリ10aへの書き込みの動作を見張り、書き込みが発生するごとにテイントタグを設定してもよい。つまり、ライブラリ関数実行監視部15は、ライブラリ関数からの復帰時に一括して、ライブラリ関数からの出力データに対してテイントタグを設定してもよいし、ライブラリ関数内で仮想物理メモリ10aに対する書き込みが発生するごとにテイントタグを設定してもよい。
 なお、仮想マシン10は、Binary Instrumentationを利用し特定のプロセスのみを仮想化するプロセス型の仮想マシンを利用してもよいし、アプリケーションとして動作する仮想マシンモニタではなく、XenやKVM(Kernel-based Virtual Machine)のようにホストOSと仮想マシンモニタを同じ層に実装するような仮想化を利用してもよい。また、仮想化実装のため、Intel(登録商標)-VT(Virtualization Technology)のようなHW(ハードウェア)サポートを利用してもよい。
 また、ログ探索部16が、図8のS25におけるログの探索において、ライブラリ関数の宣言やプロトタイプ情報を元に、どの引数のテイントタグを用いて探索するかを予め決めておいてもよい。このようにすることで、ログ探索部16は、例えば、ライブラリ関数に複数の引数が入力値(入力データ)として与えられた場合でも、ログの探索を効率的に行うことができ、また、ライブラリ関数を特定する際の特定の精度を向上させることができる。なお、この探索対象の引数は、ライブラリ関数ごとに指定してもよいし、ライブラリ関数の出力引数に応じて、どの入力引数を辿るかを指定しておいてもよい。
 また、本実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともできる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
[プログラム]
 また、情報処理装置が実行する処理をコンピュータが実行可能な言語で記述した監視プログラムを作成することもできる。この場合、コンピュータが監視プログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかる監視プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録された監視プログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。以下に、図1等に示した情報処理装置と同様の機能を実現する監視プログラムを実行するコンピュータの一例を説明する。
 図9は、監視プログラムを実行するコンピュータを示す図である。図9に示すように、コンピュータ1000は、例えば、メモリ1010と、CPU1020と、ハードディスクドライブインタフェース1030と、ディスクドライブインタフェース1040と、シリアルポートインタフェース1050と、ビデオアダプタ1060と、ネットワークインタフェース1070とを有する。これらの各部は、バス1080によって接続される。
 メモリ1010は、ROM(Read Only Memory)1011およびRAM1012を含む。ROM1011は、例えば、BIOS(Basic Input Output System)等のブートプログラムを記憶する。ハードディスクドライブインタフェース1030は、ハードディスクドライブ1090に接続される。ディスクドライブインタフェース1040は、ディスクドライブ1100に接続される。ディスクドライブ1100には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース1050には、例えば、マウス1110およびキーボード1120が接続される。ビデオアダプタ1060には、例えば、ディスプレイ1130が接続される。
 ここで、図9に示すように、ハードディスクドライブ1090は、例えば、OS1091、アプリケーションプログラム1092、プログラムモジュール1093およびプログラムデータ1094を記憶する。上記実施形態で説明した監視対象のプログラムは、例えばハードディスクドライブ1090やメモリ1010に記憶される。
 また、監視プログラムは、例えば、コンピュータ1000によって実行される指令が記述されたプログラムモジュールとして、例えば、ハードディスクドライブ1090に記憶される。具体的には、プログラム実行部13、判定部14、ライブラリ関数実行監視部15およびログ探索部16によって実行される指令が記述されたプログラムモジュールが、ハードディスクドライブ1090に記憶される。
 また、監視プログラムによる情報処理に用いられるデータは、プログラムデータとして、例えば、ハードディスクドライブ1090に記憶される。そして、CPU1020が、ハードディスクドライブ1090に記憶されたプログラムモジュールやプログラムデータを必要に応じてRAM1012に読み出して、上述した各手順を実行する。
 なお、監視プログラムに係るプログラムモジュールやプログラムデータは、ハードディスクドライブ1090に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ1100等を介してCPU1020によって読み出されてもよい。あるいは、監視プログラムに係るプログラムモジュールやプログラムデータは、LAN(Local Area Network)やWAN(Wide Area Network)等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース1070を介してCPU1020によって読み出されてもよい。
 1   ハードウェア
 3   仮想マシンソフトウェア
 10  仮想マシン
 10a 仮想物理メモリ
 10b シャドウメモリ
 11a 仮想ディスク
 11b シャドウディスク
 12  仮想CPU
 13  プログラム実行部
 14  判定部
 15  ライブラリ関数実行監視部
 16  ログ探索部
 18  仮想HWコントローラ
 18a テイント情報伝搬部
 110 ログ記憶部

Claims (5)

  1.  出力データを生成するために呼び出されたライブラリ関数を特定する情報処理装置であって、
     監視対象のプログラムの解析ログを生成する際、前記監視対象のプログラムが呼び出すライブラリ関数を捕捉し、前記ライブラリ関数の呼び出しごとに、前記ライブラリ関数の呼び出しを一意に識別するためのタグを、前記ライブラリ関数からの出力データに設定するライブラリ関数実行監視部と、
     前記ライブラリ関数からの出力データを含む前記解析ログを記憶するログ記憶部と、
     前記ログ記憶部に記憶された解析ログに設定されたタグをキーとして、当該情報処理装置からの出力データを生成するために呼び出されたライブラリ関数を特定するログ探索部とを備えることを特徴とする情報処理装置。
  2.  前記監視対象のプログラムへの入力データは、前記入力データを一意に識別するためのタグが設定されており、
     前記情報処理装置は、さらに、
     前記プログラムによる実行結果のデータに、前記入力データに設定されたタグを伝播させるテイント情報伝搬部を備え、
     前記ライブラリ関数実行監視部は、さらに、
     前記ライブラリ関数からの出力データに前記タグが設定されている場合、前記監視対象のプログラムの解析ログを生成する際に、前記ライブラリ関数からの出力データに設定されるタグを、前記ライブラリ関数からの出力データのタグとして伝搬させ、
     前記ライブラリ関数からの出力データに前記タグが設定されていない場合、前記監視対象のプログラムの解析ログを生成する際に、前記ライブラリ関数の呼び出しを一意に識別するためのタグを、前記ライブラリ関数からの出力データに設定することを特徴とする請求項1に記載の情報処理装置。
  3.  前記情報処理装置は、さらに、
     前記特定したライブラリ関数の特性から、前記監視対象のプログラムへの入力データを推定する推定部を備えることを特徴とする請求項1または2に記載の情報処理装置。
  4.  前記ログ探索部は、
     前記ログ記憶部に記憶された解析ログに設定されたタグのうち、予め決定された引数のタグをキーとして、当該情報処理装置からの出力データを生成するために呼び出されたライブラリ関数を特定することを特徴とする請求項1または2に記載の情報処理装置。
  5.  コンピュータが、
     監視対象のプログラムの解析ログを生成する際、前記監視対象のプログラムが呼び出すライブラリ関数を捕捉し、前記ライブラリ関数の呼び出しごとに、前記ライブラリ関数の呼び出しを一意に識別するためのタグを、前記ライブラリ関数からの出力データに設定するライブラリ関数実行監視ステップと、
     前記ライブラリ関数からの出力データを含む前記解析ログに設定されたタグをキーとして、当該情報処理装置からの出力データを生成するために呼び出されたライブラリ関数を特定するログ探索ステップとを実行することを特徴とする情報処理方法。
PCT/JP2014/058952 2013-05-16 2014-03-27 情報処理装置、および、情報処理方法 WO2014185165A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP14797772.2A EP2988242B1 (en) 2013-05-16 2014-03-27 Information processing device, and information processing method
CN201480028447.8A CN105210077B (zh) 2013-05-16 2014-03-27 信息处理装置以及信息处理方法
US14/891,588 US10129275B2 (en) 2013-05-16 2014-03-27 Information processing system and information processing method
JP2015516986A JP6023317B2 (ja) 2013-05-16 2014-03-27 情報処理装置、および、情報処理方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2013-104481 2013-05-16
JP2013104481 2013-05-16

Publications (1)

Publication Number Publication Date
WO2014185165A1 true WO2014185165A1 (ja) 2014-11-20

Family

ID=51898149

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/058952 WO2014185165A1 (ja) 2013-05-16 2014-03-27 情報処理装置、および、情報処理方法

Country Status (5)

Country Link
US (1) US10129275B2 (ja)
EP (1) EP2988242B1 (ja)
JP (1) JP6023317B2 (ja)
CN (1) CN105210077B (ja)
WO (1) WO2014185165A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022195739A1 (ja) * 2021-03-16 2022-09-22 日本電信電話株式会社 活動痕跡抽出装置、活動痕跡抽出方法および活動痕跡抽出プログラム
WO2023067801A1 (ja) * 2021-10-22 2023-04-27 日本電気株式会社 データ処理装置、データ処理方法、および記録媒体

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014188780A1 (ja) * 2013-05-20 2014-11-27 日本電信電話株式会社 情報処理装置及び特定方法
JP6677677B2 (ja) * 2017-06-21 2020-04-08 株式会社東芝 情報処理装置、情報処理システム、情報処理方法およびプログラム
US11016874B2 (en) * 2018-09-19 2021-05-25 International Business Machines Corporation Updating taint tags based on runtime behavior profiles
JP6899972B2 (ja) * 2018-11-16 2021-07-07 三菱電機株式会社 情報処理装置、情報処理方法及び情報処理プログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010134325A1 (ja) * 2009-05-20 2010-11-25 日本電気株式会社 動的データフロー追跡方法、動的データフロー追跡プログラム、動的データフロー追跡装置
US20110145918A1 (en) * 2009-12-15 2011-06-16 Jaeyeon Jung Sensitive data tracking using dynamic taint analysis
JP4755658B2 (ja) 2008-01-30 2011-08-24 日本電信電話株式会社 解析システム、解析方法および解析プログラム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090328218A1 (en) 2006-08-28 2009-12-31 Mitsubishi Electric Corporation Data processing system, data processing method, and program
CN102054149B (zh) * 2009-11-06 2013-02-13 中国科学院研究生院 一种恶意代码行为特征提取方法
US8769516B2 (en) 2010-08-19 2014-07-01 International Business Machines Corporation Systems and methods for automated support for repairing input model errors
US8739280B2 (en) 2011-09-29 2014-05-27 Hewlett-Packard Development Company, L.P. Context-sensitive taint analysis
US9519781B2 (en) 2011-11-03 2016-12-13 Cyphort Inc. Systems and methods for virtualization and emulation assisted malware detection
CN102521543B (zh) * 2011-12-23 2014-03-26 中国人民解放军国防科学技术大学 一种基于动态污点分析进行消息语义解析的方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4755658B2 (ja) 2008-01-30 2011-08-24 日本電信電話株式会社 解析システム、解析方法および解析プログラム
WO2010134325A1 (ja) * 2009-05-20 2010-11-25 日本電気株式会社 動的データフロー追跡方法、動的データフロー追跡プログラム、動的データフロー追跡装置
US20110145918A1 (en) * 2009-12-15 2011-06-16 Jaeyeon Jung Sensitive data tracking using dynamic taint analysis

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CLEMENS KOLBITSCH ET AL.: "Effective and Efficient Malware Detection at the End Host", 18TH USENIX SECURITY SYMPOSIUM, August 2009 (2009-08-01), XP055216530, Retrieved from the Internet <URL:https://www.usenix.org/legacy/event/sec09/tech/full_papers/kolbitsch.pdf> [retrieved on 20140623] *
See also references of EP2988242A4

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022195739A1 (ja) * 2021-03-16 2022-09-22 日本電信電話株式会社 活動痕跡抽出装置、活動痕跡抽出方法および活動痕跡抽出プログラム
WO2023067801A1 (ja) * 2021-10-22 2023-04-27 日本電気株式会社 データ処理装置、データ処理方法、および記録媒体

Also Published As

Publication number Publication date
EP2988242B1 (en) 2019-02-27
CN105210077B (zh) 2018-04-13
EP2988242A1 (en) 2016-02-24
US20160088007A1 (en) 2016-03-24
JP6023317B2 (ja) 2016-11-09
JPWO2014185165A1 (ja) 2017-02-23
CN105210077A (zh) 2015-12-30
US10129275B2 (en) 2018-11-13
EP2988242A4 (en) 2016-11-23

Similar Documents

Publication Publication Date Title
JP6023317B2 (ja) 情報処理装置、および、情報処理方法
Yin et al. Temu: Binary code analysis via whole-system layered annotative execution
US8978141B2 (en) System and method for detecting malicious software using malware trigger scenarios
Xue et al. NDroid: Toward tracking information flows across multiple Android contexts
Henderson et al. Decaf: A platform-neutral whole-system dynamic binary analysis platform
US10102373B2 (en) Method and apparatus for capturing operation in a container-based virtualization system
JPWO2010134325A1 (ja) 動的データフロー追跡方法、動的データフロー追跡プログラム、動的データフロー追跡装置
JP6734481B2 (ja) コールスタック取得装置、コールスタック取得方法、および、コールスタック取得プログラム
JP2012079130A (ja) デバッグ支援プログラム、デバッグ支援装置、及びデバッグ支援方法
US10997055B2 (en) Methods, circuits, apparatus, systems and associated software modules for evaluating code behavior
US20180189167A1 (en) Methods, circuits, apparatus, systems and associated software modules for evaluating code behavior
TW201820198A (zh) 檢測系統及檢測方法
US11361077B2 (en) Kernel-based proactive engine for malware detection
CN113778838A (zh) 二进制程序动态污点分析方法及装置
JP5766650B2 (ja) 情報処理装置、監視方法および監視プログラム
US20220335135A1 (en) Vulnerability analysis and reporting for embedded systems
Chandramouli et al. Methodology for enabling forensic analysis using hypervisor vulnerabilities data
JP5952218B2 (ja) 情報処理装置および情報処理方法
Kargén et al. Inputtracer: A data-flow analysis tool for manual program comprehension of x86 binaries
Zhao et al. Automatic extraction of secrets from malware
JP5989599B2 (ja) 情報処理装置、および、情報処理方法
Wang et al. SWIFT: Decoupled System-Wide Information Flow Tracking and its Optimizations.
KR101225577B1 (ko) 어셈블리 언어 코드의 분석 장치 및 방법
KR101583306B1 (ko) 가상화 난독화 기법이 적용된 실행 파일의 분석 방법 및 분석 장치
JP2015114786A (ja) 情報処理システム及びプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14797772

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015516986

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 14891588

Country of ref document: US

Ref document number: 2014797772

Country of ref document: EP