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

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

Info

Publication number
NO336580B1
NO336580B1 NO20055430A NO20055430A NO336580B1 NO 336580 B1 NO336580 B1 NO 336580B1 NO 20055430 A NO20055430 A NO 20055430A NO 20055430 A NO20055430 A NO 20055430A NO 336580 B1 NO336580 B1 NO 336580B1
Authority
NO
Norway
Prior art keywords
update
mobile communication
communication device
scanning subsystem
scanning
Prior art date
Application number
NO20055430A
Other languages
English (en)
Other versions
NO20055430D0 (no
NO20055430L (no
Inventor
Victor Kouznetsov
Michael C Pak
Yasutaka Urakawa
Kenji Ishii
Davide Libenzi
Masanori Fujita
Original Assignee
Ntt Docomo Inc
Mcafee Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ntt Docomo Inc, Mcafee Inc filed Critical Ntt Docomo Inc
Publication of NO20055430D0 publication Critical patent/NO20055430D0/no
Publication of NO20055430L publication Critical patent/NO20055430L/no
Publication of NO336580B1 publication Critical patent/NO336580B1/no

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/128—Anti-malware arrangements, e.g. protection against SMS fraud or mobile malware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Stored Programmes (AREA)
  • Telephone Function (AREA)

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.
NO20055430A 2003-04-17 2005-11-16 Oppdateringssystem og metode for å oppdatere et skanningsundersystem i et mobilt kommunikasjonsrammeverk NO336580B1 (no)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US46388503P 2003-04-17 2003-04-17
US10/639,007 US7254811B2 (en) 2003-04-17 2003-08-11 Update system and method for updating a scanning subsystem in a mobile communication framework
PCT/US2004/010585 WO2004095167A2 (en) 2003-04-17 2004-04-05 Update system and method for updating a scanning subsystem in a mobile communication framework

Publications (3)

Publication Number Publication Date
NO20055430D0 NO20055430D0 (no) 2005-11-16
NO20055430L NO20055430L (no) 2006-01-10
NO336580B1 true NO336580B1 (no) 2015-09-28

Family

ID=33162397

Family Applications (1)

Application Number Title Priority Date Filing Date
NO20055430A NO336580B1 (no) 2003-04-17 2005-11-16 Oppdateringssystem og metode for å oppdatere et skanningsundersystem i et mobilt kommunikasjonsrammeverk

Country Status (7)

Country Link
US (1) US7254811B2 (no)
EP (1) EP1629360B1 (no)
JP (1) JP4448849B2 (no)
KR (1) KR101071597B1 (no)
CA (1) CA2517548C (no)
NO (1) NO336580B1 (no)
WO (1) WO2004095167A2 (no)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6970697B2 (en) 2003-04-17 2005-11-29 Ntt Docomo, Inc. Platform-independent scanning subsystem API for use in a mobile communication framework
US7392043B2 (en) * 2003-04-17 2008-06-24 Ntt Docomo, Inc. API system, method and computer program product for accessing content/security analysis functionality in a mobile communication framework
US9118708B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Multi-path remediation
US9350752B2 (en) 2003-07-01 2016-05-24 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9100431B2 (en) 2003-07-01 2015-08-04 Securityprofiling, Llc Computer program product and apparatus for multi-path remediation
US20070113272A2 (en) 2003-07-01 2007-05-17 Securityprofiling, Inc. Real-time vulnerability monitoring
US9118709B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US8984644B2 (en) 2003-07-01 2015-03-17 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9118710B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc System, method, and computer program product for reporting an occurrence in different manners
US9118711B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
WO2005024628A2 (en) * 2003-09-03 2005-03-17 Bitfone Corporation Tri-phase boot process in electronic devices
US20060031408A1 (en) * 2004-05-06 2006-02-09 Motorola, Inc. Push to activate and connect client/server applications
JP2005338959A (ja) * 2004-05-24 2005-12-08 Sony Corp 情報処理装置，実行判定方法，およびコンピュータプログラム
KR100644621B1 (ko) * 2004-08-06 2006-11-10 삼성전자주식회사 네트워크 디바이스의 소프트웨어 업데이트 방법
JP2006065857A (ja) * 2004-08-24 2006-03-09 Lg Electronics Inc 移動通信端末機のプログラム強制ダウンロード方法及び装置
WO2006094117A2 (en) 2005-03-01 2006-09-08 Mfoundry Application program update deployment to a mobile device
US8272058B2 (en) 2005-07-29 2012-09-18 Bit 9, Inc. Centralized timed analysis in a network security system
US8984636B2 (en) 2005-07-29 2015-03-17 Bit9, Inc. Content extractor and analysis system
US7895651B2 (en) 2005-07-29 2011-02-22 Bit 9, Inc. Content tracking in a network security system
US7634262B1 (en) * 2006-03-07 2009-12-15 Trend Micro, Inc. Virus pattern update for mobile device
US8811968B2 (en) * 2007-11-21 2014-08-19 Mfoundry, Inc. Systems and methods for executing an application on a mobile device
US8918872B2 (en) * 2008-06-27 2014-12-23 Mcafee, Inc. System, method, and computer program product for reacting in response to a detection of an attempt to store a configuration file and an executable file on a removable device
US20100131683A1 (en) * 2008-11-26 2010-05-27 Moore Clay S System for storing, accessing and automatically updating documents
US8402544B1 (en) * 2008-12-22 2013-03-19 Trend Micro Incorporated Incremental scanning of computer files for malicious codes
US8654721B2 (en) 2010-08-04 2014-02-18 Intel Mobile Communications GmbH Communication devices, method for data communication, and computer program product
US8406780B2 (en) 2011-01-14 2013-03-26 Intel Mobile Communications GmbH LTE operation in white spaces
US10055727B2 (en) * 2012-11-05 2018-08-21 Mfoundry, Inc. Cloud-based systems and methods for providing consumer financial data
KR101438978B1 (ko) 2012-12-31 2014-09-11 현대자동차주식회사 리프로그래밍 방법 및 시스템
US9008907B2 (en) 2013-05-31 2015-04-14 Hugh D Copeland Intelligent vehicle power control system and method
US9357411B2 (en) 2014-02-07 2016-05-31 Qualcomm Incorporated Hardware assisted asset tracking for information leak prevention
CN105303106B (zh) * 2014-06-06 2019-06-25 腾讯科技（深圳）有限公司 恶意代码处理方法、装置及系统
US10841161B2 (en) * 2018-08-02 2020-11-17 Sap Se Real-time configuration check framework
DE102018219320A1 (de) * 2018-11-13 2020-05-14 Robert Bosch Gmbh Batteriesystem zur Verwendung an einem Bordnetz eines Kraftfahrzeugs
CN110874143B (zh) * 2019-11-14 2024-04-12 东莞市小精灵教育软件有限公司 传感器数据获取方法、智能终端、存储介质及电子设备
WO2022133878A1 (en) * 2020-12-24 2022-06-30 Qualcomm Incorporated Search and cell scan procedure for positioning-cellular network interworking scenarios
US20230185636A1 (en) * 2021-12-10 2023-06-15 Nvidia Corporation Application programming interfaces for interoperability
US20230185638A1 (en) * 2021-12-10 2023-06-15 Nvidia Corporation Application programming interfaces for interoperability

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4316246A (en) * 1979-09-06 1982-02-16 Honeywell Information Systems Inc. Battery switching apparatus included within a timer adapter unit
US5715463A (en) * 1992-03-31 1998-02-03 International Business Machines Corporation Installation utility for device drivers and utility programs
US5361358A (en) * 1992-08-07 1994-11-01 International Business Machines Corporation System and method for installing program code for operation from multiple bootable operating systems
US5815722A (en) * 1992-11-18 1998-09-29 Canon Information Systems, Inc. In an interactive network board, a method and apparatus for remotely downloading and executing files in a memory
US5845090A (en) * 1994-02-14 1998-12-01 Platinium Technology, Inc. System for software distribution in a digital computer network
US5802275A (en) * 1994-06-22 1998-09-01 Lucent Technologies Inc. Isolation of non-secure software from secure software to limit virus infection
US6151643A (en) * 1996-06-07 2000-11-21 Networks Associates, Inc. Automatic updating of diverse software products on multiple client computer systems by downloading scanning application to client computer and generating software list on client computer
US6321369B1 (en) 1996-10-28 2001-11-20 Altera Corporation Interface for compiling project variations in electronic design environments
US6023620A (en) 1997-02-26 2000-02-08 Telefonaktiebolaget Lm Ecrisson Method for downloading control software to a cellular telephone
US5948104A (en) * 1997-05-23 1999-09-07 Neuromedical Systems, Inc. System and method for automated anti-viral file update
US6934956B1 (en) * 1997-09-09 2005-08-23 Micron Technology, Inc. Method and apparatus for installing an operating system
GB2333864B (en) * 1998-01-28 2003-05-07 Ibm Distribution of software updates via a computer network
JP3017167B2 (ja) * 1998-05-20 2000-03-06 インターナショナル・ビジネス・マシーンズ・コーポレイション デ一タ記憶媒体からのリ一ド信号の２値化方法および装置
US6269254B1 (en) * 1998-09-28 2001-07-31 Motorola, Inc. Radio communications device and method with API between user application program and telephony program and method
EP1118949A1 (en) * 2000-01-21 2001-07-25 Hewlett-Packard Company, A Delaware Corporation Process and apparatus for allowing transaction between a user and a remote server
US6598168B1 (en) * 2000-05-09 2003-07-22 Power Digital Communications Co. Ltd Computer auto shut-off control method
US6799197B1 (en) * 2000-08-29 2004-09-28 Networks Associates Technology, Inc. Secure method and system for using a public network or email to administer to software on a plurality of client computers
US7054930B1 (en) * 2000-10-26 2006-05-30 Cisco Technology, Inc. System and method for propagating filters
US20020072347A1 (en) * 2000-12-07 2002-06-13 Dunko Greg A. System and method of receiving specific information at a mobile terminal
US6907423B2 (en) * 2001-01-04 2005-06-14 Sun Microsystems, Inc. Search engine interface and method of controlling client searches
US20020116629A1 (en) * 2001-02-16 2002-08-22 International Business Machines Corporation Apparatus and methods for active avoidance of objectionable content
US7123933B2 (en) * 2001-05-31 2006-10-17 Orative Corporation System and method for remote application management of a wireless device
US6792543B2 (en) * 2001-08-01 2004-09-14 Networks Associates Technology, Inc. Virus scanning on thin client devices using programmable assembly language
US7827611B2 (en) * 2001-08-01 2010-11-02 Mcafee, Inc. Malware scanning user interface for wireless devices
US7210168B2 (en) * 2001-10-15 2007-04-24 Mcafee, Inc. Updating malware definition data for mobile data processing devices
US6999721B2 (en) * 2002-01-17 2006-02-14 Microsoft Corporation Unified object transfer for multiple wireless transfer mechanisms
US6785820B1 (en) * 2002-04-02 2004-08-31 Networks Associates Technology, Inc. System, method and computer program product for conditionally updating a security program
US7216367B2 (en) * 2003-02-21 2007-05-08 Symantec Corporation Safe memory scanning
US6970697B2 (en) * 2003-04-17 2005-11-29 Ntt Docomo, Inc. Platform-independent scanning subsystem API for use in a mobile communication framework
US6987963B2 (en) * 2003-04-17 2006-01-17 Ntt Docomo, Inc. System, method and computer program product for content/context sensitive scanning utilizing a mobile communication device

Also Published As

Publication number Publication date
CA2517548C (en) 2012-10-30
EP1629360A4 (en) 2009-09-09
US7254811B2 (en) 2007-08-07
JP4448849B2 (ja) 2010-04-14
JP2007525059A (ja) 2007-08-30
NO20055430D0 (no) 2005-11-16
EP1629360B1 (en) 2018-06-13
US20040210891A1 (en) 2004-10-21
CA2517548A1 (en) 2004-11-04
WO2004095167A3 (en) 2006-11-30
KR101071597B1 (ko) 2011-10-10
KR20060008901A (ko) 2006-01-27
NO20055430L (no) 2006-01-10
WO2004095167A2 (en) 2004-11-04
EP1629360A2 (en) 2006-03-01

Similar Documents

Publication Publication Date Title
NO336580B1 (no) Oppdateringssystem og metode for å oppdatere et skanningsundersystem i et mobilt kommunikasjonsrammeverk
CA2517485C (en) Api system, method and computer program product for accessing content/security analysis functionality in a mobile communication framework
JP4597974B2 (ja) 移動通信装置を使用してコンテンツ／コンテクストの高感度スキャニングを行うシステム、方法及びコンピュータプログラム製品
US6970697B2 (en) Platform-independent scanning subsystem API for use in a mobile communication framework
CN100524211C (zh) 在移动通信框架内用于更新扫描子系统的更新系统与方法
CN114254320A (zh) 网络攻击回溯方法、装置、计算机设备及存储介质

Legal Events

Date Code Title Description
MM1K Lapsed by not paying the annual fees