NO336580B1 - Oppdateringssystem og metode for å oppdatere et skanningsundersystem i et mobilt kommunikasjonsrammeverk - Google Patents

Description

Oppdateringssystem og metode for å oppdatere et skanningsundersystem i et mobilt kommunikasjonsrammeverk

Introduksjon

Den foreliggende oppfinnelsen omhandler mobilkommunikasjonsinnretnings-sikkerhet, og mer spesifikt til skanning av mobile kommunikasjonsinnretninger for ondsinnet programvare.

Bakgrunn for oppfinnelsen

I det siste tiåret har det vært en rask vekst i antall og bruk av mobiltelefoner. I nyere tid har trådløse innretninger blitt introdusert som kombinerer funksjonaliteten til mobiltelefoner og personlige digitale assistenter (PDA). Det er forventet at dette området vil oppleve en massiv vekst i nær fremtid, ettersom nye mobile telekommunikasjonsstandarder (dvs. GPRS, UMTS og WAP) gjør det mulig med høyhastighetsoverføring av data langs trådløse grensesnitt.

Det kan forventes at slike plattformer vil være utsatt for angrep fra såkalt "malware" slik som virus, trojanske hester, og ormer (videre referert til som "virus"); og andre uønsket/skadelig innhold mye lignende som dagens personlige datamaskiner og arbeidsstasjoner er utsatt for. Et antall mobile telefonvirus har allerede blitt identifisert.

For å kunne motstå virusangrep, må antivirusprogramvare være anvendt på mobile plattformer på en lignende måte som den har blitt anvendt på en desktop-omgivelse. Et antall ulike desktop anti-virus-applikasjoner er for tiden tilgjengelige. Majoriteten av disse applikasjonene avhenger av basic skanningmotor som søker i mistenkelige filer etter tilstedeværelsen av forhåndsbestemte virussignaturer. Disse signaturene blir holdt i en database som konstant må oppdateres for å reflektere de nyeste identifiserte virusene.

Typisk kan en bruker laste ned erstatningsdatabaser i ny og ne, enten over internett, fra en mottatt e-post, eller fra en CDROM eller floppy disk. Brukere er også forventet å oppdatere deres softwaremotor jevnlig for å kunne ta fordel av nye virusdeteksjonsteknikker som kan være påkrevd når nye angrep av virus blir detektert.

US 6,205,579 Bl beskriver et system og en metode for oppdatering av et skanningssystem til en mobil kommunikasjonsinnretning, hvor metoden omfatter å sende en første del av oppdateringen for å oppdatere skanningssystemet til den mobile kommunikasjonsinnretningen, å sende tilleggsdeler av oppdateringen i tillegg til den første delen av oppdateringen, hvor oppdateringen blir installert med skanningssystemet.

Mobile trådløse plattformer presenterer en serie problemer for softwareutvikleren (innbefattende utviklere av anti-virusprogramvare). Hovedproblemet er begrenset minne og prosesseringskraft til mobile plattformer, og begrensede input/output-muligheter som de har (dvs. ingen CDROM eller floppy disk, og ingen høy båndbredde fastlinje nettverk eller internettforbindelse). Dessverre gjør denne ulempen at enhver oppdatering av mobile kommunikasjonsinnretninger er vanskelige.

Fremstilling av oppfinnelsen

System, metode og datamaskinprogramprodukt er tilveiebrakt for effektive oppdateringer av et skanningsundersystem til en mobil kommunikasjonsinnretning. Initielt mottatt er en første del av en oppdatering tilpasset for å oppdatere et skanningsundersystem til en mobil kommunikasjonsinnretning. Videre blir flere deler av oppdateringen mottatt i tillegg til en kvittering på den første delen av oppdateringen. Oppdateringen blir så installert med skanningsundersystemet.

I én utførelse kan integriteten til oppdateringen bli bestemt. Følgelig kan oppdateringen bli betinget installert med skanningsundersystemet, basert på om integriteten til oppdateringen er verifisert.

Som en mulighet kan integriteten til oppdateringen bli bestemt ved å utnytte en signatur. Slik signatur kan bli mottatt med én av delene (dvs. den siste delen) til oppdateringen. Deretter kan signaturen bli sammenlignet mot andre signaturer generert ved å utnytte hver av delene til oppdateringen.

For å møte den begrensede båndbredden iboende i mobile

kommunikasjonsrammeverk, kan størrelsen til delene på oppdateringen bli minimalisert. Videre kan deler av oppdateringen bli komprimert.

I bruk kan det bli bestemt om den første delen er tom. Dermed kan tilleggsdelene til oppdateringen bli betinget mottatt basert på om det blir bestemt at den første delen er tom. Igjen er et slikt trekk fordelaktig for å møte den begrensede båndbredden iboende i mobile kommunikasjonsrammeverk.

Som en opsjon, kan skanningen utnytte et skanningsundersystem som stoppes ved kvittering på oppdateringen. Videre kan skanningen bli gjenopptatt ved at oppdateringen blir installert med skanningsundersystemet.

I enda en annen utførelse, kan formatet til hver del av oppdateringen bli designet for å møte den begrensede båndbredden iboende i mobile kommunikasjonsrammeverk. F.eks. kan hver del av oppdateringen innbefatte et hode. Et slikt hode kan indikere en identifikator til den assosierte delen av oppdateringen, lengde til assosiert del av oppdateringen, etc.

I enda en annen utførelse kan oppdateringen bli forespurt av den mobile kommunikasjonsinnretningen. En slik oppdatering kan bli forespurt av den mobile kommunikasjonsinnretningen ved å bruke en forespørringsdatastruktur. Alternativt kan en slik datastruktur innbefatte variable slik som en uniform ressurslokalisator (URL) variabel, en mobil kommunikasjonsidentifikatorvariabel, en applikasjonsprogramgrensesnittversjonsvariabel, en deteksjonslogisk variabel, en signaturversjonvariabel, og/eller delnummervariabel.

Kort beskrivelse av tegningene

Fig. 1 illustrerer et mobil kommunikasjonsrammeverk, i henhold til én utførelse. Fig. 2 illustrerer et mobil kommunikasjonsrammeverk i henhold til en annen utførelse. Fig. 3 illustrerer en arkitektur assosiert med en mobil kommunikasjonsinnretning i henhold til én utførelse. Fig. 4 viser et system for å aksessere sikkerhet eller innholdsanalysefunksjonalitet som utnytter en mobil kommunikasjonsinnretning i henhold til én utførelse. Fig. 5 viser et rammeverk for å aksessere sikkerhet eller innholdsanalysefunksjonalitet som utnytter en mobil kommunikasjonsinnretning i henhold til én applikasjonsserverutførelse til systemet i fig. 4. Fig. 6 viser et rammeverk for å aksessere sikkerhet eller innholdsanalysefunksjonalitet som utnytter en mobil kommunikasjonsinnretning i henhold til en innadgående biblioteksutførelse av systemet i fig. 4. Fig. 7 viser et on-demand skanningssystem implementert i sammenheng med systemet i fig. 4. Fig. 8 viser et hierarki av ulike komponenter til et applikasjonsprogramgrensesnitt (API) som kan bli brukt som et grensesnitt på mobile applikasjonsprogrammer og et skanningsundersystem i henhold til én utførelse.

Fig. 9 illustrerer et eksempel på en biblioteksgrensesnittinitialisering.

Fig. 10 illustrerer et eksempelformat på en feilkodefunksjonalitet, i henhold til én utførelse. Fig. 11 illustrerer et skanningsundersystem API-kallsekvens, i henhold til én utførelse. Fig. 12 illustrerer en eksempelkonfigurasjon API-kallsekvens, i henhold til én utførelse. Fig. 13 illustrerer ulike eksempler på skanningsdatatyper med applikasjonsprogrammer som er i stand til å kommunisere til skanningsundersystem via en API. Fig. 14 viser en bitfeltvariabel som inneholder malware alvorlighetsflagg og applikasjonsprogramoppførselsnivåer i henhold til en eksempelvis utførelse. Fig. 15 illustrerer et diagram som fremsetter måten som timing av skanning av skanningsundersystemet varieres som en funksjon av datatype identifisert via variablene til fig. 13. Fig. 16 illustrerer en eksempelstrøm som beskriver måten som oppdateringen blir initiert av et brukergrensesnitt i henhold til én utførelse. Fig. 17 illustrerer metoden for effektiv oppdatering av skanningsundersystemet til en mobil kommunikasjonsinnretning i henhold til én utførelse.

Detaljert beskrivelse

Fig. 1 illustrerer et mobilt kommunikasjonsrammeverk 100, i henhold til én utførelse. Som vist innbefattes en mobil kommunikasjonsinnretning 102 og en bakenforliggende server (eng. backend server) 104 som er i stand til å kommunisere via et trådløst nettverk. Sett i sammenheng med den foreliggende beskrivelsen kan den mobile kommunikasjonsinnretningen 102 innbefatte, men er ikke begrenset til en mobiltelefon, en trådløs personlig digital assistent (PDA), en trådløs håndholdt datamaskin, en trådløs bærbar datamaskin eller enhver annen mobil innretning i stand til å kommunisere via et trådløst nettverk.

I én utførelse, kan den mobile kommunikasjonsinnretningen 102 være utstyrt med et skanneundersystem 105. Et slikt skanneundersystem 105 kan innbefatte ethvert undersystem som er i stand til å skanne data som enten er lagret på den mobile kommunikasjonsinnretningen 102 eller i kommunikasjon med denne. Selvfølgelig vil en slik skanning referere til on-access-skanning, on-demand-skanning, eller enhver type av skanning. Videre kan skanningen innbefatte innhold (dvs. bilder, tekst, etc.) representert av forhåndsnevnte data, generelt sikkerhetstype skanning for malware, etc.

