KR20060009257A

KR20060009257A - 이동 통신 디바이스를 이용하여 컨텐츠/컨텍스트 고감도스캐닝을 위한 시스템, 방법 및 컴퓨터 프로그램 제품

Info

Publication number: KR20060009257A
Application number: KR1020057019711A
Authority: KR
Inventors: 빅토르 쿠즈네초프; 데이비드 리벤지; 마이클 씨 박; 야스타카 우라카와; 겐지 이시이; 마사노리 후지타
Original assignee: 맥아피 인코퍼레이티드; 가부시키가이샤 엔티티 도코모
Priority date: 2003-04-17
Filing date: 2004-04-05
Publication date: 2006-01-31
Anticipated expiration: 2024-04-05
Also published as: WO2004095847A3; JP2007524902A; EP3062234B1; CA2517534C; EP1639493A4; CA2517534A1; EP3062234A1; EP1639493B1; CN101248427A; US20040210645A1; WO2004095847A2; US6987963B2; JP4597974B2; KR101120447B1; CN101248427B; EP1639493A2; NO20055429L; NO20055429D0

Abstract

이동 통신 디바이스를 이용하여 애플리케이션 프로그램 데이터를 스캐닝하기 위한 시스템, 방법 및 컴퓨터 프로그램 제품이 제공된다. 무선 네트워크를 통해 통신할 수 있는 이동 통신 디바이스상에 설치된 애플리케이션 프로그램이 포함된다. 이러한 애플리케이션 프로그램은 이동 통신 디바이스를 이용하여 태스크들을 수행하는데 적합하다. 또한, 애플리케이션 프로그램과 통신하여, 애플리케이션 프로그램에 의해 수행되는 태스크들과 관련된 애플리케이션 데이터를 스캐닝하는 스캐닝 서브시스템이 연관된다. 사용시, 애플리케이션 프로그램은, 스캐닝 서브시스템에 의한 스캐닝을 용이하게 하기 위해 스캐닝 서브시스템으로, 애플리케이션 데이터와 관련된 정보를 전달한다.

스캐닝 서브시스템, 애플리케이션 프로그램, 멀웨어, 악성 코드

Description

이동 통신 디바이스를 이용하여 컨텐츠/컨텍스트 고감도 스캐닝을 위한 시스템, 방법 및 컴퓨터 프로그램 제품{SYSTEM, METHOD AND COMPUTER PROGRAM PRODUCT FOR CONTENT/CONTEXT SENSITIVE SCANNING UTILIZING A MOBILE COMMUNICATION DEVICE}

발명의 기술 분야

본 발명은 이동 통신 디바이스 보안에 관한 것이고, 보다 상세하게는 이동 통신 디바이스를 스캐닝하여 멀웨어를 탐지하는 것에 관한 것이다.

발명의 배경

지난 10 년간 이동 셀룰러 전화기의 사용과 수에서의 급속한 성장이 있어 왔다. 보다 최근에는, 이동 전화기와 개인 휴대 단말기 (PDA : Personal Digital Assistant) 의 기능성을 결합하는 무선 디바이스들이 도입되고 있다. 새로운 셀룰러 전기통신 표준들 (즉, GPRS, UMTS 및 WAP) 이 무선 인터페이스를 통해 데이터의 고속 전달을 가능하게 함에 따라, 이분야에서 가까운 장래에 엄청난 성장이 있을 것으로 기대된다.

현재 개인 컴퓨터와 워크스테이션이 감염되기 쉬운 것과 거의 동일한 방식으로, 바이러스, 트로이 목마 및 웜 (총칭하여 이하 "바이러스"라 함) 과 같은 이른바 "멀웨어(malware)"로부터 그리고 기타 원하지 않은/해로운 컨텐츠 (content) 로부터의 공격에, 이러한 플랫폼들은 감염되기 쉬울 것으로 예상될 수 있다. 많 은 수의 이동 전화기 바이러스들의 정체가 이미 밝혀지고 있다.

바이러스의 공격에 저항하기 위해, 안티-바이러스 소프트웨어가, 데스크탑 환경에서 그것이 배치되었던 것과 거의 동일한 방식으로 이동 플랫폼 (mobile platform) 내에 배치되어야만 한다. 많은 상이한 데스크탑 안티-바이러스 애플리케이션들이 현재 입수가능하다. 이들 애플리케이션들의 대다수는 의심파일을 검색하여 소정의 바이러스 서명 (signature) 의 존재를 찾는 기본 스캐닝 엔진에 의존한다. 이들 서명들은, 가장 최근에 정체가 밝혀진 바이러스를 반영하도록 계속하여 업데이되는 데이터베이스에서 유지된다.

통상적으로, 사용자들은 인터넷을 통한 수신된 이메일로부터, 또는 CDROM 또는 플로피 디스크로부터 종종 대체 데이터베이스 (replacement database) 들을 다운로드한다. 또한, 사용자들은, 바이러스의 새로운 변종이 탐지되는 경우, 요구될 수도 있는 새로운 바이러스 탐지 기술을 이용하기 위해 종종 소프트웨어 엔진을 업데이트한다.

이동 무선 플랫폼들은 (안티-바이러스 소프트웨어 개발자들을 포함하는) 소프트웨어 개발자들에게 일련의 문제들을 제시한다. 특히, 종래에는 이동 무선 애플리케이션들은 표준화되지 않았기 때문에, 이동 무선 애플리케이션들은 임의의 스캐닝 동작이 실행되기 전에 그 애플리케이션에 대한 정보를 스캐너가 식별하는 것을 요구한다. 불행하게도, 이러한 정보 수집은 스캐닝 프로세스의 성능손실을 초래한다.

발명의 개시

이동 통신 디바이스를 이용하여 애플리케이션 프로그램 데이터를 스캐닝하기 위한 시스템, 방법 및 컴퓨터 프로그램 제품이 제공된다. 무선 네트워크를 통해 통신을 할 수 있는 이동 통신 디바이스상에 설치된 (installed) 애플리케이션 프로그램이 포함된다. 이러한 애플리케이션 프로그램은 이동 통신 디바이스를 이용하여 태스크들을 수행하는데 적합하다. 또한, 이와 함께 애플리케이션 프로그램에 의해 수행되는 태스크들과 관련된 애플리케이션 데이터를 스캐닝하기 위한, 애플리케이션 프로그램과 통신하는 스캐닝 서브시스템이 연관된다. 사용시에, 애플리케이션 프로그램은, 스캐닝 서브시스템에 의한 스캐닝을 용이하게 하기 위해, 스캐닝 서브시스템으로 애플리케이션 데이터와 관련된 정보를 통신한다.

일 실시형태에서, 스캐닝은 온-디멘드 바이러스 스캐닝 및/또는 온-액세스 바이러스 스캐닝을 포함할 수도 있다.

다른 실시형태에서, 애플리케이션 프로그램은, 태스크들이 전자 메일을 관리하는 것을 포함하는 메일 애플리케이션 프로그램을 포함할 수도 있다. 또한, 애플리케이션 프로그램은, 태스크들이 네트워크를 브라우징하는 것을 포함하는 브라우저 애플리케이션 프로그램을 포함할 수도 있다. 그러나 여전히, 애플리케이션 프로그램은, 태스크들이 복수의 전화 번호를 관리하는 것을 포함하는 전화 번호부 애플리케이션을 포함할 수도 있다. 옵션으로서, 애플리케이션 프로그램은, 태스크들이 메시지들을 통신하는 것을 포함하는 메시지 애플리케이션 프로그램을 포함할 수도 있다. 애플리케이션 프로그램의 임의의 유형 (즉, 자바 애플리케이션 프로그램) 이 포함될 수도 있다.

또 다른 실시형태에서, 스캐닝 서브시스템에 전달된 정보는 상이한 유형의 애플리케이션 데이터와 관련될 수도 있다. 이러한 유형들은 하이퍼텍스트 생성언어 (HTML)-유형 (hypertext mark-up language (HTML)-type), URL-유형 (uniform resource locator (URL)-type), 전자 메일-유형, 전화 번호-유형, 자바-유형, 텍스트-유형 및/또는 미지의 유형을 포함할 수도 있다.

옵션으로서, 또한, 정보는 애플리케이션 데이터의 유형의 각각과 연관된 포맷을 더 식별할 수도 있다. 이것은, 상이한 유형의 애플리케이션 데이터에 관련된 변수들을 그 정보에 제공함으로써 달성될 수도 있다.

또 다른 실시형태에서, 정보는 스캐닝 서브시스템에 의한 스캐닝의 타이밍을 나타낼 수도 있다. 이러한 타이밍은, 애플리케이션 데이터의 수신, 애플리케이션 데이터의 스토리지, 애플리케이션 데이터의 렌더링, 및/또는 애플리케이션 데이터의 인보킹과 관련될 수도 있다. 그러나 여전히, 그 정보는, 스캐닝 서브시스템에 의한 스캐닝이 옵션적 및/또는 강제적인지를 나타낼 수도 있다.

따라서, 그 정보는 스캐닝 서브시스템에 의한 스캐닝 타이밍을 개선시킬 수도 있다. 또한, 그 정보는 스캐닝 서브시스템에 의한 스캐닝의 정확성을 개선시킬 수도 있다.

도면의 간단한 설명

도 1 은 일 실시형태에 따른, 이동 통신 프레임워크를 나타내는 도면이다.

도 2 는 다른 실시형태에 따른, 이동 통신 프레임워크를 나타내는 도면이다.

도 3 은 일 실시형태에 따른, 이동 통신 디바이스와 연관된 아키텍처를 나타 내는 도면이다.

도 4 는 일 실시형태에 따른, 이동 통신 디바이스를 이용하여 보안 또는 컨텐츠 분석 기능성에 액세스하는 시스템을 나타내는 도면이다.

도 5 는 도 4 의 시스템의 애플리케이션 서버 실시형태에 따른, 이동 통신 디바이스를 이용하여 보안 또는 컨텐츠 분석 기능성에 액세스하는 프레임워크를 나타내는 도면이다.

도 6 은 도 4 의 재입력 가능 라이브러리에 따른, 이동 통신 디바이스를 이용하여 보안 또는 컨텐츠 분석 기능성에 액세스하는 프레임워크를 나타내는 도면이다.

도 7 은 도 4 의 시스템 맥락에서 구현된 온-디맨드 스캐닝 시스템 (on-demand scanning system) 을 나타내는 도면이다.

도 8 은 일 실시형태에 따른, 이동 애플리케이션 프로그램들 및 스캐닝 서브시스템을 인터페이스하는데 사용될 수도 있는 애플리케이션 프로그램 인터페이스 (API) 의 다양한 컴포넌트들의 계층도이다.

도 9 는 예시적인 라이브러리 인터페이스 초기화를 나타내는 도면이다.

도 10 은 일 실시형태에 따른, 에러 코드 기능성의 예시적인 포맷을 나타내는 도면이다.

도 11 은 일 실시형태에 따른, 스캐닝 서브시스템 API 호출 시퀀스 (API call sequence) 를 나타내는 도면이다.

도 12 는 일 실시형태에 따른 하나의 예시적인 컨피규레이션 (configuration) API 호출 시퀀스를 나타내는 도면이다.

도 13 은 API 를 통해 애플리케이션 프로그램이 스캐닝 서브시스템과 통신할 수 있는 여러가지의 예시적인 스캔 데이터 유형들을 나타내는 도면이다.

도 14 는 하나의 예시적인 실시형태에 따른, 멀웨어 시베러티 플래그 (malware severity flags) 및 애플리케이션 프로그램 비헤이비어 레벨들 (behavior levels) 을 포함하는 비트-필드 변수를 나타내는 도면이다.

도 15 는 스캐닝 서브시스템에 의한 스캐닝하는 타이밍이, 도 13 의 변수들을 통해 식별되는 데이터 유형들의 함수로서 변동하는 방식을 설명하는 테이블을 나타낸 도면이다.

도 16 은 일 실시형태에 따른, 사용자 인터페이스에 의해 업데이트가 개시되는 방식을 설명하는 예시적인 흐름도이다.

