HARES:HardenedAnti-ReverseEngineeringSystemTechnicalWhitepaperJacobI.T - PDF document

HARES:HardenedAnti-ReverseEngineeringSystemTechnicalWhitepaperJacobI.TorreyAssuredInformationSecurity,Inc.torreyj@ainfosec.com/@JacobTorreyABSTRACTThispaperprovidesatechnicaloverviewoftheHARESsoftwareprotectionresearcheortperformedbyAssuredInformationSecurity.HARESisanantireverse-engineeringtechniquethatuseson-CPUencryption[7]inconjunctionwithIntelx86TLB-splitting[12]inordertosignicantlyincreasetheeortrequiredtoobtaintheclear-textassemblyin-structionsthatcomprisethetargetx86application.Performanceanduse-casesofthesystemarepre-sented,andanumberofweaknessesandfutureworksarediscussed.RelatedworksarecomparedandcontrastedwithHARESinordertohighlightitsimprovementsoverthecurrentstate-of-the-art.CategoriesandSubjectDescriptorsC.0[ComputerSystemsOrganization]:Gen-eral|Systemarchitectures;D.2.0[SoftwareEn-gineering]:General|protectionmechanismsKeywordsSecurity,Obfuscation,Encryption,Split-TLB,AES,TRESOR1.INTRODUCTIONThispaperprovidesdetailsonthedesignandim-plementationoftheresearcheortHARES.HARESprovidesaproof-of-conceptcapabilitytotranspar-entlyexecutefully-encryptedbinariesonastan-dardIntelCPUwithminimalperformanceimpact.Thereareanumberofuse-casesforsuchacapa-bility:protectionofalgorithmicIP,providingresis-tancetominingforROPgadgetsandsignicantlyincreasingthedicultyof\weaponizing"acrash-caseintoaRCE.Backgroundisprovided,followedbydetailsontheHARESdesign,andanevaluationoftheproof-of-concept.Finallyrelatedworksandconclusionsarepresented.2.PROBLEMSTATEMENTThecurrentstate-of-the-artforprogramprotec-tionsarevulnerabletosucientlymotivatedat-tackersandreverse-engineers.Resultingfromtheseweaknesses,sensitivealgorithmscanbecopied,andvulnerabilitiesinsoftwareexploited.2.1BackgroundThisresearchbuildsuponnumerouspastresearcheortsandtechnologies,thefollowingsubsectionsprovidetherequisitebackgroundforagenerallytechnicalreadertofullyunderstandthemethodol-ogyofHARES.2.1.1Intelx86ArchitectureHARESsupportsthemodernIntelx86CPUarchi-tecture(Core-i4000seriesandnewer),amodied-HarvardCISCinstructionsetarchitecturecommonlyfoundontoday'sdesktopandlaptopcomputersys-tems.Thefollowingparagraphspresentadeep-diveintocertainfeaturesofthex86architecturewhichareleveragedbyHARESinordertoprovideantireverse-engineeringprotections.1 PrivilegeRings.InitiallyimplementedintheIn-tel80286,andextendedmorefullywiththe80386,privilegeringsand\protectedmode"providealevelofprotectionfrommisbehavingapplications.Priortoprotectedmode,theCPUoperatedin\realmode",whereeveryapplicationhadfullaccesstotheen-tirememoryspace,andtheabilitytodirectlycom-municatewithhardware.Ifarealmodeapplica-tionweretooverwriteacriticalportionofmemorystoringtheoperatingsystem(OS),therewerenoprotectivemechanismsinplacetopreventitfromdoingso.Inprotectedmode,theOSkernelcouldloadit-selfintoamoreprivileged\ring"thantheapplica-tionsitwassupportingandlimittheapplications'abilitytoimpactthesystemasawhole.Therearefour\ocial"privilegerings(0�3)andtwoorthreeothermodesofexecutionthataretypicallyreferredtoasrings�1;�2;&�3.ModernOSstypicallyutilizeonlytwooftheserings:ring-0fortheprivileged\kernel-mode"OSroutines,sched-ulerandinterrupthandlersandring-3forthe\user-mode"applicationswheretheyarelimitedintheirabilitiestoexecutecertaininstructions,accesspro-tectedmemoryregions,interactwiththehardware,generallytoimpactthesystemasawhole[5].Asthex86architecturehasevolvedandthescrutinyplacedonthelow-levelimplementationsincreasedinthesecuritycommunity,twomoreCPUmodeshavebeeninformallycalledrings:hypervisor(VMM)rootmode(ring�1)andsystemmanagementmode(ring�2).Ring�3isalsousedwhenreferringtoIntel'sActiveManagementTechnology(AMT),butisnotrelevantforthisresearch.Ring�1ismoreprivilegedthantheOSkernel,andisusedbyhypervisorstovirtualizemultipleOSeswith-outrequiringmodicationtotheOSkernel(full-virtualization).Thespecicsofring�1aredis-cussedlaterasHARESisimplementedasathin-hypervisor.Ring�2,morecommonlyknownassystemman-agementmode(SMM),isaparallelandhardware-enforcedstealthmodeofexecution.Itwasorig-inallydevelopedforBIOSandchip-setmanufac-turerstorunplatform-specicroutinesforpowerandthermalmanagementwithoutexposingthein-ternalstotheOS.WhentheCPUisexecutinginSMM,ithasafullviewofmemory,whilewhenex-ecutinginprotectedmode,thechip-setblocksac-cesstoSMMmemoryregions(SMRAM).Inorder Figure1:PagingTranslationonx861toswitchfromprotected(orrealmode)intoSMM,asystemmanagementinterrupt(SMI)isissuedtotheCPUandthehardwaresavesallCPUcontext,allowingtheSMMcodetoexecutewithouttheOSorhypervisordetectingitwasinterrupted.TheconditionsforthehardwaretogenerateanSMIaredenedviaanumberofchip-setregistersthatcanbelockedduringSMMinitialization[5].Paging&MemoryManagement.ModernCPUsprovidetheabilitytoprovideeachprocesswithauniqueviewofmemory[5].Thisfeature,knownasvirtualmemory,easestheOS'staskofisolatingdif-ferentapplicationsandprovidingeachapplicationwithadierentviewofmemory.Whenavirtualmemoryaddressisaccessedbyanapplication,theCPUusesanumberofdatastructurestoautomat-icallytranslatethevirtualaddressintoaphysicaladdress.Thisprocess,outlinedinFigure1,usestheCPU'sCR3registertondapagedirectoryandoptionallyapagetablethatholdsthephys-icaladdress.InmostmodernOSes,eachprocessisgivenitsownsetofpagetranslationstructurestomapthe4GiB atmemoryviewprovidedtothesystem'sphysicalmemory(assuminga32-bitOS).IntelVT-x,VT-d&EPT/VPID.Agrowingtrendininformationtechnologyistheuseofvirtualma-chines,orVMstoenabledata-centerconsolidation.Ahypervisor,orvirtualmachinemonitor(VMM),allowsmultipleOSestorunsimultaneouslyonthesamephysicalsystem,eachisolatedfromtheothersandprovidedwiththeappearanceofanormalsys-temenvironment.Whilesomehypervisorsrequire 1Imagefromhttp://viralpatel.net/taj/tutorial/image/paging.gif2 changestotheguestOS(para-virtualization)tofunctionproperly,manyleveragenewerCPUex-tensionstoallowanunmodiedOStorunwithonlyminorinteractionsfromthehypervisor.Theseextensions,knownasvirtualmachineextensions,orVT-xonIntel,improveperformancebyempow-eringtheCPUandchip-settoperformmoreoftheisolationandVMmemorymanagementinhard-wareasopposedtosoftware.VT-xallowsthehy-pervisortosetanumberofdierentexitconditionsforeachguestVMthat,whenmetwilltriggeraVMExit,returningcontroltothehypervisorforprocessing.AftertheinitialreleaseofVT-x,itwasdiscoveredin[15]thatitwaspossibletouseadevice'sdirectmemoryaccess(DMA)capabilitiestobypassVT-x'sprotectionsandcompromisethehypervisor.Inresponsetothisweakness,Intelreleasedtheexten-sionsfordirectedIO(VT-d),providingamemorymanagementunit(MMU)forIODMAmemoryac-cesses,preventingadevicefromdirectlyaccessingmainmemoryoutsideofitspolicy-proscribedre-gion(s).Inthelatestversionofhardwarevirtualizationex-tensions,IntelandAMDhavereleasedtheextendedpagetable(EPT)orrapidvirtualizationindexing(RVI)technologies,respectively.Theseallowthehypervisortotakeevenlessofaroleinthememorymanagementandisolationofeachguestbyprovid-inganotherlayerofpagingstructurestotranslatethephysicaladdressesthattheVMOSbelievestobethephysicaladdress(guestphysicaladdress)tothemachinephysicaladdress.TheCPUcanau-tomaticallytranslatetheseinasimilarfashiontoconventionalpagingandprovideaVMExit,anal-ogoustoapagefault,forthehypervisor.ThesetranslationsarestoredintheTLB,andtaggedwitheachguest'sVMprocessID(VPID)sotheyneednotbe ushedonVMcontextswitch.TheseaforementionedtechnologiessignicantlyaidthehypervisorinrunningmultipleVMsinaniso-latedfashionwithrelativelyminorperformanceim-pacts.TheimplementationinSection3extensivelyleveragesthesetechnologiestoperformtheTLB-splittingforuser-landWindowsapplications.TranslationLookasideBuffer(TLB).Thetrans-lationlookasidebuer,orTLB,actsacachefor Figure2:Core2andPreviousCPUArchi-tecture(TLBsHighlighted)3thesepagingtranslations.Duetorelativelyhighmemorylatencycomparedtocache-accessspeed,apagetranslationlookupisexpensiveintermsoftime;therefore,theseoperationsareoptimizedbycachingthevirtual-to-physicalmappingsintheTLB.Whilelogically,theTLBstoresthetransla-tionsforallaccessedaddressesinthesameregionofsilicon,thephysicalimplementationsplitstheTLB(Figure2)intotwo:oneforinstructionaddresses(I-TLB)andonefordataaddresses(D-TLB).Thisimplementationdetailisimportant,asitallowstheTLBtopointtodierentaddressesforinstructionfetchesascomparedtodataaccesses.Inearlierprocessors4,theTLBwasasingle-layer(L1)cachethat,inthesiliconwassplitintotwo:adataTLB(D-TLB)andinstructionTLB(I-TLB),fordataandinstructionfetchesrespectively.WiththereleaseoftheNehalemarchitecture5,asecondlayer(L2)cachewasintroduced,thesharedTLB(S-TLB)thatprovidesalargercacheforboththeI-TLBandD-TLBintheeventofanevictionfromtheL1,furtherreducingTLB\misses"andthere-sultantperformancehit.TheTLBoperatesinasimilarfashiontothereg-ularCPUcaches(L1,L2&L3)inthatittypicallydoes\therightthing",requiringminimalmanualmanagement.TheIntelarchitecturedoesprovideasmallnumberofinstructionsfor ushingtheTLB,eitherasingleentryormultipleentries.TheTLBis ushed(exceptingforpagesmarked\global"inthepagingstructures)whenthevalueoftheCR3CPUregisterischanged(typicallywhenswitching 3ImagefromIntelSoftwareDeveloperManual3A[5]4UptoandincludingCore-25TherstCore-iseriesprocessormicro-architecture3 processes).WiththeadditionofEPTandVPID,otherinstructionsthatoperatinginasimilarfash-ionwereintroducedtomanagedaVM-awareTLB.2.1.2TLB-SplittingTherehasbeensomepastworkthattookadvan-tageofthissplit-TLBnatureforbothdefensiveandmaliciouspurposesinthepast.InthePaX/GRSecurityproject,whoseaimwastohardentheLinuxOSfromattack,theno-execute(NX)bitwasemulatedbyoverloadingtheuser-supervisorbit(U/S)andsplittingtheTLBtopreventinstructionfetchestoaprotectedpage[9].Ontheoensiveside,theShadowWalkerroot-kit[11]builtuponthisworkaswellasworkdonetopreventself-verifyingap-plicationsfromdetectingcorruption[14].ShadowWalkerisdesignedtohidethepresenceofamali-ciouskerneldriverthroughTLB-splitting.Whenthisdriverisaccessedasdata,suchasbyananti-virustool,ShadowWalkerpointstheD-TLBto-wardstheunmodiedkernelregion,thushidingthecompromise.Whenthetargetsectionisexecuted,theI-TLBislledwiththeaddressofthemaliciousdriver'scode,allowingittorunasexpected.In[12],thenewNehalem(Core-iseries)micro-architectureisdiscussedandhighlightstheaddi-tionofanewsharedTLB(S-TLB).Withthisnewsecondlevelcacheforaddresstranslations,pre-viousworksnolongerwereabletomaintainthesplit-TLB.TheMoREworkprovidedthecapabil-ity,throughtheuseofthemoregranularpermis-sionsaordedbyEPTtoonceagainsimulatethissplitTLBenvironment,withminimalperformanceimpact.AES-NIInstructionSet.Intheaftermathof[13],Inteldevelopedahardware-basedAESimplemen-tationintheirmorerecentCPUoerings(Core-iseries4000andnew)inordertoincreasethechallengeofside-channelattacks.Theinstructionstoutilizethisimplementationwerecollectivelyre-ferredtoasAES-NI,ortheAdvancedEncryptionStandard-NewInstructions[5];AES-NIprovidesanimprovementinsecurityaswellasaperfor-manceenhancementfrombeinghardware-accelerated.2.1.3TRESORandOn-CPUAESIn[7],thenewAES-NIinstructionswereusedinaLinuxkernelpatchtoprovideon-CPUencryptionanddecryptionsupportwherethekeywaspro- Figure3:WindowsPEFileStructure8tectedfromcold-RAMattacks6.TRESORusedtheCPUdebugregisters(DR0-7)asakeystor-agemechanismanduseditspositioninthekerneltopreventapplicationsfromaccessingthoseregis-ters7.TRESORwouldhavetheuserinputthekeyintotheCPUdebugregistersduringearlyboottolimitthenumberofrunningapplicationsthatcouldinterceptthekey.2.1.4WindowsPEFormatModernWindowsOSapplicationsandkerneldriversarebinariesinaformatknownasportableexe-cutables(PE)(Figure3).Thisformatprovidestheapplicationordriverloaderwiththerequi-siteinformationtoloaditintomemory,adjustanyaddresseswhichmayhavebeenchangedandlinkinanysharedlibrariesbeforeexecution.Itdi-videsthebinaryintoanumberofdierentsections,someforcode(generallylabeled`.text'),somefordata(`.data')andotherinformationalsections.Oftheseextrasections,themostimportanttothisef-fortisthe`.reloc'section,whichliststhenumberandlocationofaddresseswhichmustbeupdatedatloadtimeifthecompile-timeaddressisdierentfromloadaddress. 6WhenRAMisbroughttoaverylowtemperature,itwillpersistitscontentsforaperiodoftime,al-lowinganattackertoinserttheRAMintoanothermachinetodumpthecontentsofmemory7DebuggingapplicationslikeGDBwillautomat-icallyswitchtousingsoftwarebreakpointsifthekernelreportsnofreedebugregisters8Imagefromhttp://i.msdn.microsoft.com/dynimg/IC155437.gif4 2.2ResearchQuestionThegoaloftheHARESresearchwastodetermineifaTRESOR-likesystemimplementedinconjunc-tionwithaTLB-splittingcapabilitywouldallowfortheapparentexecutionoffullyAES-encryptedapplicationswithoutrequiringsourceforthatbi-nary.Ifpossible,whatwouldthelimitations,secu-rityweaknessesandperformanceimpactsonsuchasystem.3.PROPOSEDSOLUTIONThebelowsubsectionsdescribeHARES,describedincomponentsthattogethercomprisetheresearchprototype.Theorderingofthefollowingsubsec-tionsareinlinewithhowtheresearcheortpro-gressed,andshouldprovidethereaderwithapic-tureofthe\journey".3.1AES-NIinVMMInordertominimizetheduplicationofeort,HARESwasbasedupontheopen-sourceVMMTLB-splittingcapabilityprovidedbyMoRE[12].MoREwasathin-VMMforWindows7(32-bit,noPAE)thataddedtherequisitefunctionalitytosimulateasplit-TLBtothe`vmcpu'root-kit.InorderforHAREStoprotecttheAES-NIkeysfromacompromisedOSkernelandtointegratesmoothlywiththeMoREcode,theon-CPUAES-NIroutines(usingthede-bugregisters)fromTRESORwere\hoisted"totheVMMandtheprotectionsagainstanOSorap-plicationfromreadingtheregistersweremovedtotheVMMlayer.Thiswasdonebyaddingdebugregisteraccesses(readandwrite)totheVMExitconditionsintheVMcontrolstructure(VMCS)fortheVM.TheVMMhandlerfortheseexitswouldeitherreturnazerovalueforreadstoallregistersorsilentlydiscardwrites9.AsMoREwasinitiallydevelopedforoperationin32-bitmode,only128-bitAESkeysaresupported.Theauthorshoweverseenobarriertoaddingsup-portfor256-bitkeylengthsona64-bitversionofHARES.3.2AESEncryptionofPEExecutablesOncetheHARESVMMcouldperformon-CPUroutinesforAESdecryption,atoolwascreatedtotakeasinputaPE.exele,andoutputitwithall 9Infuturework,weanticipateengineeringamorecompatiblesolutionthatdoesnotinterferewithapplicationdebuggingoperationthesectionsmarkedasexecutableAESencrypted.ThisprocessrequiredparsingthePEstructuresinordertolocateallthecodesectionsinthebi-nary,leavingthemeta-datastructuresanddatasectionsuntouched.InSection4.2.1,wediscussthechallengesthataroseduringthisprocess,andhowthisisaextremelydicultoperationtoperformcorrectly.Inbrief,manycompilerswillcompresstheoutputbinarybyinterleavingcodeanddataintothesamesection,thuswhenrunbyHARES,theapplicationwouldnotfunctionproperlyascer-taindatastructureswereencryptedandaccessedasdata.Wewilldiscussourcurrentwork-aroundforthisissueinSection4.2.1.3.3WindowsProcessCreationMoni-toringTheHARESVMMislaunchedthroughaco-operativeWindowskerneldriver,whichviahyper-calls,caninteractwiththeVMMfromring-0.Thisdriverregistersanewcallbackforprocesscreation:con-guringtheOStonotifythedrivereverytimeanewapplicationisstarted.Ifthenewly-startedap-plicationisnotencrypted,thedriverwillperformnoaction,allowingtheapplicationtooperateasusual.OnceaHARES-protectedapplicationisstarted,thedriverwillperformanumberofactionsinordertoallowtheOStoseamlesslyexecutetheprogram.Alimitationofthecurrentprototypeistherequire-menttolocktheprogram'sencryptedpagesintonon-pagedmemory.ThisisneededasOSeswillpageoutunusedmemorypagestodiskuntiltheyareneededinordertofreeupRAMforotherpro-cesses.SincethegoalofHARESistoacttranspar-entlytotheOSanduser,iftheOSweretopageoutanapplication'spageandreplaceitwithmemoryfromadierentprocess,theEPTmappingwouldstillre ecttheHARESapplicationandcorrupttheprocess(theOS'swritetothatpagewouldupdatethedatapage,butinstructionfetcheswouldstillgototheoriginalprogram'spage).Inordertocom-batthis,thecurrentHARESprototypewilllockthepagesintonon-pagedmemory.Thisisacon-straintonthesystem'sresourcesasthenon-pagedpoolistypicallyinhigh-demandandmuchsmaller,sotheapplicationsizeforthisprototypeislimited.Thereareengineeringsolutionstobypassthislim-itation,ifMicrosoftweretoregisteranewcall-backforaregionofmemorybeingpagedinorout,5 HAREScouldupdatetheprotectedpagesaccord-ingly.Alternatively,itwouldbefeasiblefortheVMMtomonitormodicationstothetargetpro-cess'pagingstructuresandinferthesameinforma-tioninamore\brute-force"method.Oncethememoryhasbeenlocked,itcanthenbedecryptedbyVMM(on-CPUusingAES-NI)intoaregionofmemoryprotectedbythehypervisorasexecute-only.3.3.1SimulatingtheSplit-TLBOnpre-Nehalemsystems(Core2andprevious),theI-TLBandD-TLBswerenotdirectlyconnected,andthusafullsplitwaspossible.Withnewersys-tems,theinteractionwiththeS-TLBrequirestheuseofEPT'smoregranularpermissionstopre-ventthe\pollution"oftheincorrectentrybeingmergedacrossfromtheI-TLBtotheD-TLBorvice-versa[4].HARESusesasimilarmodelasShadowWalkerforemulatingaHarvardarchitectureonx86[11].ThisworkconguredtheVMMtotraponEPTfaults(similartoapage-faultinthekernel)andwillthenusethemoregranularpermissionsavail-able(E/R/W)intheEPTpagingstructurestodi-rectdieringtypesofmemoryfetchestothecorrectlocationinphysicalRAM.EPTFaultHandling.WhentheVMMislaunched,itcreatesanidentitymap,mappingeachguest-physicalpagetothesamemachine-physicaladdresswitheverymappingpresentandfullpermissions.ThroughtheuseofthelargerpagesizesavailabletoEPT,thisisarelativelysmallpagetablecongura-tion.OncetheapplicationisloadedintomemorybytheOS,theVMMisgiventhelistofmemoryad-dressescorrespondingtothecodesectionstosplitandtheEPTpagingstructuresareupdatedtomap1-to-1foreachpage.Theseentriesaretheneithermappedexecute-onlytothedecryptedcodepagesorread/writetotheencryptedmemory.Whenamemoryfetchoccursandthereisnomatch-ingentryintheTLB,theCPUwillexaminethepagingstructures,iftheEPTmappingcurrentlysetisnotappropriateforthetypeoffetch,afaultwilloccur.TheHARESVMMwilldeterminethetypeoffault(instructionordata)andupdatetheEPTpagingstructureforthatmemorypagetopointtotheproperregionofphysicalmemoryandthepermissionssettoallowthefetch.Theguestisthenresumedandexecutioncontinuesuntilan-otherfaultistriggered.COWDetectionandSupport.Windowsprovidesthefeatureofcopy-on-writetominimizememoryduplicationwhenmultipleinstancesofthesameapplicationareruninparallel;thesamestaticcodepagesareallreferencedfromalloftheduplicateprograms.Ifasingleinstanceofaprogrammakesamodicationtothecodepage(s),theOSwillper-formthiscopy-on-writeoperation.Itwasidenti-edin[12]thatthisprocesswouldmovetheactiveapplicationpageselsewhereinmemory,defeatingtheTLB-split.Inordertokeepabreastofthesechanges,theVMMisconguredtotrapontheOSprocessswitch(changeoftheCR3register)andwillre-scantheapplication'spagingstructurestoidentifyanymodicationsandupdatethelisttheVMMusesformanagingtheTLB-splittingopera-tion.3.4SecureTear-DownTheOSdriverisalsonotiedbythekernelofprogramsterminatingviathesamemechanismasprocesscreationmonitoring.WhentheHARESdriver'scallbackisexecuted,itissuesahyper-calltotheVMMtooverwritethedecryptedcodepagewithNULL-bytesandceasetheTLB-splitforthatapplication.4.RESULTSEVALUATION&DISCUS-SIONThebelowsubsectionsprovideabriefoverviewoftheresultsofevaluatingtheprototype,andadis-cussionofitsbenetsandpossibleattackvectorsagainstaHARES-protectedapplication.4.1ProtectionsAffordedTheprotectionsprovidedbyHARESare:thepro-tectionofaprogram'scode(dataisstillvulnerable)againststaticanalysisandsignicantlyraisingthebarfordynamicreverse-engineers.Theseprotec-tionscanhelppreventsensitivealgorithmsandIPfrombeingreversedaswellasprotectavulnerableapplicationagainstcertaintypesofexploitation.DuetotheHarvardnatureoftheHARESrun-timeenvironment,anycode-injectionattackswouldbedivertedtotheencrypteddatapages,rendering6 themuseless.MiningtheencryptedapplicationforROPgadgets,or\weaponizing"acrash-caseintoaRCEwouldalsobesignicantlymorechallenging.4.2Performance&CompatibilityThefollowingparagraphs,theperformanceoftheprototypewillbedetailed.TheseresultsprovidearoughestimateofhowaHARESsystemwouldfunction,performancewillcertainlychangefordif-feringapplicationsandifanyengineeringenhance-mentsperformed.TestedApplications.TheHARESteamutilizedthesynthetictest-suiteusedin[12]inordertodeterminetheperformanceimpactofrunningaHARES-protectapplication.Inordertodeterminethefeasibilityofmoregeneralizeduse,HARESwasusedtoencryptthefollowingthreeWindows7util-ities(highlightingthatHARESdoesnotrequiresource):Notepad,CalculatorandPaint.Thesesmallapplicationscouldrunwiththememorycon-straintsimposedbytheproof-of-conceptandwereusedtogatherground-truthintohowHARESwouldimpacttheusabilityofatypicalGUIprogram.PerformanceImpact.Naturally,sinceHAREScre-atesaduplicatepageforeachexecutablepageofthetargetprogram,thereisincreasedmemoryus-age,attheworst-case(everysectionismarkedasexecutable),thememoryfootprintisslightlylessthandoubled.Theperformanceimpactisprimar-ilynoticeableincreasedstart-uptime.Overall(in-cludingstart-uptime),theperformanceimpactwascomparabletotheresultsfrom[12],orabout2%.IntermsofresponsivenessforaGUIapplication,thepresenceofHARESisunnoticeabletotheend-user.4.2.1ApplicationSupportChallengesOneofthemostdicultchallengeswiththere-searcheortwastoencryptbinarieswithoutaccesstothesourcecodeortheabilitytorecompiletheprogramwithcontroloverthelinkingandoutputlayout.Inmanycases,thecompilerwill\compress"acodeanddatasectionbycombiningthemintoasingle,dual-usesection.Duringexecution,whentheprogramisrununderHARES,thedatafetchesaccessingstrings,orotherdatavaluesinthecodesectionwereencrypted,eventotheprogram'scodeitself.Thisresultedinprograminstabilityortheencrypteddatabeingusedincorrectly.Awork-aroundforcaseswhererecompilationisnotpossibleistoputHARESin\learning"modeandruntheprogramunencrypted.Afterexercisingtheprogram(manuallyinthiseort,inthefuturewithsymbolic/concolicexecution),HARESwouldout-putmemoryregionsusedasdatainanexecutablesection.ThisoutputcouldbepassedtothePEencryptiontooltopassovertheseregionsinthebinary,leavingtheareasoftheprogramaccessedasdatainthecleartoenablesmoothexecution.4.3SecurityWeaknessesAstherearenosilver-bulletsinsecurity,thefol-lowingsubsectionsoutlinecertainclassesofattackaswellasconsiderationsforkeymanagementanddeploymentstrategies.4.3.1AttackScenariosThebelowparagraphsdescribethedierentsce-nariosinwhichitisimaginedaHARES-protectedapplicationwouldbesubjectedtoattack.Asisalwaysthecaseinsecurity,therearesuretobeadditionalscenariosnotconceivednordescribedinthispaper.TheftofProtectedApplication.Thesimplestat-tackscenariowouldbeanattackercopyinganap-plicationfromanauthorizedcomputertoanothersystemtocommitsoftwarepiracyorexaminetheapplicationforvulnerabilities.Inthisscenario,thePEleisencrypted,aswellasamemorydumpofthePEimage,thustheattackerwillbeunabletodecrypttheapplicationonanon-authorizedsys-temsavebybrute-forceattacksontheAESkey.CompromiseofAuthorizedHost.Thisscenarioiswhenanattackersuccessfullygainsremoteaccesstoanauthorizedsystemandcanlaunchsoftware-basedattacksagainsttheHARESsystem.ThisattackerisassumedtohaveOS(ring-0)privileges,thoughisunabletopenetratetheVT-xbarriersavebyanattackagainstthebootprocess,totakeeectonthenextreboot.“Authorized”LocalUsage.Thenalscenarioinscopeofthiswhite-paperiswhenanattackerhascomplete,physicalaccesstoanauthorizeddevice,7 andisabletoperformphysicalattacksagainstthehardware.Thisisthemostdicultattacktode-fendagainst;inthefollowingsubsection,physicalattacksarediscussedspecically.4.3.2PhysicalAttacksIfanattackerweretogainphysicalaccesstoacom-putersystemcurrentlyexecuting(i.e.,authorized)aHARES-protectedapplication,thereareanum-berofpossibleattackvectorsavailabletotheat-tackerinordertoreducetheprotectionsaordedbyHARES.Thisclassofattackissubdividedintothefollowingthreesub-classesviz.:hardwarede-bugging,memorydumpingandside-channels.Eachisdescribedbelowinmoredetail.JTAG/XDM.Thebarriertoentryforhardwaredebuggingonx86hasdroppedsignicantlyinre-centyears,withcostsdroppingfromve-gurestolessthan$1000.JTAGissimplyawire-protocol,thusnotevery\JTAGdebugger"onthemarketcandebuganIntelx86platform.Theuseofthesedevicesarephysicallyinvasive,generallysittingin-betweentheCPUandthemotherboard,requiringthesystemtoberebooted(removingthekeyfrommemory)underattackercontrol.IftheHARESsystemhasthekeystoredlocally,andhasapol-icyinplacetoallowittobeloadedintotheCPUdebugregistersatearlyboot,itispossibleanat-tackerwouldbeabletoexltratethekeyfromtheCPUregisters.However,ifthesystemrequiresanauthorizedusertobootthesystem(e.g.,viaaBIOSpasswordorFDEkey),theattackerwouldonlysucceedinperformingaDoSofthetargetsys-tem.Itisforthisreasonthattheauthorssuggestcomplementaryprotectionsputinplacetofollowbest-practicesfornetworkendpoints.Cold-RAM&OtherRAMDumpingTechniques.ThecurrentimplementationofHARESisvulner-abletoacold-RAMattacktargetingthedecryptedinstructions,theTRESOR-basedon-CPUAESwillpreventthekeyfromtheft.InSection4.4,wedis-cusshowtheapplication'sdecryptedinstructionscanbestoredonlyintheCPUcacheandpreventthisweakness.OtherRAMdumpingtechniques,suchasbus-snooping,etc.wouldoperateinasim-ilarfashion,thecurrentprototypecouldbecircum-ventedtoobtainthedecryptedprogram,butthekeywouldbeprotected.Theon-CPUstorageofthedecryptedinstructionswouldbeabletoprotectagainsttheseothermethodsofRAMexltration.Side-Channels.Therearecertaintobesystem-wideimpactsofHARESthatadeterminedattackerwouldbeabletoutilizetogainfurtherinformationaboutaprotectedapplication.Whilethemajorityoftheseareoutsidethescopeofthiswhite-paper,asimple\instructioninferenceengine"couldbecre-atedtosingle-stepthroughtheHARES-protectedprogramandprobabilisticallydeterminethelast-executedinstructionfromtheimpactithadonthesystemandotherinformationfromthesystem(e.g.,performancecounterMSRs).4.3.3KeyLoading&DistributionWhilethecurrentHARESprototyperesearchef-fortaimedtospecicallyfocusontheprotectivecapabilitiesavailableonexistingsystems,andkeymanagementwaslefttofuturework,thefollow-ingparagraphsoutlinesomepossiblekeyloadingoptions.KeyLoading.In[7],theAESkeyisloadedintotheCPU'sdebuggingregistersearlyintheOS'sbootprocess,whenthemajorityofapplicationsfoundonatypicalsystemhavenotyetbeenstarted.Thisconceptofminimizingthenumberofapplica-tionsrunningwhenthekeyisloadedisasoundwaytoreducerisk.Inordertoaugmenttheuserexpe-rience,thekeycouldbestoredonaUSBdevice(e.g.,aYubiKey10).Formoresecurity-consciousenvironments,thekeycouldbesealedviatheTPMsuchthatitisonlyunsealedifthesystemisintheproperstate,andtheHARESVMMhasbeenloadedasthemea-suredlaunchenvironment.OnIntelvProsystems,thisprovidesaseamlessuserexperienceandsignif-icantsecurityimprovementsasthekeywillneverbereleasedifthereisamalicioushypervisorroot-kitattemptingtocircumventtheHARESsystem.OncetheHARESVMMhasbeenloaded,andthekeyinsertedintotheCPUregisters,theycanbewipedfrommemoryandtheTPMPCRsextendedwithrandomdatainordertopreventanotherap-plicationfromunsealingthekey(s). 10https://www.yubico.com/products/yubikey-hardware/yubikey-2/8 OnsystemswithoutIntelTXT/vPro,systemssuchas[6]canbeutilizedtoperformsimilarverica-tionofaplatform'sstatepriortoloadingakeyfromaprotectedstoragemechanism.TheuseofthesetechniqueswouldpreventtheHARESkeyfrombeingreleasedunlessthedynamicvericationsucceeds,implyingthereisnomaliciousVMMorattackerattemptingtoreverseengineerordebugthekeyloadingprocess.ProtectingtheKey.OncethekeyhasbeenloadedintotheCPUregisters,itmustbeerasedfromcacheandmainmemory,itisimportanttoen-surethekeyisnotresidentinmemoryifama-liciousprocessisabletopreventtheCPUcachefrombeingwrittenbacktoRAM(suchaswiththeINVDinstruction).TheHARESVMMconguresthesystemtotraponaccessesofthedebugregis-tersandwillensureNULLisreturnedforallreadsandwritesaresilentlydiscarded.TheadvantageofdoingthisintheVMMversustheOSdriveristhatamaliciousOS,orkernel-modedriverwillstillbeunabletoreadthekeyfromtheCPUregisters.WiththeVMMprotectingthekeyintheCPUreg-isters,itisstillvulnerabletoattacksfromama-licioussystemmanagementmode(SMM)handler.ProtectingagainstSMM-basedthreatswasoutsideofthescopeofthisinitialeort,butmaybead-dressedinfutureworks.4.3.4Emulation&VirtualizationAttacksIftheHARESVMMcanbeinducedtoruninanestedvirtualizationenvironment,orunderfullemulation,theCPUdebugregisterscanbereadandtheprotectionsbypassed.Forthisreason,itiscriticaltouseasecureloadingmechanismsuchasIntelTXTorasoftware-basedequivalent,suchas[6]inordertopreventHARESfrombeingusedifthereisalreadyamoreprivilegedhypervisorordebuggingenvironmentrunningonthesystem.Emulation&VMMDetectionTechniques.In-telTXTandthesoftware-basedConqueror[6]areabletoeitherreplaceordetectthepresenceofahypervisor.In[10],itisshownthatcertaininstruc-tionssometimesrevealthepresenceofaVMM,aswellastheclock-skewintroducedbytheincreasedoverheadrequiredtocontext-switchonaVMExit.Ifatrustedclockisavailable,thendetectingthepresenceofemulationoramaliciousVMMispos-sible,andkeynotloaded,thusprotectingitfromattack.4.4FutureEnhancementsTheHARESprototypewasdevelopedasaproof-of-concept,designedtotestthefeasibilityofsuchanapproachandprovideinitialestimatesoftheperformanceimpactsontheprotectedprogramandsystemasawhole.TheHARESresearchteamisexploringsomeadditionalresearchandengineer-ingcapabilitiesusingtheHARESprototypeasafoundation.EngineeringImprovements.Thecurrentproto-typerequiressubstantialimprovementsinordertorenderitusageinatypicalenterpriseenviron-ment.Anumberoflimitationswouldneedtoberemoved,namelywiththememory-managementofaprotectedapplication.Currentlytheprogramislockedintothenon-pagedmemorypool,ofwhichthereisalimitedsupply.Additionally,duetocer-tainhard-codedvalues,theproof-of-conceptwillnotfunctiononsystemswithgreaterthan2GiBofmemory,astheWindowskernelmemorylayoutchanges;amore exiblesystemwillhavetobeim-plementedinordertooperateasaeldedproduct.SMMProtections.Systemmanagementmodeat-tacksarenotnewinthepublicart,thoughuntilrecentlyweredismissedbymanyastootargetedinordertoposearealthreat.In[8]and[16],theseassumptionswerechallenged,showingtheintro-spectivecapabilitiesofSMMaswellasthescaleofpossiblevulnerabilities.Futureworkinthisareaisneeded;thereisasig-nicantneedforadefensivemechanisminordertoprotecttheVMM,OSanduserapplicationsfromarogueSMMhandler.Intel'ssolutionofadual-monitormode[5],maybetheultimategoal,butithasyettomaterializewithhighmarketpen-etration.Inthemeantime,performingresearchintothedetectionofamaliciousSMMwouldprovevaluablesimplyasamethod-of-last-resort,chang-ingsystemsifacompromiseisdetected.Thereissomeexistingworkinthiseld[3],butfutureworkshouldbuilduponthistoensurethesystemsHARESisoperatingonaretrusted.9 MemoryProtections.OneweaknessintheHARESprototypeisitsvulnerabilitytocold-RAMattacksandothermemory-dumpingtechniques.In[2],aplatformfeaturefoundoncertainARMsystem-on-chipsisusedtopreventsensitivedatafromleavingtheSoC.ModernCPUcacheshavegrownlargeenoughtoholdsmallprograms,andintegrationandexperimentationwithsuch\no-ll"executiontechniquesareofparticularinterestasfutureworkforHARES.5.RELATEDWORKThefollowingparagraphsaimtocreditthepre-viousworkstheHARESresearchbuildsonandtodierentiatebetweentheseeortsandtheworkpresentedabove.Keepingabreastoftheresearchperformedbothintheacademicand\hacker"spheresisanextremelychallengingundertaking,assuchthissectionshouldbynomeansbeconsideredacompletesurveyoftheeld.Packers.Inessence,apackerisageneralizedtermforanyrun-timemodicationtoaprogram,typi-callywiththegoalofavoidingsignature-basedchecksoflespriortotheirexecution.Thistermcanen-capsulatemanysub-classesofprogramobfuscationtechniques,suchasVM-basedmalware,encryptiontools,andcompression.Apackerworksbycreat-ingasmallprogramstub,executedatthestartofapackedprogram'sexecutionthat\unpacks"theprogramfromitson-diskformattothatwhichisunderstandablebythehostCPUenvironment.Theprogramisunpackedintoamemoryregionthatissettobeexecutable,andexecutionispassedtothisregionafterunpackingiscomplete.Avulnerabilityofpackersistheirweaknesstorun-timereverse-engineering.Whileondiskthepro-gram'slogicmaybeobfuscatedorencrypted,oncetheunpackingroutineiscompleted,theprogramwillresideinmemory,andbeexecutedasatypi-calprogram,vulnerabletoreverse-engineeringandothersemanticanalysis.BurnEye.Anexampleofanencryption-protectedpacker,BurnEyewasaprotectivemethodforGNUELFlesthatallowedthemtobeencryptedandprotectedfromstaticreverse-engineering,andseam-lesslybedecryptedandexecuted.Unfortunately,BurnEyeisvulnerabletothesameclassesofat-tackasthemoregeneralpackers:run-timeanddynamicattacksallowtherecoveryofprogramin-structions,renderingtheprotectionsinsucientfortoday'sthreatenvironment.TrulyProtect.In[1],aCPU-boundVMinterpreteriscreatedthatperformsdecryptiononarandom-izedorencryptedintermediaterepresentation(IR)whileprotectedbyaVMM.Thisworkaimstoac-complishsimilargoals,butrequiresaVMIRtox86mapping,thuswillnotworkonexistingap-plicationswithoutaccesstothesource.Addition-ally,theremaybeariskofstatisticallyreverse-engineeringtheencryptedmappinginasimilarfash-iontotherisksassociatedwithelectroniccode-book(ECB)modewithAES.Sentry.In[2],researcherswereabletoattainasimilarlevelofprotectionsforbinariesonARMbyleveragingplatform-specicfunctionality,namelytheAES On SoCbittopreventprotectedmemoryregionsfrombeingwrittentoanystorageothesystem-on-chip.TheauthorsofHARESndtheSentryworkincrediblyvaluableasmobiledevicesstoreanever-increasingamountofsensitiveinfor-mation.Anexcitingareaforfuturestudywouldbeanabstractionlayerforencryptedsoftwarethatcanmakeuseoftheplatform'scapabilities:In-telSGX,ARMSoClocksandHARESforsystemswithoutsuchfeatures.6.CONCLUSIONInconclusion,HARESprovidesasignicantim-provementoverthecurrentstate-of-the-artinpro-tectingapplicationsfromreverse-engineering,thoughadeterminedadversarywillcertainlybeabletodefeattheprotections.HARESprovidesa\drop-in"enhancementtothesecuritypostureformanyapplicationsknowntobevulnerable,bothagainsttheftofalgorithmicIPanddenyinganumberofat-tackvectors.TheupcomingIntelSGXcapabilitywilllikelyeclipseHARESfortypicaluse,thoughtheresearchpresentedhereinisofinterestnonethe-less.7.ACKNOWLEDGMENTSTheauthorwouldliketoexpresshisgratitudetothemanypartieswhohavehelpedontheHARESeortinoneformoranother,toomanytomen-tionallbyname.Firstly,MarkBridgmanforhis10 helpontheprototypedevelopmentanddebuggingeort.Second,LocNguyenandRyanStortzfortheirinputonweaknessesandareasofimprove-ment.Finally,AISforitssupportofthisresearchanditspublication.8.REFERENCES[1]A.Averbuch,M.Kiperberg,andN.Zaidenberg.Truly-protect:Anecientvm-basedsoftwareprotection.SystemsJournal,IEEE,7(3):455{466,Sept2013.[2]P.Colp,J.Zhang,J.Gleeson,S.Suneja,E.deLara,H.Raj,S.Saroiu,andA.Wolman.Protectingdataonsmartphonesandtabletsfrommemoryattacks.InProceedingsoftheTwentiethInternationalConferenceonArchitecturalSupportforProgrammingLanguagesandOperatingSystems,ASPLOS'15,pages177{189,NewYork,NY,USA,2015.ACM.[3]B.DelgadoandK.Karavanic.Performanceimplicationsofsystemmanagementmode.InWorkloadCharacterization(IISWC),2013IEEEInternationalSymposiumon,pages163{173,Sept2013.[4]J.Gionta,W.Enck,andP.Ning.Hidem:Protectingthecontentsofuserspacememoryinthefaceofdisclosurevulnerabilities.InProceedingsofthe5thACMConferenceonDataandApplicationSecurityandPrivacy,CODASPY'15,pages325{336,NewYork,NY,USA,2015.ACM.[5]IntelCorporation.IntelR 64andIA-32ArchitecturesSoftwareDeveloper'sManual.Number253669-033US.December2009.[6]L.Martignoni,R.Paleari,andD.Bruschi.Conqueror:Tamper-proofcodeexecutiononlegacysystems.InC.KreibichandM.Jahnke,editors,DetectionofIntrusionsandMalware,andVulnerabilityAssessment,volume6201ofLectureNotesinComputerScience,pages21{40.SpringerBerlinHeidelberg,2010.[7]T.Muller,F.C.Freiling,andA.Dewald.Tresorrunsencryptionsecurelyoutsideram.InProceedingsofthe20thUSENIXConferenceonSecurity,SEC'11,pages17{17,Berkeley,CA,USA,2011.USENIXAssociation.[8]L.Nguyen.Micronesia:Sub-kernelkitforhostintrospectionindetermininginsiderthreat.ShmooCon,2015.[9]PaXProject.Pageexec,Mar2003.https://pax.grsecurity.net/docs/pageexec.txt.[10]J.Rutkowska.Redpill...orhowtodetectvmmusing(almost)onecpuinstruction,2004.[11]S.SparksandJ.Butler.Raisingthebarforwindowsrootkitdetection.Phrack,17(61),November2005.[12]J.Torrey.More:Measurementofrunningexecutables.InProceedingsofthe9thAnnualCyberandInformationSecurityResearchConference,CISR'14,pages117{120,NewYork,NY,USA,2014.ACM.[13]E.Tromer,D.A.Osvik,andA.Shamir.Ecientcacheattacksonaes,andcountermeasures,2009.[14]P.VanOorschot,A.Somayaji,andG.Wurster.Hardware-assistedcircumventionofself-hashingsoftwaretamperresistance.IEEETransactionsonDependableandSecureComputing,pages82{92,April2005.[15]R.Wojtczuk.Subvertingthexenhypervisor.InBlackHatUSA,Aug2008.[16]R.WojtczukandC.Kallenberg.Attacksonuesecurity,inspiredbydarthvenamis'smiseryandspeedracer.CanSecWest,2015.11