Det refereres videre til fig. 1 hvor den mobile kommunikasjonsinnretningen 102 videre kan være utstyrt med et display 106 i stand til å avbilde et flertall av grafiske brukergrensesnitt 108 tilpasset for å håndtere ulik funksjonalitet innbefattet i forhåndsnevnte skannefunksjonalitet.

I bruk blir displayet 106 til den mobile kommunikasjonsinnretningen 102 brukt for å fremvise data på et nettverk (dvs. internett, etc). Se operasjon 1. I den foreliggende bruken kan brukeren bruke displayet 106 til å se gjennom ulike data på nettverket ved å velge link eller ankere for å hente data fra nettverket via en backend server 104. Se operasjon 2. Deretter, i operasjon 3, blir skanningsundersystemet 105 kalt opp for å skanne de hentede data.

I det foreliggende eksemplet, blir skanningsundersystemet 105 vist til å ha lokalisert malware i sammenheng med hentede data i operasjonen 4. Ved dette punktet blir en bruker tilveiebrakt med en mulighet via displayet 106 til enten å stoppe hentingen og/eller bruke/tilegne data uavhengig av identifisert malware. Bemerk operasjon 5. Basert på denne avgjørelsen i operasjon 5, trenger, eller trenger ikke brukeren å være utsatt for et "angrep", som indikert i operasjon 6.

Fig. 2 illustrerer et mobilt kommunikasjonsrammeverk 200 i henhold til en annen utførelse. Det foreliggende mobile kommunikasjonsrammeverket 200 er lik til det mobile kommunikasjonsrammeverket 100 i fig. 1 med unntaket av måten som den mobile kommunikasjonsinnretningen opptrer på den identifiserte malware i hentede data.

Spesifikt blir brukeren kun tilveiebrakt med én mulighet i operasjon 5. Det vil si, brukeren er kun i stand til å lukke enhver dialog assosiert med data funnet til å innbefatte malware. Bemerk operasjon 6.

Fig. 3 illustrerer en arkitektur 300 assosiert med en

mobilkommunikasjonsinnretning, i henhold til én utførelse. Den foreliggende arkitekturen 300 kan bli innbefattet i den mobile kommunikasjonsinnretningen i fig. 1 og 2. Selvsagt kan arkitekturen 300 bli implementert i enhver ønsket sammenheng.

Som vist kan den foreliggende arkitekturen 300 innbefatte et flertall mobile applikasjonsprogrammer 302. Sett i sammenheng med den foreliggende beskrivelsen, kan de mobile applikasjonsprogrammene 302 innbefatte ethvert applikasjonsprogram, software, etc. installert på en mobil kommunikasjonsinnretning for å utføre ulike oppgaver. Det skal videre bemerkes at slike applikasjonsprogrammer 302 også kan være implementert i firmware, hardware, etc. etter brukerens ønsker.

I en annen utførelse kan applikasjonsprogrammene 302 innbefatte, men er ikke begrenset til mail-applikasjonsprogrammer, hvor oppgavene innbefatter håndtering av elektronisk mail. Videre kan applikasjonsprogrammet innbefatte et browser-applikasjonsprogram, hvor oppgavene innbefatter browsing av et nettverk. Videre kan applikasjonsprogrammet innbefatte et telefonbokapplikasjonsprogram, hvor oppgavene innbefatter håndtering av et flertall telefonnumre. Som én operasjon kan applikasjonsprogrammet innbefatte et beskjedapplikasjonsprogram, hvor oppgavene innbefatter kommunikasjonsmeldinger. Det skal bemerkes at enhver type applikasjonsprogram kan innbefattes. F.eks. kan et Java applikasjonsprogram eller lignende bli innbefattet.

Det vises videre til fig. 3, hvor et skanningsundersystem 304 forblir i kommunikasjon med applikasjonsprogrammene 302 via et første applikasjonsprogramgrensesnitt (API) 306 og et første bibliotek 308 assosiert med skanningsundersystem 304. Mer informasjon med hensyn til eksempelvise tilleggs-detaljer relaterende til det første applikasjonsprogramgrensesnittet 306 og det andre biblioteket 308 vil bli fremsatt i mer detalj med henvisning til fig. 4-12.

Som en opsjon kan applikasjonsprogrammene 302 kommunisere informasjon til skanningsundersystem 304 for å muliggjøre skanning av skanningsundersystem 304. Slik informasjon kan omhandle type data som skal skannes, og timing assosiert med en slik skanning. Mer eksempelvis informasjon som omhandler måten som skanningsundersystemet 304 samhandler med applikasjonsprogrammene 302 på en slik måte vil bli fremsatt med henvisning til fig. 13-15.

Som vist i fig. 3, kan et første bibliotek 308 innbefatte en oppdateringshåndterer 310, en konfigureringshåndterer 312, en signaturdatabase 314. Under bruk, kan oppdateringshåndtereren 310 håndtere prosessen hvor signaturdatabasen 314 blir oppdatert med de siste signaturene for skanningsformål. I én utførelse kan oppdateringsprosessen bli strømlinjeformet til å understøtte den begrensede båndbredden iboende i mobilkommunikasjonsrammeverk. Mer eksempelvis informasjon med hensyn til oppdateringsprosessen vil bli fremsatt under henvisning til fig. 16-17.

Videre er det tilveiebrakt en komponent til arkitekturen 300 i fig. 3 som er et opererende system 316 installert på den mobile kommunikasjonsinnretningen tilpasset til å eksekvere applikasjonsprogrammer 302. I én utførelse kan skanningsundersystem 304 være plattformuavhengig, og dermed i stand til å bli implementert på enhver type operativsystem/mobil kommunikasjonsinnretnings-kombinasjon.

For å understøtte dette trekket er et annet applikasjonsprogramgrensesnitt 318 og et annet bibliotek 320 i stand til å understøtte ulik funksjonalitet slik som system/bibliotekinitialisering 322, feilfunksjoner 336, minneallokeringer 334, input/output (I/O) 328, dataautentisering 332, synkronisering 330, hypertekstoverføringsprotokoll 326, innretningsinformasjon 324, debugging (feilsøking) 338, og annen funksjonalitet (dvs. delt minne, systemtid, etc). I én utførelse, kan det andre applikasjonsprogramgrensesnittet 318 være plattformuavhengig, lignende til skanningsundersystem 304. Mer informasjon om eksempelvise tilleggs-detaljer relaterende til det andre applikasjonsprogramgrensesnittet 318 og det andre biblioteket 320 vil bli fremsatt i større detalj med henvisning til Appendiks A.

Fig. 4 viser et system 400 for å aksessere sikkerhet eller

tilgangsanalysefunksjonalitet ved å utnytte en mobilkommunikasjonsinnretning, i henhold til én utførelse. I ett eksempel, kan det foreliggende systemet 400 bli implementert i sammenheng med applikasjonsprogrammer, skanning av undersystem, og operativsystemer med arkitektur 300 i henhold til fig. 3. Det skal

imidlertid bemerkes at det foreliggende systemet 400 kan bli implementert i enhver ønsket sammenheng.

Som vist er det innbefattet et operativsystem 402 installert på en mobil kommunikasjonsinnretning som er i stand til å kommunisere via trådløst nettverk. Videre er det tilveiebrakt et applikasjonsprogram 404 installert på den mobile kommunikasjonsinnretningen som blir eksekvert ved å utnytte additivsystemet 402 for å utføre oppgavene.

Et skanneundersystem 406 forblir i kommunikasjon med applikasjonsprogrammet 404 via applikasjonsprogramgrensesnitt og et assosiert bibliotek (se f.eks. det første applikasjonsprogramgrensesnittet 306 og det første bibliotek 308 i fig. 3). Et slikt skanneundersystem 406 er tilpasset for å aksessere sikkerhet eller tilgangsanalysefunksjonalitet i sammenheng med oppgaver utført av applikasjonsprogrammet 404. I én utførelse kan sikkerhets- eller innholdsanalysen innbefatte sikkerhetsanalyse, i en annen utførelse, kan sikkerhets- eller innholdsanalyse innbefatte innholdsanalyser. Enda i en annen utførelse kan sikkerhets- eller innholdsanalysen innbefatte on-demand virusskanning og/eller on-access virusskanning.

I bruk kan sikkerhets- eller innholdsanalysefunksjonaliteten bli anvendt på applikasjonsdata assosiert med oppgaver utført av applikasjonsprogrammet 404. I sammenheng med den foreliggende beskrivelsen, kan applikasjonsprogrammet innbefatte ethvert datainput, prosessert, gitt ut, eller på annen måte assosiert med ytelsen til oppgavene utført av applikasjonsprogrammet 404.

Med en tett kobling av skanningsundersystemet 406 og applikasjonsprogrammet 404 via applikasjonsprogramgrensesnittet, vil mindre "overhead" og koderedundanser være nødvendig. Mer eksempelvis informasjon omhandler et slikt applikasjonsprogramgrensesnitt og det assosierte bibliotek vil bli fremsatt i det følgende i større detalj med henvisning til etterfølgende figurer.

Fig. 5 viser et rammeverk 500 for å tilegne sikkerhet eller