도 17 은 일 실시형태에 따른, 이동 통신 디바이스의 스캐닝 서브시스템을 효과적으로 업데이트하기 위한 방법을 나타내는 도면이다.

상세한 설명

도 1 은 일 실시형태에 따른, 이동 통신 프레임워크 (100) 를 나타낸다. 도시된 바와 같이, 무선 네트워크를 통해 통신할 수 있는 이동 통신 디바이스 (102) 및 백엔드 서버 (104) 가 포함된다. 본 설명의 맥락에서, 이동 통신 디바이스 (102) 는 셀룰러 전화기, 무선 개인 휴대 단말기 (PDA), 무선 핸드-헬드 컴퓨터, 무선 휴대용 컴퓨터, 또는 무선 네트워크를 통해 통신할 수 있는 임의의 다른 이동 디바이스를 포함할 수도 있으며, 그러나 이것들에 한정되지 않는다.

일 실시형태에서, 이동 통신 디바이스 (102) 는 스캐닝 서브시스템 (105) 을 구비할 수도 있다. 이러한 스캐닝 서브시스템 (105) 은 이동 통신 디바이스 (102) 상에 저장되거나 이동 통신 디바이스와 통신중인 데이터를 스캐닝할 수 있는 임의의 서브시스템을 포함할 수도 있다. 물론, 이러한 스캐닝은 온-액세스 스캐닝, 온-디맨드 스캐닝, 또는 임의의 다른 유형의 스캐닝을 칭할 수도 있다. 또한, 스캐닝은 전술한 데이터, 멀웨어용 일반 보안-유형의 스캐닝 등에 의해 나타내어질 수 있는 컨텐츠 (예를 들어, 텍스트, 영상 등) 를 포함 할 수도 있다.

도 1 을 참조하면, 이동 통신 디바이스 (102) 는, 전술한 스캐닝 기능성을 포함하는 다양한 기능성을 관리하는데 적당한 복수의 그래픽 사용자 인터페이스 (108) 를 나타낼 수 있는 디스플레이 (106) 를 추가로 구비할 수도 있다.

사용시에, 이동 통신 디바이스 (102) 의 디스플레이 (106) 는 네트워크 (즉, 인터넷 등) 을 통해 데이터를 디스플레이하는데 사용된다. 동작 1 을 참조한다. 사용 과정에서, 사용자는 디스플레이 (106) 를 사용하여, 네트워크로부터 백엔드 서버 (104) 를 경유하는 데이터를 검색하기 위해 링크 또는 앵커들을 선택함으로써 네트워크상의 다양한 데이터를 브라우징할 수도 있다. 동작 2 를 참조한다. 그 다음에, 동작 3 에서는, 스캐닝 서브시스템 (105) 이 검색 데이터를 스캐닝하기 위해 호출된다.

이 예에서, 스캐닝 서브시스템 (105) 은 동작 4 에서, 검색된 데이터와 연관된 멀웨어 (malware : malicious software) 위치를 알아낸 것으로 도시된다. 이 시점에서, 그 검색을 중지 및/또는 식별된 멀웨어와 상관없이 데이터를 사용/액 세스하는 옵션이 사용자에게 디스플레이 (106) 를 통해 제공된다. 동작 5 를 참조한다. 동작 5 에서의 결정에 기초하여, 사용자는 동작 6 에서 나타내어진 바와 같이 "공격"의 대상이 되거나 또는 공격의 대상이 되지 않을 수도 있다.

도 2 는 다른 실시형태에 따른 이동 통신 프레임워크 (200) 를 나타낸다. 본 이동 통신 프레임워크 (200) 는, 검색된 데이터에서의 멀웨어 식별에 이동 통신 디바이스가 반응하는 방식을 제외하고는 도 1 의 이동 통신 프레임워크 (100) 와 유사하다.

특히, 동작 5 에서 하나의 옵션이 사용자에게 제공된다. 즉, 사용자는 멀웨어를 통합시키기 위해, 발견된 데이터와 연관된 임의의 다이얼로그를 단지 폐쇄시킬 수 있다. 동작 6 을 참조한다.

도 3 은 일 실시형태에 따른, 이동 통신 디바이스와 연관된 아키텍처 (300; architecture) 를 나타낸다. 이 아키텍처 (300) 는 도 1 및 도 2 의 이동 통신 디바이스에 통합될 수도 있다. 물론, 이 아키텍처 (300) 는 임의의 원하는 맥락에서 구현될 수도 있다.

도시된 바와 같이, 아키텍처 (300) 는 복수의 이동 애플리케이션 프로그램 (302) 을 포함할 수도 있다. 본 설명의 맥락에서, 이동 애플리케이션 (302) 은 다양한 태스크들을 실행하기 위해 이동 통신 디바이스상에 설치된 임의의 애플리케이션 프로그램, 소프트웨어 등을 포함할 수도 있다. 또한, 이러한 애플리케이션 프로그램 (302) 은 사용자의 소망에 따라서 펌웨어 (firmware), 하드웨어 등으로 구현될 수도 있다.

다른 실시형태에서, 애플리케이션 프로그램 (302) 은, 태스크들이 전자 메일을 관리하는 것을 포함하는 메일 애플리케이션 프로그램을 포함할 수도 있지만 이것들에 한정되지는 않는다. 또한, 애플리케이션 프로그램은, 태스크들이 네트워크를 브라우징하는 것을 포함하는 브라우저 애플리케이션 프로그램을 포함할 수도 있다. 그러나 여전히, 애플리케이션 프로그램은, 태스크들이 복수의 전화 번호들을 관리하는 것을 포함하는 전화 번호부 애플리케이션 프로그램을 포함할 수도 있다. 옵션으로서, 애플리케이션 프로그램은, 태스크들이 메시지들을 통신하는 것을 포함하는 메시지 애플리케이션 프로그램을 포함할 수도 있다. 애플리케이션 프로그램의 임의의 유형이 포함될 수도 있다. 예를 들어, 자바 애플리케이션 프로그램 등이 포함될 수도 있다.

도 3 을 계속하여 참조하면, 스캐닝 서브시스템 (304) 은 제 1 애플리케이션 프로그램 인터페이스 (306; API), 및 스캐닝 서브시스템 (304) 과 연관된 제 1 라이브러리 (308) 를 통해 애플리케이션 프로그램 (302) 과 통신한다. 이 후, 도 4 내지 도 12 를 참조하여, 제 1 애플리케이션 프로그램 인터페이스 (306) 및 제 1 라이브러리 (308) 와 관련된 옵션적인 예시적 세부 사항들과 관계된 보다 많은 정보들을 상세하게 설명한다.

옵션으로서, 애플리케이션 프로그램 (302) 은, 스캐닝 서브시스템 (304) 에 의한 스캐닝을 용이하게 하기 위해 스캐닝 서브시스템 (304) 으로 정보를 통신할 수도 있다. 이러한 정보는 스캔될 데이터의 유형과 관련될 수도 있고 이러한 스캐닝과 연관된 타이밍과 관련될 수도 있다. 도 13 내지 도 15 를 참조하여, 스캐닝 서브시스템 (304) 이 애플리케이션 프로그램 (302) 과 이러한 방식으로 상호 작용하는 방법과 관련된 보다 많은 예시적인 정보를 설명한다.

도 3 에 도시된 바와 같이, 제 1 라이브러리 (308) 는 업데이트 관리자 (310), 컨피규레이션 관리자 (312), 및 서명 데이터베이스 (314) 를 포함할 수도 있다. 사용시에, 업데이트 관리자 (310) 는, 스캐닝 목적으로 서명 데이터베이스 (314) 가 최신의 서명으로 업데이트되는 프로세스를 관리할 수도 있다. 일 실시형태에서, 업데이트 프로세스는, 이동 통신 프레임워크에서의 고유의 한정 대역폭을 수용하도록 유선형이 될 (steamlined) 수도 있다. 도 16 내지 도 17 을 참조하여, 이러한 업데이트 프로세스와 관련된 보다 많은 예시적인 정보를 설명한다.

또한, 이동 통신 디바이스상에 설치되어 애플리케이션 프로그램 (302) 를 실행하기에 적합한 운영 시스템 (316) 이 도 3 의 아키텍처 (300) 의 컴포넌트로서 제공된다. 일 실시형태에서, 스캐닝 서브시스템 (304) 은 플랫폼-독립적일 (platform-independent) 수도 있으며, 따라서 임의 유형의 운영 시스템/이동 통신 디바이스 조합으로 구현될 수 있다.

이러한 특징을 제공하기 위해, 제 2 애플리케이션 프로그램 인터페이스 (318) 및 제 2 라이브러리 (320) 가, 시스템/라이브러리 초기화 (322), 에러 기능 (336), 메모리 할당 (334), 입력/출력 (I/O) (328), 데이터 인증 (332), 동기화 (330), 하이퍼텍스트 전달 프로토콜 (326), 디바이스 정보 (324), 디버깅 (338) 및 다른 기능성 (즉, 공유 메모리, 시스템 시간 등) 과 같은 다양한 기능성을 지원할 수 있다. 일 실시형태에서, 제 2 애플리케이션 프로그램 인터페이스 (318) 는 스캐닝 서브시스템 (304) 에 유사하게 플랫폼 독립적일 수도 있다. 이 후, 부록 A 를 참조하여, 제 2 애플리케이션 프로그램 인터페이스 (318) 및 제 2 라이브러리 (320) 에 관련된 옵션적인 예시적 세부 사항들과 관계된 보다 많은 정보를 상세히 설명한다.

도 4 는 일 실시형태에 따른, 이동 통신 디바이스를 이용하여 보안 또는 컨텐츠 분석 기능성에 액세스하는 시스템 (400) 을 나타낸다. 일 예에서, 이 시스템 (400) 은 도 3 의 아키텍처 (300) 의 운영 시스템, 스캐닝 서브시스템 및 애플리케이션 프로그램의 맥락에서 구현될 수도 있다. 그러나, 이 시스템 (400) 은 임의의 원하는 맥락으로 구현될 수도 있다.

도시된 바와 같이, 무선 네트워크를 통해 통신할 수 있는 이동 통신 디바이스상에서 설치된 운영 시스템 (402) 이 포함될 수도 있다. 무선 통신 디바이스상에 설치되고 운영 시스템 (402) 을 사용하여 실행되어 태스크들을 수행하는 애플리케이션 프로그램 (404) 이 추가로 제공된다.

스캐닝 서브시스템 (406) 은 애플리케이션 프로그램 인터페이스 및 연관된 라이브러리를 통해 애플리케이션 프로그램 (404) 과의 통신을 유지한다 (예를 들어 도 3 의 제 1 애플리케이션 프로그램 인터페이스 (306) 및 제 1 라이브러리 (308) 을 참조). 이러한 스캐닝 서브시스템 (406) 은, 애플리케이션 프로그램 (404) 에 의해 수행되는 태스크들과 연계되어 보안 또는 컨텐츠 분석 기능성에 액섹싱하는데 적합하다. 일 실시형태에서, 보안 또는 컨텐츠 분석은 보안 분석을 포함 할 수도 있다. 다른 실시형태에서, 보안 또는 컨텐츠 분석은 컨텐츠 분석을 포함할 수도 있다. 그러나 여전히, 보안 또는 컨텐츠 분석은 온-디맨드 바이러스 스캐닝 및/또는 온-액세스 바이러스 스캐닝을 포함할 수도 있다.

사용시에, 보안 또는 컨텐츠 분석 기능성은, 애플리케이션 프로그램 (404) 에 의해 수행되는 태스크들과 연관된 애플리케이션 데이터에 적용될 수도 있다. 본 설명의 맥락에서, 애플리케이션 데이터는, 입력되고, 프로세싱되며, 출력되거나, 또는 그렇지 않으면 애플리케이션 프로그램 (404) 에 의해 실행되는 태스크들의 수행과 연관된 임의의 데이터를 포함할 수도 있다.

