I lllll llllllll II llllll lllll lllll lllll lllll lllll lllll lllll 111111111111111111111111111111111
`US 20050108562Al
`
`(19) United States
`(12) Patent Application Publication
`Khazan et al.
`
`(10) Pub. No.: US 2005/0108562 Al
`May 19, 2005
`(43) Pub. Date:
`
`(54) TECHNIQUE FOR DETECTING
`EXECUTABLE MALICIOUS CODE USING A
`COMBINATION OF STATIC AND DYNAMIC
`ANALYSES
`
`(76)
`
`Inventors: Roger I. Khazan, Somerville, MA
`(US); Jesse C. Rabek, Boston, MA
`(US); Scott M. Lewandowski, Reading,
`MA (US); Robert K. Cunningham,
`Lexington, MA (US)
`
`Correspondence Address:
`Patent Group
`Choate, Hall & Stewart
`Exchange Place
`53 State Street
`Boston, MA 02109-2804 (US)
`
`(21)
`
`Appl. No.:
`
`10/464,828
`
`(22)
`
`Filed:
`
`Jun. 18,2003
`
`Publication Classification
`
`(51)
`
`Int. Cl.7 ..................................................... G06F 11/30
`
`(52) U.S. Cl. .............................................................. 713/200
`
`(57)
`
`ABSTRACT
`
`Described are techniques used for automatic detection of
`malicious code by verifying that an application executes in
`accordance with a model defined using calls to a predeter(cid:173)
`mined set of targets, such as external routines. A model is
`constructed using a static analysis of a binary form of the
`application, and is comprised of a list of calls to targets, their
`invocation and target locations, and possibly other call(cid:173)
`related information. When the application is executed,
`dynamic analysis is used to intercept calls to targets and
`verify them against the model. The verification may involve
`comparing the invocation and target location, as well as
`other call-related information, available at the time of call
`interception to the corresponding information identified by
`static analysis. A failed verification determines that the
`application includes malicious code. As an option, once
`detected, the malicious code may be allowed to execute to
`gather information about its behavior.
`
`400~
`
`40
`
`A call to a target function being
`monitored is intercepted
`
`NO
`
`406
`
`Detect as malicious code
`and perform related processing
`
`YES
`
`NO
`
`YES
`
`41
`
`41
`
`Continue execution of
`the target function
`
`Perform post monitoring
`processing
`
`YES
`
`41
`
`Gather data about
`malicious code be ha vi or
`
`Return to
`application
`
`1
`
`SYMC 1010
`
`

`
`Patent Application Publication May 19, 2005 Sheet 1 of 13
`
`US 2005/0108562 Al
`
`7
`"' 0
`::r::
`
`..0
`.!.
`"'
`0
`::i:::
`
`-"' 0
`
`::i:::
`
`~
`;:!;
`
`(
`..0
`;:!;
`
`/
`
`r-
`00 -
`
`a
`~
`:>.
`(I)
`0)
`bO
`"' ...
`B
`~
`~
`
`(I)
`
`(
`N ,....
`
`0 -
`
`2
`
`SYMC 1010
`
`

`
`Patent Application Publication May 19, 2005 Sheet 2 of 13
`
`US 2005/0108562 Al
`
`N
`
`N ......
`
`3
`
`SYMC 1010
`
`

`
`Patent Application Publication May 19, 2005 Sheet 3 of 13
`
`US 2005/0108562 Al
`
`'\
`
`)
`
`o.l
`OJ) ""
`,_.
`8
`o.l
`CIJ
`u
`""-~
`....
`;>-
`o.l 0l
`o;J
`0 0 00
`
`(
`
`0
`0\
`
`0
`00
`,_.
`0
`"'
`"' o.l
`u
`0 ,_.
`11..
`
`~
`
`~
`o.l
`u
`·;;
`o.l
`0
`0
`\D
`;::::, 00
`
`,_.
`;>--.
`0
`s
`o.l "'i"
`~ 00
`
`4
`
`SYMC 1010
`
`

`
`100'\
`
`111\
`
`List of target functions
`whose invocations are to
`be identified by static
`analysis
`
`114\
`
`Libraries
`
`102\
`
`Application
`Executable
`
`112\
`
`List of target functions
`whose invocations are to
`be monitored by dynamic
`analysis
`
`Ill
`
`110 ~----------------------------
`
`10
`
`Static
`Analyzer
`
`Dynamic
`Analyzer
`
`FIGURE 4A
`
`(')
`
`~ .....
`
`""C
`~ .....
`~ = .....
`~ "Cl -....
`.... 0 =
`~
`O' -....
`.... 0 =
`
`(')
`
`~ .....
`
`List of target and
`invocation locations
`
`~
`~
`'-<
`'"""' ~~
`N
`8 Ul
`'Jl =(cid:173)~
`~ .....
`.i;;..
`0 .....,
`'"""' ~
`
`d
`'Jl
`N c c
`~ c
`'"""' c
`00
`Ul
`O'I
`N
`
`>
`'"""'
`
`5
`
`SYMC 1010
`
`

`
`120__,
`
`Obtain static analysis information.
`
`, ..
`
`..-
`
`Load application and associated libraries
`into memory but do not begin execution of
`the application instructions yet.
`
`(')
`
`~ .....
`
`""C
`~ .....
`~ = .....
`~ "Cl -....
`.... 0 =
`~
`O' -....
`.... 0 =
`
`(')
`
`~ .....
`
`H
`
`- Instrument the associated libraries as
`
`loaded into memory for execution.
`
`,,
`
`Execute the instrumented application and associated
`
`- ,..... libraries.
`
`FIGURE4B
`
`~
`~
`'-<
`'"""' ~~
`N
`8 Ul
`rF.J. =(cid:173)~
`~ .....
`Ul
`0 .....,
`'"""' ~
`
`d
`rF.J.
`N c c
`~ c
`'"""' c
`00
`Ul
`O'I
`N
`
`>
`'"""'
`
`6
`
`SYMC 1010
`
`

`
`Patent Application Publication May 19, 2005 Sheet 6 of 13
`
`US 2005/0108562 Al
`
`'--'
`
`<1)
`
`'--'
`
`----
`"' .....l
`.....l
`~ ~
`2
`"'
`"'
`"'
`;;.-.
`(/')
`1::
`E
`:::l
`.!:::
`"'
`i::
`
`0
`(.)
`0
`H
`0...
`0
`E
`"'
`
`;::l
`
`0 - ~
`
`,-_
`"O
`<1)
`"C)
`i::
`<1)
`
`CL "' ;::l
`
`(/')
`I
`<1)
`'c;l
`<1)
`H u
`·i::
`0
`'.;::l
`oO
`.S:l
`0.
`CL
`~
`';<"
`µ.i
`"' "' <1)
`
`(.)
`0
`H
`0...
`~ <1)
`.... u
`
`00
`0 ......
`
`tn
`
`~ ......
`
`~
`
`7
`
`SYMC 1010
`
`

`
`Patent Application Publication May 19, 2005 Sheet 7 of 13
`
`US 2005/0108562 Al
`
`.....1
`.....1
`Cl
`...
`Q)
`0..
`0..
`...
`'"
`:SC
`
`.....1
`.....1
`Cl
`r-i
`;;
`<:::
`ti
`.:.:
`
`('<)
`
`~
`x
`iii
`c:;
`.s
`'°'
`.~
`c..
`0..
`<t:
`
`~
`
`"'
`::i'
`.....1
`Cl
`...
`E
`0
`
`Q)
`
`8
`
`SYMC 1010
`
`

`
`Application.EXE (Source Function)
`
`kernel 32 DLL (Target Function)
`
`200\
`
`ADDRESS API_A
`
`LOC_A::
`
`CALL API_A
`
`<TARGET
`FUNCTION BODY>
`
`RET
`
`I* To Detours Post
`Processing *I
`
`210
`
`208
`
`rampoline Function
`
`<saved instructions from
`API_A>
`
`JUMP API_A + API_A_OFFSET
`
`Wrapper Function
`or Stub Function
`
`API_A_STUB:
`<VERIFY CALL - PRE
`MONITORING CODE>
`
`CALL API_A_TRAMPOLINE
`
`<POST MONITORING CODE>
`
`RETURN I* To source *I
`
`FIGURE 7
`
`(')
`
`~ .....
`
`""C
`~ .....
`~ = .....
`> "Cl
`"Cl -....
`.... 0 =
`""C = O' -....
`.... 0 =
`
`(')
`
`~ .....
`
`~
`~
`'-<
`'"""' ~~
`N c c
`
`Ul
`
`rF.J. =-~
`~ .....
`00
`0 .....,
`'"""' ~
`
`d
`rF.J.
`N c c
`Ul -c
`
`'"""' c
`00
`Ul
`O'I
`N
`
`>
`'"""'
`
`9
`
`SYMC 1010
`
`

`
`300,
`
`30
`
`Current target= first target
`
`YES
`
`-~3p6
`~
`
`308
`
`Save first instructions
`of current target in Trampoline
`save area for current target
`
`310
`
`Replace first instructions of current call
`nction to transfer control
`to stub for current call
`
`31
`
`Add instruction to current target's
`Trampoline to transfer control to
`current target +offset.
`
`31
`
`Current target= next target
`
`FIGURES
`
`(')
`
`~ .....
`
`""C
`~ .....
`~ = .....
`~ "Cl -....
`.... 0 =
`~
`O' -....
`.... 0 =
`
`(')
`
`~ .....
`
`~
`~
`'-<
`'"""' ~~
`N
`8 Ul
`rF.J. =(cid:173)~
`~ .....
`
`~
`0 .....,
`'"""' ~
`
`d
`rF.J.
`N c c
`~ c
`'"""' c
`00
`Ul
`O'I
`N
`
`>
`'"""'
`
`10
`
`SYMC 1010
`
`

`
`400\
`
`40
`
`A call to a target function being
`monitored is intercepted
`
`NO
`
`406
`
`YES
`
`YES
`
`YES
`
`the target function
`
`Perform post monitoring
`processing
`
`41
`
`41
`
`NO
`
`Detect as malicious code
`and perform related processing
`
`NO
`
`+ s
`
`Gather data about
`malicious code behavior
`
`418
`
`Return to
`application
`
`FIGURE9
`
`(')
`
`~ .....
`
`""C
`~ .....
`~ = .....
`~ "Cl -....
`.... 0 =
`~
`O' -....
`.... 0 =
`
`(')
`
`~ .....
`
`~
`~
`'-<
`'"""' ~~
`N
`8 Ul
`'Jl =-~
`~ .....
`'"""' c
`0 .....,
`'"""' ~
`
`d
`'Jl
`N c c
`~ c
`'"""' c
`00
`Ul
`O'I
`N
`
`>
`'"""'
`
`11
`
`SYMC 1010
`
`

`
`500,
`
`.. ....
`
`Invocation
`location 2
`
`...
`....
`
`..
`
`....
`
`Invocation
`location l
`
`Invocation
`location l
`
`Invocation
`location 1
`
`..
`...
`
`Invocation
`location 2
`
`Target location!
`
`Target location 2
`
`:
`
`Target location n
`
`:
`
`FIGURE 10
`
`(')
`
`~ .....
`
`""C
`~ .....
`~ = .....
`~ "Cl -....
`.... 0 =
`~
`O' -....
`.... 0 =
`
`(')
`
`~ .....
`
`~
`~
`'-<
`'"""' ~~
`N
`8 Ul
`'Jl =(cid:173)~
`~ .....
`'"""'
`'"""' 0 .....,
`'"""' ~
`
`d
`'Jl
`N c c
`~ c
`'"""' c
`00
`Ul
`O'I
`N
`
`>
`'"""'
`
`12
`
`SYMC 1010
`
`

`
`Patent Application Publication May 19, 2005 Sheet 12 of 13
`
`US 2005/0108562 Al
`
`.... ....
`
`N
`c::
`...... 0
`Oil
`......
`<!) · -
`~ ~
`f-< .9
`
`c:: N
`.g c::
`u ·-
`(':j 0
`-
`0 ""
`> u
`c:: .9
`
`-..
`
`c::
`c::
`...... 0
`I ! ) · -
`00 ......
`._,
`ro
`(':j u
`E-< .9
`
`c::
`c::
`.9 c::
`u ·-
`~ 0
`-
`0 ~
`> u
`c:: .9
`
`-c::
`
`..., 0
`Oil ......
`<!) · -
`~ ~
`E-< .9
`
`c:: -.9 c::
`
`~ .g
`u
`ro
`0
`> u
`c:: .9
`......
`
`(
`
`0
`"' VI
`
`13
`
`SYMC 1010
`
`

`
`600~
`
`Return locationl
`
`Invocation
`- location 1
`
`~
`
`Target locationl
`
`Return location 2
`
`~
`
`...
`
`Invocation
`location 1
`
`Target location 2
`
`Return location n
`
`Invocation
`location 1
`
`Target location n
`
`FIGURE 12
`
`(')
`
`~ .....
`
`""C
`~ .....
`~ = .....
`~ "Cl -....
`.... 0 =
`~
`O' -....
`.... 0 =
`
`(')
`
`~ .....
`
`~
`~
`'-<
`'"""' ~~
`N
`8 Ul
`'Jl =(cid:173)~
`~ .....
`'"""' ~
`0 .....,
`'"""' ~
`
`d
`'Jl
`N c c
`~ c
`'"""' c
`00
`Ul
`O'I
`N
`
`>
`'"""'
`
`14
`
`SYMC 1010
`
`

`
`US 2005/0108562 Al
`
`May 19, 2005
`
`1
`
`TECHNIQUE FOR DETECTING EXECUTABLE
`MALICIOUS CODE USING A COMBINATION OF
`STATIC AND DYNAMIC ANALYSES
`
`STATEMENT OF GOVERNMENT INTEREST
`
`[0001] The invention was made with Government support
`under contract No. F19628-00-C-0002 by the Department of
`the Air Force. The Government has certain rights in the
`invention.
`
`BACKGROUND
`
`[0002] 1. Technical Field
`
`[0003] This application generally relates to computer sys(cid:173)
`tems, and more particularly to a computer program that
`executes in a computer system.
`
`[0004] 2. Description of Related Art
`
`[0005] Computer systems may be used in performing a
`variety of different tasks and operations. As known in the art,
`a computer system may execute machine instructions to
`perform a task or operation. A software application is an
`example of a machine executable program that includes
`machine instructions which are loaded into memory and
`executed by a processor in the computer system. A computer
`system may execute machine instructions referred to herein
`as malicious code (MC). MC may be characterized as
`machine instructions which, when executed, perform an
`unauthorized function or task that may be destructive, dis(cid:173)
`ruptive, or otherwise cause problems within the computer
`system upon which it is executed. Examples of MC include,
`for example, a computer virus, a worm, a trojan application,
`and the like.
`
`[0006] MC can take any one or more of a variety of
`different forms. For example, MC may be injected into a
`software application. Injection may be characterized as a
`process by which MC is copied into the address space of an
`application or process in memory without modifying the
`binary of the application on disk. For example, MC may be
`injected into an application's address space by exploiting a
`buffer overflow vulnerability contained in the application. It
`should be noted that injection techniques, and other types of
`MC, are known in the art and described, for example, in the
`Virus Bulletin (http://www.virusbtn.com) and in "Attacking
`Malicious Code: A report to the Infosec Research Council,"
`by G. McGraw and G. Morrisett (IEEE Software, pp. 33-41,
`2000. (http://www.cigital.com/-gem/malcode.pdf).
`
`[0007] MC may also be embedded within a software
`application on disk in which case the MC appears as part of
`the application's code. Embedded MC may be classified as
`simple, dynamically generated, or obfuscated. Dynamically
`generated MC may be characterized as MC that is generated
`during application execution. For example, the MC may be
`in a compressed form included as part of the software
`application. When the software application is executed, the
`MC is decompressed and then executed. Obfuscated MC
`may be characterized as MC which tries to disguise the
`actual operation or task in an attempt to hide its malicious
`intention. Obfuscated MC may, for example, perform com(cid:173)
`plex address calculations when computing a target address
`of an execution transfer instruction at run time. Simple MC
`may be characterized as MC that is embedded, but which is
`not one included in the other foregoing categories. Simple
`
`MC may be characterized as code that appears as "straight(cid:173)
`forward" or typical compiler-generated code.
`
`[0008] There is a wide variety of known approaches used
`in detecting the foregoing types of MC. The approaches may
`be placed into two general categories referred to herein as
`misuse detection approaches and anomaly detection
`approaches. Misuse detection approaches generally look for
`known indications of MC such as, for example, known static
`code patterns, such as signatures of simple MC, or known
`run time behavior, such as execution of a particular series of
`instructions. Anomaly detection approaches use a model or
`definition of what is expected or normal with respect to a
`particular application and then look for deviations from this
`model.
`
`foregoing
`the
`techniques based on
`[0009] Existing
`approaches used in MC detection have drawbacks. One
`problem is that existing misuse detection techniques are
`based only on the known static features and/or dynamic
`behaviors of existing MC. These techniques may miss, for
`example, slight variations of known MC and new, previ(cid:173)
`ously unseen, instances of MC. Another problem relates to
`models, and techniques for generating them, that may be
`used in connection with anomaly detection approaches.
`Approaches in which humans generate and construct a
`model of an application may be inappropriate and imprac(cid:173)
`tical because they are time consuming and may be error
`prone due to the level of detail that may be required to have
`an accurate and usable model. Some existing anomaly
`detection techniques create models of normal behavior of a
`particular application based on observing sequences of sys(cid:173)
`tem calls executed at run time as part of a learning phase.
`When the learning phase is completed, anomaly detection
`may be performed by continuing to monitor the applica(cid:173)
`tion's executions looking for run time deviations from the
`learned behavior. With such techniques, false positives may
`result, for example, due to the limited amount of behavior
`observed during a learning phase. Unlearned behavior of an
`application observed during an anomaly detection phase, but
`not during the learning phase, results in false positives.
`Thus, from the conception of the model, there are antici(cid:173)
`pated failures. Additionally, statistical based models con(cid:173)
`structed from statistical measurements of static features
`and/or dynamic behavior of an application may be used.
`Statistical models generally include a detection threshold
`which adjusts the amount of false positives and/or false
`negatives. Finally, models can be constructed by static
`analysis of software applications but such approaches have
`not been practical. Some of these models are too "heavy
`weight" having excessive details about possible applica(cid:173)
`tions' behaviors so that they are not applicable to real-world
`software applications, and/or cannot be constructed, and/or
`used within acceptable overhead limits. In contrast, other
`existing models are too "light weight" having not enough
`detail so MC can easily bypass detection. Similar problems
`may apply to the models constructed by methods other than
`static analysis, such as by observing application's behavior.
`
`[0010] Thus, it may be desirable to have an efficient
`technique for MC detection that is applicable to real-world
`software applications and is able to accurately detect known
`and unknown MC prior to executing the MC. It may be
`especially desirable to have such techniques for detecting
`challenging classes of MC, such as injected, dynamically
`generated, and obfuscated. Additionally, it may be desirable
`
`15
`
`SYMC 1010
`
`

`
`US 2005/0108562 Al
`
`May 19, 2005
`
`2
`
`that the technique be able to, in addition to detecting
`presence of MC, identify which code portions within the
`applications correspond to the MC. It may also be desirable
`that the technique be useful in analysis MC, for example, to
`gather information about MC.
`
`SUMMARY OF THE INVENTION
`[0011]
`In accordance with one aspect of the invention is a
`method for detecting malicious code comprising: perform(cid:173)
`ing static analysis of an application prior to execution of the
`application identifying any invocations of at least one pre(cid:173)
`determined target routine; determining, prior to executing
`said at least one predetermined target routine during execu(cid:173)
`tion of the application, whether a run time invocation of the
`at least one predetermined target routine has been identified
`by said static analysis as being invoked from a predeter(cid:173)
`mined location in said application; and if the run time
`invocation of the at least one predetermined target routine
`has not been identified from a predetermined location by
`said static analysis, determining that the application includes
`malicious code.
`[0012]
`In accordance with another aspect of the invention
`is a method for detecting malicious code comprising: deter(cid:173)
`mining, prior to executing at least one predetermined target
`routine during execution of the application, whether a run
`time invocation of the at least one predetermined target
`routine is identified by a model as being invoked from a
`predetermined location in said application, said model iden(cid:173)
`tifying locations within said application from which invo(cid:173)
`cations of the at least one predetermined target routine
`occur; and if the run time invocation of the at least one
`predetermined target routine has not been identified from a
`predetermined location by said model, determining that the
`application includes malicious code.
`[0013]
`In accordance with yet another aspect of the inven(cid:173)
`tion is a method for detecting malicious code comprising:
`obtaining static analysis information of an application iden(cid:173)
`tifying any invocations of at least one predetermined target
`routine; determining, prior to executing said at least one
`predetermined target routine during execution of the appli(cid:173)
`cation, whether a run time invocation of the at least one
`predetermined target routine has been identified by said
`static analysis information as being invoked from a prede(cid:173)
`termined location in said application; and if the run time
`invocation of the at least one predetermined target routine
`has not been identified from a predetermined location by
`said static analysis information, determining that the appli(cid:173)
`cation includes malicious code.
`[0014]
`In accordance with another aspect of the invention
`is a computer program product that detects malicious code
`comprising: executable code that performs static analysis of
`an application prior to execution of the application identi(cid:173)
`fying any invocations of at least one predetermined target
`routine; executable code that determines, prior to executing
`said at least one predetermined target routine during execu(cid:173)
`tion of the application, whether a run time invocation of the
`at least one predetermined target routine has been identified
`by said static analysis as being invoked from a predeter(cid:173)
`mined location in said application; and executable code that,
`if the run time invocation of the at least one predetermined
`target routine has not been identified from a predetermined
`location by said static analysis, determines that the applica(cid:173)
`tion includes malicious code.
`
`[0015]
`In accordance with another aspect of the invention
`is a computer program product that detects malicious code
`comprising: executable code that determines, prior to
`executing at least one predetermined target routine during
`execution of the application, whether a run time invocation
`of the at least one predetermined target routine is identified
`by a model as being invoked from a predetermined location
`in said application, said model identifying locations within
`said application from which invocations of the at least one
`predetermined target routine occur; and executable code
`that, if the run time invocation of the at least one predeter(cid:173)
`mined target routine has not been identified from a prede(cid:173)
`termined location by said model, determines that the appli(cid:173)
`cation includes malicious code.
`
`[0016]
`In accordance with yet another aspect of the inven(cid:173)
`tion is a computer program product that detects malicious
`code comprising: executable code that obtains static analysis
`information of an application identifying any invocations of
`at least one predetermined target routine; executable code
`that determines, prior to executing said at least one prede(cid:173)
`termined target routine during execution of the application,
`whether a run time invocation of the at least one predeter(cid:173)
`mined target routine has been identified by said static
`analysis information as being invoked from a predetermined
`location in said application; and executable code that, if the
`run time invocation of the at least one predetermined target
`routine has not been identified from a predetermined loca(cid:173)
`tion by said static analysis information, determines that the
`application includes malicious code.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0017] Features and advantages of the present invention
`will become more apparent from the following detailed
`description of exemplary embodiments thereof taken in
`conjunction with the accompanying drawings in which:
`
`[0018] FIG. 1 is an example of an embodiment of a
`computer system according to the present invention;
`
`[0019] FIG. 2 is an example of an embodiment of a data
`storage system of the computer system of FIG. 1;
`
`[0020] FIG. 3 is an example of an embodiment of com(cid:173)
`ponents that may be included in a host system of the
`computer system of FIG. 1;
`
`[0021] FIG. 4A is an example of an embodiment of
`components that may be included in a host computer of FIG.
`1;
`
`[0022] FIG. 4B is a flowchart of processing steps that may
`be performed in an embodiment using the components of
`FIG. 4A.
`
`[0023] FIG. 5 is an example of routines that may be
`invoked in an embodiment of the dynamic analyzer of FIG.
`4A;
`
`[0024] FIG. 6 is an example of a representation of the
`address space of an application and associated libraries
`loaded into memory, possibly in a suspended state;
`
`[0025] FIG. 7 is an example of a logical flow of control
`between functions at run time to intercept calls to the
`predetermined functions or routines being monitored as part
`of dynamic analysis;
`
`16
`
`SYMC 1010
`
`

`
`US 2005/0108562 Al
`
`May 19, 2005
`
`3
`
`[0026] FIG. 8 is a flowchart of method steps of one
`embodiment for instrumenting functions or routines;
`
`[0027] FIG. 9 is a flowchart of method steps of one
`embodiment summarizing run time processing related to
`monitoring as performed by the dynamic analyzer; and
`
`[0028] FIGS. 10, 11 and 12 are examples of embodiments
`of data structures that may be used in storing the target
`locations and corresponding invocation locations.
`
`DETAILED DESCRIPTION OF
`EMBODIMENT(S)
`[0029] Referring now to FIG. 1, shown is an example of
`an embodiment of a computer system according to the
`present invention. The computer system 10 includes a data
`storage system 12 connected to host systems 14a-14n
`through communication medium 18. In this embodiment of
`the computer system 10, the N hosts 14a-14n may access the
`data storage system 12, for example, in performing input/
`output (110) operations or data requests. The communication
`medium 18 may be any one of a variety of networks or other
`type of communication connections as known to those
`skilled in the art. The communication medium 18 may be a
`network connection, bus, and/or other type of data link, such
`as a hardwire, wireless, or other connection known in the art.
`For example, the communication medium 18 may be the
`Internet, an intranet, network or other connection(s) by
`which the host systems 14a-14n may access and communi(cid:173)
`cate with the data storage system 12, and may also commu(cid:173)
`nicate with others included in the computer system 10.
`[0030] Each of the host systems 14a-14n and the data
`storage system 12 included in the computer system 10 may
`be connected to the communication medium 18 by any one
`of a variety of connections as may be provided and sup(cid:173)
`ported in accordance with the type of communication
`medium 18.
`[0031]
`It should be noted that the particulars of the hard(cid:173)
`ware and software included in each of the host systems
`14a-14n, as well as those components that may be included
`in the data storage system 12, are described herein in more
`detail, and may vary with each particular embodiment. Each
`of the host computers 14a-14n may all be located at the same
`physical site, or, alternatively, may also be located in dif(cid:173)
`ferent physical locations. Examples of the communication
`medium that may be used to provide the different types of
`connections between the host computer systems and the data
`storage system of the computer system 10 may use a variety
`of different communication protocols such as SCSI,
`ESCON, Fibre Channel, or GIGE (Gigabit Ethernet), and
`the like. Some or all of the connections by which the hosts
`and data storage system 12 may be connected to the com(cid:173)
`munication medium 18 may pass through other communi(cid:173)
`cation devices, such as a Connectrix or other switching
`equipment that may exist such as a phone line, a repeater, a
`multiplexer or even a satellite.
`[0032] Each of the host computer systems may perform
`different types of data operations in accordance with differ(cid:173)
`ent types of tasks. In the embodiment of FIG. 1, any one of
`the host computers 14a-14n may issue a data request to the
`data storage system 12 to perform a data operation, such as
`a read or a write operation.
`[0033] Referring now to FIG. 2, shown is an example of
`an embodiment of a data storage system 12 that may be
`
`included in the computer system 10 of FIG. 1. The data
`storage system 12 in this example may include a plurality of
`data storage devices 30a through 30n. The data storage
`devices 30a through 30n may communicate with compo(cid:173)
`nents external to the data storage system 12 using commu(cid:173)
`nication medium 32. Each of the data storage devices may
`be accessible to the hosts 14a through 14n using an interface
`connection between the communication medium 18 previ(cid:173)
`ously described in connection with the computer system 10
`and the communication medium 32. It should be noted that
`a communication medium 32 may be any one of a variety of
`different types of connections and interfaces used to facili(cid:173)
`tate communication between communication medium 18
`and each of the data storage devices 30a through 30n.
`[0034] The data storage system 12 may include any num(cid:173)
`ber and type of data storage devices. For example, the data
`storage system may include a single device, such as a disk
`drive, as well as a plurality of devices in a more complex
`configuration, such as with a storage area network and the
`like. Data may be stored, for example, on magnetic, optical,
`or silicon-based media. The particular arrangement and
`configuration of a data storage system may vary in accor(cid:173)
`dance with the parameters and requirements associated with
`each embodiment.
`[0035] Each of the data storage devices 30a through 30n
`may be characterized as a resource included in an embodi(cid:173)
`ment of the computer system 10 to provide storage services
`for the host computer systems 14a through 14n. The devices
`30a through 30n may be accessed using any one of a variety
`of different techniques. In one embodiment, the host systems
`may access the data storage devices 30a through 30n using
`logical device names or logical volumes. The logical vol(cid:173)
`umes may or may not correspond to the actual data storage
`devices. For example, one or more logical volumes may
`reside on a single physical data storage device such as 30a.
`Data in a single data storage device may be accessed by one
`or more hosts allowing the hosts to share data residing
`therein.
`[0036] Referring now to FIG. 3, shown is an example of
`an embodiment of a host or user system 14a. It should be
`noted that although a particular configuration of a host
`system is described herein, other host systems 14b-14n may
`also be similarly configured. Additionally, it should be noted
`that each host system 14a-14n may have any one of a variety
`of different configurations including different hardware and/
`or software components. Included in this embodiment of the
`host system 14a is a processor 80, a memory, 84, one or
`more 1/0 devices 86 and one or more data storage devices
`82 that may be accessed locally within the particular host
`system. Each of the foregoing may communicate using a bus
`or other communication medium 90. Each of the foregoing
`components may be any one or more of a variety of different
`types in accordance with the particular host system 14a.
`[0037] Each of the processors included in the host com(cid:173)
`puter systems 14a-14n may be any one of a variety of
`commercially available single or multi-processor system,
`such as embedded Xscale processor, an Intel-compatible x86
`processor, an IBM mainframe or other type of commercially
`available processor, able to support incoming traffic in
`accordance with each particular embodiment and applica(cid:173)
`tion.
`[0038] Computer instructions may be executed by the
`processor 80 to perform a variety of different operations. As
`
`17
`
`SYMC 1010
`
`

`
`US 2005/0108562 Al
`
`May 19, 2005
`
`4
`
`known in the art, executable code may be produced, for
`example, using a linker, a language processor, and other
`tools that may vary in accordance with each embodiment.
`Computer instructions and data may also be stored on a data
`storage device 82, ROM, or other form of media or storage.
`The instructions may be loaded into memory 84 and
`executed by processor 80 to perform a particular task.
`
`[0039]
`In one embodiment, an operating system, such as
`the Windows operating system by Microsoft Corporation,
`may reside and be executed on one or more of the host
`computer systems included in the computer system 10 of
`FIG. 1.
`
`[0040] Referring now to FIG. 4A, shown is an example of
`an embodiment of components that may reside and be
`executed on one or more of the host computer systems
`included in the computer system 10 of FIG. 1. The com(cid:173)
`ponents 100 in this embodiment include an application
`executable 102, one or more libraries, such as dynamic link
`libraries (DLLs) 114, a malicious code (MC) detection
`system 110, the list of targets and invocation locations 106,
`a list of target functions whose invocations are to be iden(cid:173)
`tified by static analysis 111, and a list of target functions
`whose invocations are to be monitored by dynamic analysis
`112. The MC detection system 110 includes a static analyzer
`104 and a dynamic analyzer 108. The application executable
`102 may be characterized as a binary file or machine
`executable program as may be produced, for example, by
`compiling and linking. In order to execute the application
`executable 102 from this point, the application executable
`may be loaded in memory, for example, as by a loader.
`Subsequently, the instructions of the application executable
`102 may be executed by one or more processors of the host
`computer.
`
`[0041]
`It should be noted that a DLL as used herein refers
`to a particular type of library as used in the Windows
`operating system by Microsoft Corporation. Other embodi(cid:173)
`ments may use other terms and names in describing other
`libraries that vary with the particular software of the
`embodiment. Also, as used herein, the terms functions and
`routines are used interchangeably.
`
`[0042]
`In this embodiment, prior to executing the appli(cid:173)
`cation executable 102, an analysis may be performed by the
`static analyzer 104 to examine and identify calls or invoca(cid:173)
`tions made from the application executable 102 to a prede(cid:173)
`termined set of target functions or routines. An embodiment
`may also identify additional information about these func(cid:173)
`tions, such as, for example, particular locations within the
`application from which the calls to these functions are made,
`parameter number and type information for each call, the
`values that some of these parameters take at run-time, and
`the like. For example, in one embodiment, it may be
`determined that the target function calls to be identified are
`those that are external to the application 102, such as those
`calls that are made to system functions. These functions may
`represent the set of Win32 Application Programming Inter(cid:173)
`faces (APis) as known to those of ordinary skill in the art in
`the Windows operating system by
`connection with
`Microsoft Corporation.
`
`[0043] Static analysis processing as described herein may
`be characterized as identifying information about code by
`st