innholdsanalysefunksjonalitet ved å utnytte mobil kommunikasjonsinnretning, i henhold til en applikasjonsserverutførelse til systemet 400 i fig. 4. Det skal bemerkes at det foreliggende rammeverket 500 kan bli implementert i enhver ønskelig sammenheng.

Som vist kan skanningsundersystemet innbefatte et skanningsprogram 502 som kommuniserer med applikasjonsprogrammet 504 via

applikasjonsprogramgrensesnitt 506 og en assosiert protokoll (dvs. ultron messaging system). Som fremsatt i større detalj senere, kan

applikasjonsprogramgrensesnittet 506 involvere en første komponent 508 assosiert med skanneprogrammet 502 og en annen komponent 510 assosiert med applikasjonsprogrammet 504.

Ulike kall 512 tilveiebrakt med applikasjonsprogramgrensesnittet 506 kan innbefatte et åpent kall, et datakall, og et lukket kall. I bruk kan skanningsprogrammet 502 skanne applikasjonsdata 516 assosiert med oppgaver utført av applikasjonsprogrammet 504.

Fig. 6 viser et rammeverk 600 for å tilegne sikkerhets- eller

innholdsanalysefunksjonalitet ved å utnytte en mobil kommunikasjonsinnretning, i henhold til en innadgående bibliotekutførelse i systemet 400 i fig. 4. Det skal bemerkes at det foreliggende rammeverket 600 kan bli implementert i enhver ønskelig sammenheng.

Som vist kan skanningsundersystemet innbefattet et inngående bibliotek 602. I bruk kan skanningsundersystemets innadgående bibliotek 602 bli linket til applikasjonsprogram 604 ved kjøretid. Dermed kan applikasjonsprogramgrensesnitt 606 bli brukt i hvert av et flertall av applikasjonsprogrammer 604.

Lignende til tidligere rammeverk i fig. 5, kan applikasjonsprogramgrensesnittet 606 involvere ulike kall 612 innbefattende et åpent kall, datakall, og lukket kall. I bruk kan innadgående bibliotek 602 bli brukt for å skanne applikasjonsdata 616 assosiert med oppgaver utført av applikasjonsprogrammet 604.

Fig. 7 viser et on-demand skanningssystem 700 implementert i sammenheng med systemet 400 i fig. 4. Det skal bemerkes at det foreliggende system 700 kan bli implementert i enhver ønskelig sammenheng.

On-demand skanning tilveiebringer skanning av lagrede applikasjonsdata 702 for ondsinnet innhold eller kode for fjerning. Brukeren kan initiere on-demand skanning via et brukergrensesnitt 703. Videre kan hvert applikasjonsplan 704 kalle et skanningsundersystem 706 for å utføre skanning av objektet lagret i tilhørende minne.

På den annen side tilveiebringer on-access skanning identifikasjon av ondsinnet kode eller innhold før applikasjonsprogram 704 prosesserer eller render applikasjonsdata 702. On-access skanning er transparent for brukeren inntil skanningsundersystem 706 detekterer ondsinnet applikasjonsdata 702.

Fig. 8 viser et hierarki av ulike komponenter til ulike

applikasjonsprogramgrensesnitt 800 som kan brukes for å ha et grensesnitt mot mobile applikasjonsprogrammer og et skanningsundersystem, i henhold til én utførelse. Som en opsjon, kan foreliggende applikasjonsprogramgrensesnitt 800 bli implementert i sammenheng med system 400 i fig. 4. Det skal imidlertid bemerkes at det foreliggende applikasjonsprogramgrensesnitt kan bli implementert i enhver ønsket sammenheng.

Som vist i fig. 8 innbefatter applikasjonsprogramgrensesnittfunksjonene MDoScanOpen() 802, MDoScanClose() 804, MDoScanVersion() 806, og MDoScanDataQ 808. MDoScanOpenQ 802 og MDoScanCloseQ 804 er brukt til å lage/åpne eller lukke et skanningsundersystem objekthendelse. MDoScanVersion() 806 tilveiebringer skanningsundersystem og signaturmønsterdataversjons-informasjon. MDoScanData() 808 utfører innholds/dataskanning og rapportering. Også innbefattet i skanningsapplikasjonsgrensesnittet er en MDoScanUpdate() 810 som tilveiebringer malware signaturdatabase og deteksjonslogikkoppdateringer. Når MDoScanUpdate() 810 blir kalt av en oppdateringsapplikasjon, forbindes biblioteket til en fjerntliggende back-end server (se f.eks. fig. 1), og laster ned de seneste filene (dvs. mdo.sdb, mdo.pd).

Skanningsundersystemkonfigurering blir gjort ved å bruke MDoConfigOpen() 812, MDoConfigClose() 814, MDoConfigGet() 816, og MDoConfigSet() 818. Når en konfigureringshendel blir oppnådd ved å kalle det foreliggende applikasjonsprogramgrensesnittet 800, bruker det oppkallende applikasjonsprogrammet å få et sett konfigurasjons API til å forespørre og sette skanningsundersystemkonfigureringsvariabler.

Også innbefattet i foreliggende applikasjonsprogramgrensesnitt 800 er en feilhentingsfunksjon med navn MDoGetLastError() 820. Denne funksjonen blir brukt for å hente informasjon om siste feil som opptrådte.

Før noen av API-kallene blir utført, fortrinnsvis ved oppstartstid, blir MDoSystemInit() 825 kalt for å initiere bibliotekomgivelsessettinger. Biblioteket beholder konfigureringsinnstillinger, ondsinnet kodedetekteringslogikk (dvs. mdo.pd) og signaturdatabase (dvs. mdo.sdb), og interne variabler (dvs. synkronisering av objekter, etc.) ved faste uavbrutte lagringslokasjoner.

MDoLibraryOpen() 830 og MDoLibraryClose() 840 blir brukt for å initiere biblioteket. Et applikasjonsprogram kan kalle MDoLibraryOpen() 830 før noen andre API-kall blir utført, og applikasjonsprogrammet kan kalle MDoLibraryClose() 840 før det avslutter.

Applikasjonsprogramgrensesnittet 800 kan være i stand til å understøtte ulik funksjonalitet slik som systemomgivelsesinitiering, versjonsstatusinformasjons-innhenting, oppdatering av skanningsundersystem, skanning, konfigurering av skanningsundersystem, etc. ved å bruke ulike applikasjonsprogramgrensesnitts-komponenter. Mer informasjon vil nå bli fremsatt i henhold til foregående funksjonalitet i sammenheng med applikasjonsprogramgrensesnitt 800.

Systeminitialisering

MDoSystemInit() 825 utfører validering og omgivelsesinitialisering av data beholdt ved spesifikke uavbrutte lagringslokasjoner. Ondsinnet kode/innholds-signaturmønsterdatabase (dvs. mdo.sdb), detekteringslogikk (dvs. mdo.pd), konfigureringsinnstillinger, og synkronisering av objekter kan bli lagret ved disse lokasjonene. MDoSystemInit() 825 kan bli kalt én gang (dvs. ved oppstartstid) før noen andre API-funksjoner blir eksekvert.

Tabell #1 illustrerer eksempelvis informasjon med hensyn til MDoSystemlnitQ 825.

Librarvlnterface API

Applikasjonsprogramgrensesnitt 800 innbefatter et flertall av biblioteksgrensesnitts-komponenter. API-grensesnittsøyeblikkelighet kan bli oppnådd ved å bruke MDoLibraryOpen() 830. Den instantane biblioteksgrensesnitthendel oppnådd ved å bruke denne funksjonen kan bli brukt for etterfølgende API-kall. Før applikasjonsprogrammet terminerer, kan MDoLibraryClose() 840 bli kalt for å frigi hendelen. Fig. 9 illustrerer et eksempel på et biblioteksgrensesnittinitialisering 900 som utnytter MDoLibraryOpen() 830 og MDoLibraryClose() 840.

Tabell #2 illustrerer eksempel hvis informasjon omhandlende MDoLibraryOpen() 830.

Tabell #3 illustrerer eksempelvis informasjon om MDoLibraryCloseQ 840.

Feilhenting

Straks et bibliotek har blitt vellykket initialisert og instantiert ved MDoLibraryOpen() 830, MDoGetLastError() 820 tilveiebringer applikasjonsprogram med informasjon om den siste feilen som skjedde.

Tabell #4 illustrerer eksempelvis informasjon omhandlende MDoGetLastError() 820.

Returverdi

MDoErrorCode datatype kan være definert som en 32-bit usignert heltall som

inneholder både komponent og feilkoder. Ofte kan feilinformasjonen hentet bli satt ved plattformabstraksjons API-lag. Av denne grunn er MdoErrorCode formatet gitt her lignende til AlErrorCode format definert ved abstraksjonslag API (se Appendiks A). Fig. 10 illustrerer et eksempel på format 1000 til MDoErrorCode, i henhold til én utførelse.

Tabell #5 illustrerer eksempel på informasjon omhandlende MDoGetLastErrorQ

Eksempel på datamaskinkode #1 illustrerer et eksempelbibliotek som kaller en sekvens med et kall til MDoGetLastError() 820.

Computerkode # 1

Feilkoder

En feilkode rapportert av MDoGetLastError 820 innbefatter to deler: komponentkode og feilkode. Se Appendiks A for informasjon. Tabell #6 lister eksempler på feilkoder og korresponderende komponentkoder. MDoGetLastError 820 returnerer også feilkoder som settes på det abstrakte bibliotekslaget. Det skal bemerkes at den følgende listen kun er for illustreringsformål og ikke skal bli betraktet som en begrensning på noen som helst måte.

Skanningsundersystem API