애플리케이션 프로그램 인터페이스를 통한 스캐닝 서브시스템 (406) 과 애플리케이션 프로그램 (404) 의 단단한 커플링에 의해, 보다 적은 오버헤드 및 코드 잉여분이 요구된다. 이 후, 다음의 도면들을 참조하여, 이러한 애플리케이션 프로그램 인터페이스 및 연관된 라이브러리에 관한 보다 많은 예시적인 정보를 보다 상세하게 설명한다.

도 5 는 도 4 의 시스템 (400) 의 애플리케이션 서버 실시형태에 따른, 이동 통신 디바이스를 이용하여 보안 또는 컨텐츠 기능성에 액세스하는 프레임워크 (500) 을 나타낸다. 이 프레임워크는 임의의 원하는 맥락에서 구현될 수도 있다.

도시된 바와 같이, 스캐닝 서브시스템은 애플리케이션 프로그램 인터페이스 (506) 및 연관된 프로토콜 (즉, uItron 메시징 시스템) 을 통해 애플리케이션 프로그램 (504) 과 통신하는 스캐닝 프로그램 (502) 을 포함할 수도 있다. 이 후 보다 상세하게 설명되는 바와 같이, 애플리케이션 프로그램 인터페이스 (506) 는 스캐닝 프로그램 (502) 과 연관된 제 1 컴포넌트 (508) 및 애플리케이션 프로그램 (504) 연관된 제 2 컴포넌트 (510) 를 포함할 수도 있다.

애플리케이션 프로그램 인터페이스 (506) 가 제공된 다양한 호출 (512) 들은 개방 호출 (open call), 데이터 호출 (data call), 및 폐쇄 호출 (close call) 을 포함할 수도 있다. 사용시에, 스캐닝 프로그램 (502) 은 애플리케이션 프로그램 (504) 에 의해 수행되는 태스크들과 연관된 스캔 애플리케이션 데이터 (516) 를 스캔할 수도 있다.

도 6 은, 도 4 의 시스템 (400) 의 재입력 가능 라이브러리 실시형태에 따른, 이동 통신 디바이스를 사용하여 보안 또는 컨텐츠 분석 기능성에 액세스하는 프레임워크 (600) 를 나타낸다. 이 프레임워크 (600) 는 임의의 원하는 맥락에서 구현될 수도 있다.

도시된 바와 같이, 스캐닝 서브시스템은 재입력 가능 라이브러리 (602) 를 포함할 수도 있다. 사용시에, 스캐닝 서브시스템 재입력 가능 라이브러리 (602) 는 런-타임에서 애플리케이션 프로그램 (604) 에 링크될 수도 있다. 따라서, 애플리케이션 프로그램 인터페이스 (606) 는 복수의 애플리케이션 프로그램 (604) 각각의 내부에 상주될 수도 있다.

도 5 의 이전 프레임워크 (500) 과 유사하게, 애플리케이션 프로그램 인터페이스 (606) 는 개방 호출, 데이터 호출, 및 폐쇄 호출을 포함하는 다양한 호출 (612) 들을 포함할 수도 있다. 사용시에, 재입력 가능 라이브러리 (602) 는, 애플리케이션 프로그램 (604) 에 의해 수행되는 태스크들과 연관된 애플리케이션 데이터 (616) 를 스캐닝하는데 사용될 수도 있다.

도 7 은 도 4 의 시스템 (400) 의 맥락에서 구현된 온-디맨드 스캐닝 시스템 (700) 을 나타낸다. 이 시스템 (700) 은 임의의 원하는 맥락에서 구현될 수도 있다.

온-디맨드 스캐닝은 악성 컨텐츠 또는 코드의 제거를 위해 저장된 애플리케이션 데이터 (702) 의 스캐닝을 제공한다. 사용자는 사용자 인터페이스 (703) 를 통해 온-디맨드 스캐닝을 시작할 수도 있다. 또한, 각 애플리케이션 프로그램 (704) 은 스캐닝 서브시스템 (706) 을 호출하여 대응하는 메모리에 저장된 객체 (object) 들의 스캐닝을 수행할 수도 있다.

한편, 온-액세스 스캐닝은, 애플리케이션 프로그램 (704) 이 애플리케이션 데이터 (702) 를 프로세싱하거나 렌더링하기 전에 악성 코드 또는 컨텐츠의 식별을 제공한다. 온-액세스 스캐닝은, 스캐닝 서브시스템 (706) 이 악성 애플리케이션 데이터 (702) 를 탐지할 때까지 사용자에게 투명하다.

도 8 은 일 실시형태에 따라, 이동 애플리케이션 프로그램과 스캐닝 서브시스템을 인터페이스하는데 사용될 수도 있는 애플리케이션 프로그램 인터페이스 (800) 의 다양한 컴포넌트들의 계층을 나타낸다. 옵션으로서, 이 애플리케이션 프로그램 인터페이스 (800) 는 도 4 의 시스템 (400) 의 맥락에서 구현될 수도 있다. 그러나, 이 애플리케이션 프로그램 인터페이스 (800) 는 임의의 원하는 맥락에서 구현될 수도 있다.

도 8 에 도시된 바와 같이, 애플리케이션 프로그램 인터페이스 함수들은 MDoScanOpen() (802), MDoScanClose() (804), MDoScanVersion() (806) 및 MDoScanData() (808) 을 포함한다. MDoScanOpen() (802) 및 MDoScanClose() (804) 는 스캐닝 서브시스템 객체 인스턴스 (instance) 를 생성/개방 및 폐쇄하는데 사용된다. MDoScanVersion() (806) 은 스캐닝 서브시스템과 서명 패턴 데이터 버전 정보를 제공한다. MDoScanData() (808) 는 컨텐츠/데이터 스캐닝과 보고를 수행한다. 또한, 스캐너 애플리케이션 프로그램 인터페이스에는 멀웨어 서명 데이터베이스 및 탐지 로직 업데이트를 제공하는 MDoScanUpdate() (810) 가 포함된다. MDoScanUpdate ()(810) 가 업데이트 애플리케이션에 의해 호출되는 경우, 라이브러리는 원격 백-엔드 서버 (예를 들어, 도 1 참조) 에 접속하여 최신의 파일들 (즉, mdo.sdb, mdo.pd) 을 다운로드한다.

스캐닝 서브시스템 컨피규레이션은 MDoConfigOpen() (812), MDoConfigClose() (814), MDoConfigGet() (816) 및 MDoConfigSet() (818) 을 사용하여 수행된다. 일단, 이 애플리케이션 프로그램 인터페이스 (800) 를 호출함으로써 컨피규레이션 핸들 (configuration handle) 이 획득되는 경우, 호출 애플리케이션 프로그램은 획득 및 설정된 컨피규레이션 API 를 사용하여 스캐닝 서브시스템 컨피규레이션 변수들을 질의하고 설정한다.

또한, 이 애플리케이션 프로그램 인터페이스 (800) 에는 MDoGetLastError() (820) 라 하는 에러 검색 함수가 포함된다. 이 함수는 발생된 최종 에러에 대한 정보를 검색하는데 사용된다.

임의의 API 호출들이 이루어지기 전에, 바람직하게는 부트-타임 (boot-time) 에서, MDoSystemInit() (825) 가 라이브러리 환경 세팅을 초기화하도록 호출된다. 라이브러리는 고정된 영속 스토리지 위치 (fixed persistent storage location) 들에 컨피규레이션 세팅, 악성 코드 탐지 로직 (즉, mdo.pd) 및 서명 데이터베이스 (즉, mdo.sdb), 및 내부 변수들 (즉, 동기화 객채 등) 을 보관한다.

MDoLibraryOpen() (830) 및 MDoLibraryClose() (840) 가 라이브러리를 초기화하는데 사용된다. 애플리케이션 프로그램은 임의의 다른 API 호출들이 이루어지기 전에 MDoLibraryOpen() (830) 을 호출할 수도 있고, 애플리케이션 프로그램은 종결전에 MDoLibraryClose() (840) 를 호출할 수도 있다.

애플리케이션 프로그램 인터페이스 (800) 는 다양한 애플리케이션 프로그램 인터페이스 컴포넌트들을 이용하여, 시스템 환경 초기화, 버전 상태 정보 검색, 스캐닝 서브시스템을 업데이트하는 것, 스캐닝, 스캐닝 서브시스템을 구성하는 것 등과 같은 다양한 기능성을 지원할 수도 있다. 이하, 애플리케이션 프로그램 인터페이스 (800) 의 맥락에서, 전술한 기능성에 대해 보다 많은 정보를 설명한다.

시스템 초기화

MDoSystemInit() (825) 는 특정 영속 스토리지 위치에 보관된 데이터에 대한 확증 (validation) 과 환경 초기화를 수행한다. 이들 위치에는 악성 코드/컨텐츠 서명 패턴 데이터베이스 (즉, mdo.sdb), 탐지 로직 (즉, mdo.pd), 컨피규레이션 세팅, 및 동기화 객체들이 저장될 수도 있다. MDoSystemInit() (825) 는 API 함수들 중 임의의 함수가 실행되기 전에 한번만 (즉, 부트-타임에서) 호출될 수도 있다.

테이블 #1 은 MDoSystemInit() (825) 에 관한 예시적인 정보를 나타낸다.

테이블 #1

MDoSystemInit

설명 (Description)

시스템 환경 정보를 확증하고 초기화 함.

프로토타입 (Prototype)

파라미터들 (Parameters)

없음

리턴값 (Return Value)

성공이면 0, 그렇지 않으면 0 이 아닌 에러 코드.

라이브러리 인터페이스 API

애플리케이션 프로그램 인터페이스 (800) 는 복수의 라이브러리 인터페이스 컴포넌트들을 포함한다. API 인터페이스 인스턴스화 (instantiation) 는 MDoLibraryOpen() (830) 을 사용하여 달성될 수도 있다. 이 함수를 사용하여 획득된 인스턴스화된 라이브러리 인터페이스 핸들은 후속 API 호출들에 사용될 수도 있다. 애플리케이션 프로그램이 종료되기 전에, MDoLibraryClose() (840) 가 핸들을 릴리즈하기 위해 호출될 수도 있다. 도 9 는 MDoLibraryOpen() (830) 및 MDoLibraryClose() (840) 을 이용하여 예시적인 라이브러리 인터페이스 초기화 (900) 을 나타낸다.

테이블 #2 는 MDoLibraryOpen() (830) 에 대한 예시적인 정보를 나타낸다.

테이블 #2

MDoLibraryOpen

설명

API 라이브러리 인터페이스 핸들을 초기화하고 리턴함.

프로토타입

파라미터들

없음

리턴값

성공적이면 라이브러리 인터페이스 핸들,

그렇지 않으면 INVALID_MDOLIB_ HANDLE.

또한 참조 (See Also)

테이블 #3 은 MDoLibraryClose() (840) 에 대한 예시적인 정보를 나타낸다.

테이블 #3

MDoLibraryClose

설명

MDoLibraryClose() 함수에 의해 리턴된 API 라이브러리 핸들과 연관된 시스 템 자원을 릴리즈함.

프로토타입

파라미터

hLib

[in] MDoLibraryOpen 에 의해 리턴되어 핸들링된 라이브러리 ([in] library handled returned by MDoLibraryOpen).

리턴값

없음

또한 참조

MDoLibraryOpen()

에러 검색 (Error Retrival)

일단 MDoLibraryOpen() (830) 에 의해 라이브러리가 성공적으로 초기화되고 인스턴스화되면, MDoGetLastError() (820) 는 발생된 최종 에러에 대한 정보를 애플리케이션 프로그램에 제공한다.

테이블 #4 는 MDoGetLastError() (820) 에 대한 예시적인 정보를 나타낸다.

테이블 #4

MDoGetLastError

설명

특정 라이브러리 인스턴스의 최종 에러값을 리턴함.

프로토타입

파라미터들

hLib

[in] MDoLibraryOpen 에 의해 리턴되어 핸들링된 라이브러리.

리턴값

