NO344529B1 - Virtualisering for diversifiserende inngrepsmotstand - Google Patents

Description

BAKGRUNN

[0001] Til tross for stor innsats av programvareleverandørene brytes programvarebeskyttelsesmekanismer fortsatt med jevne mellomrom. Videre vil en vellykket angrep på én kopi ofte kunne overføres automatisk på andre kopier. Hvis for eksempel en programvareleverandør distribuerer evalueringsversjoner av et dataprogram, kan en manipulasjon som fjerner tidsbegrensning fra ett eksemplar også brukes på alle andre distribuerte eksemplarer. Videre kan konvensjonelle distribusjonsmodeller tillate serielle angrep som raskt påvirker tusenvis av brukere.

[0002] Diversifisering er et konsept som kan brukes til å forbedre programvaresikkerhet og forstyrre angrepet. Men diversifiseringsteknikker utviklet for programvaresikkerhet er ikke alltid overførbare til programvarebeskyttelse siden det gjelder andre regler der. For eksempel kan det meste av kjøretidsdiversifiseringen som ble innført av sikkerhetshensyn, lett bli slått av når en angriper har fysisk tilgang til programmet og kjøremiljøet.

[0003] Som beskrevet her gir ulike diversifiseringsteknikker for programvarebeskyttelse fornybar forsvar i rom og tid, for eksempel ved å gi hver bruker et annet eksemplar og ved å fornye forsvaret med skreddersydde oppdateringer.

Anckaert B. et al.: Proteus: virtualization for diversified tamper-resistance, DRM '06 Proceedings of the ACM workshop on Digital rights management , pages 47-58, Alexandria, Virginia, USA — October 30 - 30, 2006. ISBN:1-59593-555-X studerer mulighetene og begrensningene ved å bruke virtualisering til å åpne et nytt sett av muligheter for å lage nye kopier av en del av programvare og å gjøre individuelle kopier mer skadingsresistende.

OPPSUMMERING

Den foreliggende oppfinnelse tilveiebringer en datamaskinimplementerbar fremgangsmåte som omfatter: å tilveiebringe en instruksjonssettarkitektur som omfatter funksjoner for å generere ulike kopier av et program; å bruke instruksjonssettarkitekturen til å generere ulike kopier av et program; å tilveiebringe en virtuell maskin for eksekvering av en av de ulike kopier av programmet, karakterisert ved at: funksjonene til å generere ulike kopier av et program omfatter instruksjonssemantikk som tillater betinget kjøring ved hjelp av predikatregistre, og funksjonene til å generere ulike kopier av et program omfatter instruksjonssemantikk med et begrenset instruksjonssett.

Ytterligere utførelsesformer av den datamaskinimplementerbare fremgangsmåten i henhold til oppfinnelsen fremgår av de uselvstendige patentkrav.

Den foreliggende oppfinnelse tilveiebringer også et datamaskin-lesbart medium som omfatter instruksjoner som, når utført ved hjelp av en prosessor, får prosessoren til å utføre fremgangsmåten ifølge oppfinnelsen.

Den foreliggende oppfinnelse tilveiebringer også en databehandlingsanordning tilpasset til å utføre fremgangsmåten ifølge oppfinnelsen.

[0004] Ulike eksempelteknikker bruker virtualisering for å diversifisere kode og/eller virtuelle maskiner (VM-er) for dermed å forbedre programvaresikkerheten. For eksempel inkluderer en datamaskin-implementbar fremgangsmåte det å tilveiebringe en instruksjonssettarkitektur (ISA) som omfatter funksjoner for å generere ulike utgaver/kopier av et program ved å bruke instruksjonssettarkitekturen til å generere ulike utgaver av et program og å tilveiebringe en VM for eksekveringen av en av de ulike kopier av programmet. Ulike andre teknologieksempler fremlegges også.

TEGNINGER

[0005] Ikke-begrensende og ikke-uttømmende eksempler beskrives med henvisning til følgende tegninger:

[0006] Figur 1 er et diagram av et system og en overordnet arkitektur som inkluderer et virtualiseringslag som en egendefinert/tilpasset/endret instruksjonssettarkitektur (ISA) og/eller en virtuell maskin (VM);

[0007] Figur 2 er et blokkdiagram av et fremgangsmåteeksempel som inkluderer en sikkerhetsmodul for å generere tilpasset kode og/eller en egendefinert VM;

[0008] Figur 3 er et blokkdiagram av et fremgangsmåteeksempel for å generere en egendefinert VM.

[0009] Figur 4 er et blokkdiagram av for en eksemplarisk fremgangsmåte for diversifiseringsfunksjoner i koden for å generere egendefinert kode;

[0010] Figur 5 er et diagram av et eksempel som gjelder fremgangsmåten i figur 4;

[0011] Figur 6 er et blokkdiagram av en eksemplarisk fremgangsmåte for å diversifisere data og/eller datastruktur.

[0012] Figur 7 er et blokkdiagram av ulike rammeverksegenskaper som kan brukes til diversifisering og inngrepsmotstand.

[0013] Figur 8 er et diagram av en kjøremodell med kjennetegn som kan brukes til diversifisering og inngrepsmotstand.

[0014] Figur 9 er et blokkdiagram av ulike tilnærminger som kan anvendes på instruksjonssemantikk for bruk ved diversifisering og inngrepsmotstand.

[0015] Figur 10 er et blokkdiagram av ulike tilnærminger som kan brukes til instruksjonskoding for bruk ved diversifisering og inngrepsmotstand.

[0016] Figur 11 er et blokkdiagram av ulike tilnærminger som kan brukes på en FETCH-syklus for diversifisering og inngrepsmotstand.

[0017] Figur 12 er et blokkdiagram av ulike tilnærminger som kan brukes på en instruksjonspeker (PC, ”program counter”) og/eller programrepresentasjon for diversifiseringen.

[0018] Figur 13 er et diagram av et eksempel på et kodefragment i et SPLAY-tre, for diversifisert inngrepsmotstand.

[0019] Figur 14 er et blokkdiagram av ulike tilnærminger som kan brukes til gjennomføring av en virtuell maskin (VM) for diversifiseringsformål.

[0020] Figur 15 er et blokkdiagram av en eksempel-databehandlingsanordning.

DETALJERT BESKRIVELSE

Oversikt

[0021] Eksempelteknikker bruker programvarebasert sikkerhet for kode som kjører på en virtuell maskin eller annen maskin som kan kontrolleres (for eksempel brukes på en bestemt måte). Ulike eksempler endrer koden, endrer data og/eller endrer virtuell maskinfunksjon på en kooperativ måte for å forbedre sikkerheten. For eksempel kan funksjoner knyttet til koden identifiseres og brukes til å diversifisere forekomster av koden. Ulike eksempler omfatter bruk av en tilpasset eller endret Instruksjonssettarkitektur (ISA) som er emulert på toppen av en eksisterende arkitektur eller modifisert arkitektur. Der den eksisterende arkitekturen omfatter et virtualiseringslag (f. eks. en virtuell maskin eller kjørefasemaskin eller bare "kjørefase"), kan en eksemplarisk tilnærming legge et annet virtualiseringslag på toppen av det eksisterende virtualiseringslaget. Gjennomføringen av ulike teknikker kan gjøres ved bruk av en tilpasset virtuell maskin som opererer på toppen av en underliggende virtuell maskin eller gjennom bruk av en modifisert virtuell maskin (for eksempel endring av en underliggende virtuell maskin). For økt sikkerhet på bekostning av ytelsen kan slike prosesser kjøres iterative for å generere en stabel med virtuelle maskiner, som hver virtualiserer instruksjonssettet til maskinen nedenfor.

[0022] Med hensyn til diversifisering kan en analogi ses i genetisk mangfold der felles komponenter (for eksempel DNA-byggeklosser) er satt sammen på en rekke måter for dermed å øke mangfoldet av en art. Til gjengjeld kan en ondsinnet agent (for eksempel et virus) trolig ikke påvirke alle medlemmer av genetisk ulike arter. En analogi eksisterer også for noen parasitter, der hundrevis av gener kan produsere proteiner som er blandet og passer. Slikt proteinmangfold hjelper en slik parasitt å unngå immunsystemgjenkjenning. Men mens genetisk mangfold i arter som beskrevet her ofte er forbundet med fenotypisk mangfold (dvs. mangfold av uttrykk eller manifestasjon), bør kodediversifisering ikke endre brukerens opplevelse. Med andre ord må alle forekomster av en diversifisert kode - samme innmating forutsatt - utføres slik at de produserer det samme resultatet.

[0023] Følgende er generaliserte likninger:

genotype miljø = fenotype (1)

kode/data maskin = resultat (2)

I likning 2 kan maskinen med diversifisert kode og/eller data være en tilpasset maskin eller en modifisert eller styrt maskin som sørger for at resultatet blir hovedsakelig det samme. Der en virtuell maskin eller virtuelle maskiner brukes, er den underliggende maskinvaren og/eller operativsystemet vanligvis upåvirket av eksempelvise sikkerhetstilnærminger som beskrevet her; imidlertid kan slike tilnærminger øke datakraftbehovet.

[0024] Som beskrevet her øker kodediversifiseringen sikkerheten ved å forvirre angrepet. I tillegg kan kodediversifiseringen forvirre serielle angrep når replikering av et vellykket angrep på en forekomst av koden er usannsynlig å lykkes på en "genetisk" annen forekomst av koden. Videre kan data (eller datastrukturer) være forskjellige for å øke sikkerheten. Og videre kan eksemplariske teknikker for diversifisering av en tilpasset eller modifisert virtuell maskin brukes til å forbedre sikkerheten med eller uten kode og/eller datadiversifisering.

[0025] Mens ulike eksempler fokuserer på generering av tilpassede bytekoder fra MSIL-binærkoder, kan ulike eksemplariske teknikker brukes for programmer uttrykt i en hvilken som helst programmeringsspråk, mellom-språk, bytekode eller opptreden.