Applikasjonsprogramgrensesnitt 800 innbefatter et flertall av skanningsundersystemkomponenter. S kanningsundersystem API-komponenter tilveiebringer data/innholdsskanning og signaturoppdateringstjeneste. Innbefattet er MDoScanOpen() 802, MDoScanClose() 804, MDoScanVersion() 806, MDoScanUpdate() 810, og MDoScanData() 808. MDoScanOpen() 802 blir brukt for å skanne undersystemobjektinstantering. MDoScanVersion() 806 tilveiebringer skanningsundersystem og signaturdatabaseversjonsinformasjon. MDoScanOpdate() 810 utfører signaturdatabaseoppdatering. MDoScanData() 808 utfører ondsinnet kode/innholdsdataskanning. Fig. 11 illustrerer et skanningsundersystem API kall sekvens 1100, i henhold til én utførelse.

MDoScanOpen

Tabell #7 illustrerer eksempelvis informasjon omhandlende MDoScanOpenQ 802.

MDoScanClose

Tabell #8 illustrerer eksempelvis informasjon omhandlende MDoScanCloseQ 804.

MDoScanVersinn

Tabell # 9 illustrerer eksempelvis informasjon omhandlende MDoScanVersionQ

Eksempelvis datamaskinkode #2 illustrerer en eksempelvis versj onsinformasj onsstruktur.

Datamaskinkode # 2

Den mobile kommunikasjonsinnretningsidentifikasjonsstrengen rapportert av MDoScanVersion() 806 blir satt ved å bruke innretningsidentifikasjonsstrengen returnert av AIDevGetlnfo. (Se Appendiks A).

MDoScanData

Tabell #10 illustrerer eksempelvis informasjon omhandlende MDoScanDataQ 808.

MDoScanUpdate

Tabell #11 illustrerer eksempelvis informasjon omhandlende MDoScanUpdateQ

Eksempelvis datamaskinkode #3 illustrerer måten som en

oppdateringsparameterstruktur er definert på.

Datamaskinkode # 3

Oppkallingsapplikasjonsprogrammet kan sette funksjonspeker og data kan formidles til funksjonen når funksjonen kalles. Bemerk tabell #12.

Konfigurasjons- APT

Applikasjonsprogramgrensesnitt 800 innbefatter et flertall av konfigurasjonskomponenter. Innbefattet i settet av funksjoner brukt for å hente og spesifisere skanningsundersysteminnstillinger. Målet med disse funksjonene er å tilveiebringe applikasjonsprogrammer og skanningsundersystem med sentralisert runtime konfigureringstilgang. Konfigureringsdata blir lagret i en non-volatile presistent datalagring (dvs. flashminne, etc).

Fig. 12 illustrerer ett eksempel på et konfigurasjons API kallsekvens 1200, i henhold til én utførelse. Som vist, returnerer MDoConfigOpen() 830 en hendel som skal overføres til konfigurasjonsinnhenting og spesifikasjonsfunksjoner.

MDoConfigClose() 814 blir brukt for å frigi og lukke konfigurasjonshendelen returnert av MDoConfigOpen() 812. MDoConfigSet() 818 setter en spesifisert konfigurasjonsvariabel med en spesifikk verdi, og MDoConfigGet() 816 returnerer en konfigurasjonsverdi for en spesifikk variabel. Konfigurasjons variable innstillinger modifisert av MDoConfSet() 818 er ikke nødvendigvis lagret til et permanent lager inntil MDoConfigClose() 814 blir kalt.

Applikasjonsprogram kan kalle konfigurasjon åpne, hent, eller sett, og straks etterfulgt av lukkefunksjon når den tilegner og/eller spesifiserer en variabel verdi.

Konfigurasjons variablene og verdiene spesifisert/hentet ved å bruke konfigurasjonskomponenter til applikasjonsprogramgrensesnitt 800 kan være representert ved null-karakter ('"\0") terminert, 8-bit karakter streng. Tabell #13 lister tilgjengelig konfigurasjonsvariable.

MDoConfieOnea

Tabell #14 illustrerer eksempelvis informasjon omhandlende MDoConfigOpen() 812.

MDoConfjgClose

Tabell #15 illustrerer eksempelvis informasjon omhandlende MDoConfigClose() 814.

MDoCopfigGet

Tabell #16 illustrerer eksempelvis informasjon omhandlende MDoConfigGetQ 816.

MDoConfjgSet

Tabell #17 illustrerer eksempelvis informasjon omhandlende MDoConfigSetQ 818.

Applikasjonsprogram/ skanningsundersystemskommunikasjon til å muliggjøre skanning

Som tidligere nevnt kan applikasjonsprogrammer kommunisere informasjon til skanningsundersystem for å muliggjøre skanning av skanningsundersystemet. Denne kommunikasjonen kan bli muliggjort via API beskrevet over. Den foregående informasjonen kan relateres til type av data som skal skannes, og timinen assosiert med en slik skanning. Mer beskrivelse omhandlende denne måten som den ovenfor beskrevne API oppnår dette på vil nå bli fremsatt.

Skanningsparametere ( SScanParam)

Oppkallsoperasjonsprogrammet kan forsyne spenning under systemet med en skanningsparameter ved å bruke SscanParam strukturen. Informasjonen inneholdt i skannparameteren tilveiebringer skanningsundersystemet med: 1) skanningsundersystemaksjonstype (dvs. iAction), 2) skanningsdatatype (dvs. type av applikasjonsdata som skal skannes (iDataType), 3) datapeker til skannmålet (dvs. pPrivate), 4) funksjon som skal hente datastørrelse i byte (dvs. pfGetSize), 5) funksjon for å gjøre om størrelsen på skanndata (dvs. pfSetSize), 6) funksjon brukt for å skanne undersystemet for å hente en blokk av skanndata (dvs. pfRead), 6) funksjon brukt til å skrive til skanndata (pfWrite), og 7) tilbakekallsfunksjon for skanningsundersystem status/programrapportering (dvs. pfCallBack).

Eksempel på datamaskinkode #4 illustrerer en dataskannparameterstruktur.

fVirrrpnt<p>r Cndet # 4

Sean Action

Sean action spesifiserer type av skanning som skal utføres på forsynte applikasjonsdata. Tabell #18 illustrere ulike eksempler på skannhandlinger.

Sean Data T ype CiDalaTvpe>

Oppkallingsapplikasjonsprogrammet kan informere skanningsundersystemet om applikasjonsdatatype og format ved å bruke denne variabelen.

Fig. 13 illustrerer ulike eksempelvise applikasjonsdatatyper 1300 som applikasjonsprogrammene er i stand til å kommunisere til skanningsundersystemet via API. url-strengformatet kan tilpasses til Uniform Resource Locators (RFC 1738) spesifikasjon. Dette e-mail strengformatet kan tilpasses med internett e-mail adresseformat (RFC 822) spesifikasjon. Default domenet kan bli satt til ethvert ønskelig domene. Videre kan telefonnummerstrengen innbefatte de nummeriske karakterene "0" til "9", og "#" og "<*>" tegn.

Skanndatapeker/ hendel ( pPrivate)

En peker (eller hendel) til et applikasjonsskannobjekt blir videre tilveiebrakt. Skanningsundersystem trenger ikke nødvendigvis å utføre direkte minne I/O ved å bruke denne datapeker/hendel. Datapeker/hendel blir sendt tilbake til oppkalleren for å utføre lese/skriving ved å bruke oppkallerspesifiserte I/O-funksjoner.

Skanndatastørrelse ( pfGetSize)

Den foreliggende funksjonen blir brukt for å skanne undersystemet for å oppnå skannmåldatastørrelse (i bytes) for å kalle applikasjonsprogrammet.

Sean Data Resize ( pfSetSize)

Denne funksjonen blir brukt for å skanne undersystemet til å forespørre oppkallsapplikasjonsprogrammet til å gjøre om størrelsen på applikasjonsdata som blir reparert/fjernet for en gitt størrelse (i bytes). Denne funksjonen kan bli brukt sammen med skann-og-reparer/slett-opsjon.

Sanndata lesefunksjon ( pfRead)

Den instantane funksjonen kan bli brukt for å skanne undersystemet for å lese en spesifikk mengde av applikasjonsdata fra det kallende applikasjonsprogrammet.

Skanndata skrivefunksjon ( pfWrite)

Dette er en tilleggsparameter som kan bli brukt av et skanneundersystem for å skrive en spesifikk mengde av applikasjonsdata for å skanne objektet som en del av en reparasjonsprosess. Denne funksjonspekeren kan settes dersom skannhandlingen blir satt til å reparere eller slette.

Tilbakekallsfunksi on ( pfCallBack)

Dersom det spesifiseres kalles skanneundersystem et den spesifiserte funksjonen med informasjonen beskrevet i tabellen under. Tilbakekallsfunksjonen, dersom den returneres med negativ verdi, avbryter skanneprosessen. Tabell #19 viser et eksempel på en tilbakekallskodeliste.

Eksempel på datamaskinkode #5 illustrerer et skanneundersystemtilbakekalls-struktur.

Datamaskinkode # 5

Skannresultat CSScanResult)

Resultatet av en objekts kanning, detektert malware informasjon, blir returnert til oppkallsapplikasjonsprogrammet i SscanResult struktur tilveiebrakt av oppkallsapplikasjonsprogrammet. SscanResult struktur inneholder en peker til en struktur som inneholder skanneresultatinformasjon og en peker til en funksjon brukt for å fjerne skanneresultatkilden. Minnet brukt for å holde skanneresultatet blir allokert av et skanneundersystem og frigjort ved å kalle opp funksjonen pekt på av pfDeleteResult peker.