MDoErrorCode 데이터 유형은 컴포넌트와 에러 코드들 양자를 포함하는 32 비트 미서명 정수 (unsigned integer) 로서 정의될 수도 있다. 빈번하게, 검색된 에러 정보는 플랫폼 애브스트랙션 API 층 (platform abstraction API layer) 에 설정될 수도 있다. 이 이유때문에, 본 명세서에서 주어진 MDoErrorCode 포맷은 애브스트랙션 층 API (부록 A 참조) 에 의해 정의되는 AlErrorCode 포맷과 유사하다. 도 10 은 일 실시형태에 따른 MDoErrorCode의 예시적인 포맷 (1000) 을 나타낸다.

테이블 #5 는 MDoGetLastError() (820) 에 대한 예시적인 정보를 나타낸다.

테이블 #5

MDoErrorCode 는,

typedef unsigned long MDoErrorcode;

로서 정의된다.

또한 참조

예시적인 컴퓨터 코드 #1 은 MDoGetLastError() (820) 로의 호출을 갖는 샘플 라이브러리 호출 시퀀스를 나타낸다.

에러 코드

MDoGetLastError() (820) 에 의해 보고된 에러 코드는 2 개의 부분 즉, 컴포넌트 코드와 에러 코드를 포함한다. 보다 많은 정보를 위해서는 부록 A 를 참 조한다. 테이블 #6 은 예시적인 에러 코드들과 대응하는 컴포넌트 코드들을 나열한다. 또한, MDoGetLastError() (820) 는 애브스트랙트 라이브러리층에 설정된 에러 코드들을 리턴한다. 다음의 리스트는 단지 예시적인 목적을 위한 것이고 임의의 방식으로 한정하는 것으로서 해석되어서는 안된다.

테이블 #6

스캐닝 서브시스템 API

애플리케이션 프로그램 인터페이스 (800) 는 복수의 스캐닝 서브시스템 컴포넌트들을 포함한다. 스캐닝 서브시스템 API 컴포넌트는 데이터/컨텐츠 스캐닝 및 서명 업데이트 서비스를 제공한다. MDoScanOpen() (802), MDoScanClose() (804), MDoScanVersion() (806), MDoScanUpdate() (810) 및 MDoScanData() (808) 이 포함된다. MDoScanOpen() (802) 은 스캐닝 서브시스템 객체 인스턴스화에 사용된다. MDoScanVersion() (806) 은 스캐닝 서브시스템 및 서명 데이터베이스 버전 정보를 제공한다. MDoScanUpdate() (810) 는 서명 데이터베이스 업데이트를 수행한다. MDoScanData() (808) 는 악성 코드/컨텐츠 데이터 스캐닝을 수행한다. 도 11 은 일 실시형태에 따른 스캐닝 서브시스템 API 호출 시퀀스 (1100) 를 나타낸다.

MDoScanOpen

테이블 #7 은 MDoScanOpen() (802) 에 대한 예시적인 정보를 나타낸다.

테이블 #7

설명

스캐닝 서브시스템 인스턴스 핸들을 리턴함.

프로토타입

파라미터들

hLib

[in] MDoLibraryOpen() 함수를 사용하여 획득된 라이브러리 핸들.

리턴값

성공이면 스캐닝 서브시스템 인스턴스 핸들.

에러이면 INVALID_MDOSCAN_HANDLE 이 리턴됨.

또한 참조

MDoScanClose

테이블 #8 은 MDoScanClose() (804) 에 대한 예시적인 정보를 나타낸다.

테이블 #8

설명

스캐닝 서브시스템 인스턴스 및 연관 시스템 자원을 릴리즈함.

프로토타입

파라미터들

hScan

[in] MDoScanOpen() 함수를 사용하여 획득된 스캐닝 서브시스템 핸들.

리턴값

없음

또한 참조

MDoScanVersion

테이블 #9 는 MDoScanVersion() (806) 에 대한 예시적인 정보를 나타낸다.

테이블 #9

설명

MDoScanOpen() 함수에 의해 리턴된 스캐너 핸들로부터 스캐닝 서브시스템 및 서명 버전 정보를 획득함.

프로토타입

파라미터들

hScan

pVersion

[out] 버전 정보를 포함하는 구조 (structure) 를 가리키는 포인터 ([out] Pointer to a structure contain version information).

리턴값

성공이면 0, 그렇지 않으면 -1.

또한 참조

예시적인 컴퓨터 코드 #2 는 샘플 버전 정보 구조를 나타낸다.

MDoScanVersion() (806) 에 의해 보고된 이동 통신 디바이스 식별 스트링은, AlDevGetInfo 에 의해 리턴된 디바이스 식별 스트링을 사용하여 설정된다 (부록 A 참조).

MDoScanData

테이블 #10 은 MDoScanData() (808) 에 대한 예시적인 정보를 나타낸다.

테이블 #10

설명

MDoScanData 는 특정 데이터 유형을 스캔하기 위해 애플리케이션 프로그램으로부터 호출됨. 그 호출 애프리케이션 프로그램은 스캐너 액션, 스캔 목표 데이터 유형, 데이터에 액세스하는 세트 I/O 함수들, 및 옵션적인 콜백 함수를 특정 함. 데이터 스캐닝의 결과는 호출자 제공 데이터 구조내로 리턴됨. MDoScanData 는 재입력 가능함.

프로토타입

파라미터들

hScan

[in] MDoScanOpen() 함수로의 호출로부터 획득된 스캐닝 서브시스템 핸들.

pParam

[in] 데이터 스캔 파라미터들을 포함하는 구조를 가리키는 포인터.

pResult

[out] 데이터 스캔 결과들을 포함하는 구조를 가리키는 포인터.

리턴값

성공이면 0, 그렇지 않으면 -1이고 에러 코드가 설정됨.

또한 참조

MDoScanUpdate

테이블 #11 은 MDoScanUpdate() (810) 에 대한 예시적인 정보를 나타낸다.

테이블 #11

설명

악성 코드/컨텐츠 서명 패턴 데이터베이스 (mdo.sdb) 및 탐지 로직 (mdo.pd) 업데이트를 수행함.

프로토타입

파라미터들

hScan

[in] MDoScanOpen() 함수를 사용하여 획득된 스캔 핸들.

pParam

[in] 업데이트 취소/중단 및 진행 상태 업데이트를 위한 콜백 함수 포인터를 포함하는 업데이트 파라미터 구조를 가리키는 포인터.

예시적인 컴퓨터 코드 #3 은, 업데이트 파라미터 구조가 정의되는 방법을 나타낸다.

함수를 호출하는 경우, 호출 애플리케이션 프로그램은 함수로 패싱되는 데이 터 및 함수 포인터를 설정할 수도 있다. 테이블 #12 를 참조한다.

테이블 #12

콜백 이유 (iReason)	설명
MDO_UCB_STATUS	콜백은 업데이트 상태를 보고하기 위해 이루어짐. pParam 은 SStatus 를 가리킴. SStatus.iCurrent 는 수신된 데이터양을 포함하고 iTotal 은 전체 업데이트 데이터의 사이즈를 바이트로 보고함.
MDO_UCB_CANCEL	업데이트 취소가 설정되었는지를 알기위해 콜백이 이루어짐. pParam 은 NULL 을 가리킴.

컨피규레이션 API

애플리케이션 프로그램 인터페이스 (800) 는 복수의 컨피규레이션 컴포넌트를 포함한다. 스캐닝 서브시스템 설정을 검색하고 특정하는데 사용되는 함수 세트를 포함한다. 이들 함수들의 하나의 목표는 집중 런타임 컨피규레이션 액세스를 애플리케이션 프로그램과 스캐닝 서브시스템에 제공하는 것이다. 이 컨피규레이션 데이터는 비휘발성 영속 데이터 스토리지 (즉, 플래시 메모리 등) 에 저장된다.

도 12 는 일 실시형태에 따른 하나의 예시적인 컨피규레이션 API 호출 시퀀스 (1200) 를 나타낸다. 도시된 바와 같이, MDoConfigOpen() (830) 은 컨피규레이션 검색 및 사양 함수들 (configuration retrieval and specification functions) 로 패싱될 핸들을 리턴한다. MDoConfigClose() (814) 는 MDoConfigOpen() (812) 에 의해 리턴된 컨피규레이션 핸들을 릴리즈하고 폐쇄하는데 사용된다. MDoConfigSet() (818) 은 특정 값을 갖는 특정 컨피규레이션 변수를 설정하고, MDoConfigGet() (816) 은 특정 변수에 대해 컨피규레이션 값을 리턴한다. MDoConfigSet() (818) 에 의해 수정된 컨피규레이션 변수(들) 설정은, MDoConfigClose() (814) 가 호출될때 까지 영속 스토리지에 반드시 저장될 필요는 없다.

애플리케이션 프로그램은 컨피규레이션 개방, 획득 또는 설정을 호출할 수도 있고, 변수값에 액세스 및/또는 특정화할때 곧 바로 폐쇄 함수가 뒤따를 수도 있다.

애플리케이션 프로그램 인터페이스 (800) 의 컨피규레이션 컴포넌트들을 사용하여 특정된/검색된 컨피규레이션 변수 및 값들은 널-문자 ('＼0') 종결의, 8-비트 문자 스트링 (character strings) 으로 표현될 수도 있다. 테이블 #13 은 이용가능한 컨피규레이션 변수들을 나열한다.

테이블 #13

컨피규레이션 변수	값/예	설명
"ScanEnable"	"0"	스캐닝 디스에이블
"ScanEnable"	"1"	스캐닝 인에이블
"updateURL"	"http://update.mcafeeacsa.com/504i"	업데이트를 위한 서명용 Base-URL (섹션0 참조)

MDoConfigOpen

테이블 #14 는 MDoConfigOpen() (812) 에 대한 예시적인 정보를 나타낸다.

테이블 #14

설명

MDoConfigGet() 및 MDoConfigSet() 에 대한 후속하는 호출로 패싱될 컨피규레이션 세팅에 핸들을 리턴함.

프로토타입

파라미터들

hLib

[in] MDoLibraryOpen() 함수를 사용하여 획득된 라이브러리 핸들.

리턴값

성공이면, 컨피규레이션 핸들

에러이면, INVALID_MDOCONFIG_HANDLE 이 리턴됨.

또한 참조

MDoConfigClose(), MDoConfigSet(), MDoConfigGet()

MDoConfigClose

테이블 #15는 MDoConfigClose()(814)에 대한 예시적인 정보를 나타낸다.

테이블 #15

설명

시스템 자원을 릴리즈하고 컨피규레이션 핸들을 폐쇄함.

프로토타입

파라미터들

hConfig

[in] MDoConfigOpen() 함수에 의해 리턴된 컨피규레이션 핸들.

리턴값

없음

또한 참조

MDoConfigGet

테이블 #16 은 MDoConfigGet() (816) 에 대한 예시적인 정보를 나타낸다.

테이블 #16

설명

특정 컨피규레이션 변수에 대한 컨피규레이션 값을 획득함.

프로토타입

파라미터들

hConfig

[in] MDoConfigOpen() 함수에 의해 리턴된 컨피규레이션 핸들.

pszName

[in] NULL-종결 컨피규레이션 변수명.

pBuffer

[out] 특정화된 변수에 대한 NULL-종료 (terminated) 컨피규레이션 세팅/값.

uSize

[in] pBuffer 의 바이트 길이.

리턴값

성공이면 0, 그렇지 않으면 -1.

또한 참조

MDoConfigSet

테이블 #17 은 MDoConfigSet() (818) 에 대한 예시적인 정보를 나타낸다.

테이블 #17

설명

특정 컨피규레이션 변수에 대한 값을 설정.

프로토타입

파라미터들

hConfig

[in] MDoConfigOpen() 함수에 의해 리턴된 컨피규레이션 핸들.

pszName

[in] NULL-종결 컨피규레이션 변수명.

pszValue

[int] 특정된 변수에 대한 NULL-종결 신규 컨피규레이션 세팅/값

리턴값

성공이면 0, 그렇지 않으면 -1.

또한 참조.

스캐닝을 용이하게 하는 애플리케이션 프로그램/스캐닝 서브시스템 통신

