Content uploaded by Shahid Alam
Author content
All content in this area was uploaded by Shahid Alam on Aug 21, 2016
Content may be subject to copyright.
1 23
Journal of Computer Virology and
Hacking Techniques
ISSN 2274-2042
J Comput Virol Hack Tech
DOI 10.1007/s11416-014-0222-y
Sliding window and control flow weight for
metamorphic malware detection
Shahid Alam, Ibrahim Sogukpinar, Issa
Traore & R.Nigel Horspool
1 23
Your article is protected by copyright and
all rights are held exclusively by Springer-
Verlag France. This e-offprint is for personal
use only and shall not be self-archived
in electronic repositories. If you wish to
self-archive your article, please use the
accepted manuscript version for posting on
your own website. You may further deposit
the accepted manuscript version in any
repository, provided it is only made publicly
available 12 months after official publication
or later and provided acknowledgement is
given to the original source of publication
and a link is inserted to the published article
on Springer's website. The link must be
accompanied by the following text: "The final
publication is available at link.springer.com”.
J Comput Virol Hack Tech
DOI 10.1007/s11416-014-0222-y
ORIGINAL PAPER
Sliding window and control flow weight for metamorphic malware
detection
Shahid Alam ·Ibrahim Sogukpinar ·Issa Traore ·
R. Nigel Horspool
Received: 10 February 2014 / Accepted: 25 July 2014
© Springer-Verlag France 2014
Abstract The latest stealth techniques, such as meta-
morphism, allow malware to evade detection by today’s
signature-based anti-malware programs. Current techniques
for detecting malware are compute intensive and unsuitable
for real-time detection. Techniques based on opcode pat-
terns have the potential to be used for real-time malware
detection, but have the following issues: (1) The frequen-
cies of opcodes can change by using different compilers,
compiler optimizations and operating systems. (2) Obfus-
cations introduced by polymorphic and metamorphic mal-
ware can change the opcode distributions. (3) Selecting too
many features (patterns) results in a high detection rate but
also increases the runtime and vice versa. In this paper we
present a novel technique named SWOD-CFWeight (Sliding
Window of Difference and Control Flow Weight) that helps
mitigate these effects and provides a solution to these prob-
lems. The SWOD size can be changed; this property gives
anti-malware tool developers the ability to select appropri-
ate parameters to further optimize malware detection. The
CFWeight feature captures control flow information to an
S. Alam (B)·R. Nigel Horspool
Department of Computer Science, University of Victoria,
Victoria, BC V8P5C2, Canada
e-mail: salam@cs.uvic.ca
R. Nigel Horspool
e-mail: nigelh@cs.uvic.ca
I. Sogukpinar
Department of Computer Engineering, Gebze Institute
of Technology, Gebze, Kocaeli 41400, Turkey
e-mail: ispinar@bilmuh.gyte.edu.tr
I. Traore
Department of Electrical and Computer Engineering,
University of Victoria, Victoria, BC V8P5C2, Canada
e-mail: itraore@ece.uvic.ca
extent that helps detect metamorphic malware in real-time.
Experimental evaluation of the proposed scheme using an
existing dataset yields a malware detection rate of 99.08%
and a false positive rate of 0.93%.
1 Introduction and motivation
Metamorphism is a technique that dynamically mutates the
binary code using a variety of obfuscations [22,24,27]. It
changes the code with each run of the infected program and
does not use any encryption or decryption. Thus, the mal-
ware never keeps the same sequence of opcodes in memory.
This is also called dynamic code obfuscation.Herewehave
provided an informal definition, a more rigorous definition
can be found in [41].
There are two kinds of metamorphic malware defined in
[27] based on the channel of communication used: Closed-
world malware, that does not rely on external communica-
tion and can generate the newly mutated code using either
a binary transformer or a metalanguage. Open-world mal-
ware, that can communicate with other sites on the Internet
and update itself with new features. Closed-world malware
usually carries its own morphing engine, which makes it far
more complex to develop than Open-world malware.Formal
grammars have been proposed for modeling many existing
morphing techniques [13], and can be used to create obfus-
cated copies of malware.
Dynamic binary code obfuscation is a stealth technique
that provides malware with the capability of evading detec-
tion by today’s signature-based anti-malware programs.
Techniques based on behavior analysis [7,12,14,16,17,20,
34,37,40] are used to detect metamorphic malware, but are
compute intensive and are not suitable for real-time detec-
tion. A subset of other techniques [4,28,30–33,36,39] that
123
Author's personal copy
S. Alam et al.
Tabl e 1 An example, comparing the change in frequency of Opcodes with the change in frequency of MAIL pattern ASSIGN, of a Windows
program sort.exe compiled with different level of optimizations
Opcode Optimization level 0 Optimization level 1 Optimization level 2
/ Total instructions 4045 Total instructions 1880 Total instructions 2276
MAIL Number of Number of %age Number of %age
pattern instructions instructions change instructions change
MOV 1339 (33.1 %) 532 (28.29 %) 14.53 607 (26.66 %) 19.50
ADD 115 (2.84 %) 35 (1.86 %) 34.51 49 (2.15 %) 24.30
LEA 59 (1.46 %) 43 (2.29 %) 56.85 54 (2.38 %) 63.01
SUB 57 (1.41 %) 22 (1.17 %) 17.02 27 (1.19 %) 15.60
AND 23 (0.57 %) 13 (0.69 %) 21.05 11 (0.49 %) 14.04
INC 4 (0.21 %) 21 (0.52 %) 147.62 18 (0.79 %) 276.20
OR 14 (0.35 %) 4 (0.21 %) 40 4 (0.17 %) 51.43
NEG 3 (0.16 %) 5 (0.12 %) 25 6 (0.27 %) 51.43
XOR 53 (1.31 %) 62 (3.30 %) 151.91 60 (2.63 %) 100.76
ASSIGN 1692 (41.83 %) 761 (40.48 %) 3.22 866 (38.10 %) 8.91
While translating an assembly program to MAIL, all 9 opcodes shown are tagged with pattern ASSIGN. We can see the frequencies of the 9 opcodes
change from 21.05 to 151.91 % when comparing optimization level 0 to optimization level 1, and from 14.04 to 276.20% when optimization level
0 is compared to optimization level 2, whereas the frequency of the MAIL pattern ASSIGN changes only by 3.22 and 8.91% respectively
use opcodes to detect malware, such as [4,28,30,33,36,39],
have been shown to detect metamorphic malware. One of the
main advantages of using opcodes for detecting malware is
that detection can be performed in real-time. However, the
current techniques using opcodes for malware detection have
several disadvantages including the following:
1. The patterns of opcodes can be changed by using a differ-
ent compiler or the same compiler with a different level
of optimizations.
2. The patterns of opcodes can also change if the code is
compiled for a different platform.
3. Obfuscations introduced by polymorphic and metamor-
phic malware can change the opcode distributions.
4. The execution time depends on the number of features
selected for mining in a program. Selecting too many
features results in a high detection rate but also increases
the execution time. Selecting too few features has the
opposite effects.
We propose a new opcode-based malware detection tech-
nique which addresses the above limitations by transforming
the assembly code to an intermediate language that makes
analysis independent of the choice of compiler and the plat-
form. In order to mitigate the effect of obfuscations intro-
duced by polymorphic and metamorphic malware, we extract
and analyze the program semantics along control flow paths.
Furthermore we use statistical analysis of opcode distribu-
tions to develop a set of heuristics that helps in selecting an
appropriate number of features and reduces the execution
time.
We illustrate our approach using an intermediate language
named MAIL (Malware Analysis Intermediate Language)
that we have recently introduced [2]. MAIL addresses some
of the problems described above. Table 1depicts an exam-
ple that highlights how the frequencies of opcodes change
significantly compared to the frequencies of a MAIL pattern
for a Windows program (sort.exe) when compiled at differ-
ent optimization levels. Patterns (tokens) present in MAIL
are a high level representation of opcodes and can be used in
a similar manner. This high level representation of opcodes
can help select an appropriate number of patterns that results
in a high detection rate while considerably reducing the exe-
cution time. The control patterns present in MAIL contain
the control flow information of a program in a form suitable
for metamorphic malware analysis and detection.
In this paper we present a novel scheme named SWOD-
CFWeight (Sliding Window of Difference and Control Flow
Weight) that helps mitigate these effects and provide a solu-
tion to these problems. SWOD is a window that represents
differences in opcode distributions, its size can change as it
slides through an opcode distribution graph; hence its name.
CFWeight captures the control flow of a program to an extent
that helps detect metamorphic malware in real-time. We show
how they can be used on MAIL patterns [2] for effective
metamorphic malware detection.
The remainder of the paper is organized as follows. Sec-
tion 2describes the most recent efforts on detecting mal-
ware using opcodes. Section 3provides statistics for MAIL
pattern distributions and motivations for developing SWOD-
CFWeight. In Sect. 4we define and develop the SWOD-
CFWeight technique, and show how it can be implemented
123
Author's personal copy
Sliding window and control flow weight
in a malware detector. In Sect. 5we evaluate the per-
formance of SWOD-CFWeight using an existing malware
dataset, and compare it to recent attempts to detect malware
using opcodes. We conclude in Sect. 6.
2 Related works
In this section, we discuss previous research efforts on mal-
ware detection using opcodes.
Santos et al. [31] use opcode sequences as a representation
of executables for malware detection. Each opcode is given
a weight based on its frequency of occurrence in malware or
in benign executables. The authors use the Term Frequency
[19] and the calculated weight to compute the Weighted Term
Frequency (WTF). The calculated weight is the relevance
(occurrence of a opcode in malware or benign executable)
of the opcode. Four different machine learning classifiers are
trained and tested using WTF to detect malware, including
Decision Tree,Support Vector Machines,K-Nearest Neigh-
bours and Bayesian Networks.
Their best results based on the detection rate are obtained
using the Decision Tree classifier which also achieves the
best malware detection time. We cannot compare/discuss the
listed malware detection timings, because it is not clear from
their results if the time listed is for each file or for the complete
dataset.
Shabtai et al. [32], similar to Santos et al. [31], also
use opcode sequences to represent executables for malware
detection. After extracting the opcode sequences they com-
pute the Term Frequency and Inverse Document Frequency
[29] for each opcode sequence or feature in each file. After
reducing the number of features by using the document
frequency measure (number of files in which the feature
appeared) they applied eight commonly used classification
algorithms for malware detection.
Most of the existing opcodes-based malware detection
approaches, including the above ones, are unsuitable for
metamorphic malware detection. To the best of our knowl-
edge, there are only six such approaches that are capable of
detecting metamorphic malware, that we discuss below.
The work by Wong et al. [39] provides a good introduction
to malware generation and detection, and served as a bench-
mark for comparison in several other studies [5,10,23,30,36]
on metamorphic malware. They analysed and quantified
(using a similarity score) the degree of metamorphism pro-
duced by different metamorphic malware generators, and
proposed a hidden Markov model (HMM) for metamorphic
malware detection. A HMM is trained using the assembly
opcode sequences of the metamorphic malware files. The
trained HMM represents the statistical properties of the mal-
ware family, and is used to determine if a suspect file belongs
to the same family of malware or not.
The malware generators analysed in [39]are,G2,MPC-
GEN, NGVCK and VCL32. Based on the results, NGVCK
(also used in this paper) outperforms other generators.
VCL32 and MPCGEN have nearly similar morphing ability,
and the malware programs generated by G2 (also used in this
paper) have a higher average similarity than the other three.
Based on these results, we can conclude that malware pro-
grams generated by NGVCK are the most difficult to detect
out of the four.
Runwal et al. [30] presented a technique that uses simi-
larity of executables based on opcode graphs for metamor-
phic malware detection. Opcodes are first extracted from
the binary of a program. Then a weighted opcode graph is
constructed. Each distinct opcode becomes a node in the
graph and a node is linked to a successor opcode by an
edge. This is similar to opcode sequences used in [31,32]
and captures the execution flow of a program but not the
control flow. The edge is given a weight based on the fre-
quency of occurrence of the successor opcode. The con-
structed graph is directly compared with the graph of some
known malware by computing a similarity score. If the simi-
larity score exceeds a specified threshold then the program is
deemed to be malware, otherwise the program is considered
benign.
Toderici et al. [36] presented a method that uses the chi-
squared (χ2)test[38] to detect metamorphic malware. Their
method is based on the observation that different compil-
ers use different instruction subsets to generate code. The
instructions that are common between different compilers
will appear with different frequencies. An estimator func-
tion can then estimate the likelihood that a particular set of
instructions was generated by a particular compiler. The same
approach can be used to evaluate instructions generated by a
metamorphic malware generator.
Their estimator works as follows. First they compute a
spectrum of an infected program. This spectrum contains
information about the typical frequencies of the opcodes,
which corresponds to the expected frequencies of the instruc-
tions in a particular metamorphic generator. To detect if a
file contains metamorphic malware, the expected frequencies
are compared with the observed frequencies. A χ2statistical
test is used to determine if there is a significant difference
between the expected and the observed frequencies. If there
is a significant difference then the file under test is benign.
The proposed detector named CSD (for chi-squared distance)
was tested against a HMM based detector proposed in [39],
and hybrid detector consisting of a combination of CSD-
based detector and HMM-based detector. Overall the CSD-
based detector performed better than the HMM-based detec-
tor and the hybrid results were slightly better than the CSD.
Their implementation uses IDA Pro [11], a closed source
disassembler, to disassemble the executables and is not fully
automatic.
123
Author's personal copy
S. Alam et al.
Rad et al. [28] presented a technique that uses a histogram
of instruction opcode frequencies to detect metamorphic mal-
ware. A histogram is built for each file and is compared
against the already built histograms of malware programs to
classify files as malware or benign. The similarity between
two histograms is measured using the Minkowski distance
[21]. The proposed detector extracts opcodes from a binary
file and uses MATLAB to generate a histogram of these
opcodes. It is not fully automatic.
Austin et al. [4] presented a model that uses hidden
Markov models (HMMs) to point out how hand written
assembly differs from compiled code and how benign code
differs from malware code. This model is used to detect mal-
ware. HMMs are built for both benign and malware pro-
grams. For each program, the probability of observing the
sequence of opcodes is determined for each of the HMMs. If
the HMM reporting the highest probability is malware, the
program is flagged as malware.
Shanmugam et al. [33] presented an opcode-based simi-
larity measure inspired by substitution cipher cryptanalysis
[18] to detect metamorphic malware. They obtained promis-
ing results. A score is computed using an analog of Jackob-
sens algorithm [18] that measures the distance between the
opcode sequence of a given program and the opcode statistics
for a malware program. A small distance indicates malware.
The above six approaches [4,28,30,33,36,39] are the only
existing opcode-based approaches capable of detecting meta-
morphic malware. We have included some of the malware
samples used in their evaluations in our dataset, along with
other malware samples of our own. This allows us to compare
our results with their results.
Here, we briefly discuss some other interesting recent
research work that is not based on opcodes but detects meta-
morphic malware and has the potential to be used in a real-
time detector. The techniques proposed in this work are based
on file structure, and are applied directly to the binary files.
Hence they save time needed to extract the opcodes. Baysa
et al. [5] proposed a technique based on structural entropy
to detect metamorphic malware. If the entropy structure of
a testing file is similar to a malware program then the file is
tagged as malware. The detection results are better for the
G2 and MWOR malware families, but are weaker for the
NGVCK malware family. Deshpande et al. [10] presented
an effective technique based on eigenvalue analysis to detect
highly morphic metamorphic malware. Eigenvectors belong-
ing to a metamorphic family of malware are used to compute
a score for classification of benign and malware files.
3 Statistical analysis of MAIL pattern distributions
A recent study [6] analysed the statistical distributions of
opcodes in 77 malware and 67 benign programs. The study
found that the malware opcode fequencies differ significantly
from non-malicious code and this difference can be used for
malware detection. In general MOV and PUSH were the most
used opcodes in the samples tested. This is the most signif-
icant research on opcodes and provides ideas and motiva-
tions to use opcodes [31,32] for malware detection. Another
recent study [4] presented some interesting opcode statis-
tics of the assembly code produced by different compilers.
The study found that the opcode distributions are different
between compilers, and can be used to identify the compiler.
These results also confirm that the frequencies of opcodes
change through use of a different compiler.
Motivated by these studies [4,6], we carried out an empiri-
cal study using metamorphic malware. Our study differs from
the studies described in [4,6], since it focuses specifically on
metamorphic malware and MAIL patterns. The main pur-
pose of our study is to study MAIL pattern distributions by
computing term frequencies, and establish how MAIL pat-
tern frequencies differ between malware and benign samples.
We then use the findings as the basis for defining new metrics
from MAIL patterns for detecting metamorphic malware.
3.1 Dataset
The dataset used for the experiments in this paper consists
of a total 5305 sample programs. Out of the 5305 programs,
1020 are metamorphic malware samples collected from three
different sources [25,28,30], and the other 4285 are benign
Windows and Cygwin programs. The distribution of sample
file sizes used in the dataset is shown in Table 2.
The dataset contains programs compiled with different
compilers (Visual C++, Visual C#, Visual Basic and GCC)
for Windows (32 and 64 bits, PE format) and Linux (32 and
64 bits, ELF format) operating systems. The sizes of the
malware samples range from 1 KB to 299 KB and the sizes
of the benign samples range from 9 bytes to 10 MB.
The 1020 malware samples belong to the following three
metamorphic families of viruses: Next Generation Virus
Construction Kit (NGVCK) [26], Second Generation Virus
Generator (G2) [15] and Metamorphic Worm (MWOR) gen-
erated by metamorphic generator [25]. NGVCK generates
malware that is highly metamorphic, and contains obfusca-
tions that range from simple to complex. They include dead
code insertion, instruction reordering and insertion of indirect
jumps. Malware generated by G2 is modestly metamorphic.
MWOR uses two kinds of obfuscations: dead code insertion
and equivalent instruction substitution. Out of 1020 malware
samples, 270 are NGVCK, 50 are G2, and 700 are MWOR
(each 100 with a padding ratio of 0.5, 1.0, 2.0, 2.5, 3.0, 3.5
and 4.0).
This variety of sample files and malware classes in the
samples provides a good testing platform for the proposed
malware detection scheme.
123
Author's personal copy
Sliding window and control flow weight
Tabl e 2 Dataset distribution
based on the size of each
program sample
Malware samples (1020) Benign program samples (4285)
Range of Number of Range of Number of
size (bytes) samples size (bytes) samples
1343–1356 50 9–19997 817
3584–4096 35 20336–29984 406
8192–16384 215 30144–49800 492
29356–35324 200 50144–119936 935
36864–40772 102 120296–980840 1,514
40960–46548 101 1001936–1553920 50
52292–57828 200 1606112–3770368 48
67072–69276 101 4086544–5771408 12
70656–74752 4 6757888–8947200 4
271872–299520 12 9074688–10124353 7
3.2 MAIL pattern distributions
First, we translated each sample from the dataset to the
corresponding MAIL program and then collected the sta-
tistics about the MAIL patterns distributions for each sam-
ple. The distributions for each program sample, benign and
malware, are shown in Fig. 1. Only seven MAIL pattern
distributions that have a significant difference in values are
shown. For clarity and readability we made the graphs sparse,
and not all the values of the MAIL pattern distributions are
shown.
The graph plots in Fig. 1show the number of samples
on the X-axis and the patterns’ percentage on the Y-axis. On
average the occurrence of MAIL pattern ASSIGN is the high-
est in over 85% of the samples. While translating a binary
program to a MAIL program, all assembly instructions that
make changes to a register or a memory place excluding
stack, e.g., MOV instructions, are tagged with MAIL pattern
ASSIGN.In[6] the MOV instruction is also the most used
opcode in the samples tested.
To show the difference between the malware and benign
MAIL pattern distributions, we superimpose the two Fig.
1a and b using all the values of the MAIL pattern distribu-
tions. For clarity and readability only three patterns, ASSIGN,
CONTROL_C and STACK, are superimposed. Figure 2shows
the superimposition of these MAIL patterns distributions.
The graph in Fig. 2is divided using perpendicular lines.
When the two plots (malware and benign) of a pattern hor-
izontally divide the space between two perpendicular lines,
this division is called one pocket of the window. There are
significant pockets of windows in MAIL pattern ASSIGN that
show a significant difference between malware and benign
samples. In contrast, there are few pockets of windows in
MAIL patterns CONTROL_C and STACK that show a signif-
icant difference between malware and benign samples. We
use this observation and the differences as a motivation to
develop a Sliding Window of Difference (SWOD) based on
MAIL patterns, which we define formally in Sect. 4.1. Instead
of using the probabilities of the occurrences and differences
of MAIL patterns in a dataset and then applying stochastic
processes, we employ empirical methods using heuristics to
develop the SWOD for a dataset. We believe this is much
closer to a practical solution to the problems of malware
detection described in Sect. 1.
Out of the seven patterns shown in Fig. 1four of them
namely, CALL_C,CONTROL_C,JUMP_C and JUMP_S,
are MAIL control patterns. We can use this difference in
MAIL control patterns between a malware sample and a
benign sample for metamorphic malware detection. These
statistics persuaded us to develop a new metric, namely Con-
trol Flow Weight (CFWeight).
4 Heuristics based on MAIL patterns for metamorphic
malware detection
In this Section we define a set of heuristics based on MAIL
patterns for metamorphic malware detection. The main goal
for developing these heuristics is to reduce the executin time
for metamorphic malware detection while keeping the same
or improving the other performance metrics.
4.1 Sliding windows of difference
Let Mibe the i-th malware sample and PjMiis the per-
centage of the j-th MAIL pattern in Mi, then we denote
MAIL pattern distributions of Pj(the j-th MAIL pat-
tern) in a dataset of malware samples as PDj={PjM1,
PjM2,PjM3,...,PjMn}, where nis the number of mal-
ware samples in the dataset. Similarly, Let Bibe the i-th
123
Author's personal copy
S. Alam et al.
(a) MAIL pattern distributions for benign samples
(b) MAIL pattern distributions for malware samples
Fig. 1 MAIL pattern distributions based on the percentage of the MAIL patterns in each sample in the dataset
benign sample and PjBiis the percentage of the j-th MAIL
pattern in Bi, then we denote MAIL pattern distributions of
Pjin a dataset of benign samples as PDj={PjB1,PjB2,
PjB3,...,PjBm}, where mis the number of benign sam-
ples in the dataset.
We compute the MAIL pattern distributions in a MAIL
program, as follows:
PjXi=aj
N
n=1bn
×100 (1)
where Xican be either a malware or a benign sample, aj
and bnare the number of times the j-th and n-th patterns
occur in a MAIL program, and Nis the total number of pat-
terns in the MAIL language; currently there are 21 patterns in
MAIL [2].
123
Author's personal copy
Sliding window and control flow weight
Fig. 2 Superimposing three of the MAIL patterns distributions from Fig. 1aandb
Before describing the heuristics for metamorphic malware
detection using MAIL pattern distributions, we first define
the following terms:
Definition 1 Vertical Window of Difference (VWOD) is the
absolute difference between the percentage of the occurrence
of a MAIL pattern in malware and a benign sample, and
is defined as VWOD
i=
PjMi−PjBi
. This difference
is also referred to as the size of the window VWOD
i,as
shown in Fig. 3, and we call it mindist, because it represents
the distance between a malware and a benign samples’ MAIL
pattern distribution points. For example if mindist is 5, then
VWOD ≥5 is required.
Definition 2 Horizontal Window of Difference (HWOD) is
defined as HWOD ={VWOD
1,VWOD
2,VWOD
3,
...VWOD
n}, where nis the size of the HWOD,asshown
in Fig. 3. The size defines the maximum size, called max-
size,oftheHWOD. The minimum size of the HWOD, called
minsize, is the percentage of VWODs out of nthat satisfy the
mindist as defined above. For example a minsize of 70 for a
HWOD means 70% of all the VWODs in the HWOD satisfy
the mindist.
Definition 3 Sliding Window of Difference (SWOD) is a 4−
tuple defined as SW O D ={HWOD,minsize,
maxsize,mindist}. Where minsize and maxsize are the
minimum and the maximum sizes of the HWOD, and mindist
is the size of VWOD.minsize,maxsize and mindist also define
the size of a SWOD. A graphical depiction of a SWOD is
shown in Fig. 3.
Vj1
Vj2
PM
jn
PB
jn
PjM1
PM
j5
PB
j1
PB
j5
j1
size
of
VWODjk
Vj3
Vj4
Vjn Vj5
Fig. 3 Sliding Window of Difference (SWOD). HWOD =
{V1,V2,V3,...Vn}where V1,V2,V3,...Vn,aretheVWODs
4.2 MAIL program signature
Algorithms 1 and 2 present in detail the heuristics for com-
puting the weight of each MAIL pattern in a dataset and
building the signature of a MAIL program.
Every MAIL statement is assigned a pattern during trans-
lation from assembly to MAIL [2]. The final weight of each
MAIL statement is computed by adding the corresponding
MAIL pattern’s weight to its CFWeight. This final weight
is then used to build the signature of a MAIL program as
shown through lines 21–27 in Algorithm 2. Reusing the same
scheme this signature is then used for malware detection.
In the following Sections we show in detail how these
weights (weight of a MAIL pattern using SWODs, and
CFWeight of a MAIL statement) are computed.
123
Author's personal copy
S. Alam et al.
Algorithm 1 Computing weight for each MAIL pattern in a dataset
1procedure ComputeWeight(P M, P B, N , nm, nb, mindi st, minsize)
2for p←1toNdo
3for i←1tonm do
4ListM alware[p]←PM[N][i]
5end for
6for i←1tonb do
7ListBenign[p]←PB[N][i]
8end for
9ListM alware[p]←Sort(ListMalware[p])
10 ListBenign[p]←Sort(ListBenig n[p])
11 end for
12 maxsize ←min(nm, nb)
N
13 for p←1toNdo
14 SWODs ←ComputeSWODs(ListM alware[p], ListB enign[p], mindist, minsize, maxsize)
15 P atternW eights [p]←SWODs.Size
16 end for
17 return P atternW eights
18 end procedure
PM and PB are the MAIL pattern distributions. mindist,minsize and maxsize are defined in Definition 3.Nis
the number of patterns in MAIL. nm is the number of malware samples and nb is the number of benign samples
in the dataset. The function Sort sorts the list in descending order. SW ODs ={SWOD1,SWOD
2,SWOD
3, .....}
and are computed as per Definition 3.
Algorithm 2 Computing CFWeight (Control Flow Weight) and Signature of a MAIL program
Precondition: P atternW eig hts assigned using Algorithm 1
1procedure BuildSignature(MailProgram,PatternWeights,NS)
2Sig ←0
3for s←1toNS do
4CFW eight ←P atternW eights[MailProgram[s].P attern]
5if MailProgram[s].Patter n =C ontrolPattern then
6if MailProgram[s].IsJ umpOutsideF unction then
7CFW eight ←CFW eight +MailProgram[s].DistanceLastStatement +1
8else if MailProgram[s].IsBackJ ump then
9CFW eight ←CFW eight +2×MailProgram[s].LengthOfJump
10 else
11 CFW eight ←CFW eight +MailProgram[s].LengthOfJump
12 end if
13 if MailProgram[s].Patter n =I f P attern then
14 CFW eight ←CFW eight +2
15 else if MailProgram[s].P attern =J umpCallP attern then
16 CFW eight ←CFW eight +1
17 end if
18 else if MailProgram[s].IsLastS tmtOf Block then
19 CFW eight ←CFW eight +1
20 end if
21 Sig[s]←CFWeight
22 end for
23 Sig ←Sort(Sig)
24 Signature ←AssignMem(Sig[Sig.Size]+1)
25 for s←1toSig.Size do
26 Signature[Sig[s]] ←Signature[Sig[s]] + 1;
27 end for
28 return Signature
29 end procedure
NS is the number of statements in the MAIL program. The function Sort sorts the array Sig in ascending order.
The loop in lines 25 - 27 stores Signature for easy and fast comparison. e.g: The Signature: 11111444777777777 is
stored as: 05003009 i.e: there are 5 1’s, 3 4’s and 9 7’s in Signature.
123
Author's personal copy
Sliding window and control flow weight
Fig. 4 Sliding Window of Differences (SWODs) for the MAIL pattern ASSIGN
4.2.1 SWODs
ComputeSWODs(): In this function (as used in Algorithm
1), we are finding the difference of the data value in two
lists, ListMalware and ListBenign for finding the SWODs.
These lists are the distributions for each MAIL pattern. We
give priority to the samples that have greater occurrences of
a MAIL pattern, therefore we first sort the lists in descending
order, as shown in lines 9 and 10. For finding the real SWODs
(that satisfy the size as per Definition 3) we go through vir-
tual SWODs in the lists, as shown in lines through 13–16 in
Algorithm 1, and stop with the shorter list. The number of
real SWODs found in a MAIL pattern is used as the weight
of the MAIL pattern. We explain this computation using an
example, as follows.
Figure 4shows an example of SWOD for the MAIL pattern
ASSIGN, which is computed using 25 % of samples selected
randomly from the dataset presented earlier, which corre-
sponds to l=1020 samples. The SWOD for the example
has a minsize = 70,maxsize = 51 (1020
20 ) and mindist = 5.
The value of maxsize is computed as shown in line 12 of
Algorithm 1. The values of minsize and mindist are com-
puted empirically. Using these samples we obtain the values
of minsize and mindist for an optimal performance of the mal-
ware detector. During the same process and using the same
samples, we compute weight of each MAIL pattern using
Algorithm 1, as follows.
According to Definition 2 of HWOD at least 35 (51
×0.70 ≈35) of the VWODs should have a value ≥5, for the
example of SWODs shown in Fig. 4. Based on these values,
size of the SWOD becomes 35 ×5, i.e: horizontal length =
35 and vertical height = 5. There are a total 20 virtual SWODs
(for the sake of the example we have assumed that there are 20
patterns in MAIL), and while sliding through the graph of the
MAIL pattern ASSIGN, 17 of them satisfy the size condition,
and can then be considered as the real SWODs. We assign 17
as the weight of the MAIL pattern ASSIGN. Similarly, each
MAIL pattern in the dataset is assigned a weight.
4.2.2 CFWeights
Before computing CFWeight we build an interprocedural
CFG (a CFG for each function in a program) [1]ofaMAIL
program. Then we add CFWeight by using the control pat-
terns of MAIL. The heuristics for computing CFWeight are
shown through lines 4–20 in Algorithm 2 and are summa-
rized as follows.
1. Each block’s last statement, and each JUMP and CALL
statement is assigned a weight of 1.
2. Each CONTROL statement is assigned a weight of 2.
3. Each control flow change (JUMP, CONTROL or CALL)
is assigned a weight equal to the length of the jump, which
correlates with the number of blocks jumped.
4. The weight of a back jump (possibly implementing a
loop) is double the length of the jump.
5. A jump whose target is outside the function is assigned
a weight equal to the distance (number of blocks) of the
jump statement from the last block of the function plus
one.
123
Author's personal copy
S. Alam et al.
Fig. 5 Malware detection using
MAIL program signatures
Signature
Generator
MAIL
Program
Original
signature
Signature
sorted
Signature
comparison
Signatures
Samples
0
0
0
3
0
1
3
0
7
0
0
0
0
0
2
0
0
2
0
0
0
0
0
1
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
3
3
3
23
14
17
17
14
8
8
8
6
6
6
5
3
8
3
3
23
17
17
14
8
8
8
6
6
6
5
3
8
0
2
2
0
3
1
0
4
M1
0
4
0
3
0
1
2
0
M2
0
2
3
1
2
1
0
1
M12
0
0
0
5
8
0
9
4
Mz
0
2
1
3
0
1
3
0
6
0
2
0
0
2
2
1
0
1
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
3
8
8
8
8
8
14
8
The CFWeight of a MAIL statement is computed by
adding all the above assigned weights to the statement.
4.2.3 Signature matching and malware Detection
To detect if a new program is malware or not, we build its
signature as explained above. This signature is compared
with the signatures of all the training malware samples. In
case of a match with any of the signatures of the training
malware samples we tag the new program as malware.
Let Si=[sik]1≤k≤pand Sj=[sjk]1≤k≤qdenote the
signature vectors, sorted in decreasing order, of two different
programs, such that p≤q.
To match the two signatures, we compare each weight’s
value in one of the signatures with the corresponding weight’s
value in the other signature, by computing the following:
dijk =
sik −sjk
max(sik,sjk)
×100,where1 ≤k≤p.
Two weights sik and sjk are matching if and only if dijk ≤
1, where 1=3×mindist.
Let yand rdenote the number of weight pairs’ (sik,sjk)
matching and the number of non-zero values in Sj, respec-
tively. Signatures Siand Sjmatch if and only if y
r×100
≥2, where 2=minsize
2.25 .
The two values, 1and 2are computed empirically from
25 % of the samples selected randomly from the dataset.
Figure 5shows an example of malware detection using
MAIL program signatures. There are a total of 19 statements
in the sample MAIL program. To generate the signature, each
statement is assigned a weight as explained above. After
sorting the signature, it is stored in an index-based array
for efficient comparison. This array stores the number of
weights with the same value at the index corresponding to the
value.
For the example shown in Fig. 5there are 3 weights with
the value 3, so we store a 3 at index 3. There is only 1 weight
withthevalue5,sowestorea1atindex5andsoon.This
index-based signature array of the MAIL program is com-
pared with the index-based signature arrays of the training
malware samples.
We can see that there is a successful match of the signa-
ture of the MAIL program with the signature of the malware
123
Author's personal copy
Sliding window and control flow weight
sample M12 and hence the program is tagged as malware.
The comparison stops after the first successful match.
The lines without a ×(12 of them) show a match (per-
centage of difference is ≤1=3×5 = 15), between the
corresponding weights, and the lines marked with a ×(6
of them) show a no-match (percentage of difference is >
1) between the corresponding weights. The malware detec-
tion stops after the 3rd match (the 5th comparison), because
3
7×100 (42.86) ≥2(70
2.25 = 31.11).
4.3 Complexity analysis
Time complexity of Algorithm 1: There are two outer loops
in function ComputeWeight(). The time of the second loop
depends on the function ComputeSWODs(). Basically this
function finds the difference of the data value in two lists and
stops with the shorter list. Therefore the time of the function
ComputeSWODs() depends on the number of either malware
or benign samples (whichever is smaller). We compute the
time complexity of Algorithm 1 as follows: time first loop +
time second loop = N(nm + nb + nm log m + b log b) + N
min(m, b), and is simplified to O(Nnlog n), where Nis the
number of patterns in MAIL, and nis either the number of
malware samples or the number of benign samples whichever
is larger.
Time complexity of Algorithm 2: The time for the ini-
tialization of Sig at line 2 and the two loops in the function
BuildSignature() depends on the number of statements (NS)
in the MAIL program. Including the time for function Sort()
at line 23 the time complexity of Algorithm 2 is 3NS + NS
log NS, and is simplified to O(nlog n), where nis the number
of statements in the MAIL program.
The average and worst case time complexities of both
algorithms depend on the Sort() function used in the imple-
mentation. The time computed (both average and worst case)
above is for a merge sort implementation [8].
5 Experimental evaluation
We carried out an empirical study to analyse the correctness
and efficiency of the proposed technique. We present, in this
section, the evaluation metrics, the empirical study, obtained
results and analysis.
5.1 Performance metrics
Before evaluating the performance of our approach, we first
define the following performance metrics:
True positive (TP) is the number of malware files that are
classified as malware. True negative (TN) is the number of
benign programs that are classified as benign. False positive
(FP) is the number of benign programs that are classified
as malware. False negative (FN) is the number of malware
programs that are classified as benign.
Accuracy is the fraction of samples, including malware
and benign, that are correctly detected as either malware or
benign. This metric is defined as follows:
Accuracy =TP +TN
P+N
where P and N are the total number of malware and benign
programs respectively. Now we define the mean maximum
accuracy (MMA) for n-fold cross-validation as follows:
MMA =1
n
n
i=1
Accuracyi(2)
We also use two other metrics, TP rate and FP rate. The TP
rate (TPR), also called detection rate (DR), corresponds to
the percentage of samples correctly recognized as malware
out of the total malware dataset. The FP rate (FPR)metric
corresponds to the percentage of samples incorrectly recog-
nized as malware out of the total benign dataset. These two
metrics are defined as follows:
TPR =TP
Pand FPR =FP
N(3)
5.2 Evaluation results
We implemented our proposed scheme in our existing tool
named MARD for Metamorphic Malware Analysis and Real-
time Detection [3]. MARD is a malware detector that fully
automates the malware analysis and detection process, with-
out any manual intervention during a complete run. In this
section we discuss the experiments conducted to evaluate
our approach and present the performance results obtained.
We have also implemented in MARD another metamorphic
malware detection technique called Annotated Control Flow
Graph (ACFG) introduced in a previous paper [3]. We also
present a comparison of SWOD-CFWeight with ACFG using
the same dataset and experimental settings as used in [3].
First we compute the size (mindist and minsize) parame-
ters of SWOD as explained in Sect. 4.2.1. For the dataset used
in our experiments, these values are computed as mindist =
5 and minsize = 70.
Through n-fold cross validation eight experiments were
conducted using different subsets of the dataset. We also
change the training set size to provide more variations for
testing.
5.2.1 Performance results of SWOD-CFWeight and
comparison with ACFG
All the eight experiments were run on the following machine:
an Intel Core i5 CPU M 430 (2 Cores) @ 2.27 GHz with 4GB
123
Author's personal copy
S. Alam et al.
Tabl e 3 Malware detection results for SWOD-CFWeight and Comparison with ACFG
Technique used Training set size Dataset size DR FPR MMA Cross validation Testing time (s)
Benign/Malware
ACFG 25 1101/250 94 % 3.1 % 0.96 10-fold 15.2
SWOD-CFWeight 25 1101/250 99.08 % 0.93 % 0.99 10-fold 2.27
ACFG 204 2330/1020 97 % 4.3 % 0.96 5-fold 946.58
SWOD-CFWeight 204 2330/1020 94.69 % 10.59 % 0.91 5-fold 6.13
SWOD-CFWeight 612 2330/1020 97.26 % 12.44 % 0.91 1-fold 8.38
SWOD-CFWeight 204 4168/1020 94.69 % 9.12 % 0.92 5-fold 12.08
SWOD-CFWeight 612 4168/1020 97.36 % 10.14 % 0.92 1-fold 15.89
SWOD-CFWeight 612 4285/1020 97.26 % 11.29 % 0.92 1-fold 15.92
The dataset used in the last row contains additional benign files whose sizes range from 1 to 10MB. All the other datasets contain files (both benign
and malware) whose sizes are ≤1 MB. Testing time is the time to check if a file is benign or not and does not include the training time. The time
reported is the testing time of all the files in the dataset
RAM, Windows 8 Professional operating system. We used
n-fold cross validation to estimate the performance of our
technique. In n-fold cross validation the original sample is
divided into n equal size subsamples. One of the samples is
used for testing and the remaining n −1 samples are used
for training. The cross validation process is then repeated n
times with n subsamples used exactly once for validation.
The results of all the experiments are listed in Table 3.
The first four rows in Table 3compare the results of
SWOD-CFWeight with ACFG. The smaller dataset SWOD-
CFWeight shows much better DR and FPR than ACFG,
but the larger dataset ACFG showsabetterDR.Themain
difference between the two techniques is the testing time.
ACFG uses graph matching for malware detection. In spite
of reducing the graph size considerably and hence the time
by 2.7 times for the smaller dataset and 100 times for the
larger dataset [3], the testing time is still much larger than
SWOD-CFWeight, especially for the larger dataset. As the
size of a program (or program sample) increases, the size
of the resulting graph (ACFG) also increases, and hence the
time for graph matching. The testing time increases from
the smaller dataset to the larger dataset by 1.7 times for
SWOD-CFWeight and by 61.3 times for ACFG.Inviewof
these results, SWOD-CFWeight should be used instead of
ACFG when the time for malware detection is more impor-
tant, such as in practical (real-time) anti-malware applica-
tions.
We would also like to mention here that ACFG is imple-
mented as a multithreaded component, whereas SWOD-
CFWeight is implemented as a singlethreaded component
in our malware detection tool, MARD. To further reduce the
execution time, in the future we are planning to parallelize
the SWOD-CFWeight component.
The next four rows give more insight into SWOD-
CFWeight. As expected the testing time increases linearly
with the size of the dataset. The DR decreases by over
4 % and the FPR increases by over 10 % as the size of the
dataset increases. We believe that the reason for this is the
size of the SWOD used in the experiments. As mentioned
before we randomly selected 25 % of the samples from the
dataset to compute the size parameters of SWOD. This shows
that the size of the SWOD affects the performance of the
malware detector and needs to be computed for every new
dataset.
In our future work, we will also investigate how we can
improve the selection of the samples to compute an opti-
mal size of the SWOD for a dataset. For example, dividing
benign and malware samples into classes, and then select-
ing an appropriate number of samples from each class, can
further optimize computation of the size parameters of the
SWOD. To achieve optimal size values of the SWOD,the
frequency of MAIL patterns in each sample must be consid-
ered when classifying these samples. The key to finding the
optimal size of SWOD is to locate the areas where signifi-
cant changes occur in MAIL pattern distributions, as shown
in Fig. 4for the distributions of MAIL pattern ASSIGN.To
locate these areas one potential method is wavelet trans-
form analysis [9]asusedin[5,35] for segmentation of
files into segments as part of their malware detection tech-
nique.
The last row shows how the sizes of the files affect the
performance of the detector. The dataset used in the last row
contains additional benign files whose size ranges from 1
MB to 10 MB. Comparing the results in the last two rows,
the testing time does increase but just by 30 ms, the DR is
almost the same and the FPR increases only by 1.15. This
shows that the sizes of the files have a very small effect on
the results and can be neglected. Therefore we can say that
the performance (DR and FPR, and to a certain extent testing
time) of the proposed scheme is almost independent of the
size of the files. To make this claim certain, in future work it
will be validated with more such experiments.
123
Author's personal copy
Sliding window and control flow weight
Tabl e 4 Comparison of SWOD-CFWeight with the malware detection techniques discussed in Sect. 2
Technique Analysis type DR FPR Dataset size Real time Platform
Benign/Malware
SWOD-CFWeight Static 99.08 % 0.93 % 1101/250 Win & Linux 64
Opcode-HMM-Wong [39] Static ∼90 % ∼2 % 40/200 ×Win & Linux 32
Chi-Squared [36] Static ∼98 % ∼2 % 40 / 200 ×Win & Linux 32
Opcode-HMM-Austin [4] Static 93.5 % 0.5 % 102/77 ×Win & Linux 32
Opcode-SD [33] Static ∼98 % ∼0.5 % 40/800 ×Linux 32
Opcode-Graph [30] Static 100 % 1% 41/200 ×Win & Linux 32
Opcode-Histogram [28] Static 100 % 0 % 40/60 ×Win & Linux 32
Opcode-Seqs-Santos [31] Static 96 % 6 % 1000/1000 ×Win 32
Opcode-Seqs-Shabtai [32] Static ∼95 % ∼0.1% 20416/5677 ×Win 32
Some of the above techniques, need more number of benign samples (more than 40/41) than tested in the papers for further validation. The DR and
FPR values for Opcode-HMM-Wong and Chi-Squared were determined (approximated for the best DR and FPR) from the ROC curves shown in
Figure 8 in [36] for a 10 % of dead code. The DR and FPR values for Opcode-SD were determined (approximated for the best DR and FPR) from
the ROC curve for a padding ratio of 2.0. The DR and FPR values for Opcode-Graph are not directly mentioned in the paper. We computed these
values by picking a threshold of 0.5 from the similarity score in the paper
5.3 Comparison with existing approaches
Table 4gives a comparison of SWOD-CFWeight with the
existing opcode-based malware detection approaches dis-
cussed in Sect. 2. None of the prototype systems’ current
implementations can be used as a real-time detector. Most of
the techniques, such as Chi-Squared,Opcode-SD,Opcode-
Graph and Opcode-Histogram show good results, and some
of them may have the potential to be used in a real-time detec-
tor by improving their implementation. Opcode-Seqs-Santos
and Opcode-Seqs-Shabtai also show impressive results but
do not yet support detection of metamorphic malware.
SWOD is a window that represents differences in MAIL
pattern distributions (instead of opcodes) and hence makes
the analysis independent of different compilers and plat-
forms, compared to existing techniques. The SWOD size can
be changed. This property gives a user (an anti-malware tool
developer) the ability to select appropriate parameters for a
dataset to further optimize malware detection.
All the systems use the frequency of occurrence of
opcodes to capture the execution flow of a program, but fail
to capture the control flow of a program that changes its own
execution flow. CFWeight proposed in this paper include this
information to an extent that helps detect metamorphic mal-
ware.
Table 4reports the best DR result achieved by the detec-
tion techniques discussed in Section 2. Out of the 9 tech-
niques, SWOD-CFWeight clearly shows superior results and,
unlike others supports metamorphic malware detection for
64 bit Windows (PE binaries) and Linux (ELF binaries) exe-
cutable files and has the potential to be used in a real-time
detector.
6 Conclusion
In this paper, we have proposed a novel malware detection
technique named SWOD-CFWeight. We have shown through
experimental evaluation that it is effective for metamorphic
malware analysis and real-time detection. We have also com-
pared the new proposed technique with other such detection
techniques. SWOD-CFWeight mitigates and addresses issues
related to the change of the frequency of opcodes in a pro-
gram, through the use of different compilers, compiler opti-
mizations, and platforms. CFWeight includes control flow
information to an extent that helps reduce the execution time
considerably from other techniques (that also use control flow
information) and results in a high detection rate for metamor-
phic malware detection.
In the future, we will explore different methods to select
samples from the dataset to compute an optimal size of
SWOD. We will also investigate the performance of our pro-
posed technique using much larger files (over 10 MB) and
larger dataset. Keeping in view the ubiquitousness of multi-
cores in the host machines and to further optimize the run-
time, we plan to parallelize the implementation of SWOD-
CFWeight. Disassembling and extracting the opcodes from
a binary file is an expensive step. To avoid this step and fur-
ther optimize the performance, in the future we would like
to apply the tranformation-based techniques for detecting
metamorphic malware [5], to SWOD-CFWeight. To further
analyse the strength of MAIL patterns for metamorphic mal-
ware detection, we will explore using hidden Markov model
analysis [39] based on MAIL patterns instead of opcodes.
Since metamorphic malware is a challenging test case, we
believe that our proposed technique can also be effectively
123
Author's personal copy
S. Alam et al.
used for the detection of other malware and would like to
carry out such experiment in the future.
References
1. Aho, A.V., Lam, M.S., Sethi, R., Ullman, J.D.: Compilers: Princi-
ples, Techniques, and Tools, 2nd edn. Addison-Wesley Longman
Publishing Co. Inc, Boston (2006)
2. Alam, S., Nigel Horspool, R., Traore, I.: MAIL: malware analysis
intermediate language—a step towards automating and optimizing
malware detection. In: Security of Information and Networks, SIN
’13, New York, NY, USA, November 2013. ACM SIGSAC (2013)
3. Alam, S., Nigel Horspool, R.,Traore, I.: MARD: A framework
for metamorphic malware analysis and real-time detection. In:
Advanced Information Networking and Applications, Research
Track—Security and Privacy, AINA ’14, Washington, DC, USA,
May 2014. IEEE Computer Society, New York (2014)
4. Austin, T.H., Filiol, E., Josse, S., Stamp, M.: Exploring hidden
Markov models for virus analysis: a semantic approach. In: 46th
Hawaii International Conference on System Sciences (HICSS),
2013, pp. 5039–5048 (2013)
5. Baysa, D., Low, R.M., Stamp, M.: Structural entropy and meta-
morphic malware. J. Comput. Virol. Hacking Tech. 9(4), 179–192
(2013)
6. Bilar, D.: Opcodes as predictor for malware. Int. J. Electron. Secur.
Digit. Forensics 1(2), 156–168 (January 2007)
7. Bruschi, D., Martignoni, L., Monga, M.: Detecting self-mutating
malware using control-flow graph matching. In: DIMVA, 2006, pp.
129–143. Springer, Berlin (2006)
8. Cormen, T.H., Leiserson, C.E., Rivest, R.L., Stein, C.: Introduction
to Algorithms, 3rd edn. The MIT Press, Cambridge (2009)
9. Daubechies, I.: Ten lectures on wavelets. SIAM 61, 1–357 (1992)
10. Deshpande, S., Park, Y., Stamp, M.: Eigenvalue analysis for meta-
morphic detection. J. Comput. Virol. Hacking Tech. 10(1), 53–65
(2014)
11. Eagle, C.: The IDA Pro Book: The Unofficial Guide to the World’s
Most Popular Disassembler. No Starch Press, San Francisco (2008)
12. Faruki, P., Laxmi, V., Gaur, M.S., Vinod, P.: Mining control flow
graph as API call-grams to detect portable executable malware. In
Security of Information and Networks, SIN ’12, New York, NY,
USA, 2012. ACM SIGSAC (2012)
13. Filiol, E.: Metamorphism, formal grammars and undecidable code
mutation. Int. J. Comput. Sci. 2(1), 70–75 (2007)
14. Flake, H.: Structural comparison of executable objects. In: Flegel,
U., Meier, M. (eds.) DIMVA. LNI, vol. 46, pp. 161–173. GI (2004)
15. G2.: Second Generation Virus Generator. http://vxheaven.org/vx.
php?id=tg00. Accessed 28 July 2014
16. Ghiasi, M., Sami, A., Salehi, Z.: Dynamic malware detection using
registers values set analysis. In: Information Security and Cryptol-
ogy, pp. 54–59 (2012)
17. Guo, H., Pang, J., Zhang, Y., Yue, F., Zhao, R.: Hero: a novel
malware detection framework based on binary translation. In: ICIS,
2010, vol. 1, pp. 411–415 (2010)
18. Jakobsen, T.: A fast method for cryptanalysis of substitution
ciphers. Cryptologia 19(3), 265–274 (1995)
19. Sparck Jones, K.: A statistical interpretation of term specificity and
its application in retrieval. J. Documentation 28, 11–21 (1972)
20. Kirda, E., Kruegel, C., Banks, G., Vigna, G., Kemmerer R.A.:
Behavior-based spyware detection. In: Proceedings of the 15th
Conference on USENIX Security Symposium, vol. 15, USENIX-
SS’06, Berkeley, CA, USA, 2006. USENIX Association (2006)
21. Kruskal, J.B.: Multidimensional scaling by optimizing goodness
of fit to a nonmetric hypothesis. Psychometrika 29, 1–27 (1964)
22. Kuzurin, N., Shokurov, A., Varnovsky, N., Zakharov, V.: On the
Concept of software obfuscation in computer security. In: Proceed-
ings of the 10th International Conference on Information Security,
ISC’07, pp. 281–298. Springer, Berlin (2007)
23. Lin, D., Stamp, M.: Hunting for undetectable metamorphic viruses.
J. Comput. Virol. 7(3), 201–214 (2011)
24. Linn, C., Debray, S.: Obfuscation of executable code to improve
resistance to static disassembly. In: ACM CCS, pp. 290–299. ACM,
New York (2003)
25. Sridhara, S.M., Stamp, M.: Metamorphic worm that carries its own
morphing engine. J. Comput. Virol. Hacking Tech. 9(2), 49–58
(2013)
26. NGVCK: Next Generation Virus Construction Kit. http://
vxheaven.org/vx.php?id=tn02. Accessed 28 July 2014
27. OKane, P., Sezer, S., McLaughlin, K.: Obfuscation: the hidden
malware. IEEE Secur. Privacy 9(5), 41–47 (September 2011)
28. Rad, B.B., Masrom, M., Ibrahim, S.: Opcodes histogram for classi-
fying metamorphic portable executables malware. In: ICEEE, pp.
209–213 (2012)
29. Robertson, S.: Understanding inverse document frequency: on the-
oretical arguments for idf. J. Documentation 60 (2004)
30. Runwal, N., Low, R.M., Stamp, M.: Opcode graph similarity and
metamorphic detection. J. Comput. Virol. 8(1–2), 37–52 (May
2012)
31. Santos, I., Brezo, F., Ugarte-Pedrero, X., Bringas, P.G.: Opcode
sequences as representation of executables for data-mining-based
unknown malware detection. Inf. Sci. 231, 64–82 (2013). Data
Mining for Information Security
32. Shabtai, A., Moskovitch, R., Feher, C., Dolev, S., Elovici, Y.:
Detecting unknown malicious code by applying classification tech-
niques on opcode patterns. Secur Inform 1(1), 1–22 (2012)
33. Shanmugam, G., Low, R.M., Stamp, M.: Simple substitution dis-
tance and metamorphic detection. J. Comput. Virol. Hacking Tech.
9(3), 159–170 (2013)
34. Song, F., Touili, T.: Efficient malware detection using model-
checking. In: Giannakopoulou, D., Mery, D. (eds.) FM: Formal
Methods. Lecture Notes in Computer Science, vol. 7436, pp. 418–
433. Springer, Berlin (2012)
35. Sorokin, I.: Comparing files using structural entropy. J. Comput.
Vir ol . 7(4), 259–265 (2011)
36. Toderici, A.H., Stamp, M.: Chi-squared distance and metamorphic
virus detection. J. Comput. Virol. 9, 1–14 (2013)
37. Vinod, P., Laxmi, V., Gaur, M.S., Chauhan G.: MOMENTUM:
metamorphic malware exploration techniques using MSA signa-
tures. In: IIT, pp. 232–237 (2012)
38. Weisstein, E.W.: Chi-squared test. In: MathWorld—A Wolfram
Web Resource. Wolfram Research Inc. http://mathworld.wolfram.
com/Chi-SquaredTest.html. Accessed 28 July 2014
39. Wong, W., Stamp, M.: Hunting for metamorphic engines. J. Com-
put. Virol. 2, 211–229 (2006)
40. Yin, H., Song, D.: Privacy-breaching behavior analysis. In: Auto-
matic Malware Analysis, Springer Briefs in Computer Science, pp.
27–42. Springer, New York (2013)
41. Zuo, Z., Zhu, Q., Zhou, M.: On the time complexity of computer
viruses. IEEE Trans. Inf. Theor. 51(8), 2962–2966 (2005)
123
Author's personal copy