[0026] Som beskrevet her forenkler prosessen med virtualisering (f. eks. kjøring av kode på en virtuell maskin eller i et virtuelt miljø) (i) muligheten til å lage mange forskjellige versjoner av et program, og (ii) muligheten til å gjøre hver forekomst av et program robust mot angrep. Ulike eksemplariske teknikker bruker virtualisering til å etterligne en tilpasset instruksjonssettarkitektur (ISA) på toppen av et portabelt, kontrollerbart, verifiserbar styrt CLR-miljø. Et tilpasset kjørefasemiljø eller modifisert kjørefasemiljø kan brukes til å etterligne den tilpassede ISA, dvs. på noen måte, det underliggende kjørefasemiljø må kunne håndtere diversifiseringen innført via tilpassede ISA.

[0027] Virtualisering gir frihetsgrader som kan brukes i diversifiseringen. For eksempel omfatter en instruksjonssettarkitektur (ISA) (dvs. og/eller mikroarkitektur) vanligvis (1) instruksjonssemantikk, (2) instruksjonskoding, (3) instruksjonskode-koding, (4) koderepresentasjon og en instruksjonspeker og (5) en tilsvarende intern implementering av en virtuell maskin. Med disse frihetsgrader kan ulike eksemplariske fremgangsmåter generere mange forskjellige utgaver av et program med en hvilken som helst av en rekke beskyttelsesmekanismer.

[0028] Frihetsgrader tilknyttet en ISA tilveiebringer design og utvalg av inngrepsresistente programmer. For eksempel kan inngrepsmotstand være et resultat av (1) å gjøre lokale modifikasjoner vanskeligere gjennom (a) variable instruksjonslengder, (b) begrenset instruksjonssett, og fremme (c) fysisk og (d) semantisk overlapping; (2) gjøre globale endringer vanskeligere ved alt det tidligere nevnte og utydeliggjøring av grensene mellom kode, data og adresser; (3) gjøre instruksjonssemantikken variabel, og (4) stadig flytte koden.

[0029] Mer spesifikke eksempler omfatter (i) å tilfeldiggjøre instruksjonssemantikk ved å bygge instruksjoner gjennom kombinasjon av mindre instruksjoner, (ii) å velge instruksjonssemantikk for å muliggjøre økt semantisk overlapping, (iii) å gå fra den tradisjonelle lineære kodefremstillingen til å representere koden som en datastruktur som et selvtilpassende (SPLAY) binærtre; (iv) å tilordne variable lengder til instruksjonskoder og operander for å komplisere tilbakeoversettelse og å gjøre lokale modifikasjoner vanskeligere; (v) å begrense instruksjonsettet for å gi angriperen færre alternativer til å analysere og endre koden, og (vi) å gjøre avbildning mellom bitmønster, instruksjonskoder og operander variabel. Noen av disse eksemplene er beskrevet nærmere nedenfor. Den detaljerte beskrivelsen inneholder den modus som for tiden ansees som best.

[0030] Før ulike detaljer beskrives viser figur 1 som bakgrunn et generelt system 100 og en arkitektur 105 som inkluderer virtualisering. Arkitekturen 105 viser videre en tilpasset og/eller endret ISA og/eller virtuell maskin i forhold til en virtuell maskin referert til som et felles-språk-kjørefasemiljø (CLR; ”common language runtime”). Det CLR i figur 1 er for eksempel et CLR som er i stand til å håndtere en mellomliggende språkkode avledet fra en hvilken som helst av en rekke objektorienterte programmeringsspråk (OOPLs), derfor begrepet "felles". Mens figur 1 er diskutert med referanse til .NET -rammeverk (Microsoft Corp, Redmond, WA), kan eksemplariske teknikker brukes med andre arkitekturer.

[0031] Systemet 100 inneholder forskjellige databehandlingsanordninger 101, 101', 102, 102' kommuniserende via et nettverk 103. Anordningene 101, 101' kan være klienter (for eksempel PC-er, arbeidsstasjoner, lette anordninger, intelligente anordninger etc.), mens anordninger 102, 102'er servere. Arkitekturen 105 er vist med noen koblinger til anordningen 101, serveren 102' ' og nettverket 103.

[0032] .NET-rammeverk har to hovedkomponenter: felles-språkkjørefasemiljøet (CLR) og .NET-rammeverk klassebibliotek. Disse vises som tilordnet til styrte brukerprogrammer. CLR er en virtuell maskin (VM) på grunnlag av .NET-rammeverk. CLR opptrer som en agent som administrerer koden i eksekeringsfasen, tilveiebringer kjernetjenester som minnestyring, trådstyring, og fjerneksekvering, mens det også håndheves streng typsikkerhet og andre former for kodenøyaktighet som fremmer sikkerhet og robusthet. Kodestyringskonseptet er et grunnleggende prinsipp i CLR. Kode som er rettet mot CLR kalles styrt kode, mens kode som ikke retter seg mot kjørefasemiljøet kalles ikke-styrt kode (høyre halvdel av arkitektur).

[0033] I .NET-rammeverket kjøres programmer i et styrt kjøremiljø gitt av CLR. CLR forbedrer kjørefaseinteraktivitet mellom programmer, mobilitet, sikkerhet, utviklingsenkelhet, kryssspråkintegrering sterkt og tilveiebringer et utmerket grunnlag for et rikt sett med klassebiblioteker. Hvert språk rettet mot .NET-rammeverket CLR kompilerer kildekoden og produserer metadata og Microsoft Intermediate Language (MSIL-) -kode. Mens ulike eksempler nevner MSIL, kan ulike eksemplariske sikkerhetsteknikker brukes med andre språkkoder. For eksempel kan ulike teknikker brukes med de fleste lavt-nivå assembler-liknende språk (f. eks mellomliggende språk (IL) kode). Ulike teknikker kan brukes med bytekoder som de fra JAVA-rammeverk (Sun Microsystem, Sunnyvale, CA).

[0034] I .NET<TM>rammeverk omfatter programkode vanligvis informasjon som kalles "metadata", eller data om data. Metadata inneholder ofte en fullstendig spesifikasjon for et program med alle sine typer, bortsett fra selve implementeringen av hver funksjon. Disse implementeringene lagres som MSIL, som er maskinuavhengig kode som beskriver instruksjonene i programmet. CLR kan bruke denne "blåkopi" for å vekke et .NET<TM>-program til liv under kjøring ved å tilveiebringe tjenester langt utover det som er mulig med tradisjonell tilnærming som baseres på å kompilere koden direkte til assembler-språk.

[0035] Klassebiblioteket, den andre hovedkomponenten av .NET-rammeverkert, er en omfattende objektorientert samling av gjenbrukbare typer for å utvikle programmer som spenner fra tradisjonelle kommandolinjeprogrammer eller programmer med grafisk brukergrensesnitt (GUI) til programmer basert på de nyeste innovasjonene som ASP.NET, for eksempel Web Forms og XML-webtjenester.

[0036] Mens CLR vises på siden av det styrte programmet i arkitektur 105, kan .NET-rammeverket bevertes av uovervåkede komponenter som laster CLR i sine prosesser og starter gjennomføringen av styrt kode, og dermed skape et programvaremiljø som kan utnytte både styrte og ikke-styrte funksjoner..NET-rammeverket tilveiebringer ikke bare flere kjørefasevertene, men støtter også utvikling av tredjeparts kjørefaseverter.

[0037] For eksempel beverter ASP.NET kjøretidsfasen (RT) for å tilveiebringe et skalerbart miljø på server-siden for styrt kode. ASP.NET samarbeider direkte med kjøretidsmiljøet for å aktivere ASP.NET-programmer og XML-webtjenester.

[0038] Internet Explorer nettleserprogrammet (Microsoft Corp) er et eksempel på et ikke-styrt program som er vert for kjørefasen (for eksempel i form av en MIME-typ-utvidelse). Ved at Internet Explorer-programvare er vert for kjørefasen, muliggjøres det at en bruker legger styrte komponenter eller Windowsskjemaelementer inn i HTML-dokumenter. Å være vert for kjørefasen på denne måten gjør styrt mobil kode (som ligner på Microsoft ActiveX -kontroller) mulig, men med betydelige forbedringer som bare styrt kode kan tilby, som for eksempel semiklarert kjøring og isolert fillagring.

[0039] Som beskrevet her kan styrt kode være en hvilken som helst kode som er rettet mot et kjørefasemiljø (f.eks en virtuell maskin, kjørefasemotor, etc., der kjørefase grensesnitter med et underliggende operativsystem (OS), vanligvis direkte knyttet til styringen av maskinvaren (HW)). I .NET-rammeverket retter den styrte koden mot CLR og inkluderer vanligvis ekstra informasjon som kalles metadata som "beskriver seg selv". Mens både styrt og ikke-styrt kode kan kjøres i CLR, inneholder styrt kode informasjon som gjør at CLR kan garantere for eksempel sikker kjøring og interoperabilitet.

