Instruksjoner

Mange sier assemblyspråk er vanskelig, men hver type assemblyinstruksjon er faktisk veldig kortfattet og forståelig.

FASM

Nedenfor følger instruksjoner for FASM – en mye brukt assembler. Det finnes selvsagt alternative assemblere, da vil instruksjonene være litt annerledes.

mov

For å flytte (dvs. kopiere) data brukes instruksjonen mov:

mov destinasjon,kilde

Noen eksempler:

mov eax,8CBh
mov eax,edx
mov si,cx

Øverst er det verdien 8CBh som flyttes. Dette er en heksadesimalverdi da det er hengt på en h til slutt. For flytting av data mellom to forskjellige registre må begge registrene være av samme størrelse.

add

Om man skal legge sammen to verdier brukes add:

add destinasjon,kilde

Noen eksempler:

add eax,11b
add eax,edx
add si,cx

I øverste eksempel legges verdien 11b til verdien som allerede finnes i eax. Fordi det henger en b til slutt er dette et binærtall. Hvis man legger sammen registre må begge registrene være av samme størrelse, sånn som greia også er ved flytting.

sub

Motsetningen til add blir sub, for å trekke fra:

sub destinasjon,kilde

Noen eksempler:

sub eax,4h
sub cl,dl

Øverst trekkes 4h fra verdien som allerede finnes i eax. Størrelseskravet gjelder også her ved bruk av to forskjellige registre.

inc

Som et mulig alternativ til add har man inc:

inc destinasjon

Noen eksempler:

inc eax
inc cl
inc dl

Her inkrementeres verdien som allerede finnes i registeret, dvs. at den økes med 1.

dec

Motsetningen til inc blir dec:

dec destinasjon

Noen eksempler:

dec eax
dec cl
dec dl

Verdien som allerede finnes i registeret blir dekrementert, dvs. redusert med 1.

mul

Skal man multiplisere sammen to verdier bruker man mul og oppgir kun èn kilde:

mul kilde

Resten er allerede bestemt:

  • Kilde nr. 2 skal være al (8-bit), ax (16-bit) eller eax (32-bit).
  • Valgt kilde nr. 2 må være like stor som kilde nr. 1!
  • Destinasjonens størrelse blir dobbelt så stor som kildene. Så 8-bits kilder gir destinasjon som er 16-bit, o.s.v.
  • Mulige destinasjoner er
    • ah kombinert med al som sammen gir 16-bit.
    • dx kombinert med ax som sammen gir 32-bit.
    • edx kombinert med eax som sammen gir 64-bit.

Før mul kjøres må selvsagt begge kilder gis verdi – se komplett eksempel:

mov si,2h           ; verdi satt for første kilde
mov ax,11b          ; verdi satt for andre kilde
mul si              ; resultatet skal tilsvare 6 i desimaltallsystemet

OBS: mul foretar usignert multiplikasjon, for signert må imul brukes i stedet.

div

Som med multiplikasjon oppgir man kun èn kilde for divisjon (div):

div kilde        ; dette er nevner, altså den verdien det skal deles på

Resten er bestemt og ganske likt som for mul:

  • Den andre kilden (dvs. teller) blir en av
    • ah kombinert med al som sammen gir 16-bit.
    • dx kombinert med ax som sammen gir 32-bit.
    • edx kombinert med eax som sammen gir 64-bit.
  • Delregistrene over benyttes også for å lagre resulterende kvotient og rest
    • Rest lagres øverst, i ah (8-bit), dx (16-bit) eller edx (32-bit).
    • Kvotient lagres nederst, i al (8-bit), ax (16-bit) eller eax (32-bit).

Før div kjøres må selvsagt begge kilder ha verdi – se eksempel:

mov si,2h           ; verdi satt for nevner
mov eax,110b        ; verdi satt for teller
div si              ; resultatet skal tilsvare 3 i desimaltallsystemet

OBS: Som med mul jobber også div usignert, man har da idiv hvis man ønsker signert.

TBC

Registre

Enhver prosessor har registre for oppbevaring av forskjellige viktige data ved kjøring av instruksjoner i et program.