이미 언급한 바와 같이, 애플리케이션 프로그램은 스캐닝 서브시스템에 의한 스캐닝을 용이하게 하기 위해 스캐닝 서브시스템에 정보를 전달할 수도 있다. 이 통신은 전술한 API 를 통해 용이해질 수도 있다. 전술한 정보는 스캔될 데이터의 유형, 및 이러한 스캐닝과 연관된 타이밍과 관련된다. 이하, 상기 API 가 달성하는 방법에 대해 보다 상세하게 설명한다.

스캔 파라미터들 (SScanParam)

호출 애플리케이션 프로그램은 SScanParam 구조를 사용하여 스캐닝 파라미터를 스캐닝 서브시스템에 제공할 수도 있다. 스캔 파라미터에 포함된 정보는 스캐닝 서브시스템에, 1) 스캐닝 서브시스템 액션 유형 (즉, iAction), 2) 스캔 데이터 유형 (즉, 스캔될 애플리케이션 데이터의 유형-iDataType), 3) 스캔 목표를 가리키는 데이터 포인터 (즉, pPrivate), 4) 데이터 사이즈를 바이트로 검색하는 함수 (즉, pfGetSize), 5) 스캔 데이터를 리사이징하는 (resize) 함수 (즉, pfSetSize), 6) 스캔 데이터의 블록을 검색하기 위해 스캐닝 서브시스템에 의해 사용되는 함수 (즉, pfRead), 7) 스캔 데이터를 기록하기 위해 사용되는 함수 (즉, pfWrite), 및 8) 스캐닝 서브시스템 상태/진행을 보고하기 위한 콜백 함수 (즉, pfCallBack) 를 제공한다.

예시적인 컴퓨터 코드 #4 는 데이터 스캔 파라미터 구조를 나타낸다.

스캔 액션 (iACTION)

스캔 액션은 공급된 애플리케이션 데이터에 대해 수행될 스캐닝의 유형을 특정한다. 테이블 #18은 다양한 예시적인 스캔 액션을 나타낸다.

테이블 #18

스캔 액션 ID	설명
MDO_SA_SCAN_ONLY	스캐닝 서브시스템은 스캐닝을 수행하고 발견된 악성 코드를 보고함. 어떠한 치료도 수행되지 않음.
MDO_SA_SCAN_REPAIR	스캐닝을 수행한 후, 악성 코드를 포함하는 객체는 치료됨.

스캔 데이터 유형 (iDataType)

호출 애플리케이션 프로그램은 애플리케이션 데이터 유형을 스캐닝 서브시스템에 통보할 수도 있고 이 변수를 사용하여 포맷할 수도 있다.

도 13 은, 애플리케이션 프로그램이 API 를 통해 스캐닝 서브시스템과 통신할 수 있는 다양한 예시적인 애플리케이션 데이터 유형 (1300) 을 나타낸다. url-스트링 포맷 (url-string format) 은 URL (Uniform Resource Locators) (RFC 1738) 사양 (specification) 에 따를 수도 있다. 이메일-스트링 포맷은 인터넷 이메일 어드레스 포맷 (RFC 822) 사양에 따를 수도 있다. 디폴트 도메인은 임의의 원하는 도메으로 설정될 수도 있다. 그러나 여전히, 전화 번호 스트링은 숫자 '0' 내지 '9', '#' 및 '*' 문자를 포함할 수도 있다.

스캔 데이터 포인터/핸들 (pPrivate)

애플리케이션 스캔 객체를 가리키는 포인터 (또는 핸들) 가 추가로 제공된다. 스캐닝 서브시스템은, 이 데이터 포인터/핸들을 사용하여 직접 메모리 I/O 를 반드시 수행하는 것은 아니다. 데이터 포인터/핸들은 다시 호출자에게로 패스되어 호출자 특정 I/O 함수들을 사용하여 판독/기록을 수행한다.

스캔 데이터 사이즈 (pfGetSize)

이 함수는, 호출 애플리케이션 프로그램으로부터 스캔 목표 데이터 사이즈 (바이트로) 획득하기 위해 스캐닝 서브시스템에 의해 사용된다.

스캔 데이터 리사이즈 (pfSetSize)

이 함수는, 치료중이고/클리닝중인 애플리케이션 데이터를 소정의 (바이트로) 리사이징하도록 호출 애플리케이션 프로그램에 요청하기 위해, 스캐닝 서브시 스템에 의해 사용된다. 이 함수는 스캔-앤-치료/삭제 옵션과 연계하여 사용될 수도 있다.

스캔 데이터 판독 함수 (pfRead)

이 인스턴트 함수는 호출 애플리케이션 프로그램으로부터 애플리케이션 데이터의 특정량을 판독하기 위해 스캐닝 서브시스템에 의해 사용될 수도 있다.

스캔 데이터 기록 함수 (pfWrite)

이것은, 치료 프로세스의 일부로서 애플리케이션 데이터의 특정량을 스캔 객체 (scan object) 에 기록하기 위해 스캐닝 서브시스템에 의해 사용될 수도 있는 옵션적인 파라미터이다. 스캔-액션이 치료 또는 삭제로 설정된 경우, 함수 포인터가 설정될 수도 있다.

콜백 함수 (pfCallBack)

특정된다면, 스캐닝 서브시스템은 하기 테이블에서 설명된 정보를 갖는 특정 함수를 호출한다. 만약 네가티브 리턴값을 가지고 리턴되면, 콜백 함수는 스캐닝 프로세스를 중단한다 (abort). 테이블 #19 는 예시적인 콜백 코드 리스트를 설명한다.

테이블 #19

콜백 이유 Reason ID	설명
MDO_CB_DETECTED	악성 코드가 스캔 목표에서 탐지된 호출 애플리케이션 프로그램을 보고함. 콜백 데이터 독립변수 'arg' 는 SCBArg 구조를 가리키는 포인트에 설정됨.
MDO_CB_CLEAN_READY	식별된 멀웨어가 클리닝/치료준비가 된 호출 애플리케이션 프로그램을 보고함. 콜백 데이터 독립변수 'arg' 는 SCBArg 구조를 가리키는 포인트에 설정됨.

예시적인 컴퓨터 코드 #5 는 스캐닝 서브시스템 콜백 구조를 나타낸다.

스캔 결과 (SScanResult)

객체 스캐닝의 결과인 탐지된 멀웨어 정보는, 호출 애플리케이션 프로그램에 의해 제공된 SScanResult 구조의 호출 애플리케이션 프로그램에 리턴된다. SScanResult 구조는 스캔 결과 정보를 포함하는 구조를 가리키는 포인터 및 스캔 결과 자원을 제거하는데 사용되는 함수를 가리키는 포인터를 포함한다. 스캔 결과를 유지하는데 사용되는 메모리는 스캐닝 서브시스템에 의해 할당되며, pfDeleteResult 포인터에 의해 지시된 함수를 호출함으로써 자유로워진다 (freed).

예시적인 컴퓨터 코드 #6 은 샘플 호출 시퀀스를 나타낸다.

예시적인 컴퓨터 코드 #7 은 탐지된 악성 코드/컨텐츠 정보 구조를 나타낸다.

예시적인 컴퓨터 코드 #8 은 스캔 결과 구조를 나타낸다.

시베러티 클래스 및 비헤이비어 레벨 (uBehavior)

도 14 는 하나의 예시적인 실시형태에 따른, SDetect 구조에서 포함된 애플리케이션 프로그램 비헤이비어 레벨 및 멀웨어 시베러티 플래그 (malware severity flag) 를 포함하는 비트-필드 변수 (1400) 을 나타낸다.

테이블 #20 은 예시적인 멀웨어 시베러티 클래스 리스트를 설명한다.

테이블 #20

시베러티 플래그	설명
MDO_SC_USER	탐지된 멀웨어는 사용자에게 해로움.
MDO_SC_TERMINAL	탐지된 멀웨어는 디바이스에 해로움.

스캔된 애플리케이션 데이터가 이동 통신 디바이스의 사용자에게 해로운 멀웨어를 포함하고 있는 경우, 스캐닝 서브시스템은 MDO_SC_USER 플래그를 설정한다. 스캔된 애플리케이션 데이터가 이동 통신 디바이스 그 자체에 해로운 경우, MDO_SC_TERMINAL 플래그가 설정된다. 사용자와 이동 통신 디바이스 양자에 해로운 경우에는, MDO_SC_USER 플래그 및 MDO_SC_TERMINAL 플래그가 설정된다.

애플리케이션 프로그램 비헤이비어 레벨은 탐지된 멀웨어를 포함하는 애플리케이션 데이터를 어떻게 처리하는지를 명기한다. 테이블 #21 은 비헤이비어 레벨 값들과 애플리케이션 프로그램에 의한 대응 액션들을 나타낸다.

테이블 #21

비헤이비어 레벨	설명
MDO_BC_LEVEL0	경고 상태로 프로세싱함. 이 시베러티 레벨은 이미 악성인것으로 고려된 데이터에 할당될 수도 있음.
MDO_BC_LEVEL1	프로세싱전에 사용자에게 프롬프트함. 그/그녀가 애플리케이션이 데이터를 프로세싱하기를 원하는지를 사용자에게 질의함.
MDO_BC_LEVEL2	데이터를 프로세싱하지 않음
MDO_BC_LEVEL3	데이터를 프로세싱하지 않고 제거를 위해 사용자에게 프롬프트함. 컨텐츠가 디바이스상에 저장된 경우, 제거전에 허락을 위해 사용자에게 프롬프트함.
MDO_BC_LEVEL4	저장된 경우 데이터를 프로세싱하지 않고 자동적으로 제거함.

스캔된 애플리케이션 데이터에서 다수의 악성 코드가 발견되는 경우, 호출 애플리케이션 프로그램은 가장 높은 비헤이비어 레벨로 동작하는 것으로 예상된다. 예를 들어, MDO_BC_LEVEL0 및 MDO_BC_LEVEL3 양자 모두가 보고되면, 애플리케이션 프로그램은 MDO_BC_LEVEL3 액션을 취할 수도 있다.

도 15 는 스캐닝 서브시스템에 의한 스캐닝 타이밍이 도 13 의 변수들을 통해 식별된 데이터 유형의 함수로서 변화하는 방식을 설명하는 도표 (1500) 를 나타낸다.

서명 데이터베이스 업데이트

이미 언급한 바와 같이, 업데이트 프로세스는 이동 통신 프레임워크들에 고유의 한정 대역폭을 수용하기 위해 유선형이 될 수도 있다. 이하, 이것이 달성될 수도 있는 다양한 방식에 대한 보다 많은 정보를 설명한다.

업데이트 컴포넌트

MDoScanUpdate 함수는 2 개의 컴포넌트[즉, 악성 코드 탐지 로직 (mdo.pd) 및 서명 데이터베이스 (mdo.sdb)] 에 업데이트 서비스를 제공한다. 하나의 컴포넌트 (즉, mdo.pd) 는 탐지 로직을 포함할 수도 있고 새로운 버전이 이용가능한 때에는 완전히 업데이트될 수도 있다. 또 다른 컴포넌트 (즉, mdo.sdb) 는 n 개의 이전 버전들 (previous version) 까지 증가하면서 업데이트될 수도 있다. 또 다른 컴포넌트에 대한 완전한 업데이트는 n 보다 더 오래된 버전들을 갖는 이동 통신 디바이스들상에서 수행될 수도 있다. 예를 들어, n 이 5 로 설정되고 가장 최근의 버전이 20 인 경우, 완전한 업데이트가 15 보다 더 오래된 버전을 갖는 이동 통신 디바이스상에서 수행된다.

사용자 인터페이스를 통한 활성화 (Activation via User Interface)