Eksemplet i datamaskinkode # 6 illustrerer en eksempeloppkallingssekvens.

Datamaskinkode # 6

Eksempeldatamaskinkode #7 illustrerer en detektert ondsinnet kode/innholdsinformasjonsstruktur.

Datamaskinkode # 7

Eksempel på datamaskinkode #8 illustrerer en skannresultatstruktur.

Datamaskinkode # 8

Alvorlighetsklasse og oppførselsnivå ( uBehavior)

Fig. 14 viser en bitfeltvariabel 1400 som inneholder malware alvorlighetsflagg og applikasjonsprogramoppførselsnivåer innbefattet i SDetect struktur, i henhold til én eksempelvis utførelse.

Tabell #20 fremsetter et eksempel på malware alvorlighetsklasseliste.

Skanningsundersystemet setter MDOSCUSER flagget, dersom skanningsapplikasjonsdata inneholder malware skadelig til brukeren av den mobile kommunikasjonsinnretningen. MDOSCTERMINAL flagget settes dersom det er skadelig for den mobile kommunikasjonsinnretningen i seg selv. Både MDO_SC_USER og MD OS CTERMIN AL flaggene blir satt dersom det er skadelig for både brukeren og den mobile kommunikasjonsinnretningen.

Applikasjonsprogramoppførselsnivåer spesifiserer hva som skal gjøres med applikasjonsdata som inneholder detektert malware. Tabell #21 lister oppførselsnivåverdier og korresponderende handlinger for applikasjonsprogrammet. Når multiple ondsinnede koder blir funnet i skannede applikasjonsdata, forventes det at det kalte applikasjonsprogrammet opptrer med det høyeste oppførselsnivå. F.eks. dersom både MDOBCLEVELO og MDOBCLEVEL3 blir rapportert, kan applikasjonsprogrammet utføre MDO BC LEVEL3 handlinger.

Fig. 15 illustrerer et diagram 1500 som fremsetter måten som timing av skanningsundersystemet varieres som en funksjon av datatype identifisert ved variabelen i fig. 13.

Signatur databaseoppdatering

Som tidligere nevnt kan oppdateringsprosessen bli strømlinjeformet for å understøtte den begrensede båndbredden som er iboende i

mobilkommunikasjonsrammeverket. Mer informasjon omhandlende de ulike måtene som dette kan oppnås på vil bli fremsatt.

Oppdaterte komponenter

MdoScanUpdate funksjoner tilveiebringer to komponenter [dvs. ondsinnet kodedeteksjonslogikk (mdo.pd) og signaturdatabase (mdo.sdb)] med oppdateringstjeneste. En komponent (dvs. mdo.pd) kan inneholde detekteringslogikk og kan bli oppdatert fullstendig når en nyere versjon er tilgjengelig. En annen komponent (dvs. mdo.sdb) kan bli oppdatert inkrementelt opptil n tidligere versjoner. En full oppdatering for den andre komponenten kan bli utført på de mobile kommunikasjonsinnretningene med versjoner eldre enn n. F.eks. dersom n blir satt til 5, og den seneste versjonen er 20, så kan en full oppdatering utføres på den mobile kommunikasjonsinnretningen med en versjon eldre enn 15.

Aktivering via brukergrensesnitt

Fig. 16 illustrerer et eksempel på en flyt 1600 som beskriver måten som oppdateringen blir initiert på ved brukergrensesnitt, i henhold til én utførelse. Som vist, kan virusmønsteroppdatering bli initiert av brukeren til den mobile kommunikasjonsinnretningen ved å velge en menyinntasting via brukergrensesnitt 1602. Når en bruker velger oppdateringsmenyen, blir en oppdateringsapplikasjon 1604 aktivert og forbundet til back end server via passende

oppdateringsgrensesnittfunksjon 1606.

Kommunikasi onsprotokoll

Oppdateringsbiblioteket kan kommunisere med back end server via HTTP-protokollen.

Oppdateringsprosess

Fig. 17 illustrerer en metode 1700 for effektiv oppdatering av et skanningsundersystem til en mobil kommunikasjonsinnretning, i henhold til én utførelse. I én utførelse kan den foreliggende metoden 1700 bli implementert i sammenheng med applikasjonsprogrammer, skanne undersystem, og operativsystemer til arkitektur 300 i fig. 3 og systemene til fig. 1 og 2. Det skal imidlertid bemerkes at den foreliggende metoden 1700 kan bli implementert i enhver ønsket sammenheng.

For å initiere prosessen, kan en forespørsel for en oppdatering bli sendt fra i det minste én mobil kommunikasjonsinnretning til en back end server. Selvfølgelig kan i én utførelse oppdateringen bli sendt uten en forespørsel.

I én utførelse kan oppdateringen bli forespurt av den mobile

kommunikasjonsinnretningen som utnytter en forespørselsdatastruktur. I tillegg kan en slik datastruktur innbefatte variable slik som en uniform ressurslokator (URL) variabel, mobil kommunikasjonsidentifikatorvariabel, en applikasjonsprogram-grensesnittsversjonvariabel, en deteksjonsvariabel, en signaturversjonsvariabel, og/eller en delnummervariabel.

Tabell #22 illustrerer en eksempelvis URL som kan bli brukt for et slikt formål.

Tabell #23 illustrerer et spesifikt eksempel på en URL som er i overensstemmelse med beskrivelsen ovenfor.

Den ovenfor beskrevne URL i tabell #23 spesifiserer base-URL "http://update.mcafeeacsa.com/504i", "X504i05" som innretningsidentifikator, API versjon 2, ondsinnet kodedetekteringslogikkversjon 3, og signaturdatabase versjon 56. Det skal bemerkes at "chunk" eller del, tall kan bli satt til 1 når den mobile kommunikasjonsinnretningen initielt kontakter back end serveren. Base-URL kan også bli oppnådd ved å bruke MDoConfigGet API ved å bruke "UpdateURL" konfigurasj onsvariabel.

Etter å ha mottatt en forespørsel bestemmer back end serveren hvilken oppdateringspakke som er nødvendig til å bli lastet ned ved å sammenligne lagrede ondsinnede kodedetekteringslogikk og signaturdatabaseversjoner med versjonsinformasjonen dekodet i URL.

Dersom ingen oppdatering er nødvendig, returnerer back end en ikke-innholdsrespons. Under operasjon 1701, mottar den mobile

kommunikasjonsinnretningen responsen som en første del. Dersom det ble bestemt at den første delen innbefatter en foregående ikke-innholdsrespons (se bestemmelse 1702), blir metoden 1700 terminert, siden det ikke er noen oppdatering å laste ned. Slike trekk er fordelaktige i understøttelse av begrenset båndbredde iboende i mobilkommunikasj onsnettverk.

På den annen side, dersom en første del av en oppdateringspakke blir returnert, blir metoden 1700 fortsatt ved å motta tilleggsdeler av oppdatering etterfulgt til (eller muligens i parallell med) kvittering på den første delen av oppdateringen. Bemerk operasjonene 1704-1708. Det skal bemerkes at den første del kan bli oppnådd med en total pakkestørrelse og delingsinformasjon.

For å laste ned gjenværende oppdateringsdeler, kan delnummeret til nedlastings URL bli modifisert. Tabell #24 illustrerer et spesifikt eksempel til en URL som spesifiserer delnummer "3".

Tabell # 24

http: // iipdate. mcaf eeacsa. com/ 504i?dev=X504i05tai^ o=2&eiiq=3&8ab=56&cbk=3

I én utførelse, kan integriteten til oppdateringen bli bestemt. Følgelig kan oppdateringen bli betingelsesinstallert med skanningsundersystem, basert på om integriteten til oppdateringen er verifisert.

Som en opsjon kan integriteten til oppdateringen bli bestemt ved å utnytte en signatur. En slik signatur kan bli mottatt med én av delene (dvs. en siste del) til oppdateringen. Deretter kan signaturen bli sammenlignet mot andre signaturer generert ved å utnytte hver av delene av oppdateringen. Bemerk operasjon 1710.

I én utførelse kan signaturen bli generert ved å bruke RSA private key og autentisert på den mobile kommunikasjonsinnretningen ved å bruke korresponderende public key innbefattet i oppdateringen. Signaturverifiseringen og genereringen kan videre bli utført ved å bruke spesifisert autentiseringsbibliotek.

Ved å anta at integriteten blir verifisert, blir enhver skanning som utføres av skanningsundersystemet satt på pause, eller stoppet. Bemerk operasjon 1712. Det skal også bemerkes at en slik pause kan være en tilleggsmulighet.

Deretter kan en oppdatering bli installert med skanneundersystemet. Bemerk operasjon 1714. I én utførelse hvor en skanning blir satt i pause, kan skanningen etterfølges av gjenopptatt utnyttelse av skanningsundersystem under oppdateringen som blir installert med skanningsundersystemet. Se operasjon 1716.

For å understøtte den begrensede båndbredden iboende i mobile kommunikasjonsrammeverk, kan størrelsen til delene av oppdateringen bli minimalisert. Videre kan delene av oppdateringen bli komprimert.

I enda en annen utførelse, kan formatet til hver av delene til oppdateringen bli designet til å understøtte den begrensede båndbredden iboende i mobile kommunikasjonsrammeverk. Mer informasjon vil nå bli fremsatt med hensyn til et slikt format.

Tabell #25 illustrerer et eksempelformat for nedlasting av deler av oppdateringen.