[0040] I tillegg til styrt kode finnes styrt data i arkitekturen av .NET-rammeverket. Noen .NET--språk bruker styrte data som standard (for eksempel C#, Visual Basic.NET, JScript.NET) mens andre (for eksempel C++) ikke gjør det. Som med styrt og ikke-styrt kode er bruk av både styrt og ikke-styrt data mulig i .NET-programmer (for eksempel data som ikke får ryddet etter seg, men i stedet er ivaretatt av ikke-styrt kode).

[0041] Et program eller en kode er vanligvis distribuert som en portabel, kjørbar fil (for eksempel en "PE). I en .NET-PE er første blokk av data i PE-innpakningen er MSIL, som, som allerede nevnt, ser omtrent ut som en lavt-nivå assembler-språkkode. MSIL er konvensjonelt det som er kompilert og eksekvert i .NET-rammeverket. En annen blokk av data i PE er etter konvensjonen metadataene og beskriver innholdet i PE (for eksempel hvilke metoder den tilveiebringer, hvilke parametre de tar, og hva de tilbakeleverer). En tredje blokk av data kalles manifest, som konvensjonelt beskriver hvilken andre komponenter den kjørbare delen trenger for å kjøre. Manifestet kan også inneholde offentlige nøkler for eksterne komponenter, slik at CLR kan sikre at eksterne komponenten er riktig identifisert (dvs. komponenten som kreves av den kjørbare delen).

[0042] Når den eksekverbare/kjørbare delen kjører, kan .NET-CLR bruke Just-In-Time- (JIT) -kompilering. JIT-kompilering aktiverer all styrt kode til å kjøre i grunnleggende maskinspråk i systemet hvor den er under utføring (OS/HW). Ifølge JIT, som hver metode innenfor den eksekverbare delen blir kalt, blir oversatt til maskinspråk kode og, avhengig av konfigurasjon, påfølgende oppkall til samme metoden må ikke nødvendigvis gå gjennom samme oversettelse, noe som kan redusere overhead (dvs. overhead pådras bare én gang per metodeoppkall). Selv om CLR tilveiebringer mange standard kjørefasetjenester blir styrt kode aldri tolket. Samtidig fjerner minnestyringen mulighetene for fragmentert minne og øker minnets referanselokalitet til ytterligere å øke ytelsen.

[0043] Igjen med henvisning til arkitektur 105 vises forholdet mellom CLR og klassebiblioteket med hensyn til brukerprogrammer og til det generelle system (f.eks systemet 100) og viser hvordan styrt kode opererer innenfor en større arkitektur.

[0044] CLR forvalter minne, trådkjøring, eksekvering av kode, kodesikkerhetsbekreftelse, kompilering og andre tjenester. Disse funksjonene er vesentlig for styrt kode som kjøres på CLR.

[0045] Med hensyn til sikkerhet kan styrte komponenter tildeles varierende grad av tillit, avhengig av en rekke faktorer, inkludert deres opprinnelse (for eksempel Internett, bedriftens nettverk eller den lokale datamaskinen). Dette betyr at en styrt komponent kan eller kan ikke utføre filtilgangsoperasjoner, registertilgangsoperasjoner eller andre sensitive funksjoner, selv om det blir brukt i samme aktive brukerprogram.

[0046] CLR kan håndheve kodetilgangssikkerhet. For eksempel kan brukerne stole på at en eksekverbar fil innebygd i en webside, kan spille en animasjon på skjermen eller synge en sang, men får ikke tilgang til sine personlige data, filsystem eller nettverket. Sikkerhetsfunksjonene i CLR kan dermed få legitim Internett-distribuert programvare til å være eksepsjonelt rik av funksjoner.

[0047] CLR kan også håndheve koderobusthet ved å gjennomføre en streng type-og-kode-verifikasjonsinfrastruktur, kalt felles-type-system (CTS, ”common type system”). CTS sikrer at all styrt kode er selvbeskrivende. Styrt kode kan oppta andre styrte typer og forekomster, mens det strengt håndhever typerenhet og type-sikkerhet.

[0048] Det styrte miljø av CLR sikter på å eliminere mange felles programvareproblemer. For eksempel kan CLR automatisk håndtere objektlayout og håndtere referanser til objekter, slippe dem når de ikke lenger brukes. Slik automatisk minnestyring løser de to vanligste programfeil, minnelekkasjer og ugyldige minnereferanser. Samkjøringsevne mellom styrt og ikke-styrt kode kan gjøre det mulig for utviklere å fortsette å bruke nødvendige COM-komponenter (Component Object Model) og DLL-filer (dynamic-link libraries).

[0049] .NET-rammeverkets CLR kan bevertes av høy-ytelses, server-sideprogrammer, for eksempel Microsoft SQL Server og Internet Information Services (IIS). Denne infrastrukturen muliggjør bruk av styrt kode for skriving av forretningslogikk, mens en fortsatt bruker bedriftens servere som støtter kjørefasevertstjenesten.

[0050] Serverprogrammer i den styrte domenen er implementert som kjøreverter. Ikke-styrte brukerprogrammer beverter CLR, som tillater tilpasset styrt kode for å styre atferden til en server. En slik modell tilveiebringer funksjonene i CLR og klassebiblioteket samtidig som en oppnår ytelsen og skalerbarheten av en vertsserver.

[0051] Som allerede nevnt bruker ulike eksemplariske teknikker virtualisering til å etterligne en tilpasset eller endret ISA på toppen av et portabelt, kontrollerbart, styrt CLR-miljø. Dette er vist i arkitekturen 105 ved en eksemplarisk tilpasset/endret ISA og/eller VM 107 (stiplet bue) som sitter på toppen av grensen til CLR og rommet til de styrte programmer (bemerk at ulike eksempler diskuterer også ikke-styrte programmer). Dette viser at tilpasset/endret ISA ikke forstyrrer driften av CLR og den underliggende sikkerheten eller "host"-miljøet (for eksempel, OS/HW). Mens en egendefinert ISA kan tilveiebringe styring av CLR eller "VM" i den grad det er nødvendig for å iverksette ulike funksjoner i den egendefinerte ISA, stoler ulike eksempler på en tilpasset VM, som er en modifisert versjon av det underliggende VM (dvs. en endret CLR). Derfor kan en eksemplarisk arkitektur omfatte en enkel modifisert VM eller flere VM-er (for eksempel en tilpasset VM på toppen av en målrettet VM). For å øke sikkerheten på bekostning av ytelsen kan flere VM-er stables på en måte slik at alle bortsett fra den laveste-nivå-VM virtualiserer instruksjonssettet til VM-en rett under.

[0052] I figur 1 peker en pil på et eksempel hvor et konvensjonelt CLR har et virtualiseringslag med to typer virtualiseringer VM1 og VM2 på toppen av det og et annet eksempel der et konvensjonelt CLR har to stablede virtualiseringslag VM1 og VM3 på toppen. I slike eksempler kan underliggende CLR være et tilpasset eller proprietært CLR med sikkerhetsfunksjoner hvor ytterligere ett eller flere virtualiseringslag forbedrer sikkerheten. Et fremgangsmåteeksempel inkluderer flere stablede VM-er der hver VM virtualiserer instruksjonssettet av maskinen rett under. Merk at VM-en på det laveste nivået vanligvis virtualiserer et operativsystem som kontrollerer maskinvaren mens andre høyere-nivå VM-er virtualiserer en annen VM. Som vist i figur 1 er ulike arrangementer mulig (for eksempel to VM-er på toppen av en VM, stablede VM-er osv.). En flerfoldig "tilpasset" VM-tilnærming kan bli sett på som å utnytte virtualiseringen til å få mer sikkerhet, på bekostning av ytelsen.

[0053] Med fortsatt henvisning til analogien med genetikk og miljø kan genetikk betraktes som statisk, mens miljøet kan være dynamisk. Tilsvarende kan ulike diversifiseringsbaserte tilnærminger til inngrepsmotstand være statiske og/eller dynamiske. Generelt diversifiserer en statisk tilnærming kopier av programkode, mens en dynamisk tilnærming diversifiserer VM-er eller VM-drift eller programoperasjon under kjøring. Således omfatter, som beskrevet her, ulike eksemplariske teknikker virtualisering som virker statisk, dynamisk og/eller både statisk (for eksempel å generere individualisert programkode) og dynamisk (for eksempel å variere programmet under kjøring).

[0054] Et fremgangsmåteeksempel kan være å tilveiebringe en arkitektur som omfatter et første virtualiseringslag og å tilveiebringe et andre virtualiseringslag på toppen av det første virtualiseringslaget, der den andre virtualiseringen er konfigurert til å motta en diversifisert kopi av et program og tillater kjøring av programmet ved hjelp av det første virtualiseringslaget. En slik fremgangsmåte kan forbedre programvaresikkerhet gjennom bruk av de her beskrevne diversifiseringsteknikkene.

[0055] Et fremgangsmåteeksempel kan omfatte å generere individualiserte kopier av en programkode og å tilveiebringe en virtuell maskin for gjennomføring av en individualisert kopi av programkoden, der den virtuelle maskinen kan variere programmet under kjøringen. En slik fremgangsmåte kan forbedre programvaresikkerheten gjennom bruk av de her beskrevne diversifiseringsteknikkene.

[0056] For enkelhets skyld refereres individuelt tilpassede og modifiserte ISAs her som tilpassede ISAs. En egendefinert ISA kan brukes til å lage et sett av forskjellige utgaver (eller "versjoner") av et program med følgende egenskaper: (i) hvert eksemplar i settet har et rimelig nivå for å forsvare seg mot manipulering og (ii) det er vanskelig å ny-sikte et eksisterende angrep mot én kopi til å arbeide mot en annen kopi. De mange valg resulterer i et stort område med semantisk ekvivalente programmer som kan genereres. En tilnærming kan vurdere hele dette område for å gi mer spredning, eller alternativt kan en tilnærming vurdere bare deler av dette området som antas å være, eller er bevist til å være, mer inngrepsmotstandsdyktig enn andre deler.

[0057] Inngrepsmotstandsdyktige egenskaper omfatter følgende: (i) å hindre statisk analyse av programmet, (ii) å hindre dynamisk analyse av programmet, (iii) å hindre lokale modifikasjoner, og (iv) å hindre global modifikasjoner. De to første er nær knyttet til problemet med tilsløring, mens sistnevnte to er mer inngrepsmotstandsorienterte. Men intelligent manipulering krever minst en viss grad av programforståelse, noe som vanligvis oppnås ved å observere det statiske binærprogrammet, å observere det kjørende eksekverbare programmet eller en kombinasjon og/eller gjentakelse av de to foregående teknikker.

[0058] Ulike ISAs eksisterer, for eksempel CISC, RISC og i nyere tid JAVA-bytekode og styrt MSIL. Men de siste to tenderer til å være lettere analyserbare på grunn av en rekke årsaker. Først kjøres binærkodene vanligvis ikke direkte på maskinvaren, men trenger å bli emulert eller oversatt til egen kode før kjøring. For å muliggjøre dette må grenser mellom kode og data være kjente, og det kan ikke være uklarhet mellom konstante og relokerbare adresser. Selvfølgelig medfører dette fordeler for portabiliteten. Foruten portabilitet inkluderer designprinsipper støtte for typ-spesifikk minneforvaltning og verifiserbarhet. For å sikre verifiserbarhet er pekeraritmetikk ikke tillatt, styreflyt begrenses osv. For å muliggjøre typ-spesifikk minneforvaltning, må mye informasjon kommuniseres til kjøremiljøet om objekttyper.

[0059] Alle disse designprinsipper har ført til binærkoder som er lette å analysere av eksekveringsmiljøet, men er like enkelt å analysere av en angriper. Dette har ført til dannelsen av rekompilatorer for både JAVA og styrte MSIL-binærkoder.

[0060] Generelt sett finnes en trend der designprinsipper til ISA-er kommer mer og mer i konflikt med designprinsipper som vil forenkle programvarebeskyttelse.

[0061] Som beskrevet her tilføyer en eksemplarisk teknikk for å motvirke denne utviklingen et ekstra lag med virtualisering (eller eventuelt flere tilleggs virtualiseringslag). Mer spesifikt kan virtualiseringen brukes til å etterligne en egendefinert ISA på toppen av et portabelt, verifiserbart, administrert kjørefasemiljø. Betrakt følgende konstruksjon: (i) skriv en emulator (for eksempel en tilpasset virtuell maskin) for miljøet som kjører på toppen av et CLR, (ii) ta den binære representasjon av en binærkode og legge den til som data til emulatoren og (iii ) la hovedprosedyren starte emulering på startpunktet til det originale kjørbare programmet. Gitt denne konstruksjonen er resultatet et styrt, portabelt og verifiserbart binærprogram. Videre er det beskyttet som et originalt binærprogram, siden en angriper på det originale binærprogrammet kan lett ta det originale binærprogrammet og følge konstruksjon ovenfor.

[0062] Generelt tilsier erfaring og intuisjon for binærkodene, at den gjennomsnittlige IA32 binærkode er langt mer komplisert å forstå og å manipulere enn en gjennomsnittlig, styrt binærkode. Noen bakenforliggende årsaker omfatter (i) variabel instruksjonslengde, (ii) ingen tydelig skille mellom kode og data, og (iii) ikke klart skille mellom konstante og relokerbare adresser. Siden instruksjoner (instruksjonskode operander) kan ha variabel lengde (for eksempel 1-17 bytes), må instruksjoner bare være rettet ut på byte-grenser, og kan blandes med fylldata eller ordinær data på IA32, tilbake-assemblere kan lett komme ut av synkroniseringen. Siden det ikke finnes noen eksplisitt skille mellom kode og data, kan begge leses og skrives transparent og brukes fritt. Dette gir mulighet for selvendrende kode, en funksjon som er kjent for å være vanskelig å analysere og å forvirre angripere.

[0063] Trekket at den binære representasjon av koden kan lett bli lest, har blitt brukt til å muliggjøre selvkontrollerende mekanismer mens fraværet av kontrollflytrestriksjoner har muliggjort teknikker som kontrollflytspredning ("control flow flattening") og instruksjonsoverlapping.

[0064] At adresser kan beregnes, og at de ikke lett kan skilles fra vanlige data, gjør inngrep i binærkoder komplisert. For eksempel kan en angriper bare foreta lokale endringer, siden han har ikke tilstrekkelig informasjon til å flytte hele binærkoden. Slike observasjoner kan brukes til å generere en tilpasset eksempel-ISA som viser seg vanskelig å analysere ISA. En slik ISA kan øke sikkerheten.

[0065] Mens eksempelteknikker kan omfatte selvmodifiserende kode på en ISA og/eller kontrollflytspredning og/eller instruksjonsoverlapping, inkluderer spesifikke eksempler diskutert her bestemmelser for variabel lengde på instruksjoner og bruk av binærrepresentasjonen av deler av et program for økt inngrepsmotstand, som kan sies å være knyttet til noen selvkontrollerende mekanismer.

[0066] Programvare vet ofte ting den ikke ønsker å dele på en ukontrollert måte. Prøveversjoner kan for eksempel inneholde funksjonalitet for å utføre en bestemt oppgave, men en begrensning kan forhindre å utføre den for lenge. I digital containere brukes programvare ofte for å gi kontrollert tilgang til innholdet. Mobile agenter kan inneholde kryptografiske nøkler som må forbli hemmelig.

[0067] For å forvirre angrepet omfatter eksemplariske tilnærminger (i) gjør programmet forskjellig for ulike innretninger, (ii) gjør programmet forskjellige over tid gjennom skreddersydde oppdateringer, og (iii) gjør programmet forskjellig for hver kjøring gjennom kjørefaserandomisering.

[0068] Figur 2 viser en eksemplarisk sikkerhetsmodul 200 utført i forbindelse med et rammeverk som kjører portable kjørbare filer på en virtuell maskin. Sikkerhetsmodul 200 inkluderer et front-end-prosessmodulen 210 og en back-end-prosessmodulen 250. Front-prosessmodulen 210 leser en kjørbar binærkode 110 som er rettet mot en VM og produserer en tilpasset kjørbar binærkode 150 som er rettet mot en modifisert versjon av den opprinnelige mål-VM eller et tilpasset VM. I begge eksempler kan front-end-prosessmodulen 210 bruke filen 110 for å bestemme informasjon om den opprinnelige mål-VM, så som en VM-beskrivelse 115. Back-end-prosessmodul 250 kan bruke VM-beskrivelse 215 for å generere koden, en DLL og lignende, for en tilpasset VM 170. For eksempel kan en konvensjonell VM bli utgitt som et delt bibliotek eller DLL (for eksempel en "original"-bibliotek), og slike teknikker kan brukes for en tilpasset VM, med henvisning til at der en VM opererer på toppen av et VM, kan spesifikke egenskaper av underliggende VM tas hensyn til i formen og/eller karakteristikken av en tilpasset VM. For enkelhets skyld brukes begrepet "tilpasset" som brukt på en VM kan omfatte en modifisert VM (for eksempel en modifisert versjon av den opprinnelige mål-VM kode).

[0069] I et eksempel rettet mot .NET-rammeverk, leser front-end prosessmodulen 210 en styrt MSIL-binærkode 110, går noen ganger gjennom koden for å bestemme ISA, og produserer en XML-beskrivelse 215 av sin mål-VM. Når ISA er fastsatt kan modulen 210 omskrive den opprinnelige binærkoden til tilpassede bytekode-språk 150.

[0070] Figur 3 viser et fremgangsmåteeksempel 300 der prosessmodulens back-end 250 leser XML-beskrivelse 215 og skaper en styrt DLL for et tilpasset VM 172. Skillet i en back-end og front-end er noe kunstig, men det gir mulighet for et mer modulært design og kan forenkle feilsøking. For eksempel kan back-end prosessmodulen 250 instrueres til å utmate C#-kode 174 i stedet for å kompilere en DLL direkte (se for eksempel 172). Koden 174 kan så inspiseres og feilsøkes separat.

[0071] Figur 4 viser et fremgangsmåteeksempel 400 der ulike deler av den opprinnelige binærkoden beholdes. Nærmere bestemt inkluderer den opprinnelige kjørbare VM-binærkoden 110 en omslutning 111 rundt funksjonene 115(1)-(N) og front-end prosessmodulen 210 omskriver hver funksjon 115(1)-(N) i en omslutning 113 som kaller VM-en, og videreformidler de nødvendige argumentene. I et slikt eksempel kan alle argumenter videreføres i et array med objekter. For "INSTANCE"-funksjoner inkluderer fremgangsmåten 400 "THIS"-pekeren også. Siden fremgangsmåte 400 opererer på alle funksjoner for å plassere hver som én struktur, kan back-end prosessmodulen 210 også sørge for å formidle en identifisering av startpunktet i hver funksjon. I tillegg kan front-end prosessmodulen 210 tilby funksjoner for å sikre at et returnert objekt er omformet til retur-typen av den opprinnelige funksjon der det passer.

[0072] Figur 5 viser en spesiell implementering av fremgangsmåte 400 mer detaljert. I dette eksempelet har front-end prosessmodulen 210 konvertert funksjoner til stubber ved å bruke en omslutning som påkaller en VM. Mer spesifikk er funksjonen "foo" omsluttet av oppkallet "InvokeVM".

[0073] Som allerede nevnt kan data eller datastruktur tilveiebringe et middel for diversifisering. Figur 6 viser et fremgangsmåteeksempel 450 hvor den eksemplariske front-end prosessmodulen 210 mottar en binærkode 110 med data 117(1)-(N) i en original datastruktur og utmater en tilpasset binærkode 150 med data 117(1)-(N) i modifisert eller tilpasset datastruktur 156. Mens fremgangsmåte 450 også viser innpakning av funksjoner 115(1)-(N) kan en eksemplarisk fremgangsmåte generere en egendefinert binærkode ved å diversifisere kode, diversifisere data, og/eller diversifisere kode og data. Uttrykket "diversifiseringen av data" kan inneholde diversifiseringen av data og diversifisering basert på datastruktur.

[0074] Eksempelvise fremgangsmåter som inkluderer å omskrive det opprinnelige programmet på en per-funksjon basis har bare en fordel i at ting som datasanering ("garbage collection") ikke blir et problem, siden datastrukturer fortsatt behandles som i det opprinnelige programmet. Hvor det brukes teknikker for å tilsløre, diversifisere og for å gjøre data mer inngrepsmotstandsdyktig, kan endringer tilveiebringe oppgaver som datasanering.

[0075] Figurene 1-6, beskrevet ovenfor, illustrerer hvordan virtualiseringen kan brukes til å forbedre sikkerheten. Mer konkret kan en front-end prosessmodul brukes til å generere en egendefinert binærkode og en back-end prosess kan brukes til å generere en egendefinert VM for å utføre den tilpassede binærkoden. Figurene 7-14, beskrevet nedenfor, illustrerer hvordan spesifikke funksjoner i en ISA og/eller et VM kan brukes til å forbedre sikkerheten gjennom diversifisering.

[0076] Med hensyn til styrt kode og ulike eksemplariske teknikker som presenteres her, er valget mellom styrt-MSIL for CLR og JAVA-bytekode for JAVA-kjørefasemiljø (JRE, ”JAVA Runtime Environment”)) noe tilfeldig siden ulike eksemplariske teknikker kan overføres fra .NET- til JAVA-domenen. Videre kan teknikker for tilsløring av JAVA-bytekode brukes til styrt MSIL-binærkode. Disku sjonen som følger fokuserer hovedsakelig på eksemplariske teknikker som stammer fra et "tillagt" eller egendefinert virtualiseringslag. Automatiserte diversifisering av distribuerte kopier, for eksempel via Internett-distribusjon får kontinuerlig mer akseptans. Derfor er innføring av overhead med hvilken som helst av de eksempelvise teknikkene økonomisk stadig mer forsvarlig.

[0077] Ulike eksemplarisk teknikker kan innføre beskyttelsen automatisk ved et punkt der menneskelig samhandling ikke lenger er nødvendig. Det er teoretisk mulig å generere et uhåndterbart antall diversifiserte, semantisk ekvivalente programmer: Tenk et program med 300 instruksjoner og velg for hver instruksjon om å tilføye et no-op. Dette gir 2<300>ulike, semantisk tilsvarende programmer og 2<300>er større enn 10<87>, det anslåtte antall partikler i universet.

[0078] Men unikhet er ikke nødvendigvis tilstrekkelig siden de resulterende programmer bør være mangfoldige nok til å komplisere kartlegging av informasjon fått fra en forekomst på en annen forekomst. Videre bør de resulterende programmer fortrinnsvis være ikke-triviell å bryte. Mens det er urimelig å forvente at ko-domenen til ulike eksemplariske diversifiseringsteknikker inkluderer alle semantisk ekvivalente programmer, kan et mål settes til å maksimere ko-domenen til en diversifiserer siden jo større rommet er, jo lettere blir det å få internt ulike programmer.

[0079] En eksempel-tilnærming starter fra en eksisterende implementering av semantikk, snarere enn fra semantikken selv. Gjennom en rekke parametriserbare transformasjoner oppnås forskjellige versjoner. I ulike eksempler som følger, identifiseres en rekke komponenter i en ISA er som kan individualiseres uavhengig.

[0080] Figur 7 viser eksemplariske rammekarakteristika 500 gruppert som binære komponenter 505 og en VM-implementeringskomponent 560. Binærkomponentene 505 inkluderer instruksjonssemantikk 510, instruksjonskoding 520, operandkoding 530, FETCH-syklus 540 og instruksjonspeker (PC) og programrepresentasjon 550. Disse komponentene kan være individuelt tilpassede på en ortogonal måte så lenge grensesnittet blir respektert. Komponentene 505 er tilstrekkelige til å generere en binærkode i en tilpasset bytekode-språk; dvs. å bestemme en eksemplarisk tilpasset ISA. I tillegg kan diversifisering oppstå ved å diversifisere mål-VM eller en tilpasset VM (se for eksempel VM-implementeringskomponent 560).

[0081] Figur 8 viser en eksekveringsmodell og grensesnitt 800. Modellen 800 inkluderer kode 802, datastruktur 804, et metoderammverk 810 og en tilpasset binærkode 150. I figur 8 representerer piler grensesnittavhengigheter og stjerner representerer noen diversifiserbare deler. En eksemplarisk tilnærming som bruker en slik modell gir en modulær design og uavhengig utvikling.

[0082] Ifølge modellen 800 og rammeverket 500 kan diversifisering omfatte (i) randomisering av instruksjonssemantikk ved å bygge instruksjoner gjennom kombinasjon av mindre instruksjoner, (ii) å velge instruksjonssemantikk for å muliggjøre økt semantisk overlapping, (iii) å gå fra tradisjonell lineær kodefremstilling til å representere koden som en datastruktur så som et selvtilpassende (SPLAY) binærtre, (iv) å tilordne variable lengder til instruksjonskoder og operander for å komplisere tilbakeoversettelse og gjøre lokale modifikasjoner vanskeligere, (v) å begrense instruksjonssettet for å gi angriperen færre alternativer i å analysere og endre koden, (vi) å gjøre tilordningen mellom bitmønster, instruksjonskoder og operander variabel.

[0083] Kode 802 i figur 8 gir en oversikt på høyt nivå over en eksekveringsmotor basert på en FETCH-EXECUTE-syklus. De viktigste interne datastrukturer av VM er vist som fremgangsmåterammeverk 810. Som allerede nevnt viser pilene grensesnittavhengighet. For eksempel forventer DecodeOpcode å kunne hente en del bits.

[0084] Figur 9 viser instruksjonssemantikken 510 av figur 5 og enkelte funksjoner som kan brukes til diversifisering. Konseptet med mikrooperasjoner kan tillate diversifiseringen av instruksjonssemantikk. For eksempel kan en instruksjon i en tilpasset bytekode-språk (for eksempel gjennom en egendefinert ISA) være enhver sekvens av et forhåndsdefinert sett av mikrooperasjoner. For MSIL inkluderer settet med mikrooperasjoner i øyeblikket verifiserbare MSIL-instruksjoner og mange flere instruksjoner for å: (i) kommunisere metainformasjon som er nødvendig for riktig kjøring og (ii) aktivere tilleggsfunksjoner så som semantikkendringer (beskrevet nærmere lenger nede).

[0085] Dette kan sammenliknes med begrepet mikrooperasjoner (μOPS) i P6 mikroarkitekturen. Hver IA32 instruksjon er oversatt til en rekke operasjoner som deretter kjøres i parallell. Dette kan også bli sammenliknet med superoperatorer. Superoperatorer er virtuell-maskin-operasjoner automatisk sammensatt av kombinasjoner av mindre operasjoner for å unngå kostbar peroperasjon-overhead og å redusere størrelsen til eksekveringskoden.

[0086] Et fremgangsmåteeksempel kan omfatte å tilveiebringe stubber til å emulere hver av mikrooperasjonene, og disse kan kobles i serie for å etterligne mer uttrykksfulle instruksjoner i et tilpasset bytekode-språk (for eksempel en egendefinert ISA), men merk at mange emuleringsfunksjoner kan basere seg tungt på refleksjon.

[0087] Tenk, at et eksempel bruker følgende MSIL-instruksjoner (addisjon, laste argument og laste konstant) og deres emuleringsstubber (som har blitt forenklet):

ldarg Int32:

EvaluationStack.Push (

ArgsIn.Peek(getArgSpec(insNr) );

ldc Int32:

EvaluationStack.Push (

getInt32Spec(insNr) );

add:

EvaluationStack.Push (

(Int32)EvaluationStack.Pop()

(Int32)EvaluationStack.Pop() );

[0088] Forestill deg, at en i løpet av instruksjonsutvalgsfasen ønsker å opprette en tilpasset bytekode-instruksjon med følgende semantikk:

CustomIns n i: load the nth argument, load the constant i and add these two values.

Denne instruksjonen blir knyttet til en "case"-setning (for eksempel 1) i en stor "switch"-setning. CASE-setningen er sammenkoblingen av de ulike emuleringsstubber av mikrooperasjonene:

switch(insNr) {

...

case 1:

//Concatenation of stubs

break;

...

}

[0089] Med hensyn til inngrepsmotstand vil mangel på kunnskap om semantikken av en instruksjon komplisere programforståelsen, i motsetning til å ha en manual der semantikken er angitt. For å gå ett nivå videre kan en tilpasset inngrepsmotstandsdyktig ISA velge instruksjonssemantikken som følger noe(n) designprinsipp(er).

[0090] Med fortsatt henvisning til figur 9 kan betinget utførelse 512 brukes, eventuelt sammen med predikat-registre 513 for å øke inngrepsmotstand. Betinget utførelse kan videre fremme sammenslåing av deler av koden som er litt avvikende. I nærvær av betinget utførelse kan instruksjoner predikat-settes ved predikatregistre. Hvis predikatregisterer er satt til FALSE, tolkes instruksjonen som et no-op (ingen operasjon), ellers emuleres instruksen. Ved å bruke denne tilnærmingen settes registrene på eller langs forskjellige ekseveringsbaner for å kunne kjøre litt forskjellige deler av koden.

[0091] Et fremgangsmåteeksempel kan omfatte å tilveiebringe kodesekvenser a, b, c og a, d, c i to ulike sammenhenger i et originalt program og deretter å sammenføye koden til a, [p1]b, [p2]d, c der p1 er satt til "sann" og p2 er satt til "usann" for å kjøre koden i første konteksten og omvendt å kjøre koden i den andre konteksten. Som et resultat av å innstille én eller flere predikatregistre ulik, kan ulike deler av koden bli utført (for eksempel a, b, no-op, c og a, no-op, d, c).

[0092] Et begrenset instruksjonssett 514 kan brukes til å øke inngrepsmotstand. For eksempel kan en egendefinert ISA mangle no-ops 515, begrense representerbare operander 516 og/eller eliminere minst noen betingete grener 517. En annen tilnærming kan skreddersy en tilpasset VM til et bestemt program (mer); dermed kan en eksemplarisk tilnærming sikre at VM-en bare kan etterligne operasjoner som kreves av programmet.

[0093] Med fortsatt henvisning til en egendefinert ISA uten no-ops 515 utgjør dette en felles angrepsteknikk som fjerner "uønsket" funksjonalitet (for eksempel en lisenskontroll eller å redusere helsen til en såret spillefigur) ved å overskrive slik funksjonalitet med no-ops. I mange tilfeller er det liten grunn til å ta en no-op-instruksjon i en egendefinert ISA og å ikke ha denne instruksjonen vil komplisere en angripers forsøk til å viske ut den uønskede koden.

[0094] Med hensyn til å begrense representerbare operander 516, viser statistikken at for eksempel av heltall-literaler fra rundt 600 JAVA-programmer (1,4 millioner linjer totalt) er 80% mellom 0-99, 95% er mellom 0 og 999 og 92% er potenser av 2 eller potenser av 2 pluss eller minus 1. Slik kan en eksemplarisk tilpasset ISA begrense antall representerbare operander, som igjen begrenser friheten i et angrep.

[0095] En annen eksemplarisk tilnærmingen kan endre eller begrense bruken av minst noen betingete grener 517. For eksempel er det som regel to versjoner for hver tilstand: "forgren hvis tilstanden er satt og forgren dersom tilstanden ikke er satt". Siden bruk av to grener er overflødige, kunne en egendefinert ISA inkludere og omskrive koden slik at kun en versjon brukes og at den andre ikke er inkludert i ISA. Denne eksemplariske teknikken kan være nyttig for eksempel når en lisenssjekk forgrener betinget avhengig av gyldigheten av serienummeret: Det vil hindre angriperen fra bare å legge om forgreningsbetingelsen.

[0096] Figur 10 viser instruksjonskoderingsblokk 520 fra figur 5 med ulike aspekter av instruksjonskoding som kan brukes til diversifisering. Mer konkret inkluderer aspektene variable instruksjonsstørrelser 522, monokoding for fysisk overlapping 524, ikke-lokal semantikk 526 og omorganisering av dekoderingsstruktur 529.

[0097] Når instruksjonssemantikk er fastsatt finnes et behov for å bestemme en instruksjonskode-koding for disse instruksjonene. Størrelsen på alle instruksjonskodes for tradisjonelle arkitekturer er vanligvis konstant eller ubetydelig variabel. For eksempel er MSIL-instruksjonskoder vanligvis en byte med en bytteverdi (0xfe) for å aktivere 2-byte-instruksjonskoder for sjeldnere instruksjoner. Den begrensede variasjon muliggjør rask oppslag gjennom tabelltolkning. Men mer generelt gir enhver prefikskode (ingen kodeord er et prefiks for andre kodeord) entydig tolkning.

[0098] I sin mest generelle form, kan dekoding av instruksjonskoder til semantikk gjøres gjennom å følge gjennom et binærtre. Dekoding begynner normalt i rot-noden; når en 0-bit leses, gjøres et trekk til venstre undernode, når en 1-bit leses, gjøres et trekk til høyre undernode. Når en bladnode nås er instruksjonskoden dekodert (for eksempel tenk på en blad-node som inneholder en henvisning til CASE-setningen som emulerer semantikken i instruksjonen).

[0099] Hvis en egendefinert ISA tillater vilkårlige instruksjonskodestørrelser, uten ulovlige instruksjonskoder, er antall mulige kodinger for n instruksjoner gitt ved følgende ligning:

(3)

I likning 3 representerer brøket antall av planare binærtrær med n blader (katalansk tall), mens fakultetsverdien representerer tilordningen av instruksjonskoder til blader. Hvis fast instruksjonskodestørrelser ble valgt med kortest mulig koding, dvs. log2 (n) bit, kan dette introdusere ulovlige instruksjonskoder. I dette tilfellet er antall mulige kodinger gitt ved følgende uttrykk (likning 4):

(4)

[0100] Mange flere muligheter fantes hvis den tilpassete ISA tillot ulovlige instruksjonskoder av andre grunner enn minimal fast instruksjonskodestørrelser. Men dette kan øke størrelsen på en binærkode skrevet i egendefinert ISA uten å gi fordeler.

[0101] I de ulike eksemplene som presenteres her rettet mot .NET-rammeverket (f.eks MSIL), kan følgende moduser bli støttet: (i) fast lengde for instruksjonskoder med tabelloppslag, (ii) flernivå-tabellkoding for å muliggjøre instruksjoner med noe variabel lengde (byttekoder brukes til lengre instruksjonskoder) og (iii) instruksjonskoder med vilkårlig lengde med binærtresøking for dekoding. Slike moduser kan brukes til andre rammeverk hvis de passer.

[0102] Å ikke vite tilordningen fra bitsekvenser til semantikk introduserer for en angriper en læringskurve med hensyn til å inngrepsmotstand, for eksempel i forhold til å ha slik informasjon i en brukerveiledning. En rekke andre tilnærminger eksisterer for å velge en tilordning på en slik måte, at den tillater inngrepsmotstandsegenskaper.

[0103] Som allerede nevnt omfatter instruksjonskodingsblokk 520 i figur 10 en tilnærming med variabel instruksjonsstørrelse 522. For eksempel kan egendefinerte ISA introdusere enda mer varians i instruksjonskodelengden enn tillatt i en CISC-binærkode. Variable instruksjonsstørrelser kan også brukes til å gjøre lokale modifikasjoner mer komplisert. Generelt sett kan ikke en større instruksjon bare erstatte en mindre instruksjon, fordi det vil overskrive neste instruksjon. En egendefinert ISA kan også sørge for at mindre instruksjoner som ikke overfører kontrollen, ikke kan erstatte større instruksjoner. For eksempel kan dette gjøres ved å sikre at slike instruksjoner ikke kan utfylle til å la kontrollflyten gå til neste instruksjon.

[0104] Betrakt en kode eller ISA med 64 instruksjoner der hver instruksjon kan være tildelt en unik størrelse i en rekke bits (for eksempel mellom ca 64 bits og ca 127 bits). Det er klart at større instruksjonene ikke passer inn i plassen til mindre instruksjoner. Videre passer mindre instruksjonene in i plassen til større instruksjoner. Men når kontrollflyten kommer til neste bit er det ingen instruksjon til å fylle ut de resterende bits med no-ops for å sikre kontrollflyten til neste instruksjon. Følgelig er det med denne ordningen nyttig å gjøre flytstyringsinstruksjoner lengst for å holde en angriper fra å bryte ut til et annet sted hvor han kan gjøre hva han vil.

[0105] Instruksjonskoderingsblokk 520 omfatter også en monokodingstilnærming 524 for å oppnå eksempelvis fysisk overlapping. En monokodingstilnærming kan komplisere et program ved å øke eller maksimere fysisk overlapping. For eksempel kan en slik tilnærming være i stand til å hoppe til midten av en annen instruksjon, og starte å dekode en annen instruksjonen. Denne tilnærmingen kan lettes ved å velge en god koding. For eksempel kan monokoding brukes til å kode instruksjonskoder (0, 01, 001, ..., 0631). I dette eksempelet er det sannsynlig at man finner en annen instruksjon når man hopper en bit bak begynnelsen av en instruksjon:

1: add

01: mul

001: sub

0001: div

Ovenfor har fire instruksjoner fått en instruksjonskode som bruker monokoding. I dette eksempel hvis dekoding starter på det andre bit av divisjonsinstruksjonen (div), leser en subtraksjonsinstruksjonen (sub). På samme måte fremkommer på det siste bit av divisjons-, subtraksjons- og multiplikasjons- (mul) -instruksjon en addisjonsinstruksjon.

[0106] En annen innfallsvinkel for en egendefinert ISA knyttet til instruksjonskoding bruker ikke-lokal semantikk 526. Når en har et unik bytekode-språk for hver utdelt kopi bygges det en betydelig barriere mot angripere.

[0107] Generelt sett er det for ISA ingen dokumentasjon tilgjengelig for: (i) avbildningen fra bitmønstre til instruksjoner, (ii) instruksjonssemantikk , (iii) avbildningen fra bitmønstre til operander, (iv) visningen av datastrukturer, etc. Men slike avbildninger eller fremstillinger kan evt. læres av en angriper gjennom statiske eller dynamiske undersøkelser. For å forvirre et angrep kan en egendefinert ISA bruke ikke-lokal semantikk 524 for å sikre at et bitmønster har andre betydninger langs ulike eksekveringsbaner.

[0108] Et binærprogram er bare en sekvens av 1-er og 0-er, som er gitt en betydning for en prosessor. Meningen mellom bitmønstre og tolkning er vanligvis gitt av ISA. På tradisjonelle arkitekturer, hvis instruksjonskoden av en bestemt instruksjon er representert ved et gitt bitmønster, er dette mønsteret konstant for hver binærstreng overalt den finnes. En egendefinert ISA kan gjøre ethvert bestemt bitmønster variabel, men merk at ikke alle instruksjonsbitmønstre må gjøres variable for å bygge en betydelig barriere mot angrep. Derfor inkluderer den ikke-lokal-semantikkblokk 526 en variabel-bitmønster-blokk-tilnærming 527, for eksempel for en instruksjonskode for en instruksjon.

[0109] I en egendefinert ISA kan et bitmønster bare tildeles mening avhengig av tidligere kjørt kode. For å gjøre tolkningen avhengig av tidligere kjørt kode, kan, avhengig av (fullt spesifisert) innmating, en egendefinert ISA gjøre det mulig å gå til et programpunkt langs ulike eksekveringsbaner. Men en slik egendefinert ISA kan fortsatt ønske å ha kontroll over tolkningen av bits på et gitt programpunkt. For å ta hensyn til denne variasjonen, kan en egendefinert ISA gjøre tolkningsendringer heller eksplisitt enn implisitt som en bivirkning av en annen hendelse. Derfor inkluderer ikke-lokal-semantikkblokk 526 en bitmønsterblokk-tilnærming 528, for eksempel for å tildele mening basert på tidligere kodeeksekvering. Videre lenker ikke-lokal-semantikkblokk 526 eksplisitt til tolkningsendringer i den egendefinerte ISA, for eksempel for å gå til et programpunkt langs ulike eksekveringsbaner.

[0110] Et fremgangsmåteeksempel omfatter generering av diverse kopier av et program ved hjelp av instruksjonskoding for å omorganisere en dekodingsstruktur og dermed gi mulighet for å komme til et punkt i programmet langs to eller flere eksekveringsstier der en tilordnet betydningen av bitmønsteret på punktet avhenger på eksekveringsbanen til punktet. For eksempel kan en slik fremgangsmåte tildele mening basert på tidligere kodeeksekvering, som kan være ulik for ulike eksekveringsbaner.

[0111] En egendefinert ISA kan sikte til å ikke begrense kompleksiteten med hensyn til å få til et eksekveringsmiljøet i en bestemt tolkningstilstand. Med andre ord kan en slik tilnærming sikre at dersom det er lov å komme til et programpunktet fra ulike eksekveringsstier i ulike tolkningstilstander, kan det være relativt lett å migrere til et enkelt tolkningstilstandsmål uansett hva de andre tolkningstilstander kan være.

[0112] En spesiell tilnærming innebærer å omorganisere strukturen 529. For eksempel kan det å endre tolkningen utgjør ikke mer enn å omorganisere et dekodertre. Ved å ta hensyn til tidligere observasjoner kan en egendefinert ISA kun tillate en begrenset form av diversifisering. Til dette formål kan en egendefinert ISA ha et valgt nivå, ved hvilket undertreer (eller andre understrukturer) kan flyttes rundt. Et slikt valg er et kompromiss mellom hvor mange ulike tolkninger som er mulig, og hvor enkelt det er å gå til en bestemt tolkning fra et sett av eventuelt andre tolkningstilstander.

[0113] For eksempel velges det tredje nivået i en trestruktur. Forutsatt at den korteste instruksjonskode er 3 bit gir dette 8! tolkningstilstander, hvor enhver fortolkningstilstand kan nås på maksimalt 8 mikrooperasjoner. En slik tilnærming kan anvendes på et sett med MSIL-mikrooperasjoner. For eksempel følgende mikrooperasjoner:

Swap(UInt3 position1, UInt3 position2), som bytter ut nodene ved position1 og position2 og

Set(UInt3 label, UInt3 position), som bytter ut noden med merke (hva det måtte være) og node ved posisjon position.

I tilfelle av tabelltolkning, implementeres dette som en to-nivå tabelltolkning. Det første nivået kan henvise til andre tabeller som kan byttes.

[0114] I det foregående eksempel svarer mikrooperasjoner i stor grad til MSIL-instruksjoner og operandtyper samsvarer i stor grad til MSIL-operandtyper. Mikrooperasjonsemuleringsstubber som bruker operander bruker funksjonskall for å sikre at instruksjonskodekoding kan diversifiseres ortogonalt. Slike tilbakekall fører dessuten et argument "insNr" som identifiserer en egendefinert-VM-instruksjon som den ble oppkalt fra (se for eksempel eksempelet for instruksjonssemantikk 510). Dette sørger for å kode operander ulikt for ulike egendefinerte VM-instruksjoner. Merk at på grunn av seriekoblingen av stubber, kan et vilkårlig antall operander følge instruksjonskoden. Dermed kan tilnærmingen for operandkoding 530 omfatte slike teknikker. Derfor kan lignende diversifiseringstilnærminger for instruksjonskodekodingen utføres som for instruksjonskoding.

[0115] Diversifisering av FETCH-syklusen kan betraktes som en "kunstig" form av diversifisering. Figur 11 viser FETCH-syklus-blokk 540 som inkluderer ulike tilnærminger som bruker "filtre" 542. En grunnleggende "ikke-tilpasset" FETCH-syklus får ganske enkelt en rekke bits fra en egendefinert bytekodebinærstreng avhengig av gjeldende instruksjonspeker (PC). Men bruk av ett eller flere filtre 542 muliggjør en tilpasset FETCH-syklus som forbedrer inngrepsmotstanden. En slik filter eller filtre kan forvandle selve bits i binærstrengen til bits som så tolkes av VM-en.

[0116] FETCH-syklus-filtre 542 kan tilføye kompleksitet ved å kombinere en eller flere valgte bits med annen informasjon. For eksempel kan de reell valgte bits kombineres med andre deler av et program 543. På denne måten blir et program mer avhengig av seg selv siden endringer i en del av programmet også kan påvirke andre deler. Andre filtertilnærminger omfatter et filter som kombinerer en eller flere bits med en tilfeldig verdi 544 (f. eks. avledet fra en hemmelig nøkkel) og et filter som kombinerer en eller flere bits med instruksjonspekeren (PC) 545 for å komplisere mønsteravbildningsteknikker.

[0117] Den mest tradisjonelle fremstilling av kode er som en lineær sekvens av bytes. I en slik tilnærming peker en instruksjonspeker (PC) bare til neste byte som skal utføres og flytendringer spesifiserer vanligvis den byten for å fortsette kjøringen som en relativ forskyvning eller en absolutt adresse. Dette kan i hovedsak ses på som en struktur som representerer koden som et felt med bytes.

[0118] Figur 12 viser instruksjonspekeren og programrepresentasjonsblokk 550 sammen med ulike strukturelle tilnærminger, inkludert array 553, tre 554, koblet liste 555 og hash-tabell 556. En egendefinert ISA kan representere koden som et SPLAY-tre så som SPLAY-trærne 1320 og 1330 i figur 13. Mens koden kan representeres som et SPLAY-tre kan en eksemplarisk tilnærming for en egendefinert ISA alternativt eller i tillegg representerer dataene i et SPLAY-tre eller en annen valgt struktur for å forbedre sikkerheten. Generelt kan slike tilnærminger tilveiebringe diversifiseringen lettere enn en tradisjonell lineær representasjon (se for eksempel, lineær tilnærming 1310 i figur 13).

[0119] SPLAY-trær har en rekke fordeler: De er selvbalanserende, som gir mulighet for automatisk flytting av kode. Videre er de nesten optimale i forhold til amortisert kost for vilkårlige sekvenser. Endelig tenderer nylig åpnete noder til å være nær roten av treet, noe som gir mulighet for delvis innflytelse av romlig og tidsmessig lokalitet som finnes i de fleste eksekverbare filer.

[0120] På grunn av selvbalanseringsegenskapen kan et stykke kode være på mange ulike steder i minnet, avhengig av utførelsesbanen som førte til et bestemt kodefragment. Kodefragmenter kan flyttes rundt så lenge det er en måte å referere til dem for kontrollflytendring, og slik at de kan hentes når kontrollen er overført til dem. En eksemplarisk strukturtilnærming bruker nøkkelen til nodene i SPLAY-treet der kontrolloverføringer angir nøkkelen til noden som kontrollen skal overføres til. I et slikt eksempel er kravet at målene for kontrollflyten er noder (dvs. en kan ikke uten videre hoppe i midten av koden innenfor en node). I praksis betyr dette at kjøringen starter en ny node for hver grunnblokk. Gjennomkjøringsbaner kan håndteres ved å gjøre all kontrollflyt eksplisitt. I et slikt eksempel kan alle kontrollflytmål være angitt som nøkler til noden som inneholder målkoden. Videre kan størrelsen til koden i en node være konstant. Enda mer kan, hvis en node er for lite til å inneholde en hel grunnblokk, det overskytende "renne over" til en annen node og fortsette kjøringen der.

[0121] Figur 13 illustrerer et tilnærmingseksempel som bruker SPLAY-trær 1320, 1330 for en gitt lineær tilnærming 1310 for en fakultetsfunksjon "Fac". Når for eksempel funksjonen "Fac" kalles for første gang, blir noden med nøkkel 1 referert og trekker til roten, som vist i del (2). En annen ting som er verdt å legge merke til i dette eksemplet er, at oppkallene ikke lenger trenger å spesifisere funksjonssignaturen, siden denne koden ikke vil være gjenstand for verifikasjon.

[0122] Hvis en slik teknikk implementeres naiv, ville kun pekere bli flyttet rundt, og den faktiske koden ville forbli på samme sted i minnet. For å komplisere dette ytterligere kan en eksplisitt utveksling av selve innholdet (av primitiv-typer) av nodene skje, eller alternativt en tildeling av en ny kodebuffer kan gjøres sammen med kopiering av kodebuffer til tildelt plass, muligens med ny-kryptering og/eller med annen dataavfallstømming.

[0123] Med fortsatt henvisning til rammeverkskarakteristika 500 i figur 7 kan eksemplariske tilnærminger brukes til VM-implementering 560. Noen tilnærminger er vist i figur 12. For en gitt intern implementering, fastsettes en vurderingsstabel ikke på grunnlag av ISA (f. eks. se komponenter 505). I et slikt eksempel kan emuleringsstubber for mikrooperasjoner kun stole på et grensesnitt som støtter en rekke operasjoner så som "pop" og "push". Et tilnærmingseksempel for en intern implementering av en stabeldatastruktur 562 introduserer uavhengig diversifikasjon via gjennom for eksempel, et felt, en lenket liste, osv. Et tilnærmingseksempel kan eventuelt tilveiebringe en rekke ulike implementeringer av slike grensesnitt.

[0124] En annen tilnærming har som mål å spre VM-generering 564. For eksempel kan, når parametrene for ovenfor angitte former for diversifiseringen er fullt spesifisert, en eksemplarisk back-end prosess kombinere kodebiter fra ulike steder sammen med noe automatisk generert kode for å sette sammen en styrt C#-representasjon for implementering av den egendefinerte VM. Alternativt kan en eksemplarisk back-end prosess utmate en DLL direkte.

[0125] En annen eksemplarisk tilnærming innebærer å diversifisere DLL-er 566, for eksempel ved hjelp randomiserbare versjoner av eksisterende kodetransformasjoner fra ulike domener så som programvareoptimalisering, programvaretilsløring, (tilnærminger ikke basert på virtualisering til) programvarediversifisering etc.

[0126] Mens ulike eksemplariske teknikker diskutert her generelt innfører noe overhead, kan slik overhead tolereres hvor DRM (digital rights management), sensitiv informasjon (for eksempel regjering, proprietær osv.), lisenser, etc., er involvert, gitt den økte sikkerheten innført via diversifisering. I slike tilfeller kan diversifiseringsteknikker brukes på de typisk utsatte områder og ikke på kjørefasefunksjoner som krever en viss grad av samtidig eller "real-time"-utførelse. For eksempel kan diversifisering brukes på kode forbundet med administrasjon av digitale rettigheter og ikke på kode som krever en form for DRM-ok før kjøringen.

[0127] Virtualisering åpner en rekke muligheter for både diversifikasjon og inngrepsmotstand. Å kontrollere et eksekveringsmiljø tilveiebringer betydelig innflytelse på å komplisere oppgaven for en angriper. Mens ulike eksempler viser til et spesielt rammeverk for programvarebeskyttelse basert på begrepet virtualisering, har ulike tilnærminger også blitt identifisert hvor diversitet og/eller inngrepsmotstandsdyktige trekk kan bli innført på en hovedsakelig selvstendig måte. Modulær utvikling og/eller distribusjon kan brukes.

[0128] Figur 15 illustrerer en eksempelvis databehandlingsanordning 1500 som kan brukes til å implementere ulike eksemplariske komponenter og til å danne et eksempelsystem. For eksempel kan servere og klienter av systemet i figur 1 omfatte ulike trekk fra anordning 1500.

[0129] I en grunnkonfigurasjon inneholder databehandlingsanordningen 1500 vanligvis minst en prosessorenhet 1502 og systemminne 1504. Avhengig av den nøyaktige konfigurasjonen og typen avdatabehandlingsanordning, kan systemminne 1504 være flyktig (som RAM), ikke-flyktig (som ROM, flashminne, osv.) eller en kombinasjon av de to. Systemminne 1504 inneholder vanligvis et operativsystem 1505, ett eller flere programmoduler 806, og kan inneholde programdata 1507. Operativsystemet 1506 inkluderer et komponentbasert ramme verk 1520 som støtter komponenter (herunder egenskaper og hendelser), objekter, arv, polymorfisme, refleksjon, og tilveiebringer et objektorientert komponentbasert API ("Application Programming Interface"), for eksempel .NET-rammeverk produsert av Microsoft Corporation, Redmond, WA. Operativsystemet 1505 omfatter også et eksemplarisk rammeverk 1600, for eksempel - men ikke begrenset på - et eksempelvis rammeverk med en egendefinert ISA og/eller egendefinert VM. Videre kan databehandlingsanordningen 1500 inneholde en programvaremodul for å generere en egendefinert ISA og/eller en egendefinert VM. Enda videre kan databehandlingsanordningen 1500 inneholde en programvaremodul for å teste en egendefinert ISA og/eller en egendefinert VM. Databehandlingsanordningen 1500 kan inneholde en programvaremodul for å generere en egendefinert kode og/eller en egendefinert VM til å, i alle fall delvis, utføre en egendefinert kode. Enheten 1500 har en meget grunnleggende konfigurasjon markert med den stiplede linjen 1508. En terminal kan ha færre komponenter, men vil samhandle med databehandlingsanordningen som kan ha en slik grunnleggende konfigurasjon.

[0130] Databehandlingsanordningen 1500 kan ha flere trekk eller funksjonalitet. For eksempel kan databehandlingsanordningen 1500 også omfatte flere datalagringsanordninger (flyttbare og/eller ikke-flyttbare) som for eksempel magnetiske disker, optiske disker eller bånd. Slikt ekstra lagringsplass er illustrert i figur 15 ved flyttbare lagringsmedier 1509 og ikke-flyttbare lagringsmedier 1510. Datamaskinlagringsmedier kan omfatte flyktige og ikke flyktige, flyttbare og ikke flyttbare medier implementert med en hvilken som helst fremgangsmåte eller teknologi for lagring av informasjon, for eksempel datamaskin-lesbare instruksjoner, datastrukturer, programmoduler eller andre data. Systemminne 1504, flyttbare lagringsmedier 1509 og ikke-flyttbare lagringsmedier 1510 er eksempler på datamaskinlagringsmedier. Datamaskinlagringsmedier inkluderer, men er ikke begrenset til, RAM, ROM, EEPROM, flashminne eller andre minneteknologier, CD-ROM, digital versatile disker (DVD) og andre optiske lagringsmedier, magnetiske kassetter, magnetiske bånd, magnetisk disklagring eller andre magnetiske lagringsanordninger eller et annet medium som kan brukes til å lagre ønsket informasjon, og som kan åpnes av databehandlingsanordningen 1500. Enhver slik datamaskinlagringsmedier kan være en del av anordningen 1500. Databehandlingsanordningen 1500 kan også ha innmatingsanordningen (-er) 1512, for eksempel tastatur, mus, penn, taleinnmatingsanordning, berøringsinnmatingsanordninger osv. Utmatingsanordningen (-er) 1514, for eksempel en skjerm, høyttalere, skriver etc. kan også være inkludert. Disse anordningene er godt kjent i faget og trenger ikke å bli diskutert utførlig her.

[0131] Databehandlingsanordningen 1500 kan også inneholde kommunikasjonstilkoblinger 1516 som gjør at anordningen kan kommunisere med de andre dataanordninger 1518, for eksempel over et nettverk (for eksempel nevnte web eller Internett-nettverk 103). Kommunikasjonstilkoblinger 1516 er ett eksempel på kommunikasjonsmedier. Kommunikationsmedier kan vanligvis utformes av datamaskinlesbare instruksjoner, datastrukturer, programmoduler eller andre data i et modulert datasignal, for eksempel en transportbølge eller annen transportmekanisme og omfatter ethvert informasjonsleveringsmedium. Begrepet "modulert datasignal" betyr et signal som har ett eller flere av dens egenskaper satt eller endret på en måte for å kode informasjonen i signalet. Som eksempel, og ikke begrensning, inkluderer kommunikasjonsmedier kabeltilkoblede medier som et kablet nettverk eller direkte kablet tilkobling og trådløse medier som akustisk, radio, infrarød og andre trådløse media. Begrepet datamaskinlesbare medier som brukes her, omfatter både lagringsmedier og kommunikasjonsmedier.

[0132] Selv om temaet har vært beskrevet med ord som er spesifikk for strukturelle funksjoner og/eller metodiske handlinger, skal det forstås at søknadsgjenstanden definert ved de tilføyde patentkrav ikke nødvendigvis er begrenset til bestemte funksjoner eller handlinger beskrevet ovenfor. Snarere beskrives de spesifikke funksjoner og handlinger beskrevet ovenfor, som eksempler for implementering av kravene.

Claims (13)

P A T E N T K R A V

1. Datamaskinimplementerbar fremgangsmåte som omfatter:

å tilveiebringe en instruksjonssettarkitektur (200) som omfatter funksjoner for å generere ulike kopier av et program;

å bruke instruksjonssettarkitekturen til å generere ulike kopier av et program (150); å tilveiebringe en virtuell maskin (170) for eksekvering av en av de ulike kopier av programmet,

k a r a k t e r i s e r t v e d at:

funksjonene til å generere ulike kopier av et program omfatter instruksjonssemantikk (510) som tillater betinget kjøring (512) ved hjelp av predikatregistre (513), og

funksjonene til å generere ulike kopier av et program omfatter instruksjonssemantikk (510) med et begrenset instruksjonssett (514).

2. Fremgangsmåte ifølge krav 1, der det å tilveiebringe en virtuell maskin omfatter å generere et dynamisk koppelbart bibliotek (172) for en virtuell maskin.

3. Fremgangsmåte ifølge krav 1, hvor det begrensede instruksjonssett er en eller flere av:

et instruksjonssett som ikke inneholder en "ingen operasjon"-instruksjon (515); et instruksjonssett som har begrenset representasjon av operander (516); og et instruksjonssett som begrenser minst noen betingede forgreninger (517).

4. Fremgangsmåte ifølge krav 1, der funksjonene til å generere ulike kopier av et program omfatter en eller flere av:

instruksjonskoding (520) for variabel instruksjonsstørrelser (522); instruksjonskoding for å tilordne en instruksjonskode ved bruk av monokoding for å innføre fysisk overlapping (524);

instruksjonskoding for å innføre et variabelt bitmønster for en instruksjonskode for en instruksjon (527);

instruksjonskoding for å tilordne et bitmønster basert på tidligere eksekvering av en instruksjonskode (528); og

instruksjonskoding for å omorganisere en dekoderingsstruktur (529) for dermed gi rom for å komme til et punkt i programmet langs to eller flere eksekveringsstier, der en tilordnet betydning av et bitmønster ved punktet avhenger av eksekveringsbanen til punktet.

5. Fremgangsmåte ifølge krav 1, der funksjonene til å generere ulike kopier av et program omfatter et eller flere FETCH-syklus-filtre (542).

6. Fremgangsmåte ifølge krav 5, hvor det ene eller flere FETCH-syklus-filtre (542) omfatter et filter som tilføyer informasjon til et anmodet bit eller bits av en kode (543).

7. Fremgangsmåte ifølge krav 6, hvor informasjonen omfatter en eller flere av: en tilfeldig verdi (544); og

en instruksjonspekerverdi (545) eller informasjon minst delvis basert på en instruksjonspekerverdi.

8. Fremgangsmåte ifølge krav 1, der funksjonene til å generere ulike kopier av et program omfatter minst én struktur, valgt fra en gruppe (550) bestående av SPLAY-trær, koblede lister og hash-tabeller for å representere programmet.

9. Fremgangsmåte ifølge krav 1, hvor den virtuelle maskin genereres som en diversifisert virtuell maskin ved å kombinere deler av koden fra ulike steder og noe automatisk generert kode for å sette sammen en styrt koderepresentasjon for implementering av virtuell maskin eller for å mate ut en variert virtuell-maskin-DLL.

10. Fremgangsmåte ifølge krav 1, hvor minst et andre virtualiseringslag er tilveiebrakt på toppen av et første virtualiseringslag, der det andre virtualiseringslaget er konfigurert til å motta den diversifiserte kopi av programmet og tillate kjøring av programmet ved hjelp av det første virtualiseringslaget.

11. Fremgangsmåte ifølge krav 1, der den virtuelle maskinen kan variere programfunksjonen i kjørefasen.

12. Datamaskin-lesbart medium som omfatter instruksjoner som, når utført ved hjelp av en prosessor, får prosessoren til å utføre fremgangsmåten ifølge kravene 1 til 11.

13. Databehandlingsanordning tilpasset til å utføre fremgangsmåten ifølge kravene 1 til 11.