도 16 은 일 실시형태에 따른, 사용자 인터페이스에 의해 업데이트가 시작되는 방식을 설명하는 예시적인 흐름 (1600) 을 나타낸다. 도시된 바와 같이, 사용자 인터페이스 (1602) 를 통해 메뉴 엔트리를 선택함으로써 이동 통신 디바이스 사용자에 의해 바이러스 패턴 업데이트가 시작된다. 일단 사용자가 업데이트 메뉴를 선택하면, 업데이트 애플리케이션 (1604) 이 활성화되고 적절한 업데이트 인터페이스 함수 (1606) 을 통해 백엔드 서버에 접속된다.

통신 프로토콜

업데이트 라이브러리는 HTTP 프로토콜을 통해 백엔드 서버와 통신할 수도 있다.

업데이트 프로세스

도 17 은 일 실시형태에 따른, 이동 통신 디바이스의 스캐닝 서브시스템을 효과적으로 업데이트하는 방법 (1700) 을 나타낸다. 일 실시형태에서, 이 방법 (1700) 은 애플리케이션 프로그램, 스캐닝 서브시스템, 도 3 의 아키텍처 (300) 의 운영 시스템 및 도 1과 도 2 의 시스템들의 맥락에서 구현될 수도 있다. 그러나, 이 방법 (1700) 은 임의의 원하는 맥락에서 구현될 수도 있다.

프로세스를 시작하기 위해, 업데이트 요청이 하나 이상의 이동 통신 디바이스로부터 백엔드 서버로 전송될 수도 있다. 물론, 다른 실시형태에서, 업데이트는 요청없이 전송될 수도 있다.

일 실시형태에서, 요청 데이터 구조를 사용하여 이동 통신 디바이스에 의해 업데이터가 요청될 수도 있다. 옵션으로, 이러한 데이터 구조는 URL 변수, 이동 통신 식별자 변수, 애플리케이션 프로그램 인터페이스 버전 변수, 탐지 로직 변수, 서명 버전 변수, 및/또는 포션 넘버 (portion number) 변수와 같은 변수들을 포함할 수도 있다.

테이블 #22 는 이러한 목적에 사용될 수도 있는 예시적인 URL 을 나타낸다.

테이블 #22

아래는 상기 URL 변수들을 설명하는 테이블이다.

변수	설명
<BASE-URL>	MDoConfigGet 함수를 사용하여 획득된 업데이트 서버 URL (섹션 0 참조)
<DEV-ID>	AlDevGetInfo 함수에 의해 리턴된 이동 통신 디바이스 식별자
<MDO-VER>	MDo API 버전
<ENG-VER>	탐지 로직, mdo.pd, version
<SDB-VER>	서명 데이터베이스, mdo.sdb, version
<CHUNK>	업데이트 패키지 청크, 또는 포션, 넘버; 초기 하나(=1)

테이블 #23 은 상기 설명을 따르는 URL 의 특정 예를 나타낸다.

테이블 #23

상기 테이블 #23 의 URL 은 베이스-URL "http://update.mcafeeacsa. com/504i", 디바이스 식별자로서의 "X504i05", API 버전 2, 악성 코드 탐지 로직 버전 3 및 서명 데이터베이스 버전 56 을 명기한다. 이동 통신 디바이스가 초기에 백엔드 서버와 접속할 때, "청크(chunk)" 또는 포션 넘버는 1 로 설정될 수도 있다. 또한, 베이스-URL 은 "UpdateURL" 컨피규레이션 변수를 사용하는 MDoConfigGet API 를 사용하여 획득될 수도 있다.

요청을 수신한 후에, 백엔드 서버는, 저장된 악성 코드 탐지 로직 및 서명 데이터베이스 버전들을, URL 에서 인코딩된 버전 정보와 비교함으로써, 어떤 업데이트 패키지가 다운로드될 필요가 있는지를 결정한다.

업데이트가 필요없는 경우, 백엔드는 컨텐츠가 없는 응답을 리턴한다. 동작 1701 에서, 이동 통신 디바이스는 제 1 포션으로서 응답을 수신한다. 제 1 포션이 전술한 컨텐츠가 없는 응답을 포함하고 있는 것으로 결정된 경우 (결정 1702), 다운로드할 업데이트가 없기 때문에 방법 (1700) 은 종료한다. 이러한 특징은 이동 통신 프레임워크에서의 고유의 한정 대역폭을 수용하는데 유익하다.

한편, 업데이트 패키지의 제 1 포션이 리턴되는 경우, 방법 (1700) 은 업데이트의 제 1 포션의 수신에 후속하는 (또는 아마도 병렬인) 업데이트의 추가 포션들을 수신함으로써 계속된다. 동작 1704 내지 동작 1708 을 참조한다. 제 1 포션은 전체 패키지 사이즈 및 포션 카운트 정보를 수반할 수도 있다.

남아있는 업데이트 포션들을 다운로드하기 위해, 다운로드 URL 의 포션 넘버는 수정될 수도 있다. 테이블 #24 는 포션 넘버 "3" 을 특정하는 URL 의 특정 예이다.

테이블 #24

일 실시형태에서, 업데이트의 무결성 (integrity) 이 결정될 수도 있다. 따라서, 업데이트의 무결성이 확증되었는지에 기초하여, 스캐닝 서브시스템을 통해 조건부적으로 업데이트가 설치될 수도 있다.

옵션으로서, 서명을 이용하여 업데이트 무결성이 판정될 수도 있다. 이러한 서명은 업데이트의 포션들중 하나의 포션 (즉, 최종 포션) 과 함께 수신될 수도 있다. 그 후, 서명은, 업데이트의 포션들 각각을 이용하여, 생성된 다른 서명과 비교될 수도 있다. 동작 1710 을 참조한다.

일 실시형태에서, 서명은, RSA 개인키 (RSA private key) 를 사용하여 생성될 수도 있고, 업데이트에 포함된 대응 공개 키 (public key) 를 사용하여 이동 통신 디바이스상에서 인증될 (authenticated) 수도 있다. 이 서명 확증 및 생성은 특정 인증 라이브러리를 사용하여 추가로 수행될 수도 있다.

무결성이 확증된 것으로 가정하면, 스캐닝 서브시스템에 의해 수행된 임의의 스캐닝은 중지 또는 휴지된다. 동작 1712 를 참조한다. 이러한 중지는 옵션적이다.

다음으로, 스캐닝 서브시스템을 통해 업데이트가 설치될 수도 있다. 동작 1714 를 참조한다. 임의의 스캐닝이 중지된 실시형태에서, 업데이트가 스캐닝 서브시스템을 통해 설치되는 즉시, 스캐닝 서브시스템을 이용하여 스캐닝이 후속적으로 재개될 수도 있다. 동작 1716 을 참조한다.

이동 통신 프레임워크에서의 고유의 한정 대역폭을 수용하기 위해, 업데이트의 각 포션의 사이즈는 최소화로 될 수도 있다. 또한, 업데이트의 포션들은 압 축될 수도 있다.

또 다른 실시형태에서, 업데이트 각 포션의 포맷은 이동 통신 프레임워크에서의 고유의 한정 대역폭을 수용하기 위해 설계될 수도 있다. 이하, 이러한 포맷에 대해 더 많은 정보를 설명한다.

테이블 #25 는 업데이트의 포션들을 다운로드하기 위한 예시적인 포맷을 나타낸다.

테이블 #25

테이블 #25 에서 설명된 전술한 파트들 (parts) 의 각각은 테이블 #26 에서 다음과 같이 정의된다.

테이블 #26

각 파트는 헤더 (header) 와 데이터로 이루어진다. 이러한 헤더는 업데이트의 연관된 포션의 식별자, 업데이트의 연관된 포션의 길이 등을 나타낼 수도 있다. 또한, 헤더는 포함된 데이터 명칭 및 길이를 특정할 수도 있고, 여분의 CR+LF 쌍을 갖는 실제 데이터로부터 분리될 수도 있다. 테이블 #27 은 헤더와 연관된 예시적인 데이터 명칭/컨텐츠 명칭을 설명한다.

테이블 #27

컴포넌트 명칭	설명
"pd"	탐지 로직
"sdb"	서명 데이터베이스 업데이트

테이블 #28 은 예시적인 업데이트 패키지를 나타낸다.

테이블 #28

애브스트랙트 라이브러리 API

이미 언급된 바와 같이, 플랫폼-독립 시스템 및 연관 방법은 이동 통신 디바이스와의 사용을 위해 제공된다. 스캐닝 목적으로 이동 통신 디바이스의 운영 시스템과 통신하는 플랫폼-독립 스캐닝 서브시스템이 포함된다. 운영시스템과 스캐닝 서브시스템을 인터페이싱하기 위한 플랫폼-독립 애플리케이션 프로그램 인터페이스가 추가로 제공된다. 플랫폼-독립 애플리케이션 프로그램 인터페이스는, 플랫폼-독립 스캐닝 서브시스템을 이동 통신 디바이스 및 연관 운영 시스템에 포팅시키는 (porting) 애브스트랙트 라이브러리를 포함한다.

이 설계에 의해, 스캐닝 서브시스템은 플랫폼-독립적일 수도 있어, 운영 시스템/이동 통신 디바이스 조합의 임의의 유형으로 구현될 수 있다.

일 실시형태에서, 애브스트랙트 라이브러리는 시스템 초기화, 라이브러리 초기화, 에러 함수, 메모리 할당, 입력/출력 (I/O), 데이터 인증, 동기화, 하이퍼텍스트 전달 프로토콜, 공유 메모리, 시스템 타임, 디바이스 정보, 및 디버깅을 지원할 수도 있다. 전술한 애플리케이션 프로그램 인터페이스의 하나의 옵션적 구현예와 관련된 보다 많은 예시적인 정보가 부록 A 에서 설명된다.

다양한 실시형태가 전술되었지만, 이 실시형태는 한정이 아닌 단지 예로서 제시되었을 뿐이다. 따라서, 바람직한 실시형태의 폭과 범위가 전술한 예시적인 실시형태들 중 어떤 실시형태로서 한정되어서는 아니되고 다음의 청구항들과 이들의 균등물에 따라서만 정의되어져야 한다.

부록 A

이 애플리케이션 프로그램 인터페이스 (API) 는 다음의 서브시스템을 포함한다.

시스템 동기화

라이브러리 동기화

에러 함수들

히프 메모리 할당

영속 메모리/스토리지I/O

데이터 인증

동기화 객체(세마포어)

HTTP API

공유 메모리

시스템 타임

디바이스 정보

디버깅

또한, 부록 A 에서는, API 라이브러리용의 애브스트랙션 라이브러리 (AL) 층에서 정의된 일련의 C-언어 정의(들) 이 설명된다.

시스템 초기화

플랫폼/시스템 의존 부트 초기화는 AlLibrarySysInit() 함수에 의해 수행된다. 이 함수는 이미 설명한 MDoSystemInit() 함수로부터 호출되도록 설계된다.

AlLibrarySysInit

설명

시스템 의존 초기화를 수행함.

프로토타입

파라미터들

없음

리턴값

성공이면 0, 그렇지 않으면 -1.

라이브러리 초기화

플랫폼 애브스트랙션 API 라이브러리는 AlInitLibrary() 함수를 사용하여 초기화된다. 애브스트랙션 라이브러리는, 애브스트랙션 API 함수가 호출되기 전에 한번 초기화된다. AlInitLibrary() 에 의해 획득되고 초기화된 시스템 자원은, AlCleanupLibrary() 함수가 호출될 때 릴리즈된다.

AlInitLibrary

설명

라이브러리 초기화를 수행함. 이 함수는 MDoLibraryOpen() 함수에 의해 호출됨.

프로토타입

파라미터들

없음

리턴값

성공이면 0, 그렇지 않으면 -1.

AlCleanupLibrary

설명

AlInitLibrary() 함수에 의해 획득된 시스템 자원을 릴리즈함. 이 함수는 이미 특정된 MDoLibraryClose() 함수에 의해 호출됨.

프로토타입

파라미터들

없음

리턴값

없음

에러 함수

태스크/스레드 (task/thread) 특정 에러 코드를 설정하고 검색하는데 사용되는 에러 함수 세트가 AL 라이브러리에 포함된다. 적절한 에러 코드와 컴포넌트 코드를 설정하는 것은 애브스트랙션층 임플리멘터 (implementer) 의 담당이다.

