Analysis, Anti-Analysis, Anti-Anti-Analysis

38 Pages·2017·0.31 MB·English

Analysis, Anti-Analysis,
Anti-Anti-Analysis: An Overview of the Evasive Malware Scenario
MarcusBotacin1,VitorFalcãodaRocha1,PauloLíciodeGeus1,AndréGrégio2
1InstitutodeComputação(IC)
UniversidadeEstadualdeCampinas(Unicamp)
Campinas–SP–Brasil
2DepartamentodeInformática(DInf)
UniversidadeFederaldoParaná(UFPR)
Curitiba–PR–Brasil
Abstract. Malicious programs are persistent threats to computer systems, and their
damagesextendfromfinanciallossestocriticalinfrastructureattacks. Malwareanalysis
aimstoprovideusefulinformationtobeusedforforensicproceduresandcountermeasures
development. Tothwartthat,attackersmakeuseofanti-analysistechniquesthatpreventor
difficulttheirmalwarefrombeinganalyzed. Thesetechniquesrelyoninstructionside-effects
andthatsystem’sstructurechecksareinspection-aware. Thus,detectingevasionattempts
isanimportantstepofanysuccessfulinvestigativeprocedure. Inthispaper, wepresent
a broad overview of what anti-analysis techniques are being used in malware and how
theywork,aswellastheirdetectioncounterparts,i.e.,theanti-anti-analysistechniquesthat
maybeusedbyforensicinvestigatorstodefeatevasivemalware. Wealsoevaluatedover
onehundredthousandsamplesinthesearchofthepresenceofanti-analysistechniqueand
summarizedtheobtainedinformationtopresentanevasion-awaremalwarethreatscenario.
1. Introduction
Malicioussoftware,alsoknownasmalware,isapieceofsoftwarewithmaliciouspurposes. Malware
actionscanvaryfromdataexfiltrationtopersistentmonitoring,causingdamagestobothprivateand
publicinstitution,eitheronimageorfinancialaspects. AccordingtoCERTstatistics[Cert.br2015],
malwaresamplesmayaccountbymorethan50%oftotalreportedincidents.
Given this scenario, analysts are required to analyze malicious samples in order to provide either
defensiveproceduresormechanismstoprevent/mitigatetheinfection,aswellastoperformforensic
proceduresonalreadycompromisedsystems. Thesetoftechniquesusedforsuchkindofinspection
isknownasmalwareanalysis. Analysisprocedurescanbeclassifiedintostatic,wherethereisnoneed
torunthecode,anddynamic,wherecoderunsoncontrolledenvironment[SikorskiandHonig2012].
Thescopeofthisworkislimitedtostaticprocedures,sincetheyarethefirstlineofdetectionagainst
evasivemalware.
Consideringmalwareanalysiscapabilitesandpeculiarities,criminalsstartedtoprotecttheirartifacts
frombeinganalyzed,equippingthemwithso-calledanti-analysis(oranti-forensics)techniques. This
way,theirinfectioncouldlastlongersincetheycouldmaketheirsamplesstealth. Recentstudies,such
as[Brancoetal. 2012],presentscenariosinwhich50%ofsamplescontainatleastoneanti-analysis
technique,andthisnumberhasbeengrowingconstantly.
Inordertokeepsystemsprotectedfromsuchnewarmoredthreats,weneedtounderstandhowthese
anti-analysis techniques work so as to develop ways to effectively detect evasive samples before
theycanact. Thisiscalledanti-anti-analysis. Inthispaper,wepresentthemodusoperandibehind
suchkindoftechniques,aswellaspossibledetectionmethodsindetails. Weevaluatedthedeveloped
solutionagainstoverahundredthousandsamples,benignandmalicious,whichallowedustobuild
an evasive scenario panorama. We also compared evasive techniques used on different contexts
(distinctcountries),whichcanhelpanalyststobeaheadofthenextcomingthreats.
This work is organized as follows: Section 2 introduces basic concepts related to anti-analysis
techniquesanddiscussesrelatedworkandtoolsaimedatdetectinganti-analysistechniques;Section3
describesanstudyofhowdistinctevasiontechniqueswork,andpresentsourdetectionframework;
Section4showstheresultsobtainedfromapplyingoursolutiontodistinctdatasets;finally,Section5
presentsconcludingremarksandfuturework.
2. BackgroundandRelatedWork
Inthissection, wepresenttheconceptsrelatedtoanti-analysisandtheirdetectioncounterpartsas
wellasintroducethecurrentstate-of-the-artsolutions.
2.1. Anti-analysis
The main idea of anti-analysis techniques is to raise the bar of counteraction methods. It can be
doneinmanyways,e.g.,leveragingtheorethicalhard-to-computeconstructions. InthisSection,we
provideanoverviewofsuchanti-analysistechniques.
Onecommonapproachistofingerprinttheanalysisenvironment. Knownanalysissolutionsexpose
regularpatterns,suchasfixedIPaddresses,hostnames,andserialnumbers. Evasivesamplescan
detect those patterns and suspend their execution [Yokoyamaetal. 2016]. This type of approach
wassuccesfullyusedagainstCuckoo[Ferrand2015]andEther[Péketal. 2011]sandboxes.
Anotherapproachistoevadeanalysisbydetectingexecutionsideeffectsofvirtualmachinesand
emulators, which has been the most used enviroment for malware analysis. Those systems may
exhibit a differing behavior when compared to their bare-metal counterparts, such as instructions
notbeingatomic[Willemsetal. 2012]. Currently,thereareautomatedwaysofdetectingtheseside
effects[Palearietal. 2009]. VirtualMachinescanalsobedetectedbythechangesthathypervisors
performonsysteminternals(e.g.,tablerelocations). Manytables,suchastheInterruptDescriptor
Table(IDT),havetheiraddresseschangedonVMswhencomparedtobare-metalsystems. These
addressescanthenbeusedasanindicatorofavirtualizedenvironment[Ferrie2007].
Therealsoapproachesbasednotonevadingtheanalysisitself,butonhardeningthepost-infection
reverse engineering procedure. One notable technique is the anti-disassembly, a way of coding
wherejunkdataisinsertedamonglegitimatecodetofoolthedisassemblertool. Anothervariation
ofanti-disassemblytechniquesistouseopaqueconstants[Kruegeletal. 2007],constructionsthat
cannot be solved without runtime information. Static attempts to guess resulting values of these
expressionstendtoleadtothepathexplosionproblem[Xiaoetal. 2010].
Finally, there are samples that make use of time measurement for analysis detection, since any
monitoringtechniqueimposessignificantoverheads[Lindorferetal. 2011]. Althoughsomesolutions
try to mitigate this problem by faking time measures, either on system APIs [Singh2014], or on
the hardware timestamp counter [Hexacorn2014], the problem is unsolvable in practice, since an
advancedattackercanmakeuseofanexternelNTPserveroverencryptedconnections.
2
Anotableexampleofanti-analysistoolis pafish [Pafish2012],whichconsistsofaseriesofmod-
ulesthatimplementmanyofmentioneddetectiontechniques,suchasvirtualmachinesdetectionand
environmentfingerprints. Thetool’sintentionistobeusedasverifierforanyattemptoftransparent
solution,aswellastoallowforabetterunderstandingofpracticalmalwareevasiontechniques.
2.2. Anti-Anti-Analysis
Aswellastheanti-analysistechniques, theanti-anti-analysisonesmayalsobeclassifiedasstatic
ordynamicapproaches. Staticapproachescanbeappliedintheformofpatternmatchingdetectorsof
knownanti-analysisconstructions,forinstance,addressverificationsandlocations. However,dueto
itsknownlimitations,someconstructionscanonlybesolvedduringruntime,whichisaccomplished
whentheyruninsidedynamicenvironments.
Dynamicsolutions,inageneralway,arebasedonfakinganswersforknownanti-analysischecks,
such as in COBRA [VasudevanandYerraballi2006]. These approaches, however, turn into an
arms-race,sincenewanti-analysistechniquesareoftenreleasedandthesesystemsneedtobeupdated.
To minimze the impact of this issue, transparent analysis systems have been proposed, such as
Ether[Dinaburgetal. 2008]andMAVMM[Nguyenetal. 2009]. Thesesystems,however,impose
highoverheadsanddevelopmentcosts.
In the following sections, we review the anti-anti-analysis techniques for the above presented
anti-analysisclassesandpresentstaticdetectorsforthesetechniques. Weleftdynamicdetectorsfor
futurework,sincetheyarenotpartofthiswork’sscope.
2.3. State-of-the-artofanti-anti-analysis
Ourworkisrelatedtomanydetectionsolutions. Twonoticeableonesarepyew [Pyew2012]and
peframe [Peframe2014], which aim to detect the evasive technique itself, and not whether a
tool/system/environmentmaybeevadedornot. Theyworkbystaticallylookingforknownshellcodes
andlibraryimportsrelatedtoanalysisevasion. Inthiswork,wehaveexpandedthesesdetectorsin
ordertoproviderabroadercoverage.
Inadditiontotheaforementionedtools,ourworkrelatestotheonepresentedby[Brancoetal. 2012],
whichimplementedseveralanti-anti-analysisdetectorsandanalyzedevasivesamples. Inthiswork,we
haveimplementedboththeanti-analysistechniquesaswellasthepresentedstaticdetectors,applying
themagainstourdistinctdatasets,andenrichingtheiranalysiswiththediscussionoftheworkingflow
ofthementionedtechniques. Wealsoproceedinthesamewayregardingtheworkby[Ferrie2008].
At the time we were writing this article, we have noticed a related work implementing similar
techniques[Oleg2016]. Suchwork,however,islimitedtoimplementationissueswhereaswepresent
acomprehensivediscussionandresultsevaluation.
Other related approaches, although more complex, are those which rely on using intermediate
representations (IR) [Smithetal. 2014] or interleaving instructions [Salehetal. 2014], cases not
coveredbythiswork. Thisworkalsodoesnotcoverobfuscationtechniquesbasedonencryption.
Thisissuewasaddressedbyotherwork,suchas[Calvetetal. 2012].
3. Anti-AnalysisTechniquesandDetection
In this section, we summarize the anti-analysis techniques, their operation, and how they
can be detected. The techniques were originally described in the previously presented
3
works[Brancoetal. 2012,Ferrie2008,Pyew2012,Peframe2014,Pafish2012,Oleg2016]andare
hereclassifiedaccordingtotheirpurpose: anti-disassembly,anti-debugging,andvirtualmachinede-
tection. Thecompletediscussionofeachtrickispresentedontheappendix1,duetospaceconstraints.
3.1. Anti-disassembly
Tounderstandhowdisassemblycanturnintoahardtask,wefirstintroducehowcurrentdisassemblers
work. Afterthat,wepresentknowntrickstodetectevasion.
Ingeneral, disassemblerscanbeclassifiedinto linear sweep and recursive traver-
sal approaches[Schwarzetal. 2002]. Intheformer,thedisassemblyprocessstartsatthefirstbyte
ofagivensectionandproceedssequentially. Themajorlimitationofthisapproachisthatanydata
embeddedinthecodeisinterpretedasaninstruction,leadingtoawrongfinaldisassembledcode.
Thelatterapproachtakesintoaccountthecontrolflowoftheprogrambeingdisassembled,following
the possible paths from the entry point, which solves part of problems presented by the linear
approach,suchasidentifying jmp-preceededdataascode. Themajorassumptionofthisapproach
isthatitispossibletoidentifyallsucessorsofagivenbranch,whichisnotalwaystrue,sinceany
failonidentifyingtheinstructionsizecanleadtoincorrectpathsandinstructions.
3.1.1. Tricks
Table1showsasummaryofanti-disassemblytechniquesandtheirdetectionmethods2.
Table1. Anti-disassemblytechniquesandtheirdetectionmethods.
Technique Description Detection
PUSH and POP avalue Detectasequenceof
PUSHPOP
on/fromthestack PUSH and POP
MATH
insteadofusingadirect MOV on/fromaregister.
PUSH avalueonthestackand RET Detectasequenceof
PUSHRET
toitinsteadoftheordinaryreturn. PUSH and RET
Getloadedlibrarydirectly
LDRaddress Checkmemoryaccessreferring
fromthePEBinsteadof
resolving thePEBoffset.
usingafunctioncall
StealthAPI Manuallyresolvinglibraryimports Checkforasequenceof
import insteadofdirectlyimportingthem. access/comparesofPEBsoffsets.
Breakspatternmatchingby Detectasequenceof NOPs
NOPsequence
implantingNO-OPerations withinagivenwindow
Checkforbranch-succeded
FakeConditional Createanalways-takenbranch
instructionswhichsetbranchflags
Changingcontrolflowwithin Checkforthe PUSH-RET
ControlFlow
aninstructionblock instructionsequence
GarbageBytes Hidedataasinstructioncode Checkforbranch-preceededdata
1 https://github.com/marcusbotacin/Anti.Analysis/tree/master/Whitepaper 2 De-
scribedbyBrancoetal.2012
4
3.2. Anti-Debug
In order to understand how anti-debug techniques work, we firstly introduce the basic idea of
mosttricks: usingdirectmemorychecksinsteadoffunctioncalls. Secondly,wepresentthetricks
themselves.
3.2.1. KnownAPIxDirectcall
MostO.S.providesupportfordebuggingchecks. Windows,forinstance,providesthe IsDebug-
gerPresent API[Microsoft2016]. Mostanti-debugtricks,however,donotrelyontheseAPIs,
but perform direct calls instead. The main reason behind such decision is that APIs can be easily
hooked by analysts, thus faking their responses. Internal structures, in turn, such as the process
environment block (PEB) [Microsoft2017c], are much harder to fake — some changes can even
breaksystemparts.
3.2.2. Tricks
Table2presentsasummaryofanti-debugtechniquesandtheirdetectioncounterparts345.
Table2. Anti-debugtechniquesandtheirdetectionmethods.
Technique Description Detection
KnownDebugAPI Calladebug-checkAPI CheckforAPIimports
Checkthepresenceofknown CHeckknownstrings
DebuggerFingerprint
debuggerstrings insidethebinary
Checkforflagsinsidethe Checkforaccesson
NtGlobalFlag
PEBstructure thePEBoffset
Checkthedebuggerflag CheckaccesstoPEBon
IsDebuggerPresent
onthePEBstructure thedebuggerflagoffset
Verifywhetherafunction Checkfora CMP instruction
HookDetection
entrypointisa JMP instruction having JMP opcodeasanargument
checkforheapchecks
HeapFlags CheckforheapflagsonthePEB
involvingPEBoffsets
Checkwhetherhardware Checkforaccess
HardwareBreakpoint
breakpointregistersarenotempty involvingthedebuggercontext
Insertacheckwhen
SSRegister CheckforSSregister’s POPs
interruptionsaredisabled
SoftwareBreakpoint Checkforthe INT3 instruction Checkfor CMP with INT3
SizeOfImage Changecodeimagefield CheckforPEBchanges.
3.3. Anti-VM
Asummaryofanti-analysistricksusedbyattackerstoidentifyandevadevirtualizedenvironments
isshowninTable367.
3 APIcheckimplementedbyPyewandPeframe 4 SizeOfImageimplementedbyFerrie2008 5 Othertechniques
implementedbyBrancoetal.2012 6 VMfingerprintimplementedbyPafish 7 OthertechniquesbyBrancoetal.2012
5
Table3. Anti-vmtechniquesandtheirdetectionmethods.
Technique Description Detection
Checkforknownstrings, Checkforknownstrings
VMFingerprint
suchasserialnumbers insidethebinary
CheckforknownCPU
CPUIDCheck CheckCPUvendor
vendorstrings
Launchhypervisor-specific Checkforspecificinstrutions
InvalidOpcodes
instructions onthebinary
SystemTableChecks CompareIDTvalues LookforchecksinvolvingIDT
HyperCallDetection Platformspecificfeature Lookforspecificinstructions
3.4. DetectionFramework
Giventhepresenteddetectionmechanisms,wehaveimplementedthembyusingaseriesofPython
scripts8. They work by iterating over libopcodes-disassembled instructions, and performing
apatternmatchingonthese,accordingthetrickwearelookingfor. Ourpipelineisabletoprovide
theinformationwhetheragiventechniquewasfoundonabinaryornot,thenumberofoccurrences
perbinary,andthesectionthetrickwasfound.
Unlike Branco et al. 2012 approach, which considered the RET instruction as a code block
delimiter,wehaveimplementedavariable-sizewindowdelimitertoevaluateifthetricksmayhave
beenimplementedbymakinguseofmulti-blockconstructions.
4. Results
Inthissection,wepresenttheresultsofapplyingoursetofdetectorstodistinctdatasetsanddiscuss
howanti-analysistrickshavebeenappliedinpractice.
4.1. Binarysections
Hereweshowthebinarysectioninfluenceonthetrickdetection. Inordertoperformthisevaluation,
weconsideredadatasetof70thousandworldwidecrawledsamples.
Figure1showsthedetectiondistributionalongthebinarysections. Itisworthtonoticethattheusual
instruction section (text) is only the 5th more prevalent section. The presence of other sections
canbeduetosamplesmovingtheirtrickstodinstinctsectionsinordertonotbedetectedbyanti-virus
(AV). This fact can only be exactly determined through dynamic analysis. The presence of some
sectionsuchas .aspack,forinstance,isduetothepresenceofapackertoobfuscatethecode.
Figure2showsthatthetrickscontainedinthe .text sectioncorrespondtohalfofthetotaltricks
detected. Themostprevalenttechniques,suchas PushPop and PushRet,arethemostsimple.
4.2. Packerinfluence
In the last section, we could see that sections related to packer obfuscation were identifyed. In
this section, we discuss the packer influence on trick detection. The first noticeable situation is
that the tricks detected on packed samples are not equally distributed among sections, as shown
in Figure 3. We can observe that the C++ compiler and the PIMP packer exhibit tricks on the
.rsrc section,whereasthe UPX packerpresentstricksondistinctsections. Asimilarsituation
8 https://github.com/marcusbotacin/Anti.Analysis
6
Trick detection − total and .text section
90.0%
Trick detection by section Total
25.0% .Text
Sections 80.0%
70.0%
20.0%
60.0%
50.0%
15.0%
40.0%
10.0% 30.0%
20.0%
5.0% 10.0%
0.0%
0.0% .rsrc .rdata .reloc .data .text .None .idata .itext .aspack PushRet GarbageBytes ControlFlow PushPop SoftBreakpoint HookDetect NOP FakeConditional CPUInstr SSRegister
Figure 2. Tricks - total and .text
Figure1. Tricksbysection. section.
happenswhenconsideringthedetectedtricks,asshowninFigure4. The C++ compilerandthe
PIMP packerpresentssimilarratesoftrickswhilethe UPX packerpresentsdistincttricks. Finally,
inordertoevaluatethepackerinfluenceontrickdetection,weunpackedallsamplesforwhichthere
areknownunpackers(6thousandsamples),thusobtainingtheresultsshowninFigure5. Wecould
confirmourexpectationsthatthemajorityofthetricksarepresentonthepacker,notontheoriginal
code. Thisfactismostlyduetotheusageofmalwarekitgenerators.
Packer − section trick distribution Packer − section trick distribution
8.0% 6.0%
PIMP PIMP
C++ C++
7.0% UPX UPX
5.0%
6.0%
4.0%
5.0%
4.0% 3.0%
3.0%
2.0%
2.0%
1.0%
1.0%
0.0% 0.0%
.rsrc .rdata .text .reloc PushRet PushPop Garbage
Figure 3. Packer distribution across Figure 4. Tricks detected on distinct
binarysections. packers.
4.3. MalwareandGoodware
Someofthepresentedtricksarewidelyused,sotheycanbefoundeitheronbenignprograms(good-
ware)andmaliciousones. Toverifyifthedetectionofthoseaforementionedtrickscouldbeusedasa
maliciousprogramindicator,wecomparedthetrickincidentonbothprogramclasses,asshowninFig-
ure6. WeperformedourtestsusingasabenigndatasetthebinariesandDLLsfromacleanWindows
installation(binariesfromthe System32 directory). Wecanobservethatsomegeneraltricks(CPU
identification)canalsobefoundonsystemDLLs,butthesearenotpresentonthebinaries. Thisfact
isexplainedbytheWindowsarchitecture,whichreliesonDLLsforuserland-kernelcommunication.
Thisindicatesthatweneedtoemploydistinctappracheswhendevelopingheuristicsforexecutables
andDLLs. Weaimtoextendthisevaluationforgeneralbinaries,despitesystemones. However,it
ishardtoensureinternet-downloadedbinariesarenottrojanizedinanyway,thusbiasingtheresults.
7
Packer x Unpacked
95.0%
Packed
Unpacked
90.0%
85.0%
80.0%
75.0%
70.0%
65.0%
60.0%
55.0%
50.0%
PushPop PushRet Garbage ontrolFlow SoftBreak
C
Figure5. Packerinfluenceontrickdetection.
Malware x Goodware
90.0%
Malicious
WinBin
80.0% WinDLL
70.0%
60.0%
50.0%
40.0%
30.0%
20.0%
10.0%
0.0%
CPUInstr SoftBreak SRegister
S
Figure6. Tricksdetectiononmalwareandgoodware.
4.4. DistinctScenarios
The tricks prevalence differs across distinct datasets. In order to provide a view on how these
differences affect user in practice, we compared the worldwide crawled dataset9 to a dataset of
30 thousand brazillian collected samples10. Figure 7 shows the results of comparing the datasets
usingthePEframetool. Wecanobservethatthebrazilliandatasetpresentedhigherdetectionrates
forthe VmCheck andthe VirtualBox tricksandlowerfortheothers. Theseratesarequite
surprisingly,giventhepreviousresearchresultsregardingthebrazillianscenario. Whenperforming
the same checks using our developed tricks, as shown on Figure 8, we show that the brazillian
scenario presents lower trick rates than the worldwide one. This differences can be explained by
thefactthattheknowledgebehindthetricksdetectedbythePEframearemorespreaded,sincethey
are easier. More advanced tricks, suchas some of those we have presented in this work, are only
9 From http://malshare.com/ 10 ThesameasinBotacinetal.2015
8
presentonabroaderscenario,i.e.,theworldwidedataset.
Comparing Scenarios Comparing Scenarios
12.0% 100.0%
World World
Brazil Brazil
95.0%
10.0%
90.0%
85.0%
8.0%
80.0%
6.0% 75.0%
70.0%
4.0%
65.0%
60.0%
2.0%
55.0%
0.0% 50.0%
VmCheck Bochs Qemu Vbox Vmware VPC PushPop PushRet Garbage FakeCnd
Figure 7. Comparing scenarios: Figure8. Comparingscenarios: Tricks
PEframedetection. detection.
The presented results are in agreement with previous research results regarding the brazilian
scenario[Botacinetal. 2015].
4.5. Improvingtricksandtheirdetection
Inthissection,wepresentwaysthetrickscanbeenhancedandhowtodetectthem.
4.5.1. Tricksplitting
Awayofevadingthetrickdetectionistosplititacrossdistinctblocks. Althoughwecannotcheck
suchusageinpracticewithoutdynamicanalysis,wecanlookforsignsofspllited-tricksbychanging
the detection window, as show on Figure 9. The initial value is the RET window, on which we
traverse the block until the instruction is found. We considered the detection rate of this window
asagroundtruth,thuspresentingthe 100% detectedvalue. Theothervaluesarefixed-sizenumber
ofinstructionswhichwillbetraversed,thusincreasingthedetectionrate. Weobservedamaximum
increaseof 0.65%.
4.5.2. Instructiondisalignment
Another possible way of evading tricks detection is by using unaligned instructions, so the
disassemblerisnotabletopresentthecorrectopcode. Althoughwecouldonlychecktheeffective
usageofsuchapproachonadynamicsystem,wecanlookforstaticsignsofsuchusage. Inorder
todoso,wehaveimplementedsomedetectorsusingYARA11 rulesandrunningthemonthebinary
bytes. ThetestsresultsareshownintheTable4. Wehaveconsidered300randomsamples,beingthe
Aligned consideredasgroundtruth. Wecanobservethe Unaligned resultsaresignificantly
higher,indicatingitisaviablewayofhiddingcode.
11 https://virustotal.github.io/yara/
9
Detection Window
100.7
Window
100.6
100.5
100.4
100.3
100.2
100.1
100
RET 10 20 30 40 50 60 70 80 90 100
Figure9. Evaluatingblockwindoweffectontrickdetection.
Table4. Evaluatingtheoccurrenceofmisalignedtricks.
Trick Aligned Unaligned
CPU 182 287
FakeJMP 63 203
4.5.3. Compiler-basedtricks
Another way of hidding the trick is to compile the code using instructions unsupported by AVs
andothertoolsorindirectconstructions. TheROPitselfmalware[Pouliosetal. 2015],forinstance,
suggestedturningamalwaresampleintoaROP12 payload, approachwhichwasimplementedby
theRopinjectortool[Poulios2015]. TheSSexytool[Bremer2012]compilesthecodeusing SSE13
instructions. The Movfuscator [domas2015] does the same using XOR ones. Finally, the
work[Barngert2013]compilesacodetorunusingonly MMU instructions14. Inordertoverifythat
inpractice,wesubmitedsomeknownshellcodesfromExploitDBcompiledusingtheROPInjector
solution,beingtheresultsreportedintheTable5. WecannoticethattheAVwerenotabletodetect
thepayloadswhencompiledusingthetool.
Table5. Compilation-basedevasion.
ShellCode 115 216 317 418 519
Unarmored 4/57 15/58 9/57 7/68 9/53
ROPInjector 0/57 0/57 0/54 0/54 0/53
4.6. GeneralAVdetection
TheresultsfromtheprevioussectionsuggeststhatAVarenotabletohandlesometricks. Problems
onAVemulatorswerealsodescribedonotherwork[Nasi2014]. Wesubmittedtovirustotalsome
12 ReturnOrientedProgramming 13 StreamingSIMDExtensions 14 MemoryManagementUnit
10