Hver av de foregående delene fremsatt i tabell 25 er definert som følgende i tabell #26.

Hver del utgjøres av en header og data. Slik header kan indikere en identifikator assosiert til oppdateringen, en lengde av assosiert del av oppdateringen, etc. Videre kan headeren spesifisere det inneholdte datanavnet og lengden, og bli separert fra de faktiske dataene med en ekstra CR+LF par. Tabell #27 fremsetter eksempel på data/innholdsnavn assosiert med headeren.

Tabell #28 illustrerer et eksempel på en oppdateringspakke.

Sammendragsbibliotek API

Som tidligere nevnt er plattformuavhengig system og assosiert metode tilveiebrakt for bruk med en mobil kommunikasjonsinnretning. Innbefattet i plattformuavhengig skanningsundersystem i kommunikasjon med operativsystemet til en mobil kommunikasjonsinnretning for skanningsformål. Videre er det tilveiebrakt et plattformuavhengig applikasjonsprogramgrensesnitt for å ha et grensesnitt til operativsystemet og skanningsundersystemet. Plattformuavhengig applikasjonsprogramgrensesnitt innbefatter et sammendragsbibliotek for å portere plattformuavhengig skanningsundersystem til mobile kommunikasjonsinnretninger og assosiert operativt system.

Ved dette designet kan skanningsundersystem være plattformuavhengig, og dermed være i stand til å bli implementert på enhver type av operativsystem/mobile kommunikasjonsinnretningskombinasjoner.

I én utførelse kan sammendragsbiblioteket understøtte systeminitialisering, bibliotekinitialisering, feilfunksjoner, minneallokeringer, input/output (I/O), dataautentisering, synkronisering, hypertekst overføringsprotokoll, delt minne, systemtid, innretningsinformasjon, og debugging. Mer eksempelvis informasjon relaterende til tilleggsimplementering av foregående

applikasjonsprogramgrensesnitt er fremsatt i Appendiks A.

Ulike utførelser har blitt beskrevet over og det skal forstås at de har blitt presentert på denne måten kun som et eksempel og ikke som en begrensning. Dermed skal bredden og omfanget til en foretrukket utførelse ikke være begrenset til noen av de ovenfor beskrevne eksempelvise utførelsene, men skal være definert kun i henhold til følgende krav og deres ekvivalenter.

APPENDIKS A

Det foreliggende applikasjonsprogramgrensesnittet (API) innbefatter følgende undersystemer:

• systeminitialisering

• biblioteksinitialisering

• feilfunksjoner

• heap minneallokering

• persistent minne/lagrings I/O

• dataautentisering

• synkroniseringsobjekt (semaphore)

• HTTP API

• delt minne

• systemtid

• innretningsinformasjon

• debugging

Også beskrevet i dette Appendikset er et sett av C-språkdefinisjon(er) definert i abstraksjonsbibliotek (AL) laget for bruk i API-biblioteket.

Systeminitialisering

Plattform/systemavhengig oppstartsinitialisering blir utført av AlLibrarySysInit() funksjon. Denne funksjonen er designet for å bli oppkalt fra MDoSystemInit() funksjonen beskrevet tidligere.

AlLibrary Syslnit

Beskrivelse

Utfører systemavhengig initialisering.

Prototype

int AlLibrarySysInit(void);

Parametere

ingen

Returverdi

0 dersom vellykket, -1 dersom ikke.

Biblioteksinitialisering

Plattformabstraksjons API-bibliotek blir initiert ved å bruke AlInitLibrary() funksjon. Abstraksjonsbiblioteket skal bli initialisert én gang før en abstraksjon API funksjon blir kalt. Systemressursene tilegnet og initiert av AlInitLibrary() blir frigitt når AlCleanupLibraryQ funksjonen blir kalt.

AlInitLibrarv

Beskrivelse

Utfører biblioteksinitialisering. Denne funksjonen skal kalles av MDoLibraryOpen() funksjonen.

Prototype

int AlInitLibrary(void);

Parametere

ingen

Returverdi

0 om vellykket, -1 ellers.

AlCleanupLibrary

Beskrivelse

Frigir systemressurser tilegnet av AlInitLibrary() funksjonen. Denne funksjonen skal kalles av MDoLibraryClose() funksjonen spesifisert tidligere.

Prototype

void AlCleanupLibrary(void);

Parametere

ingen

Returverdi

ingen

Feilfunksjoner

Innbefattet i AL-biblioteket er et sett av feilfunksjoner brukt til å sette og hente oppgaver/trådspesifikke feilkoder. Det er ansvaret til abstraksjonslagimplementerer å sette passende feilkode og komponentkoder.

AlGetLastError

Beskrivelse

Returnerer oppkallingsoppgaven/trådenes siste feilkodeverdi. Funksjonene setter returnert verdi ved å bruke AlSetLastError() funksjonen.

AlErrorCode datatypen er initielt representert ved å bruke 32-bits usignert verdi.

Prototype

AlErrorCode AlGetLastError(void);

Parametere

ingen

Returverdi

Oppkallingstrådene skal strekke oppgavenes siste feilverdi sett ved å bruke AlSetLastErrorQ funksjonen.

AlSetLastError

Beskrivelse

Sett siste feilkode for kalletrådene/oppgavene.

Prototype

forlater AlSetLastError (AlErrorCode errorCode);

Parametere

errorCode

[inn] 32-bits feilkodeverdi.

Returverdi

ingen

Feil/ statuskoder

Den ovenfor viste tabellen lister et sett av AL-komponent og feilkoder. En feil rapportert ved å bruke AlSetLastError funksjon er en 32-bits verdi formet av kombinasjon av komponentkode med feilkode. Feilsettet med AL-nivå blir mottatt ved å bruke MdoGetLastError funksjon til å utføre passende handling når en feil opptrer.

Heap- minneallokering

Abstraksjonslaget tilveiebringer en heap-minneallokering API for et oppkallingsapplikasjonsprogram (dvs. en "oppkaller") til dynamisk å allokere minnet nødvendig. Det allokerte minnet er antatt å være globalt delbart som kan aksesseres av multiple applikasjoner/oppgaver. AlMemAlloc () og AlMemFree() API-funksjoner tilveiebringer allokering og de-allokering av heap-minnet.

AlMemAlloc

Beskrivelse

Alloker en spesifikk mengde av dynamisk minne og returner en peker til minnet. Det allokerte minneblokken er direkte aksesserbar av oppkalleren (dvs. kallende applikasjonsprogram) uten å kreve spesielle operasjoner (dvs. minnelåsing).

Prototype

void<*>AlMemAlloc(unsigned int uSize);

Parametere

uSize

[inn] mengde av minne som skal allokeres i bytes.

Returverdi

En peker til allokert minne. NULL dersom forespørselen feiler eller forespørselsstørrelsen er null.

Se også

AlMemFree()

AlMemFree

Beskrivelse

Frigjør dynamisk minneblokk returnert av AlMemAlloc() funksjonen.

Prototype

void AlMemFree(void<*>pData);

Parametere

pData

[inn] peker til minneblokken som skal frigjøres.

Returverdi

ingen

Se også

AlMemAllocO

Persistent lagring I/ O

Persistent lagring (dvs. flashminne) tilgang blir utført ved å bruke fil I/O API. Se under:

Filhendelen type ALFILEHANDLE er definert som

Og en konstant brukt til å spesifisere en ugyldig persistent lagringshendel INVALIDALFILEHANDLE er definert som

#define INVALID_AL_FILE_HANDLE ((AL_FILE_HANDLE)0)

Filstatusbuffertype AlStatBuf er definert som

AlFileO<p>en

Beskrivelse

Åpner spesifisert fil og returnerer dens hendel.

Prototype

AL FILE HANDLE AlFileOpen(const char<*>pszFilename, int iMODE);

Parametere

pszFilename

[inn] filnavn/stistreng.

iMode

[inn] filaksessmode.

AL_OPEN_READ Open file for reading

AL_OPEN_WRITE Open file for both reading and writing Returverdi

Filhendel dersom vellykket, INVALID AL FILE HANDLE ellers.

Se også

AlFileClose(), AlFileRead(), AlFileWrite()

AlFileClose

Beskrivelse

Lukker og frigjør systemressurser assosiert med spesifikk filhendel.

Prototype

void AlFileClose(AL_FILE_HANDLE hFile);

Parameter

hFile

[inn] filhendel returnert av AlFileOpen().

Returverdi

ingen

Se også

AlFileOpen(), AlFileRead(), AlFileWrite()

AlFileSeek

Beskrivelse

Reposisjonerer les/skriv filoffset.

Parameter

hFile

[inn] en åpen fil handel.

1 Offset

[inn] filoffset relativ til iWhence direktiv.

iWhence

[inn] initiell posisjon. Mulige verdier er:

ALSEEKSET Offsetparameterne spesifiserer den absolutte filoffset. Med andre ord, offset fra

begynnelsen av filen.

ALSEEKCUR Spesifiserer relativ offset - offsetparameterne spesifiserer filoffset fra foreliggende

filoffset.

AL SEEK END Spesifiserer filoffset fra slutten av filen.

Returverdi

Resulterende filoffset dersom vellykket, -IL ellers.

Se også

AlFileOpen(), AlFileClose(), AlFileRead(), AlFileWrite()

AlFileRead

Beskrivelse

Leser en blokk av data fra en fil.

Prototype

Parameter

hFile

[inn] En åpen filhendel.

pBuffer

[ut] Databuffer.

uSize

[ut] Mengde av data som skal leses.