AlGetLastError

설명

호출 태스크/스레드의 최종-에러 코드값을 리턴함. 함수는 AlSetLastError() 함수를 사용하여 리턴값을 설정함.

AlErrorCode 데이터 유형은 32 비트 미서명값을 이용하여 내부적으로 표현됨.

프로토타입

파라미터들

없음

리턴값

호출 스레드/태스크의 최종-에러값은 AlSetLastError() 함수를 사용하여 설정함.

AlSetLastError

설명

호출 스레드/태스크에 대해 최종-에러 코드를 설정함.

프로토타입

파라미터들

errorCode

[in] 32-비트 에러 코드값

리턴값

없음

에러/상태 코드들

상기 테이블은 AL 컴포넌트 코드 및 에러 코드의 세트를 나열한다. AlSetLastError 함수를 사용하여 보고되는 에러는 컴포넌트 코드와 에러 코드를 조합함으로써 형성된 32 비트값이다. AL 레벨로 설정된 에러가, 에러가 발생하는 경우 적절한 조치를 취하기 위해 MDoGetLastError 함수를 사용하여 검색된다.

히프 메모리 할당

애브스트랙션층은, 동적으로 필요 메모리를 할당하기 위해 호출 애플리케이션 프로그램 (즉, 호출자) 에 히프 메모리 할당 API 를 제공한다. 할당된 메모리는 글로벌적으로 공유가능하여 멀티플 애플리케이션/태스크에 의해 액세스될 수 있다고 가정한다. AlMemAlloc() 및 AlMemFree() API 함수는 히프 메모리의 할당 및 반환 (deallocation) 을 제공한다.

함수	설명
void^*AlMemAlloc(unsigned int uSize)	동적 메모리 블록을 할당함
void AlMemFree(void^*ptr)	AlMemAlloc 을 사용하여 할당된 프리 메모리

AlMemAlloc

설명

동적 메모리의 특정량을 할당하고 포인터를 그 메모리로 리턴시킴. 할당된 메모리 블록은 특정 동작 (즉, 메모리 락킹 (memory locking)) 을 요구하는 것 없이 호출자 (즉, 호출 애플리케이션 프로그램) 에 의해 직접 액세스가능함.

프로토타입

파라미터들

uSize

[in] 바이트로 할당하기 위한 메모리량

리턴값

할당된 메모리를 가리키는 포인터. 요청이 실패하거나 또는 요청 사이즈가 0 이면, NULL.

또한 참조

ALMemFree()

AlMemFree

설명

AlMemAlloc() 함수에 의해 리턴된 동적 메모리 블록을 해제시킴 (free).

프로토타입

파라미터들

pData

[in] 해제되는 메모리 블록을 가리키는 포인터

리턴값

없음

또한 참조

AlMemAlloc()