På Intel-plattformen er det mye tilbakekompatibilitet, som blant annet viser seg i hvordan prosessorens mange registre som regel er designet:

Illustrasjonen viser et typisk eksempel, nemlig registeret rax. Dette er en utvidelse av eax. Videre er eax en utvidelse av ax. Og ax består av ah ("a high") og al ("a low").

Med et slikt design kan man faktisk hente verdiene i eax, ax, ah og al bare ved å avlese rax. Bokstaven a står for akkumulator (dvs. «accumulator» på engelsk). Registeret brukes gjerne for aritmetikk og logikk.

Noen typer

I hovedsak finnes det tre typer registre og noen typer har igjen egne undergrupper.

Generelle

For generelle registre er det tre grupper av registre siden formålene er forskjellige.

Dataregistre

Det er ganske opplagt hva et dataregister brukes til, det er data.

Og det finnes fire stk – hvor disse utvider eksisterende mindre registre:

  • RAX (64-bit) <== EAX (32-bit) <== Accumulator (AX) (16-bit) <== AH og AL (8-bit).
  • RBX (64-bit) <== EBX (32-bit) <== Base (BX) (16-bit) <== BH og BL (8-bit).
  • RCX (64-bit) <== ECX (32-bit) <== Counter (CX) (16-bit) <== CH og CL (8-bit).
  • RDX (64-bit) <== EDX (32-bit) <== Data (DX) (16-bit) <== DH og DL (8-bit).

Pekerregister

Et pekerregister inneholder adressen til det som det skal pekes til. Man har f.eks. peker som viser til neste instruksjon som skal kjøres.

To pekerregistre:

  • ESP (32-bit) som utvider Stack Pointer (SP) (16-bit).
  • EBP (32-bit) som utvider Base Pointer (BP) (16-bit).

Indeksregister

Man bruker gjerne et indeksregister slik man bruker vanlige tellere i et hvilket som helst programmeringsspråk, når man skal forholde seg til tabeller eller vektorer.

To indeksregistre:

  • ESI (32-bit) som utvider Source Index (SI) (16-bit)
  • EDI (32-bit) som utvider Destination Index (DI) (16-bit).

Kontroll

Registre for kontroll handler om hva som har skjedd og hva som skal skje:

  • Flaggregister (32-bit) som inneholder flagg (dvs. 0 eller 1), her er noen:
    • Overflow Flag (OF)
    • Direction Flag (DF)
    • Interrupt Flag (IF)
    • Trap Flag (TF)
    • Sign Flag (SF)
    • Zero Flag (ZF)
    • Auxiliary Carry Flag (AF)
    • Parity Flag (PF)
    • Carry Flag (CF)
  • Instruction Pointer (IP) (32-bit), som peker til neste instruksjon.

Segment

Det finnes flere segmentregistre. De viktigste er for stack, kode og data.

TBC

To typer programvaresikkerhet

Programvaresikkerhet kan deles opp i to typer:

  • Kode-, og designsikkerhet. Hvor fokuset er på å designe sikker programvare samt unngå lus når man foretar implementeringen. Her gjør man hva man kan (f.eks. statisk analyse) for å unngå dårlig design og kode.
  • Applikasjonssikkerhet. Her prøver man å sikre seg i ettertid, ved å bestemme hva som skal kjøres, av hvem, og hvor. Dette kan f.eks. gjøres med en sandboks («sandbox» på engelsk) for sikker kjøring eller policier.

Begge typer er viktige om man ønsker best mulig sikkerhet.

Statisk analyse

Når man analyserer kode for å finne svakheter, uten å kjøre programmet, foretar man det som kalles for statisk analyse.

Det er da flere ting man som regel ønsker å sjekke:

  • Typer – f.eks. forsøk på å lagre tekst i en variabel for tall. Dette blir først og fremst nødvendig hvis brukte verktøy (f.eks. IDE og kompilator) ikke undersøker selv.
  • Stil. Dette er simpelthen kodestil, altså kodeformatering. Dvs. tomrom, navning, kommentarskriving, o.s.v. Noen undersøker også programstruktur og kan si ifra hvis det mangler noe. Denne type sjekking bør man helst ha med fra starten av i et prosjekt, før man begynner å skrive masse kode og tillegge seg (u)vaner.
  • Lus – dvs. «bugs» på engelsk. Her sjekkes det for uønsket og ikke tiltenkt funksjonalitet, fordi dette kan åpne for sikkerhetshull.