Returverdi

Antall bytes lest dersom vellykket, -1 ellers.

Se også

AlFileOpen(), AlFileClose(), AlFileSeek(), AlFileWrite()

AlFile Write

Beskrivelse

Skriver en blokk av data til filen.

Prototype

Parameter

hFile

[inn] En åpen filhendel

pBuffer

[inn] Buffer som holder data som skal skrives.

uSize

[ut] Mengden av data som skal skrives.

Returverdi

Mengde av data skrevet dersom vellykket, -1 ellers.

Se også

AlFileOpen(), AlFileClose(), AlFileSeek(), AlFIleRead()

AlFileSetSize

Beskrivelse

Gjør om størrelsen på åpen fil.

For plattformer uten innebygd filstørrelseomgjøringsstøtte, implementerer abstraksjonsbiblioteket denne funksjonaliteten ved å modifisere størrelsesinformasjonen lagret i begynnelsen av hver fil når AlFileClose() funksjonen blir kallet.

Prototype

unsigned int AlFileSetSize (AL FILE HANDLE hFile,

unsigned int uSize);

Parameter

hFile

[inn] Hendel som henviser til en åpen fil med skrivemode.

uSize

[ut] Ny fillengde i bytes.

Returverdi

0 dersom vellykket, -1 ellers.

Se også

AlFileStatO

AlFileStat

Beskrivelse

Hent filstørrelse og tidsstempel for når den ble laget.

For plattformer som ikke tilveiebringer innebygd filstørrelse og/eller tidsstempelinformasjonhentingsmetode, implementerer absorpsjonsbiblioteket denne funksjonen ved å lagre informasjonen ved begynnelsen av hver fil.

Prototype

int AlFileStat(char const<*>pszFilename,

AlStatBuf<*>pStat);

Parameter

pszFilename

[inn] Navn til filen som skal hente informasjon.

pStat

[ut] Peker til en struktur brukt for å returnere størrelsen og tidsstempelinformasjon. Strukturen inneholder følgende felt:

Returverdi

0 om vellykket, -1 ellers.

Dataautentisering

Innbefattet i plattformabstraksjons-API er et sett med funksjoner for autentisering av data. Dataautentiserings-API blir brukt for å validere nedlastet malware-signatur database.

Når en oppkaller oppnår en autentiseringsobjekthendel ved å bruke AlDaOpen-funksjon, blir et kall til AlDaVerify gjort for å verifisere data gitt.

AlDaGetSignerInfo() blir brukt for å hente en signeringsinformasjon. AlDaClose() blir brukt for å lukke og frigjøre dataautentiseringshendel og relaterte systemressurser.

Under er et eksempel på dataautentiserings-API.

Dataautentiseringshendelen returnert av AlDaOpenQ funksjonen er definert som

ALHANDLE(AL_DA_HANDLE);

#define INVALID_AL_DA_HANDLE ((AL_DA_HANDLE)0)

Signeringsinformasjonsstrukturen er definert som

AlDaOpen

Beskrivelse

Skaper og returnerer en dataautentiseringshendel.

Prototype

ALDAHANDLE AlDaOpen(const void<*>pSig,

unsigned int uSitSize);

Parametere

pSig

[inn] Peker til signaturdata.

uSigSize

[inn] Signaturstørrelse i bytes.

Returverdi

Dataautentiseringshendel dersom vellykket, INVALID AL DA HANDLE ellers.

Se også

AlDaClose(), AlDaUpdate(), AlDaVerify(), AlDaGetSignerInfo()

AlDaClose

Beskrivelse

Relaterer systemressurser brukt av dataautentiseringshendel.

Prototype

void AlDaClose(AL_DA_HANDLE hDa);

Parametere

hDa

[inn] Dataautentiseringshendel returnert av AlDaOpen.

Regurverdi

ingen

Se også

AlDaOpen(), AlDaUpdate(), AlDaVerify(),

AlDaGetSignerlnfoQ

AlDaVerifv

Beskrivelse

Utfører dataautentisering.

Prototype

Parametere

hDa

[inn] Dataautentiseringshendel.

pfRead

[inn] Oppkallers tilbakekallsfunksjon for bruk for å lese data (se). Den returnerer -1 i tilfelle en feil, 0 dersom det ikke er mer data å lese, og ellers mengden av data som leses og returneres til AlDaVerify funksjonen. Det er forventet at funksjonen blir kalt multiple ganger.

iTotalSize

[inn] Total datastørrelse som skal verifiseres.

pPrivate

[inn] Innkallers private data som skal overføres av pfRed tilbakekall.

Returverdi

0 dersom applikasjonsdata blir autentisert, -1 ellers.

Se også

AlDaOpen(), AlDaClose(), AlDaGetSignerInfor()

Under ses eksempeldata på lesetilbakekallingsfunksjon.

AlDaGetSignerlnfo

Beskrivelse

Returnerer dataautentiseringssigneringsinformasjon.

Prototype

int AlDaGetSignerInfo(AL_DA_HANDLE hDA,

DaSignerInfo<*>pDSI);

Parametere

hDa

[inn] Dataautentiseringshendel.

pDSI

[ut]Peker til en struktur som inneholder signeringsinformasjon.

Returverdi

0 dersom signeringsinformasjonen tilegnet er vellykket, -1 ellers.

Se også

AlDaOpen(), AlDaClose(), AlDaVerify()

Synkroniseringsobiekt

Ressurssynkronisering og kontroll blir utført ved å bruke en semafor. Innbefattet i abstraksjonsbiblioteket er et sett av funksjoner for å lage, åpne, lukke og modifisere et semaforobjekt. Under er et eksempel på semafor API.

AlSemCreate

Beskrivelse

Lager en navnsemafor, setter intern teller til null, og returnerer dens hendel.

Prototype

ALSEMHANDLE AlSemCreate(char const<*>pszName);

Parametere

pszName

[inn] Semafor navnstreng.

Returverdi

Semafor hendel dersom vellykket, INVALID_AL_SEM_HANDLE ellers.

Se også

AlSemOpenO, AlSemClose(), AlSemGet(), AlSemRelease()

AlSemOpen

Beskrivelse

Returnerer en hendel til eksisterende semafor.

Prototype

AL_SEM_HANDLE AlSemOpen(char const<*>pszName);

Parametere

pszName

[inn] Semafornavn.

Returverdi

Semaforhendel dersom vellykket, IN VAL ID_AL_SEM_HANDLE ellers.

Se også

AlSemCreateO, AlSemClose(), AlSemGet(), AlSemRelease()

AlSemClose

Beskrivelse

Lukker og frigjør systemressurser assosiert med spesifisert semaforhendel. Semafor bruk/referanseteller blir også dekrementert, og det refererte semaforobj ektet blir ødelagt dersom telleren når null.

Prototype

void AlSemClose(AL_SEM_HANDLE hSem);

Parametere

hSem

[inn] Semaforhendel tilegnet ved å bruke AlSemCreate() eller AlSemOpen().

Returverdi

ingen

Se også

AlSemCreateO, AlSemOpen(), AlSemGet(), AlSemRelease()

AlSemGet

Beskrivelse

Tilegnes spesifisert semafor. Dersom intern teller er større enn null ved inngang, blir den dekrementert med én og straks returnert. Dersom intern teller er null ved inngang, blir kallet blokkert inntil andre oppgaver/trådkall AlSemRelease() for å gjøre den større enn null.

Prototype

int AlSemGet(AL_SEM_HANDLE hSem);

Parametere

hSem

[inn] Semaforhendel.

Returverdi

0 dersom vellykket, -1 ellers.

Se også

AlSemCreate(), AlSemOpen(), AlSemClose(), AlSemRelease()

AlSemRelease

Beskrivelse

Frigjør semaforen, inkrementerer intern teller med én.

Prototype

int AlSemRelease(AL_SEM_HANDLE hSem);

Parametere

hSem

[inn] Semaforhendel.

Returverdi

0 dersom vellykket, -1 ellers.

Se også

AlSemCreateO, AlSemOpen(), AlSemClose(), AlSemGet()

HTTP API

Innbefattet i abstraksjonsbiblioteket et sett med funksjoner som tilveiebringer HTTP-nettverk I/O ved å bruke en opphaller tilveiebragt tilbakekallingsstruktur. Under er et eksempel på HTTP API.

HTTP-hendelen returnert av AlHttpOpen() funksjonen er definert som HTTP-tilbakekallsstrukturen AlHttpCallbacks er definert som

Tilbakekallingsfunksj onene gitt i den ovenfor HTTP-tilbakekallingsstrukturen tilveiebringer følgende funksjonaliteter: pWrite Tilbakekalt av system HTTP-bibliotek for å lagre innkommende HTTP- forespørringsdata.

pRead Brukes for å hente applikasjonsdata som skal sendes som en del av en

HTTP-forespørsel.

pGetSize Tilveiebringer HTTP-bibliotek med applikasjonsinnholdsdatastørrelse,

" innhol dslengde".

pSetSize Oppkalt av HTTP-bibliotek for å informere oppkallingsapplikasjonen

om innkommende innholdsdatalengde når tilgjengelig.

AlHttpQpen

Beskrivelse

Lagrer og returnerer en hendel til HTTP-biblioteket.

Prototype

ALHTTPHANDLE AlHttpOpen(void);

Parametere

ingen

Returverdi

INVALIDALHTTPHANDLE blir returnert dersom det feilet å lage en HTTP-hendelse.

Se også

AlHttpClose()

AlHttpClose

Beskrivelse