영속 스토리지 I/O (Persistent Storage I/O

영속 스토리지 (즉, 플래시 메모리) 액세스가 파일 I/O API 를 사용하여 수행된다. 아래를 참조한다.

파일 핸들 타입 AL_FILE_HANDLE 은,

로서 정의된다.

그리고 무효 영속 스토리지 핸들을 설명하는데 사용되는 상수 INVALID_AL_FILE_HANDLE 은,

로서 정의된다.

파일 상태 버퍼 타입 AlStatBuf 는,

로서 정의된다.

AlFileOpen

설명

특정 파일을 개방하고 그것의 핸들을 리턴함.

프로토타입

파라미터들

iMode

[in] 파일 엑세스 모드

AL_OPEN_READ 판독하기 위해 파일 개방

AL_OPEN_WRITE 판독 및 기록하기 위해 파일 개 방

리턴값

성공이면 파일 핸들, 그렇지 않으면 INVALID_AL_FILE_HANDLE.

또한 참조

AlFileClose

설명

특정된 파일 핸들과 연관된 시스템 자원을 폐쇄하고 릴리즈함.

프로토타입

파라미터

hFile

[in] AlFileOpen() 에 의해 리턴된 파일 핸들

리턴값

없음

또한 참조

AlFileSeek

설명

판독/기록 파일을 리포지션함.

프로토타입

파라미터

hFile

[in] 개방 파일 핸들.

iOffset

[in] iWhence 지시어 (directive) 와 관련된 파일 오프셋.

iWhence

[in] 초기 위치. 가능값들은 다음과 같다.

AL_SEEK_SET 오프셋 파라미터는 절대적 파일 오프셋을 특정함. 즉, 파일의 시작에서의 오프셋.

AL_SEEK_CUR 상대적 오프셋을 특정함-오프셋 파라미터는 현재의 파일 오프셋으로부터 파일 오프셋을 특정함.

AL_SEEK_END 파일의 종단에서의 파일 오프셋을 특정함.

리턴값

성공이면 결과로 생기는 파일 오프셋, 그렇지 않으면 -1L.

또한 참조

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

AlFileRead

설명

파일로부터 데이터 블록을 판독.

프로토 타입

파라미터

hFile

[in] 개방 파일 핸들.

pBuffer

[out] 데이터 버퍼.

uSize

[out] 판독할 데이터량.

리턴값

성공이면 바이트들의 넘버 판독, 그렇지 않으면 -1

또한 참조

AlFileWrite

설명

데이터 블록을 파일에 기록.

프로토타입

파라미터

hFile

[in] 개방 파일 핸들

pBuffer

[int] 기록할 데이터를 유지하는 버퍼.

uSize

[out] 기록할 데이터량

리턴값

성공이면 기록된 데이터량, 그렇지 않으면 -1.

또한 참조

AlFileSetSize

설명

개방 파일을 리사이즈함.

고유 파일 리사이즈 지원이 없는 플랫폼에 대해, 애브스트랙션 라이브러리는, AlFileClose() 함수가 호출되는 경우 각각의 파일의 처음에 저장된 사이즈 정보를 변경함으로써 이 기능성을 구현함.

프로토타입

파라미터

hFile

[in] 기록-모드를 통해 개방 파일을 레프런싱하는 (referencing) 핸들.

uSize

[out] 신규 파일의 바이트 길이.

리턴값

성공이면 0, 그렇지 않으면 -1.

또한 참조

AlFileStat()

AlFileStat

설명

파일 사이즈 및 생성 타임스탬프 검색.

고유 파일 사이즈 및/또는 타임스탬프 정보 검색 방법을 제공하지 않은 플랫폼에 대해, 애브스트랙션 라이브러리는, 각각의 파일의 처음에 정보를 저장함으로써 이 함수를 구현함.

프로토타입

파라미터

pszFilename

[in] 정보를 검색하기 위한 파일명

pStat

[out] 사이즈 및 타임스탬프 정보를 리턴하는데 사용되는 구조를 가리키는 포인터. 그 구조는 다음의 필드들을 포함함.

리턴값

성공이면 0, 그렇지 않으면 -1.

데이터 인증

플랫폼 애브스트랙션 API 에는 데이터를 인증하는 함수 세트가 포함된다. 데이터 인증 API 는 다운로드된 멀웨어 서명 데이터베이스를 확증하는데 사용된다.

일단 호출자가 AlDaOpen 함수를 사용하여 인증 객체 핸들을 획득하면, 제공된 데이터를 확증하기 위해 AlDaVerify 의 호출이 이루어진다. AlDaGetSignerInfo() 은 서명자 정보를 검색하는데 사용된다. AlDaClose() 는 데이터 인증 핸들 및 관련 시스템 자원을 폐쇄하고 릴리즈하는데 사용된다. 아래는 예시적인 데이터 인증 API 이다.

AlDaOpen () 함수에 의해 리턴된 데이터 인증 핸들은,

로서 정의된다.

서명자 정보 구조는,

로서 정의된다.

AlDaOpen

설명

데이터 인증 핸들을 생성 및 리턴함.

프로토타입

파라미터들

pSig

[in] 서명 데이터를 가리키는 포인터.

uSigSize

[in] 서명 바이트 크기.

리턴값

성공이면 데이터 인증 핸들, 그렇지 않으면 INVALID_AL_DA_HANDLE.

또한 참조

AlDaClose

설명

데이터 인증 핸들에 사용되는 시스템 자원을 릴리즈함.

프로토타입

파라미터들

hDa

[in] AlDaOpen 에 의해 리턴된 데이터 인증 핸들.

리턴값

없음

또한 참조

AlDaVerify

설명

데이터 인증을 수행함.

프로토타입

파라미터들

hDa

[in] 데이터 인증 핸들.

pfReed

[in] 데이터를 판독용 호출자 콜백 함수 (참조). 에러의 경우 -1 을 리턴하고 판독할 데이터가 더이상 없는 경우 0 을 리턴하며, 그렇지 않고 판독된 데이터량이 있는 경우, AlDaVerify 함수로 리턴됨. 함수가 여러번 호출될 것으로 예상됨.

iTotalSize

[in] 확증될 전체 데이터 사이즈.

pPrivate

[in] pfRead 콜백에 의해 패싱될 호출자 개인 데이터.

리턴값

애플리케이션 데이터가 인증되면 0, 그렇지 않으면 -1.

또한 참조

아래는 샘플 데이터 판독 콜백 함수이다.

AlDaGetSignerInfo

설명

데이터 인증 서명자 정보를 검색함.

프로토타입

파라미터들

hDa

[in] 데이터 인증 핸들.

pDSI

[out] 서명자 정보를 포함하는 구조를 가리키는 포인터.

리턴값

서명자 정보가 성공적으로 획득되면 0, 그렇지 않으면 -1.

또한 참조

동기화 객체

세마포어 (semaphore) 를 사용하여 자원 동기화 및 제어가 행해진다. 애브스트랙션 라이브러리에는 세마포어 객체를 생성, 개방, 폐쇄 및 변경시키는 함수 세트가 포함된다. 아래에는 예시적인 세마포어 API 이다.

AlSemCreate

설명

지정된 세마포어를 생성하고 내부 카운터를 0 으로 설정하며, 그것의 핸들을 리턴함.

프로토타입

파라미터들

pszName

[in] 세마포어명 스트링 ([in] Semaphore name string).

리턴값

성공이면 세마포어 핸들, 그렇지 않으면 INVALID_AL_SEM_HANDLE.

또한 참조

AlSemOpen

설명

핸들을 기존의 세마포어로 리턴함.

프로토타입

파라미터들

pszName

[in] 세마포어명.

리턴값

성공이면 세마포어 핸들, 그렇지 않으면 INVALID_AL_SEM_HANDLE.

또한 참조

AlSemCreate(), AlSemClose(), AlSemGet(), AlSemRelease()

AlSemClose

설명

특정 세마포어 핸들과 연관된 시스템 자원을 폐쇄 및 릴리즈함. 또한, 세마포어 사용/레퍼런스 카운트가 감소되고, 만약 카운트가 0 에 도달하면 그 레퍼런스 세마포어 객체는 파기됨.

프로토타입

파라미터들

hSem

[in] AlSemCreate() 또는 AlSemOpen() 를 사용하여 획득된 세마포어 핸들.

리턴값

없음

또한 참조

AlSemGet

설명

특정 세마포어를 획득함. 내부 카운터가 엔트리에서 0 보다 더 크면, 1 만큼 감소되고 즉시 리턴됨. 내부 카운터가 엔트리에서 0 이면, 다른 태스크/스레드가 카운터를 0 보다 더 크게 하기 위해 AlSemRelease() 를 호출할 때까지, 호출은 차단됨.

프로토타입

파라미터들

hSem

[in] 세마포어 핸들.

리턴값

성공이면 0, 그렇지 않으면 -1.

또한 참조

AlSemRelease

설명

내부 카운터를 1 만큼 증가시키면서, 세마포어를 릴리즈함.

프로토타입

파라미터들

hSem

[in] 세마포어 핸들.

리턴값

성공이면 0, 그렇지 않으면 -1.

또한 참조

HTTP API

애브스트랙센 라이브러리에는 호출자 제공 콜백 구조를 이용하여 HTTP 네트워크 I/O 를 제공하는 함수 세트가 포함된다. 아래는 예시적인, HTTP API이다.

AlHttpOpen() 함수 에 의해 리턴된 HTTP 핸들은,

로서 정의된다.

HTTP 콜백 구조 AlHttpCallbacks 은,

로서 정의된다.

상기 HTTP 콜백 구조에서 주어진 콜백 함수는 다음의 기능성들을 제공한다.

pWrite 입력되는 HTTP 요청 데이터를 저장하기 위해 시스템 HTTP 라이브러리에 의해 호출됨.

pRead HTTP 요청의 파트로서 전송될 애플리케이션 데이터를 검색하는데 사용됨.

pGetSize HTTP 라이브러리에 애플리케이션 컨텐츠 데이터 사이즈, ,"Content-Length"를 제공함.

pSetSize 이용가능한 경우, 입력되는 컨텐츠 데이터 길이를 호출 애플리케이션에 통지하도록 HTTP 라이브러리에 의해 호출 됨.

AlHttpOpen

설명

핸들을 생성하여 HTTP 라이브러리에 리턴함.

프로토타입

AL_HTTP_HANDLE AlHttpOpen(void);

파라미터들

없음

리턴값

HTTP 인스턴스를 생성하는데 실패하면 INVALID_AL_HTTP_HANDLE 이 리턴됨.

또한 참조

AlHttpClose()

AlHttpClose

설명

HTTP 핸들과 연관된 시스템 자원들을 폐쇄하고 릴리즈함.

프로토타입

파라미터들

hHTTP

[in] AlHttpOpen()함수에 의해 리턴된 HTTP 라이브러리 핸들.

리턴값

없음

또한 참조

AlHttpClose()

AlHttpExec

설명

옵션적인 헤더 정보를 이용하여 특정 URL 상에서 HTTP 메소드 ("GET" 또는"POST") 를 실행함.

프로토타입

파라미터들

hHTTP

[in] AlHttpOpen()함수에 의해 리턴된 HTTP 라이브러리 핸들.

pszMethod

[in] HTTP 메소드 사양. HTTP "GET" 또는 "POST".

pszURL

[in] HTTP 요청이 이루어진 URL.

pHttpCb

[in] 호출자 특정 HTTP I/O 함수 세트를 가리키는 포인터. HTTP 라이브러리는 데이터 I/O 용 AlHttpCallbacks 구조에서 특정된 함수들을 사용함.

pPrivate

[in/out] AlHttpCallbacks 구조에서 특정된 콜백 함수들로 역으로 패스될 호출자 데이터를 가리키는 포인터.

리턴값

성공이면 0, 그렇지 않으면 -1.

또한 참조

공유 메모리

라이브러리의 공유 객체들이 저장된 시스템 메모리의 위치는 AlShmAddress() 함수를 사용하여 획득된다. 이 공유 정보 영역은 디바이스 부트 타임에서 할당/준비되고 라이브러리의 상이한 인스턴스들에 의해 레퍼런스된다 (referenced).

AlShmAddress

설명

공유 메모리 어드레스를 린턴함.

프로토타입

파라미터들

없음

리턴값

성공이면 공유 메모리 어드레스, 그렇지 않으면 NULL.

시간

AlTmGetCurrent() 는 호출자에게 현재 시스템 시간을 초단위로 (in seconds) 제공한다.

AlTmGetCurrent

설명

현재 시스템 시간을 획득함.

프로토타입

unsigned long AlTmGetCurrent (void);

파라미터들

없음

리턴값

성공시에는, 시간 기점 (Epoch) (1970년 1월 1일, UTC에서의 00:00:00) 이후 의 초단위의 시간. 에러시에는, ((unsigned long)-lL) 이 리턴됨.

디바이스 정보

AlDevGetInfo

설명

다바이스 사양 정보를 검색함. 이 함수에 의해 리턴된 디바이스 식별 스트링은 API 에 의해 사용됨.

프로토타입

파라미터들

pDeviceInfo

[out] 디바이스 정보를 가리키는 포인터.

AlDeviceInfo 구조는,

로서 정의됨.

식별 스트링 szDeviceID 는, 특정의 이동 통신 디바이스를 다른 모든 것으로부터 고유하게 식별하는데 사용되는 고유 터미널/디바이스 식별자 (unique terminal/device identifier) 임. 이 정보는 이동 통신 디바이스용 멀웨어 서명 다운로드 URL 을 구성하는데 사용됨. URL 에서 허락되지 않은 임의의 문자 (character) (즉, 화이트 스페이스) 를 포함해서는 안됨.

리턴값

성공이면 0, 실패면 -1.

디버깅

AlDbgOutput

설명

디버그 스트링을 디버그 컨솔 (debug console) 로 출력함. 이 함수는 릴리즈 빌드용 널 함수 (null function for release build) 임.

프로토타입

파라미터들

pszOutput

[in] 디버그 컨솔로 출력되는 스트링.

리턴값

성공이면 0, 실패면 -1.

Claims

이동 통신 디바이스를 이용하여 애플리케이션 프로그램 데이터를 스캐닝하는 시스템으로서,

무선 네트워크를 통해 통신할 수 있는 이동 통신 디바이스상에 설치되고, 상기 이동 통신 디바이스를 이용하여 태스크들을 수행하는데 적합한 애플리케이션 프로그램; 및

상기 애플리케이션 프로그램과 통신하여, 상기 애플리케이션 프로그램에 의해 수행되는 상기 태스크들과 관련된 애플리케이션 데이터를 스캐닝하는 스캐닝 서브시스템을 포함하고,

상기 애플리케이션 프로그램은, 상기 스캐닝 서브시스템에 의한 상기 스캐닝을 용이하게 하기 위해, 상기 애플리케이션 데이터와 관련된 정보를 상기 스캐닝 서브시스템에 통신하는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 1 항에 있어서,

상기 스캐닝은 온-디멘드 (on-demand) 바이러스 스캐닝을 포함하는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 1 항에 있어서,

상기 스캐닝은 온-액세스 (on-access) 바이러스 스캐닝을 포함하는, 애플리 케이션 프로그램 데이터 스캐닝 시스템.
제 1 항에 있어서,

상기 애플리케이션 프로그램은 메일 애플리케이션 프로그램을 포함하고, 상기 태스크들은 전자 메일을 관리하는 것을 포함하는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 1 항에 있어서,

상기 애플리케이션 프로그램은 브라우저 애플리케이션 프로그램을 포함하고, 상기 태스크들은 네트워크를 브라우징하는 것을 포함하는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 1 항에 있어서,

상기 애플리케이션 프로그램은 전화 번호부 애플리케이션 프로그램을 포함하고, 상기 태스크들은 복수의 전화 번호를 관리하는 것을 포함하는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 1 항에 있어서,

상기 애플리케이션 프로그램은 메시지 애플리케이션 프로그램을 포함하고, 상기 태스크는 메시지를 통신하는 것을 포함하는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 1 항에 있어서,

상기 애플리케이션 프로그램은 자바 애플리케이션 프로그램 (JAVA application program) 을 포함하는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 1 항에 있어서,

상기 이동 통신 디바이스는 셀룰러 전화기를 포함하는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 1 항에 있어서,

상기 정보는 상이한 유형들의 애플리케이션 데이터와 관련된, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 10 항에 있어서,

상기 유형들은 하이퍼텍스트 생성 언어 (HTML)-유형 (hypertext mark-up language (HTML)-type), URL-유형 (uniform resource locator (URL)-type), 전자 메일-유형, 전화 번호-유형, 자바-유형, 텍스트-유형 및 미지의 유형으로 이루어지는 그룹에서 선택되는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 10 항에 있어서,

상기 유형들은 하이퍼텍스트 생성 언어 (HTML)-유형, URL-유형, 전자 메일-유형, 전화 번호-유형, 자바-유형, 텍스트-유형 및 미지의 유형을 포함하는 그룹에서 선택되는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 10 항에 있어서,

상기 정보는 상기 애플리케이션 데이터의 유형들의 각각과 연관된 포맷을 식별하는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 10 항에 있어서,

상기 정보는 상기 상이한 유형들의 애플리케이션 데이터와 관련된 변수들을 포함하는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 1 항에 있어서,

상기 정보는 상기 스캐닝 서브시스템에 의한 스캐닝 타이밍을 나타내는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 15 항에 있어서,

상기 타이밍은 상기 애플리케이션 데이터의 수신과 관계가 있는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 15 항에 있어서,

상기 타이밍은 상기 애플리케이션 데이터의 스토리지와 관계가 있는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 15 항에 있어서,

상기 타이밍은 상기 애플리케이션 데이터의 렌더링 (rendering) 과 관계가 있는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 15 항에 있어서,

상기 타이밍은 상기 애플리케이션 데이터의 인보킹 (invoking) 과 관계가 있는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 1 항에 있어서,

상기 정보는, 상기 스캐닝 서브시스템에 의한 스캐닝이 옵션적인지를 나타내는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 1 항에 있어서,

상기 정보는, 상기 스캐닝 서브시스템에 의한 스캐닝이 강제적인지를 나타내는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 1 항에 있어서,

상기 정보는 상기 스캐닝 서브시스템에 의한 스캐닝의 타이밍을 개선하는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
제 1 항에 있어서,

상기 정보는 상기 스캐닝 서브시스템에 의한 스캐닝의 정확성을 개선하는, 애플리케이션 프로그램 데이터 스캐닝 시스템.
이동 통신 디바이스를 이용하여 애플리케이션 프로그램 데이터를 스캐닝하는 시스템으로서,

무선 네트워크를 통해 통신할 수 있는 이동 통신 디바이스상에 설치되고, 상기 이동 통신 디바이스를 이용하여 태스크들을 수행하는데 적합한 애플리케이션 프로그램 수단; 및

상기 애플리케이션 프로그램 수단과 통신하여, 상기 애플리케이션 프로그램수단에 의해 수행되는 상기 태스크들과 관련된 애플리케이션 데이터를 스캐닝하는 스캐닝 서브시스템 수단을 포함하고,

상기 애플리케이션 프로그램 수단은, 상기 스캐닝 서브시스템 수단에 의한 상기 스캐닝을 용이하게 하기 위해, 상기 애플리케이션 데이터와 관련된 정보를 상기 스캐닝 서브시스템 수단에 통신하는, 애플리케이션 프로그램 데이터 스캐닝 시 스템.
이동 통신 디바이스를 이용하여 애플리케이션 프로그램 데이터를 스캐닝하는 방법으로서,

상기 이동 통신 디바이스상에 설치된 애플리케이션 프로그램을 갖는 상기 이동 통신 디바이스를 이용하여 태스크들을 수행하는 단계; 및

상기 애플리케이션 프로그램과 통신하는 스캐닝 서브시스템을 이용하여, 상기 태스크들과 관련된 애플리케이션 데이터를 스캐닝하는 단계를 포함하고,

상기 애플리케이션 프로그램은, 상기 스캐닝 서브시스템에 의한 상기 스캐닝을 용이하게 하기 위해, 상기 애플리케이션 데이터와 관련된 정보를 상기 스캐닝 서브시스템에 통신하는, 애플리케이션 프로그램 데이터 스캐닝 방법.
이동 통신 디바이스를 이용하여 애플리케이션 프로그램 데이터를 스캐닝하는 컴퓨터 프로그램 제품으로서,

상기 이동 통신 디바이스상에 설치된 애플리케이션 프로그램을 갖는 상기 이동 통신 디바이스를 이용하여 태스크들을 수행하는 컴퓨터 코드; 및

상기 애플리케이션 프로그램과 통신하는 스캐닝 서브시스템을 이용하여, 상기 태스크들과 관련된 애플리케이션 데이터를 스캐닝하는 컴퓨터 코드를 포함하고,

상기 애플리케이션 프로그램은, 상기 스캐닝 서브시스템에 의한 상기 스캐닝을 용이하게 하기 위해, 상기 애플리케이션 데이터와 관련된 정보를 상기 스캐닝 서브시스템에 통신하는, 컴퓨터 프로그램 제품.