For sistnevnte vil man som regel oppleve å få falske positiver og falske negativer, selv om analyseprogrammene er lagd av veldig proffe folk. Og man avdekker først og fremst kun generelle kodefeil som åpner for sikkerhetshull uansett hvilke omstendigheter som er gjeldende.

Å oppdage kodefeil som gir situasjonsbestemte sikkerhetshull er vanskeligere.

TBC

De syv farlige kongeriker

Innenfor temaet kodesikkerhet finnes det syv forskjellige felt:

  1. Inndatabehandling – alle innmatede data må sjekkes grundig. Buffer-overflyt og SQL-injeksjon er to eksempler på angrep som kan utføres når ting ikke er på stell.
  2. API-misbruk, her tukler man med et API ved å ikke bruke det slik det er ment.
  3. Sikkerhetsfunksjonalitet – når autentisering, tilgangskontroll, konfidensialitet, kryptografi, o.s.v. implementeres må det gjøres tilfredsstillende.
  4. Tidspunkt og tilstander. Programmer som ikke kjører fra start til slutt uavbrutt, f.eks. spill med masse spillere samtidig, må gis ekstra sikkerhet, for å hindre manipulering.
  5. Feilhåndtering – når det oppstår feil må dette håndteres riktig. Og uten at man avslører mye data eller hvordan programmet fungerer internt.
  6. Kodekvalitet. Hvis et program har dårlig kodekvalitet er som regel sikkerheten også fraværende. Et tegn på dette er at programmet er lite brukervennlig.
  7. Innkapsulering – å ha tydelige skiller, f.eks. mellom validerte og uvaliderte data.

Rekkefølgen gjenspeiler hvor viktig hver kategori er. Sammen utgjør de det som kalles for de syv farlige kongeriker. Man bør også ta med ett åttende ledd, som er omgivelsene.

Switch-sikkerhet

Med en smart switch kan man velge hvem som skal få koble til et lokalt kablet nettverk, omtrent slik greia også er for vanlige trådløse aksesspunkt.

Det finnes to muligheter:

  • Portsikkerhet – her velger man hvilke MAC-adresser som skal tillates på nettverket.
  • 802.1x – hvor man kobler til ved å autentisere seg. I virksomheter flest blir dette da med samme brukernavn og passord som når man logger på brukerprofilen sin, hvis ting er satt opp riktig.

Alternativ nr. 1 er ikke sikker da MAC-adresser kan forfalskes. Ønsker man uautorisert tilgang med alternativ nr. 2 må man derimot finne et gyldig brukernavn og passord.

Sikkerhetspolicy

En sikkerhetspolicy kommuniserer på høyt nivå hvilke krav som stilles når virksomhetens datasystemer installeres, vedlikeholdes og brukes. Altså gjør man det klart hvor policyen gjelder og for hvem. Man bør også redegjøre for hva som er meningen med den.

Sikkerhetspolicier er viktige fordi de styrer arbeidet med å utvikle sikkerhetsstandarder, sikkerhetsprosedyrer og sikkerhetsguider.

Å lage en sikkerhetspolicy bør gjøres i faser:

  1. Kartlegging av alle krav – forretningsmessige, lovregulerte, beste praksis og muligens noen som er virksomhetsspesifikke.
  2. Definere behovet og basert på dette lage et grovt forslag til policy.
  3. Skrive en komplett policy med utgangspunkt i forslaget.
  4. Kritisk vurdering av policyen også eventuelt vedtakelse av den.
  5. Publisering og distribusjon av policyen for hele virksomheten.
  6. Evigvarende vedlikehold og fornyelse når policyen trenger det, dvs. at man påbegynner kravinnsamling igjen.

En sikkerhetspolicy skal ikke lages i et vakuum, man må involvere alle avdelinger og ansatte som vil bli berørt av den.

TBC