Lukker og frigjør systemressurser assosiert med en HTTP-hendel.

Prototype

void AlHttpClose(AL_HTTP_HANDLE hHTTP);

Parametere

hHTTP

[inn] HTTP-bibliotekshendel returnert av AlHttpOpen() funksjon.

Returverdi

ingen

Se også

AlHttpCloseO

AlHttpExec

Beskrivelse

Eksekvere en HTTP-metode ("GET" eller "POST") på en spesifisert URL med tilleggsheaderinformasj on.

Prototype

Parametere

hHTTP

[inn] HTTP-bibliotekshendel returnert av AlHttpOpen() funksjon.

pszMetode

[inn] HTTP-metodespesifikasjon. HTTP "GET" eller "POST".

pszURL

[inn] URL'en hvor HTTP-forespørselen utføres.

pHttpCb

[inn] Peker til et sett av oppkallerspesifiserte HTTP I/O-funksjoner. HTTP-biblioteket bruker funksjonene spesifisert i AlHttpCallbacks struktur for data I/O.

pPrivate

[inn/ut] Peker til en oppkallerdata som skal formidles tilbake til tilbakekallingsfunksjoner spesifisert i AlHttpCallbacks struktur.

Returverdi

0 dersom vellykket, -1 ellers.

Se også

AlHttpOpenO, AlHttpClose()

Delt minne

Lokasjonen til systemminnet hvor bibliotekets delte objekter er lagret blir oppnådd ved å bruke AlShmAddress() funksjonen. Dette delte informasjonsområdet er allokert/forberedt ved innretningsoppstartstiden og henvist ved ulike hendelser i biblioteket.

AlShmAddress

Beskrivelse

Returnere delt minneadresse.

Prototype

void<*>AlShmAddress(void);

Parametere

ingen

Returverdi

delt minneadresse dersom vellykket, NULL ellers.

Tid

AlTmGetCurrent() tilveiebringer oppkaller med foreliggende systemtid i sekunder.

AlTmGetCurrent

Beskrivelse

Oppnår foreliggende systemtid.

Prototype

usignert lang AlTmGetCurrent(void);

Parametere

ingen

Returverdi

Ved suksess blir tid i sekunder siden Epoch (00:00:00 i UTC, 1. januar, 1970). Ved feil, ((unsigned long) -IL) blir returnert.

Innretningsinformasjon

AlDevGetlnfo

Beskrivelse

Henter innretningsspesifikk informasjon. Innretningsinformasjonsstreng returnert av denne funksjonen blir brukt av API.

Prototype

int AlDevGetInfo(AlDeviceInfo<*->pDeviceInfo);

Parametere

pDevicelnfo

[ut] Peker til innretningsinformasjon.

AlDevicelnfo-strukturen er definert som

Identifikasjonsstreng, szDevicelD er en unik terminal/innretningsidentifikator - brukt til å unikt identifisere en spesifikk mobil kommunikasjonsretning fra alle andre. Denne informasjonen blir brukt ved konstruksjon av malware-signatur nedlastet URL for den mobile kommunikasjonsinnretningen. Den må ikke inneholde noen tegn som ikke er tillatt i URL (f. eks. mellomrom).

Returverdi

0 ved suksess, -1 ved feiling.

Debugging

AlDbeOutput

Beskrivelse

Mater ut debug streng til et debuggingskonsoll. Denne funksjonen er en nullfunksjon for frigjøringsbygging.

Prototype

int AlDbgOutput(char const<*>pszOutput);

Parametere

pszOutput

[inn] Streng som skal mates ut til debuggingskonsollet.

Returverdi

0 ved suksess, -1 ved feiling

Claims (24)

1. Metode for effektiv oppdatering av et skanningsundersystem (105) til en mobil kommunikasjonsinnretning (102), omfattende: å motta en første del av en oppdatering tilpasset for å oppdatere et skanningsundersystem (105) til en mobil kommunikasjonsinnretning (102) som er i stand til å skanne etter uønsket innhold; å motta tilleggsdeler av oppdateringen i tillegg til kvitteringen til den første delen av oppdateringen; og å installere oppdateringen med skanningsundersystemet (105); hvor den første delen og tilleggsdelene blir individuelt forespurt og sammen danner en enkelt pakke; hvor den første delen blir fulgt av deltellingsinformasjon som indikerer det totale antall deler som skal mottas.

2. Metode i henhold til krav 1, og som videre omfatter å bestemme en integritet til oppdateringen.

3. Metode i henhold til krav 2, hvor oppdateringen blir installert med skanningsundersystemet (105) dersom integriteten til oppdateringen blir verifisert.

4. Metode i henhold til krav 2, hvor integriteten til oppdateringen blir bestemt ved å utnytte en signatur.

5. Metode i henhold til krav 4, hvor signaturen blir mottatt med én av delene til oppdateringen.

6. Metode i henhold til krav 4, hvor signaturen blir sammenlignet med en annen generert signatur ved å utnytte hver av delene til oppdateringen.

7. Metode i henhold til krav 4, hvor signaturen blir mottatt kun med en siste av tilleggsdelene til oppdateringen.

8. Metode i henhold til krav 1, hvor størrelsen på delene til oppdateringen blir minimalisert.

9. Metode i henhold til krav 1, hvor delene til oppdateringen blir komprimert.

10. Metode i henhold til krav 1, og som videre omfatter å bestemme om den første delen er tom.

11. Metode i henhold til krav 10, hvor tilleggsdelene til oppdateringen blir betinget mottatt basert på om det blir bestemt at den første delen er tom.

12. Metode i henhold til krav 1, og som videre omfattende å sette skanningen på pause ved å utnytte skanningsundersystemet (105).

13. Metode i henhold til krav 12, og som videre omfatter å gjenoppta skanningen ved å utnytte skanningsundersystemet (105) ved at oppdateringen blir installert med skanningsundersystemet (105).

14. Metode i henhold til krav 1, hvor oppdateringen blir forespurt av den mobile kommunikasjonsinnretningen (102).

15. Metode i henhold til krav 14, hvor oppdateringen blir forespurt av den mobile kommunikasjonsinnretningen (102) ved å utnytte en forespørselsdatastruktur.

16. Metode i henhold til krav 15, hvor forespørselsdatastrukturen innbefatter variabler valgt fra en gruppe bestående av en uniform ressurslokalisator (URL) variabel, en mobil kommunikasjonsidentifikatorvariabel, en applikasjonsprogramgrensesnittversjonsvariabel, en deteksjonslogisk variabel, en signaturversjonsvariabel, og en delnummervariabel.

17. Metode i henhold til krav 15, hvor forespørselsdatastrukturen innbefatter en uniform ressurslokalisator (URL) variabel, en mobil kommunikasj onsidentifikatorvariabel, en applikasjonsprogramgrensesnittsversjonsvariabel, en deteksjonslogisk variabel, en signaturversjonvariabel, og en delnummervariabel.

18. Metode i henhold til krav 1, hvor hver del av oppdateringen innbefatter et hode.

19. Metode i henhold til krav 18, hvor hodet indikerer en identifikator til den assosierte delen av oppdateringen.

20. Metode i henhold til krav 18, hvor hodet indikerer en lengde til den assosierte delen av oppdateringen.

21. Metode i henhold til krav 1, hvor den mobile kommunikasjonsinnretningen (102) innbefatter en mobiltelefon.

22. Datamaskinprogramprodukt for effektiv oppdatering av et skanningsundersystem (105) til en mobil kommunikasjonsinnretning (102) omfattende: datamaskinkode for å motta en første del av en oppdatering tilpasset for å oppdatere et skanningsundersystem (105) til en mobil kommunikasjonsinnretning (102) som er i stand til å skanne etter uønsket innhold; datamaskinkode for å motta tilleggsdeler av oppdateringen i tillegg til mottak av den første delen av oppdateringen; og datamaskinkode for å installere oppdateringen med skanningsundersystemet (105); hvor den første delen og tilleggsdelene blir individuelt forespurt og sammen danner en enkelt pakke; hvor den første delen blir fulgt av en total pakkestørrelse.

23. System for effektiv oppdatering av et skanningsundersystem (105) til en mobil kommunikasjonsinnretning (102) omfattende: en backend server (104); og en mobil kommunikasjonsinnretning (102) i trådløs kommunikasjon med backend serveren (104) for å motta fra denne en første del av en oppdatering tilpasset for å oppdatere et skanningsundersystem (105) til den mobile kommunikasjonsinnretningen (102) som er i stand til å skanne etter uønsket innhold, å motta tilleggsdeler til oppdateringen i tillegg til mottak av den første delen av oppdateringen, og å installere oppdateringen med skanningsundersystemet (105); hvor den første delen og tilleggsdelene blir individuelt forespurt og sammen danner en enkelt pakke; hvor den første delen blir fulgt av deltellingsinformasjon.

24. Metode for effektiv oppdatering av et skanningsundersystem (105) til en mobil kommunikasjonsinnretning (102) som utnytter en backend server (104), omfattende: å sende en første del av oppdateringen tilpasset for å oppdatere et skanningsundersystem (105) til en mobil kommunikasjonsinnretning (102) som er i stand til å skanne etter uønsket innhold; og å sende tilleggsdeler av oppdateringen i tillegg til den første delen av oppdateringen; og hvor oppdateringen blir installert med skanningsundersystemet (105) til den mobile kommunikasjonsinnretningen (102); hvor den første delen og tilleggsdelene blir individuelt forespurt og sammen danner en enkelt pakke; hvor den første delen blir fulgt av en total pakkestørrelse.