Einige Inhalte dieser Anwendung sind momentan nicht verfügbar.
Wenn diese Situation weiterhin besteht, kontaktieren Sie uns bitte unterFeedback&Kontakt
1. (WO2019004503) APPLICATION VULNERABILITY DETECTION METHOD AND SYSTEM
Document

명세서

발명의 명칭

기술분야

1  

배경기술

2   3   4   5   6   7  

발명의 상세한 설명

기술적 과제

8  

과제 해결 수단

9   10   11   12  

발명의 효과

13  

도면의 간단한 설명

14   15   16   17   18   19   20   21   22   23   24   25   26   27  

발명의 실시를 위한 최선의 형태

28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52   53   54   55   56   57   58   59   60   61   62   63   64   65   66   67   68   69   70   71   72   73   74   75   76   77   78   79   80   81   82   83   84   85   86   87   88   89   90   91   92   93   94   95   96   97   98   99   100   101   102   103   104   105   106   107   108   109   110   111   112   113   114   115   116   117   118   119   120   121   122   123   124   125   126   127   128   129   130   131   132   133   134   135   136   137   138   139   140   141   142   143   144   145   146   147   148   149   150   151   152   153   154   155   156   157   158   159   160   161   162   163   164   165   166   167   168   169   170   171   172   173   174   175   176   177   178   179   180   181   182   183   184   185   186   187   188   189   190   191   192   193   194   195   196   197   198   199   200   201   202   203   204   205   206   207   208   209   210   211   212   213   214   215   216   217   218   219   220   221   222   223   224   225   226   227   228   229   230   231   232   233   234   235   236   237   238   239   240   241   242   243   244   245   246   247   248   249   250   251   252   253   254   255   256   257   258   259   260   261   262  

발명의 실시를 위한 형태

263   264  

청구범위

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19  

도면

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16  

명세서

발명의 명칭 : 어플리케이션의 취약점을 탐지하는 방법 및 시스템

기술분야

[1]
아래의 설명은 어플리케이션의 취약점을 탐지하는 방법 및 시스템, 그리고 컴퓨터와 결합되어 취약점 탐지 방법을 컴퓨터에 실행시키기 위해 컴퓨터 판독 가능한 기록매체에 저장된 컴퓨터 프로그램에 관한 것이다.

배경기술

[2]
앱스토어(App store)는 스마트폰과 같은 단말에 탑재할 수 있는 다양한 어플리케이션을 판매하는 온라인상의 컨텐츠 장터이다. 예를 들어, 어플리케이션의 개발자들은 개발된 어플리케이션을 단말에 설치하기 위한 파일(일례로, 안드로이드 응용 프로그램 패키지(Android Application Package, APK))를 앱스토어에 등록하고, 어플리케이션의 이용자들은 앱스토어를 통해 필요한 어플리케이션을 위한 파일을 다운로드받아 자신의 단말에 어플리케이션을 설치 및 구동할 수 있게 된다. 또한, 게임 퍼블리셔와 같이 다양한 게임 어플리케이션을 이용자들에게 배포하는 경우도 존재한다. 이처럼, 자신들이 직접 개발하지 않은 다양한 어플리케이션들을 개발자들로부터 등록받고, 등록받은 어플리케이션들을 이용자들에게 배포하는 어플리케이션 퍼블리셔들이 존재한다.
[3]
이때, 어플리케이션의 위험성은 다양한 관점에서 설명될 수 있다.
[4]
일례로, 어플리케이션의 첫 번째 위험성은 어플리케이션이 악성 코드와 같이 악의적인 의도로 개발된 정보를 포함함으로써, 어플리케이션이 등록되는 어플리케이션 퍼블리셔나 또는 어플리케이션이 설치 및 구동되는 이용자들의 단말에서 악의적인 기능을 수행하는 경우의 위험성을 들 수 있다. 한국공개특허 제10-2014-0098025호는 앱 스토어로 업로드 된 어플리케이션의 보안 평가를 위한 시스템 및 그 방법에 관한 것으로, 앱스토어에 등록될 어플리케이션이 악의적인 기능을 수행하는 것으로 탐지되는 경우, 해당 어플리케이션의 진입(앱스토어로의 등록)을 거절하는 기술에 대해 개시하고 있다.
[5]
다른 예로, 어플리케이션의 두 번째 위험성은 어플리케이션 자체의 보안성에 대한 위험성을 들 수 있다. 배포된 어플리케이션에 대한 분석을 통해 어플리케이션의 소스 코드가 변경 또는 수정됨에 따라 어플리케이션이 개발자에 의해 원래 의도된 기능이 아닌 다른 기능을 수행하게 됨으로써, 해당 어플리케이션을 통해 제공하고자 하는 서비스의 신뢰도가 감소하는 문제점이 존재한다. 따라서, 어플리케이션 퍼블리셔들은, 자신들이 직접 개발하지 않은 다양한 어플리케이션들(어플리케이션들의 설치 파일들)을 배포함에 있어서, 어플리케이션들에 대해 일정 수준 이상의 보안성을 제공할 필요성이 존재한다.
[6]
그러나, 이러한 어플리케이션의 두 번째 위험성과 관련하여, 등록되는 어플리케이션마다 제공하는 보안 수준은 차이가 있다. 예를 들어, 각 어플리케이션들에는 서로 다른 보안 수준의 보안 솔루션들이 탑재되어 있을 수 있고, 아무런 보안수단도 포함되어 있지 않을 수 있다. 또한, 각 어플리케이션들에 탑재된 보안 솔루션들마다 제공하는 보안 수준에도 차이가 존재한다.
[7]
종래기술에서는 단순히 프로그래밍 언어 수준(일례로, 안드로이드 응용 프로그램 패키지(Android Application Package, APK)에 대해 자바(java) 단의 취약점 점검만을 진행할 수 있을 뿐, 어플리케이션 퍼블리셔의 관점에서는, 등록되는 수많은 어플리케이션들 각각에 대해 일정한 수준 이상으로 유지되는 보안성을 제공하기 어렵다는 문제점이 있다.

발명의 상세한 설명

기술적 과제

[8]
어플리케이션의 취약점(vulnerability)을 진단하기 위한 탐색 패턴을 미리 설정하고, 설정된 탐지 패턴에 기반하여 배포를 위해 등록되는 어플리케이션의 패키지 파일에 대한 취약점을 탐지할 수 있는 취약점 탐지 방법 및 시스템을 제공한다.

과제 해결 수단

[9]
어플리케이션의 취약점을 탐지하는 방법에 있어서, 어플리케이션의 설치 및 구동을 위한 패키지 파일이 포함하는 파일들 및 상기 파일들이 포함하는 코드들 중 적어도 하나와 관련하여, 상기 어플리케이션의 취약점 진단을 위한 기 설정된 탐지 패턴들을 관리하는 단계; 어플리케이션의 설치 및 구동을 위해 이용자들에게 배포하기 위한 패키지 파일을 등록하는 단계; 및 상기 탐지 패턴들 중 적어도 하나의 탐지 패턴에 따라 상기 등록된 패키지 파일을 분석하여 상기 적어도 하나의 탐지 패턴별로 취약점 정보를 탐지하는 단계를 포함하는 것을 특징으로 하는 취약점 탐지 방법을 제공한다.
[10]
상기 취약점 탐지 방법을 컴퓨터에 실행시키기 위한 컴퓨터 프로그램이 기록되어 있는 것을 특징으로 하는 컴퓨터 판독 가능한 기록매체를 제공한다.
[11]
컴퓨터와 결합하여 상기 취약점 탐지 방법을 컴퓨터에 실행시키기 위해 컴퓨터 판독 가능한 기록매체에 저장된 컴퓨터 프로그램을 제공한다.
[12]
어플리케이션의 취약점을 탐지하는 시스템에 있어서, 컴퓨터에서 판독 가능한 명령을 실행하도록 구현되는 적어도 하나의 프로세서를 포함하고, 상기 적어도 하나의 프로세서는, 어플리케이션의 설치 및 구동을 위한 패키지 파일이 포함하는 파일들 및 상기 파일들이 포함하는 코드들 중 적어도 하나와 관련하여, 상기 어플리케이션의 취약점 진단을 위한 기 설정된 탐지 패턴들을 관리하고, 어플리케이션의 설치 및 구동을 위해 이용자들에게 배포하기 위한 패키지 파일을 등록하고, 상기 탐지 패턴들 중 적어도 하나의 탐지 패턴에 따라 상기 등록된 패키지 파일을 분석하여 상기 적어도 하나의 탐지 패턴별로 취약점 정보를 탐지하는 것을 특징으로 하는 취약점 탐지 시스템을 제공한다.

발명의 효과

[13]
어플리케이션의 취약점(vulnerability)을 진단하기 위한 탐색 패턴을 미리 설정하고, 설정된 탐지 패턴에 기반하여 배포를 위해 등록되는 어플리케이션의 패키지 파일에 대한 취약점을 탐지할 수 있다.

도면의 간단한 설명

[14]
도 1은 본 발명의 일실시예에 따른 네트워크 환경의 예를 도시한 도면이다.
[15]
도 2는 본 발명의 일실시예에 있어서, 전자 기기 및 서버의 내부 구성을 설명하기 위한 블록도이다.
[16]
도 3은 본 발명의 일실시예에 따른 보안성 평가 시스템의 블록 다이어그램이다.
[17]
도 4는 본 발명의 일실시예에 있어서, 인스트럭션 매스들간의 호출 관계를 설명하기 위한 도면이다.
[18]
도 5는 본 발명의 일실시예에 있어서, 메서드들간의 호출 관계를 설명하기 위한 도면이다.
[19]
도 6은 본 발명의 일실시예에 따른 룰 및 패턴을 설명하기 위한 도면이다.
[20]
도 7은 본 발명의 일실시예에 있어서, 패턴의 구조를 설명하기 위한 도면이다.
[21]
도 8은 본 발명의 일실시예에 있어서, 패턴의 소스를 설명하기 위한 도면이다.
[22]
도 9는 본 발명의 일실시예에 있어서, 임의의 파일들에 대한 패턴의 예를 도시한 도면이다.
[23]
도 10은 본 발명의 일실시예에 있어서, 파일에서 특정 문자열을 탐지한 결과와 패키지 파일에서 특정 파일을 탐지한 결과의 예를 도시한 도면이다.
[24]
도 11은 본 발명의 일실시예에 있어서, 안드로이드 매니페스트 파일에 대한 패턴의 예를 도시한 도면이다.
[25]
도 12는 본 발명의 일실시예에 있어서, 덱스 파일에 대한 패턴의 예를 도시한 도면이다.
[26]
도 13은 본 발명의 일실시예에 있어서, so 파일에 대한 패턴의 예를 도시한 도면이다.
[27]
도 14는 본 발명의 일실시예에 있어서, dll 파일에 대한 패턴의 예를 도시한 도면이다.

발명의 실시를 위한 최선의 형태

[28]
이하, 실시예를 첨부한 도면을 참조하여 상세히 설명한다.
[29]
본 발명의 실시예들에 따른 취약점 탐지 시스템은 이후 설명될 서버를 통해 구현될 수 있으며, 본 발명의 실시예들에 따른 취약점 탐지 방법은 상술한 서버를 통해 수행될 수 있다. 예를 들어, 서버에는 본 발명의 일실시예에 따른 컴퓨터 프로그램이 설치 및 구동될 수 있고, 서버는 구동된 컴퓨터 프로그램의 제어에 따라 본 발명의 일실시예에 따른 취약점 탐지 방법을 수행할 수 있다. 상술한 컴퓨터 프로그램은 컴퓨터로 구현되는 서버와 결합되어 취약점 탐지 방법을 컴퓨터에 실행시키기 위해 컴퓨터 판독 가능한 기록매체에 저장될 수 있다.
[30]
도 1은 본 발명의 일실시예에 따른 네트워크 환경의 예를 도시한 도면이다. 도 1의 네트워크 환경은 복수의 전자 기기들(110, 120, 130, 140), 복수의 서버들(150, 160) 및 네트워크(170)를 포함하는 예를 나타내고 있다. 이러한 도 1은 발명의 설명을 위한 일례로 전자 기기의 수나 서버의 수가 도 1과 같이 한정되는 것은 아니다.
[31]
복수의 전자 기기들(110, 120, 130, 140)은 컴퓨터 장치로 구현되는 고정형 단말이거나 이동형 단말일 수 있다. 복수의 전자 기기들(110, 120, 130, 140)의 예를 들면, 스마트폰(smart phone), 휴대폰, 네비게이션, 컴퓨터, 노트북, 디지털방송용 단말, PDA(Personal Digital Assistants), PMP(Portable Multimedia Player), 태블릿 PC 등이 있다. 일례로 도 1에서는 전자 기기 1(110)의 예로 스마트폰의 형상을 나타내고 있으나, 본 발명의 실시예들에서 전자 기기 1(110)은 실질적으로 무선 또는 유선 통신 방식을 이용하여 네트워크(170)를 통해 다른 전자 기기들(120, 130, 140) 및/또는 서버(150, 160)와 통신할 수 있는 다양한 물리적인 장치들 중 하나를 의미할 수 있다.
[32]
통신 방식은 제한되지 않으며, 네트워크(170)가 포함할 수 있는 통신망(일례로, 이동통신망, 유선 인터넷, 무선 인터넷, 방송망)을 활용하는 통신 방식뿐만 아니라 기기들간의 근거리 무선 통신 역시 포함될 수 있다. 예를 들어, 네트워크(170)는, PAN(personal area network), LAN(local area network), CAN(campus area network), MAN(metropolitan area network), WAN(wide area network), BBN(broadband network), 인터넷 등의 네트워크 중 하나 이상의 임의의 네트워크를 포함할 수 있다. 또한, 네트워크(170)는 버스 네트워크, 스타 네트워크, 링 네트워크, 메쉬 네트워크, 스타-버스 네트워크, 트리 또는 계층적(hierarchical) 네트워크 등을 포함하는 네트워크 토폴로지 중 임의의 하나 이상을 포함할 수 있으나, 이에 제한되지 않는다.
[33]
서버(150, 160) 각각은 복수의 전자 기기들(110, 120, 130, 140)과 네트워크(170)를 통해 통신하여 명령, 코드, 파일, 컨텐츠, 서비스 등을 제공하는 컴퓨터 장치 또는 복수의 컴퓨터 장치들로 구현될 수 있다. 예를 들어, 서버(150)는 네트워크(170)를 통해 접속한 복수의 전자 기기들(110, 120, 130, 140)로 제1 서비스를 제공하는 시스템일 수 있으며, 서버(160) 역시 네트워크(170)를 통해 접속한 복수의 전자 기기들(110, 120, 130, 140)로 제2 서비스를 제공하는 시스템일 수 있다. 보다 구체적인 예로, 서버(150)는 어플리케이션 퍼블리셔의 시스템을 구성하는 장치들 중 적어도 일부일 수 있으며, 복수의 전자 기기들(110, 120, 130, 140)에 설치되어 동작되는 어플리케이션의 패키지 파일을 등록받아 배포하는 서비스를 상기 제1 서비스로서 제공할 수 있다. 다른 예로, 서버(160)는 배포된 패키지 파일을 통해 어플리케이션을 설치 및 구동하는 복수의 전자 기기들(110, 120, 130, 140)로 상기 어플리케이션과 연관된 서비스를 상기 제2 서비스로서 제공할 수 있다. 실시예에 따라 서버(150)는 등록되는 패키지 파일의 취약점 정보를 탐지하기 위한 전용 시스템을 구현하기 위해 이용될 수도 있다.
[34]
도 2는 본 발명의 일실시예에 있어서, 전자 기기 및 서버의 내부 구성을 설명하기 위한 블록도이다. 도 2에서는 전자 기기에 대한 예로서 전자 기기 1(110), 그리고 서버(150)의 내부 구성을 설명한다. 또한, 다른 전자 기기들(120, 130, 140)이나 서버(160) 역시 상술한 전자 기기 1(110) 또는 서버(150)와 동일한 또는 유사한 내부 구성을 가질 수 있다.
[35]
전자 기기 1(110)과 서버(150)는 메모리(211, 221), 프로세서(212, 222), 통신 모듈(213, 223) 그리고 입출력 인터페이스(214, 224)를 포함할 수 있다. 메모리(211, 221)는 컴퓨터에서 판독 가능한 기록매체로서, RAM(random access memory), ROM(read only memory) 및 디스크 드라이브와 같은 비소멸성 대용량 기록장치(permanent mass storage device)를 포함할 수 있다. 여기서 ROM과 디스크 드라이브와 같은 비소멸성 대용량 기록장치는 메모리(211, 221)와는 구분되는 별도의 영구 저장 장치로서 전자 기기 1(110)나 서버(150)에 포함될 수도 있다. 또한, 메모리(211, 221)에는 운영체제와 적어도 하나의 프로그램 코드(일례로 전자 기기 1(110)에 설치되어 구동되는 브라우저나 특정 서비스의 제공을 위해 전자 기기 1(110)에 설치된 어플리케이션 등을 위한 코드)가 저장될 수 있다. 이러한 소프트웨어 구성요소들은 메모리(211, 221)와는 별도의 컴퓨터에서 판독 가능한 기록매체로부터 로딩될 수 있다. 이러한 별도의 컴퓨터에서 판독 가능한 기록매체는 플로피 드라이브, 디스크, 테이프, DVD/CD-ROM 드라이브, 메모리 카드 등의 컴퓨터에서 판독 가능한 기록매체를 포함할 수 있다. 다른 실시예에서 소프트웨어 구성요소들은 컴퓨터에서 판독 가능한 기록매체가 아닌 통신 모듈(213, 223)을 통해 메모리(211, 221)에 로딩될 수도 있다. 예를 들어, 적어도 하나의 프로그램은 개발자들 또는 어플리케이션의 설치 파일을 배포하는 파일 배포 시스템(일례로, 상술한 서버(160))이 네트워크(170)를 통해 제공하는 파일들에 의해 설치되는 컴퓨터 프로그램(일례로 상술한 어플리케이션)에 기반하여 메모리(211, 221)에 로딩될 수 있다.
[36]
프로세서(212, 222)는 기본적인 산술, 로직 및 입출력 연산을 수행함으로써, 컴퓨터 프로그램의 명령을 처리하도록 구성될 수 있다. 명령은 메모리(211, 221) 또는 통신 모듈(213, 223)에 의해 프로세서(212, 222)로 제공될 수 있다. 예를 들어 프로세서(212, 222)는 메모리(211, 221)와 같은 기록 장치에 저장된 프로그램 코드에 따라 수신되는 명령을 실행하도록 구성될 수 있다.
[37]
통신 모듈(213, 223)은 네트워크(170)를 통해 전자 기기 1(110)과 서버(150)가 서로 통신하기 위한 기능을 제공할 수 있으며, 전자 기기 1(110) 및/또는 서버(150)가 다른 전자 기기(일례로 전자 기기 2(120)) 또는 다른 서버(일례로 서버(160))와 통신하기 위한 기능을 제공할 수 있다. 일례로, 전자 기기 1(110)의 프로세서(212)가 메모리(211)와 같은 기록 장치에 저장된 프로그램 코드에 따라 생성한 요청이 통신 모듈(213)의 제어에 따라 네트워크(170)를 통해 서버(150)로 전달될 수 있다. 역으로, 서버(150)의 프로세서(222)의 제어에 따라 제공되는 제어 신호나 명령, 컨텐츠, 파일 등이 통신 모듈(223)과 네트워크(170)를 거쳐 전자 기기 1(110)의 통신 모듈(213)을 통해 전자 기기 1(110)로 수신될 수 있다. 예를 들어 통신 모듈(213)을 통해 수신된 서버(150)의 제어 신호나 명령, 컨텐츠, 파일 등은 프로세서(212)나 메모리(211)로 전달될 수 있고, 컨텐츠나 파일 등은 전자 기기 1(110)가 더 포함할 수 있는 저장 매체(상술한 영구 저장 장치)로 저장될 수 있다.
[38]
입출력 인터페이스(214)는 입출력 장치(215)와의 인터페이스를 위한 수단일 수 있다. 예를 들어, 입력 장치는 키보드 또는 마우스 등의 장치를, 그리고 출력 장치는 디스플레이, 스피커와 같은 장치를 포함할 수 있다. 다른 예로 입출력 인터페이스(214)는 터치스크린과 같이 입력과 출력을 위한 기능이 하나로 통합된 장치와의 인터페이스를 위한 수단일 수도 있다. 입출력 장치(215)는 전자 기기 1(110)과 하나의 장치로 구성될 수도 있다. 또한, 서버(150)의 입출력 인터페이스(224)는 서버(150)와 연결되거나 서버(150)가 포함할 수 있는 입력 또는 출력을 위한 장치(미도시)와의 인터페이스를 위한 수단일 수 있다. 보다 구체적인 예로, 전자 기기 1(110)의 프로세서(212)가 메모리(211)에 로딩된 컴퓨터 프로그램의 명령을 처리함에 있어서 서버(150)나 전자 기기 2(120)가 제공하는 데이터를 이용하여 구성되는 서비스 화면이나 컨텐츠가 입출력 인터페이스(214)를 통해 디스플레이에 표시될 수 있다.
[39]
또한, 다른 실시예들에서 전자 기기 1(110) 및 서버(150)는 도 2의 구성요소들보다 더 많은 구성요소들을 포함할 수도 있다. 그러나, 대부분의 종래기술적 구성요소들을 명확하게 도시할 필요성은 없다. 예를 들어, 전자 기기 1(110)은 상술한 입출력 장치(215) 중 적어도 일부를 포함하도록 구현되거나 또는 트랜시버(transceiver), GPS(Global Positioning System) 모듈, 카메라, 각종 센서, 데이터베이스 등과 같은 다른 구성요소들을 더 포함할 수도 있다. 보다 구체적인 예로, 전자 기기 1(110)이 스마트폰인 경우, 일반적으로 스마트폰이 포함하고 있는 가속도 센서나 자이로 센서, 카메라 모듈, 각종 물리적인 버튼, 터치패널을 이용한 버튼, 입출력 포트, 진동을 위한 진동기 등의 다양한 구성요소들이 전자 기기 1(110)에 더 포함되도록 구현될 수 있다.
[40]
도 3은 본 발명의 일실시예에 따른 보안성 평가 시스템의 블록 다이어그램이다. 도 3의 보안성 평가 시스템(300)은 앞서 설명한 서버(150)를 통해 구현될 수 있으며, 앞서 설명한 취약점 탐지 시스템은 보안성 평가 시스템(300)에 포함되도록 구현되거나 또는 보안성 평가 시스템(300)에서 취약점 탐지를 위한 구성만을 별도로 포함하도록 구현될 수 있다.
[41]
보안성 평가 시스템(300)이 포함하는 패키지 분해 모듈(310), 파일 식별 모듈(320), 파싱 모듈(330), 분석 모듈(340) 및 리포트 모듈(350)은 서버(150)가 포함하는 프로세서(222)의 서로 다른 기능들(different functions)의 표현들일 수 있다. 예를 들어, 서버(150)의 프로세서(222)가 컴퓨터 프로그램이 포함하는 제어 명령에 따라 패키지 파일을 분해하는 프로세서(222)의 기능으로서 패키지 분해 모듈(310)이 이용될 수 있다. 이때, 분석 모듈(340)이 포함하는 취약점 탐지 모듈(342)이 취약점 탐지를 위한 핵심 모듈로서 구현될 수 있다.
[42]
앞서 설명한 바와 같이, 서버(150)는 개발자들이 등록하는 어플리케이션의 패키지 파일들을 이용자들에게 배포하는 서비스를 제공할 수 있다.
[43]
이때, 패키지 분해 모듈(310)은 등록된 패키지 파일들을 분해할 수 있다. 예를 들어, 안드로이드 응용 프로그램 패키지(Android Application Package, APK)는 모바일 운영체제인 안드로이드의 소프트웨어와 미들웨어 배포에 사용되는 패키지 파일의 파일 포맷으로서 '.apk' 확장자를 갖는다. 이하의 실시예들에서는 이러한 APK와 같은 패키지 파일을 기반으로 본 발명의 실시예들을 설명하나, 이러한 설명을 통해 다른 종류의 패키지 파일에도 동일 또는 유사한 특징이 적용될 수 있음을 당업자라면 쉽게 이해할 수 있을 것이다.
[44]
또한, APK는 이미 잘 알려져 있기 때문에 APK 파일 또는 APK 파일이 포함하는 파일들 자체에 대한 설명 역시 당업자가 이미 잘려진 종래기술들을 통해 쉽게 이해할 수 있을 것이며, 따라서 APK 파일 또는 APK 파일이 포함하는 파일들 자체에 대한 자세한 설명은 생략한다.
[45]
파일 식별 모듈(320)은 분해된 패키지 파일에 포함된 파일들을 식별할 수 있다. 도 3에서 나타난 확장자들('dex', 'so', 'dll', 'json', 'ini', 'apk', 'xml', 'cert')은 이미 설명한 바와 같이 APK와 관련된 종래기술들을 통해 당업자가 쉽게 이해할 수 있을 것이다.
[46]
파싱 모듈(330)은 식별된 파일들을 파싱할 수 있다. 이를 위해, 파서(331)는 식별된 파일들 중 특정 확장자(일례로, 'dex', 'so', 'dll')의 파일들을 파싱할 수 있으며, 콜렉터(332)는 특정 확장자(일례로, 'json', 'ini', 'apk', 'xml', 'cert')의 파일들로부터 필요한 정보를 수집할 수 있다.
[47]
예를 들어, 파싱 모듈(330)은 'dex' 파일이 포함하는 클래스(class)들과 메서드(method)들 각각을 식별할 수 있으며, 메서드가 포함하는 인스트럭션들을 추적하여 다수의 매스(mass)들로 구분하여 식별할 수 있다. 인스트럭션들의 매스는 'goto' 문이나, 'switch' 문 또는 'if' 문 등과 같은 분기명령을 기준으로 구분될 수 있다. 또한, 파싱 모듈(330)은 이러한 인스트럭션 매스들간의 호출 관계에 대한 정보를 생성하여 관리할 수 있다. 일례로, 인스트럭션 매스들간의 호출 관계는 트리 구조로 관리될 수 있으며, 호출 관계에 대한 정보는 특정 인스트럭션 매스가 호출하는 메서드에 대한 정보를 포함할 수 있다. 이러한 정보의 생성 및 관리는 APK 파일과 같은 패키지 파일이 포함하는 파일들 각각에 대해 처리될 수 있으며, 파일의 특성에 따라 파싱 방식은 달라질 수 있다.
[48]
파싱된 정보들과 수집된 정보들은 분석 모듈(340)로 전달될 수 있다.
[49]
분석 모듈(340)은 파싱 모듈(330)로부터 전달되는 정보들에 기반하여 해당 패키지 파일(또는 해당 패키지 파일을 통해 전자 기기 1(110)과 같은 이용자 단말에서 설치 및 구동되는 어플리케이션)에 대한 난독화(obfuscation) 관점, 취약점(vulnerability) 관점 및 보안솔루션 관점의 분석정보를 생성 및 제공할 수 있다.
[50]
예를 들어, 난독화 탐지 모듈(341)은 특정 확장자(일례로, 'dex', 'so', 'dll')의 파일들에 어느 정도 수준의 난독화가 적용되어 있는가에 대한 분석정보를 생성할 수 있다. 이를 위해, 난독화 탐지 모듈(341)은 파일의 종류에 따라 미리 설정되는 항목별로 난독화가 적용되어 있는지 여부 등을 판단할 수 있다.
[51]
또한, 취약점 탐지 모듈(342)은 특정 확장자(일례로, 'dex', 'so', 또는 설정(configuration) 파일의 확장자인 'config')의 파일들에 어떠한 취약점이 있는가에 대한 분석정보를 생성할 수 있다. 이를 위해, 보안성 평가 시스템(300)은 이미 알려진 취약점들에 대한 정보를 관리할 수 있으며, 취약점 탐지 모듈(342)은 이러한 취약점들에 대한 정보를 이용하여 어떠한 파일들에 어떠한 취약점이 존재하는가에 대한 분석정보를 생성할 수 있다.
[52]
또한, 플랫폼 탐지 모듈(343)은 해당 어플리케이션이 개발된 플랫폼 및/또는 해당 어플리케이션이 동작하는 플랫폼에 대한 정보를 추출할 수 있다. 예를 들어, 보안성 평가 시스템(300)은 해당 어플리케이션이 어떠한 플랫폼(일례로, 유니티(Unity)나 코코스(Cocos)와 같은 개발 툴)에서 개발되었는가에 따라 서로 다른 분석 방식을 활용할 수 있다.
[53]
또는, 보안성 평가 시스템(300)은 어플리케이션이 동작하는 플랫폼마다 패키지 파일이 포함하는 파일 포맷이 달라질 수 있기 때문에, 이러한 플랫폼마다 서로 다른 분석 방식을 활용할 수도 있다.
[54]
이를 위해, 보안성 평가 시스템(300)은 패키지 파일에 대한 플랫폼에 대한 정보를 추출할 수 있으며, 이러한 정보에 기반하여 패키지 파일을 분석하거나 또는 추출된 플랫폼에 대한 정보를 외부로 제공할 수 있다.
[55]
보안 툴 탐지 모듈(344)은 패키지 파일의 개발자들이 자체적으로 패키지 파일에 삽입한 보안솔루션을 탐지할 수 있다. 예를 들어, 제3자에 의해 라이브러리 형태로 제공되는 제1 보안 툴이 개발자에 의해 해당 패키지 파일에 추가되어 있을 수 있다. 다른 예로, 개발자가 자체 개발한 제2 보안 툴이 개발자에 의해 해당 패키지 파일에 추가되어 있을 수도 있다. 다시 말해, 보안 툴 탐지 모듈(344)은 이러한 보안 툴의 패키지 파일에 대한 적용 여부에 대한 분석정보를 생성할 수 있다.
[56]
관계 분석 모듈(345)은 패키지 파일이 포함하는 파일들간의 참조 관계에 대한 분석정보를 생성할 수 있다. 예를 들어, 제1 파일이 제2 파일을 호출하기 위한 코드를 포함하고 있는 경우, 제1 파일과 제2 파일간의 참조 관계에 대한 정보가 분석정보에 포함되도록 분석정보가 생성될 수 있다.
[57]
리포트 모듈(350)은 분석 모듈(340)에서 생성되는 분석정보들을 수집하여 보안성 평가 시스템(300)의 관계자(일례로 서버(150)의 관리자 또는 어플리케이션 퍼블리셔의 보안 검수 팀)에게 제공하기 위한 보고서를 생성할 수 있다. 이러한 보고서는 도 3의 예에서와 같이 HTML(Hypertext Markup Language)나 XML(eXtensible Markup Language)를 이용하여 관계자들의 단말로 제공될 수 있다.
[58]
도 4는 본 발명의 일실시예에 있어서, 인스트럭션 매스들간의 호출 관계를 설명하기 위한 도면이다. 도 4는 하나의 메서드 A(Method A, 400)에 대해 루트 매스(Root Mass, 410), 인스트럭션 매스 1(Instruction Mass 1, 420), 인스트럭션 매스 2(430), 인스트럭션 매스 3(440) 및 인스트럭션 매스 5(450)와 같은 다섯 개의 인스트럭션 매스들이 식별된 예를 나타내고 있다. 이미 설명한 바와 같이 인스트럭션 매스는 분기명령에 기반하여 구분될 수 있으며, 인스트럭션 매스들 각각을 노드라 가정할 때, 도 4에서 점선 화살표들은 특정 노드의 부모 노드를 지시하고 있다. 예를 들어, 도 4는 인스트럭션 매스 3(440)의 부모 노드가 인스트럭션 매스 2(430)임을 지시하고 있다. 여기서 자식 노드는 부모 노드가 포함하는 분기명령에 따라 구분되는 인스트럭션들의 매스를 포함할 수 있다. 루트 매스(410)는 메서드 A(400)에 대해 가장 먼저 실행되는 인스트럭션들의 매스일 수 있다.
[59]
보다 구체적인 예로, 도 4는 인스트럭션 매스 1(420)이 조건부 분기(conditional branch, 421)를 위한 명령을 포함하고, 조건에 따라 인스트럭션 매스 3(440) 또는 인스트럭션 매스 4(450)의 명령들이 실행된다고 가정하자. 이때, 인스트럭션 매스 3(440)과 인스트럭션 매스 4(450)가 식별될 수 있으며, 인스트럭션 매스 3(440)과 인스트럭션 매스 4(450)의 부모 노드는 인스트력션 매스 1(420)이 될 수 있다. 또한, 조건부 분기(421)를 위한 명령에 따라 인스트럭션 매스 3(440)으로 이동되는 위치가 레이블 1(Lable 1, 441)에 의해, 그리고 인스트럭션 매스 4(450)로 이동되는 위치가 레이블 2(Lable 2, 451)에 의해 각각 지시될 수 있다. 다시 말해, 인스트럭션 매스 1(420)에서 호출이 탐지될 수 있으며, 탐지된 호출을 통해 호출되는 인스트럭션 매스들(440, 450)이 레이블들(441, 451)을 통해 지시될 수 있다. 도 4에서 실선들이 이러한 지시 관계를 나타내고 있다.
[60]
도 5는 본 발명의 일실시예에 있어서, 메서드들간의 호출 관계를 설명하기 위한 도면이다. 도 5는 호출 참조에 대한 정보(510)와 메서드 a(520)를 나타내고 있다. 메서드 a(520)는 적어도 하나의 인스트럭션 매스들을 포함할 수 있으며, 도 5는 하나의 인스트럭션 매스(521)를 나타내고 있다.
[61]
이때, 도 5에서는 인스트럭션 매스(521)에서 메서드 b(511)와 메서드 c(512)에 대한 호출이 탐지된 예를 나타내고 있다. 메서드들은 각각 고유한 메서드 ID에 의해 식별될 수 있다. 본 실시예에 따른 취약점 탐지 시스템은 탐지된 호출에 따라 호출 참조에 대한 정보(510)에서 메서드 a(520)의 메서드 ID를 이용하여 메서드 b(511)와 메서드 c(512)에 대한 정보를 획득할 수 있다.
[62]
여기서, 메서드 b(511)와 메서드 c(512)에 대한 정보는 각각 도 4를 통해 설명한 바와 같이 호출된 메서드 b(511)와 메서드 c(512) 각각에 대한 인스트럭션 매스들에 대한 정보 그리고 인스트럭션 매스들간의 참조 관계에 대한 정보 등을 포함할 수 있다. 따라서, 취약점 탐지 시스템은 해당 파일에 따른 프로그램의 실행 제어가 어떤 방법으로 옮겨지고 있는가를 파악할 수 있게 된다.
[63]
도 6은 본 발명의 일실시예에 따른 룰 및 패턴을 설명하기 위한 도면이다. 도 6은 본 실시예에 따른 룰(Rule, 600)의 구조의 예를 설명하고 있다. 본 실시예에서 룰(600)은 이미 알려진 취약점들 중 어느 하나에 대응하여, 해당 취약점을 탐지하기 위한 탐지 패턴에 대한 정보를 포함할 수 있다.
[64]
도 6에서 '이름(Name)' 항목(610)은 해당 룰(600)의 이름을 포함할 수 있으며, '설명(Description)' 항목(620)은 해당 룰(600)에 대한 자세한 설명을 포함할 수 있다. 예를 들어, 해당 룰(600)이 어떠한 취약점에 대한 것인가에 대한 설명 정보를 포함할 수 있다. 또한, '가이드(Guide)' 항목(640)은 해당 룰(600)의 사용과 관련된 행동 원리나 지침에 대한 정보를 포함할 수 있다.
[65]
또한, '우선순위(Priority)' 항목(630)은 해당 취약점에 대한 위험성 등급에 대한 정보를 포함할 수 있다. 예를 들어, '크리티컬(Critical)', '워닝(Warning)', '노멀(Normal)'과 같은 세 개의 위험성 등급 중 하나의 등급에 대한 값이 '우선순위(priority)' 항목(630)에 포함될 수 있다. 이러한 위험성 등급이 두 개의 등급이나 넷 이상의 등급으로도 설정될 수도 있음은 자명하다.
[66]
또한, '의존성(Dependency)' 항목(650)은 취약 계층의 실제 취약성을 동적으로 결정해야 하는 조건이 존재하는지 여부를 나타낼 수 있다. 예를 들어, 하나의 취약점에 대한 위험성이 조건에 따라 달라지는 경우가 존재할 수 있다. 예를 들어, 취약점 a가 조건 1에서는 '크리티컬(Critical)'한 위험성 등급을 갖지만, 취약점 a가 조건 2에서는 '노멀(Normal)'한 위험성 등급을 갖거나 또는 전혀 위험성이 없는 경우도 존재할 수 있다. 따라서, 이러한 조건별 차이를 구분하기 위해 '의존성(Dependency)' 항목(650)은 조건에 대한 정보와 조건별 위험성 등급에 대한 정보를 포함할 수 있다. 또는 단순히 이러한 조건이 존재하는지 여부에 대한 정보를 포함할 수도 있다.
[67]
이상에서 설명한 룰(600)의 항목들은 실시예에 따라 선택적으로 룰(600)에 포함되어 활용될 수 있다.
[68]
'패턴(Pattern)' 항목(660)은 취약점 탐지를 위한 하나 이상의 탐지 패턴을 포함할 수 있다. 탐지 패턴들은 기 설정될 수 있으며, 하나의 룰(600)은 취약점 탐지를 위한 하나의 탐지 패턴을 포함하거나 또는 둘 이상의 탐지 패턴의 조합을 포함할 수 있다. 탐지 패턴은 적어도 하나의 명령들로 구현될 수 있으며, 적어도 하나의 명령들 각각은 파라미터를 갖는 메서드나 클래스의 형태로 구현될 수 있다. 파라미터는 미리 설정될 수도 있고, 다른 패턴을 통해 추출되는 값으로 동적으로 설정될 수도 있다.
[69]
도 7은 본 발명의 일실시예에 있어서, 패턴의 구조를 설명하기 위한 도면이다.
[70]
룰 테이블(rule_tbl, 710)은 설정된 룰에 대한 정보를 포함할 수 있다. 'rule_id(pk)'는 설정된 룰들 중에서 주식별자(primary key, pk)에 대응하는 룰을 의미할 수 있다. 이러한 실제로는 'rule_id(pk)'는 주식별자 pk를 파라미터로 받아서 대응하는 룰의 식별자를 반환하는 함수를 의미할 수 있다. 'name(key)'는 키(key)에 대응하는 룰의 이름을 의미할 수 있다. 이러한 'name(key)' 역시 실제로는 키 key를 파라미터로 받아서 대응하는 룰의 이름을 반환하는 함수를 의미할 수 있다. 이처럼, 도 7에서 'x(y)'는 'y'가 입력된 함수 'x'를 의미할 수 있으나 간략하게 'y'에 대응하는 'x'를 의미하는 것으로 설명한다. 'pattern_hash(fk)'는 외부식별자(foreign key, fk)에 대응하는 패턴의 해시값을 의미할 수 있다. 또한, '설명(description)', '우선순위(priority)', '가이드(guide)', '의존성(dependency)'은 각각 도 6을 통해 설명한 '설명(Description)' 항목(620), '우선순위(Priority)' 항목(630), '가이드(Guide)' 항목(640) 및 '의존성(Dependency)' 항목(650)에 대응하는 값들을 의미할 수 있다. 'pattern_hash(key)'는 키에 대응하는 패턴의 해시값을 의미할 수 있다. 취약점 탐지 시스템은 룰 테이블(710)을 이용하여 필요한 룰에 대한 정보를 얻을 수 있으며, 얻어진 룰에 포함된 패턴의 식별자로서 패턴의 해시값을 획득할 수 있다.
[71]
패턴 테이블(pattern_tbl, 720)은 설정된 패턴에 대한 정보를 포함할 수 있다. 'pattern_id(pk)'는 주식별자(primary key, pk)에 대응하는 패턴을, 'rule_id(pk)'는 외부식별자(foreign key, fk)에 대응하는 룰을 각각 의미할 수 있다. 또한, '소스(source)'는 패턴의 소스에 대한 정보를 의미할 수 있다. 예를 들어, 패턴의 소스는 APK와 같은 패키지 파일에서 탐색될 파일의 종류를 나타낼 수 있다. '테이블 타입(table_type)'은 반환되는 패턴의 타입에 대한 정보를, '조인 패턴(join_pattern)'은 해당 패턴과 결합되어 하나의 룰을 구성하는 다른 패턴에 대한 정보를, 'join_type(and/or/sub)'는 패턴들이 어떠한 타입으로 결합되는가에 대한 정보를 각각 의미할 수 있다. 여기서 'and', 'or' 및 'sub'는 이후 표 19를 통해 설명되는 바와 같이 패턴들의 조합을 위한 논리 연산자들을 의미할 수 있다. 취약점 탐지 시스템은 룰 테이블(710)에서 얻어지는 룰에 대한 정보를 통해 해당 룰이 포함하는 패턴들을 식별할 수 있으며, 패턴 테이블(720)을 통해 해당 룰이 포함하는 패턴들에 대한 정보를 얻을 수 있다.
[72]
덱스 파일 테이블(pattern_data_dex_find_api, 730)은 APK의 덱스 파일에서 추출되는 정보를 포함할 수 있다. 'pattern_id(fk)'는 설정된 패턴들 중에서 외부식별자(foreign key, fk)에 대응하는 패턴을 의미할 수 있다. '호출된 클래스 이름(called_class_name)'은 호출되는 클래스 이름을 식별하기 위한 값을, '호출된 메서드 이름(called_method_name)'은 호출되는 메서드 이름을 식별하기 위한 값을 각각 의미할 수 있다. 'enable_tracing_argument(optional)'는 추적 가능한 인수(argument)를 반환하는 함수를, 'argument_index(optional)'는 인수의 인덱스를 반환하는 함수를, '인수 타입(argument_type)'은 반환되는 인수의 타입을 각각 의미할 수 있다. 'argument_from_null_detect(true/false)'는 널(null) 인수를 탐지할 것인지 여부를, 와 'argument_from_null_except(true/false)'는 널(null) 인수를 예외로 할 것인지 여부를 각각 의미할 수 있다. 또한, 덱스 파일 테이블(730)은 탐지된 API 리스트로부터의 인수(argument_from_detect_api_list), 예외 처리된 API 리스트로부터의 인수(argument_from_except_api_list), 탐지된 필드 리스트로부터의 인수(argument_from_detect_field_list) 및 예외 처리된 리스트로부터의 인수(argument_from_except_list)에 대한 정보들을 포함할 수 있다. 취약점 탐지 시스템은 패턴에 따라 취약점 탐지에 필요한 정보를 탐지함에 있어서 덱스 파일 테이블(730)을 참조할 수 있다. 예를 들어, 취약점 탐지 시스템은 특정 인스트럭션 매스에 대한 취약점을 탐지함에 있어서, 해당 인스트럭션 매스에서 호출하는 메서드나 클래스를 덱스 파일 테이블(730)을 이용하여 식별할 수 있다.
[73]
파일 테이블(pattern_data_retrieve_file_tbl, 740)은 패키지 파일이 포함하는 특정 파일의 정보를 추출하는 패턴 정보를 포함할 수 있다. 'pattern_id(fk)'는 설정된 패턴들 중에서 외부식별자(foreign key, fk)에 대응하는 패턴을 의미할 수 있고, 'pattern_hash(key)'는 키에 대응하는 패턴의 해시값을 의미할 수 있다. '파일 타입(file_type)'은 패턴을 통해 검색되는 파일의 타입을, '파일 확장자(file_extension)'은 패턴을 통해 검색되는 파일의 확장자를, '파일 이름(file_name)'은 패턴을 통해 검색되는 파일의 이름을 각각 의미할 수 있다.
[74]
컨텐츠 테이블(pattern_data_retrieve_file_contents_tbl, 750)은 파일에 포함된 문자를 추출하는 패턴 정보를 포함할 수 있다. 'pattern_id(fk)'는 설정된 패턴들 중에서 외부식별자(foreign key, fk)에 대응하는 패턴을 의미할 수 있고, 'pattern_hash(key)'는 키에 대응하는 패턴의 해시값을 의미할 수 있다. '파일 타입(file_type)'은 패턴을 통해 검색되는 파일의 타입을, '문자 타입(character_type)'은 문자(또는 문자열)의 타입을, '문자(character)'는 파일에서 검색하고자 하는 문자(또는 문자열)을 의미할 수 있다.
[75]
퍼미션 테이블(pattern_data_retrieve_permission_tbl, 760)은 패키지 파일의 퍼미션(permission) 정보를 추출하는 패턴 정보를 포함할 수 있다. 'pattern_id(fk)'는 설정된 패턴들 중에서 외부식별자(foreign key, fk)에 대응하는 패턴을 의미할 수 있고, '이름(name)'은 퍼미션의 이름을 의미할 수 있다.
[76]
액티비티 테이블(pattern_data_retrieve_activity_tbl, 770)은 액티비티 정보를 추출하는 패턴 정보를 포함할 수 있다. 'pattern_id(fk)'는 설정된 패턴들 중에서 외부식별자(foreign key, fk)에 대응하는 패턴을 의미할 수 있고, '이름(name)'은 액티비티의 이름을 의미할 수 있다. 여기서 액티비티는 사용자 인터페이스가 있는 하나의 화면을 의미하는 것으로, 일례로 APK에서 액티비티 클래스(activity class)를 상속해서 구현될 수 있다. 이처럼, 상술한 액티비티나 퍼미션 등의 용어들은 APK에 대한 종래의 기술들을 통해 당업자가 용이하게 이해할 수 있을 것이다.
[77]
SDK 테이블(pattern_data_retrieve_min_sdk, 780)은 SDK(Software Development Kit)에 대한 정보를 추출하는 패턴 정보를 포함할 수 있다. 'pattern_id(fk)'는 설정된 패턴들 중에서 외부식별자(foreign key, fk)에 대응하는 패턴을 의미할 수 있고, '버전(version)'은 SDK의 버전 정보를, '버전 탐지 조건(conditional_equality)'는 버전의 탐지 조건을 각각 의미할 수 있다. 예를 들어, '버전(version)'이 '21'로 설정되고, '버전 탐지 조건(conditional_equality)' 이 '작거나 같다'인 경우, 버전이 21 이하인 경우 해당 SDK의 버전이 탐지될 수 있다.
[78]
도 8은 본 발명의 일실시예에 있어서, 패턴의 소스를 설명하기 위한 도면이다. 룰(600)이 포함하는 패턴(660)의 소스는 APK와 같은 패키지 파일의 특정 파일일 수 있다. 도 8에서는 패턴(660)이 패키지 파일이 포함하는 임의의 파일들(Any files, 810), 덱스 파일(dex, 820), 안드로이드 매니페스트 파일(AndroidManifest.xml, 830), so 파일(so, 840) 또는 dll 파일(dll, 850)을 소스로 가질 수 있음을 나타내고 있다.
[79]
도 9는 본 발명의 일실시예에 있어서, 임의의 파일들에 대한 패턴의 예를 도시한 도면이다. 도 9는 임의의 파일들(810)에 대한 패턴들(900)의 종류를 나타내고 있다.
[80]
제1 종류(910)의 패턴은 파일에서 특정 문자(또는 문자열)를 찾는 패턴을 의미할 수 있으며, 아래 패턴 1과 같이 표현될 수 있다.
[81]
[패턴 1]
[82]
RetrieveFileContents:
[83]
: FileType(string) CharacterType(string) Character(string)
[84]
예를 들어, JSON(JavaScript Object Notation) 파일에서 URL(Uniform Resource Locator)를 찾는 패턴은 'RetrieveFileContents: FileType(json) CharacterType(string) Character(http://*)'와 같이 구현될 수 있다. 다시 말해, 상술한 예시의 패턴은 파일에 포함된 컨텐츠를 검색하는 패턴으로서 'json' 타입의 파일에서 'string' 타입의 문자열로서 'http://*'를 탐색하라는 명령을 의미할 수 있다. 이러한 패턴 'RetrieveFileContents'에서 파일 타입 'FileType()'의 파라미터는 'all', 'apk', 'txt', 'ini', 'property', 'json', 'xml', 'img', 'mp4' 등과 같은 파일 확장자에 기반하여 기설정된 값들 중에서 미리 기설정되거나 동적으로 설정될 수 있다. 여기서 파일 타입 'all'은 모든 확장자의 파일들을 의미할 수 있다. 또한, 캐릭터 타입 'CharacterType()'의 파라미터는 'string', 'hexa' 등과 같이 문자나 문자열의 종류를 의미할 수 있다. 'Character()'의 파라미터는 검색하고자 하는 문자열을 의미할 수 있으며, 별표(*)는 별표 앞의 문자열로 시작하는 모든 문자열을 의미할 수 있다.
[85]
제2 종류(920)의 패턴은 패키지 파일 내에서 특정 파일을 찾는 패턴을 의미할 수 있고, 아래 패턴 2와 같이 표현될 수 있다.
[86]
[패턴 2]
[87]
RetrieveFile:
[88]
: FileType(string) FileName(string)
[89]
예를 들어, 패키지 파일이 포함하는 파일들 중에서 DLL(Dynamic Linking Library) 타입을 갖고 파일 이름이 "Assembly-Csharp"인 파일을 찾는 패턴은 'RetrieveFile: FileType(string) FileName(Assembly-Csharp)'와 같이 구현될 수 있다. 다른 예로, 패키지 파일이 포함하는 파일들 중에서 DLL 타입의 파일을 찾는 패턴은 'RetrieveFile: FileType(string)'와 같이 구현될 수 있다.
[90]
파일 타입 'FileType()'의 파라미터는 'all', 'apk', 'txt', 'ini', 'property', 'json', 'xml', 'img', 'mp4' 등과 같은 파일 확장자에 기반하여 설정된 값들 중에서 미리 기설정되거나 또는 동적으로 설정될 수 있다. 파일 이름 'FileName()'의 파라미터 역시 미리 기설정되거나 또는 동적으로 설정될 수 있다. 필요에 따라 파일 확장자를 기준으로 파일을 탐색하기 위한 'FileExtension()'이 더 이용될 수도 있으며, 'FileExtension()'의 파라미터 역시 미리 기설정되거나 또는 동적으로 설정될 수 있다.
[91]
도 10은 본 발명의 일실시예에 있어서, 파일에서 특정 문자열을 탐지한 결과와 패키지 파일에서 특정 파일을 탐지한 결과의 예를 도시한 도면이다.
[92]
탐지된 정보(1010)는 제1 종류(910)의 패턴에 따라 탐지된 파일 이름(File name, 1011)과 매칭 스트링(Match string, 1012)을 포함할 수 있음을 나타내고 있다. 상술한 도 9의 예에서, 'json' 타입의 파일이 3 개가 존재하는 경우, 3 개의 파일들 각각에서 'string' 타입의 문자열로서 'http://*'가 탐색될 수 있으며, 탐지된 문자열들이 파일 이름별로 제공될 수 있다. 하나의 'json' 파일이 복수의 URL들을 포함하는 경우, 복수의 문자열들이 탐지될 수 있다.
[93]
또한, 탐지된 정보(1020)는 제2 종류(920)의 패턴에 따라 패키지 파일에서 탐지된 파일 이름(File name, 1021)을 포함할 수 있음을 나타내고 있다. 이 경우에도 패턴에 따라 복수의 파일 이름들이 탐색될 수 있다.
[94]
도 11은 본 발명의 일실시예에 있어서, 안드로이드 매니페스트 파일에 대한 패턴의 예를 도시한 도면이다. 도 11은 안드로이드 매니페스트 파일(AndroidManifest.xml, 830)에 대한 패턴(1100)의 종류를 나타내고 있다.
[95]
제3 종류(1110)의 패턴은 안드로이드 매니페스트 파일(830)에서 퍼미션(permission) 그룹을 찾는 패턴을 의미할 수 있으며, 아래 패턴 3과 같이 표현될 수 있다.
[96]
[패턴 3]
[97]
RetrievePermission:
[98]
: Name(string or *)
[99]
예를 들어, 패턴 'RetrievePermission: Name(*)'에 대한 탐지 결과로 'android.permission.GET_TASKS' 및 'android.permission.INTERNET'과 같은 퍼미션들이 제공될 수 있다. 다른 예로, 패턴 'RetrievePermission: Name(android.permission.READ_EXTERNAL_STORAGE)'와 같이 특정 퍼미션 이름으로 해당 이름의 퍼미션이 검색될 수도 있다. 만약, 특정 퍼미션과 관련된 취약점이 알려져 있다면, 해당 퍼미션이 존재하는지 찾기 위한 패턴이 기설정될 수 있고, 설정된 패턴에 기반하여 취약점 탐지가 수행될 수 있다. 이후 설명될 패턴들에서도 공통된 팩터들은 공통된 역할을 포함할 수 있다.
[100]
제4 종류(1120)의 패턴은 안드로이드 매니페스트 파일(830)에서 액티비티(activity) 그룹을 찾는 패턴을 의미할 수 있으며, 아래 패턴 4와 같이 표현될 수 있다.
[101]
[패턴 4]
[102]
RetrieveActivity:
[103]
: Name(string or *)
[104]
제5 종류(1130)의 패턴은 안드로이드 매니페스트 파일(830)에서 최소 SDK API 버전을 찾는 패턴을 의미할 수 있으며, 아래 패턴 5와 같이 표현될 수 있다.
[105]
[패턴 5]
[106]
RetrieveMinSDK:
[107]
: Version(string or *)
[108]
: ConditionalEquality
[109]
버전 'Version()'의 파라미터는 원하는 버전의 값이 스트링 타입으로 동적으로 설정되거나 또는 모든 버전을 의미하는 별표(*)가 활용될 수 있다. 또한, 비교조건을 의미하는 'ConditionalEquality'는 등호나 부등호를 이용하여 버전 'Version()'에서 설정된 값과 안드로이드 매니페스트 파일에 설정된 SDK API 버전간의 비교를 위해 활용될 수 있다. 예를 들어, ' RetrieveMinSDK: Version(21) ConditionalEquality(<=)'는 버전 21 이하인 경우를 탐지하는 패턴을 의미할 수 있다.
[110]
제6 종류(1140)의 패턴은 안드로이드 매니페스트 파일(830)에서 타겟 SDK API 버전을 찾는 패턴을 의미할 수 있으며, 아래 패턴 6과 같이 표현될 수 있다.
[111]
[패턴 6]
[112]
RetrieveTargetSDK:
[113]
: Version(string or *)
[114]
: ConditionalEquality
[115]
버전 'Version()'과 비교조건을 의미하는 'ConditionalEquality'는 패턴 6에서와 공통될 수 있다.
[116]
제7 종류(1150)의 패턴은 안드로이드 매니페스트 파일(830)에서 메인 어플리케이션(main application)을 찾는 패턴을 의미할 수 있으며, 아래 패턴 7과 같이 표현될 수 있다.
[117]
[패턴 7]
[118]
RetrieveMainApplication:
[119]
: Name(string or *)
[120]
제8 종류(1160)의 패턴은 안드로이드 매니페스트 파일(830)에서 서비스 그룹을 찾는 패턴을 의미할 수 있으며, 아래 패턴 8과 같이 표현될 수 있다.
[121]
[패턴 8]
[122]
RetrieveService:
[123]
: Name(string or *)
[124]
제9 종류(1170)의 패턴은 안드로이드 매니페스트 파일(830)에서 리시버 그룹을 찾는 패턴을 의미할 수 있으며, 아래 패턴 9와 같이 표현될 수 있다.
[125]
[패턴 9]
[126]
RetrieveReceiver:
[127]
: Name(string or *)
[128]
제10 종류(1180)의 패턴은 안드로이드 매니페스트 파일(830)에서 프로바이더 그룹를 찾는 패턴을 의미할 수 있으며, 아래 패턴 10과 같이 표현될 수 있다.
[129]
[패턴 10]
[130]
RetrieveProvider:
[131]
: Name(string or *)
[132]
안드로이드 매니페스트 파일(830)에서 탐색되는 퍼미션, 액티비티, 최소 SDK API 버전, 타겟 SDK API 버전, 메인 어플리케이션, 서비스, 리시버, 프로바이더는 APK에 대해 이미 잘 알려진 종래기술들을 통해 당업자가 쉽게 이해할 수 있을 것이다.
[133]
도 12는 본 발명의 일실시예에 있어서, 덱스 파일에 대한 패턴의 예를 도시한 도면이다. 도 12는 덱스 파일(dex, 820)에 대한 패턴들(1200)의 종류를 나타내고 있다.
[134]
제11 종류(1210)의 패턴은 호출된 API를 찾는 패턴을 의미할 수 있으며, 아래 패턴 11과 같이 표현될 수 있다.
[135]
[패턴 11]
[136]
DexFindApi:
[137]
: DexCalledAPI (require)
[138]
: ClassName, MethodName
[139]
: DexTraceArgument (optional)
[140]
: ArgumentIndex(number)
[141]
: ArgumentType(string)
[142]
: DexArgumentFrom (optional)
[143]
: Exceptional(true/false)
[144]
: FromNull
[145]
: List: FromAPIList
[146]
:ClassName, MethodName
[147]
: List: FromFieldList
[148]
:ClassName, MethodName
[149]
여기서 'DexFindApi'는 호출된 API를 찾는 패턴의 패턴명을 의미할 수 있다. 또한, 'DexCalledAPI'는 특정 클래스의 특정 메서드를 지정하기 위한 팩터를 의미할 수 있다. 이러한 클래스와 메서드는 'ClassName' 및 'MethodName'에 따라 지정될 수 있다. 또한, 'DexTraceArgument'는 특정 인덱스 및/또는 특정 타입의 인수(argument)를 지정하기 위한 팩터를 의미할 수 있다. 또한, 'DexArgumentFrom'은 예외처리 여부를 결정하거나 널(null)로부터의 인수를 탐지하거나 또는 특정 API 리스트나 필드 리스트를 지정하기 위한 팩터를 의미할 수 있다.
[150]
아래 표 1은 인스트럭션 매스의 제1 예를 표 2는 패턴의 제1 예를 각각 나타내고 있다.
[151]
[표1]
Class cfindMe{ public void mfindMe{ SSLContext sc = SSLContext.getInstance("TLS"); sc.init(null, new TrustManager[]{new VulnClass01()}, new java.security.SecureRandom()); }}

[152]
[153]
[표2]
DexFindApi: DexCalledAPI:: ClassName(Liavax/net/ssl/SSLContext) MethodName(init)

[154]
표 2의 패턴은 클래스 'Liavax/net/ssl/SSLContext'의 메서드 'init'를 호출하는 API를 찾는 패턴을 의미할 수 있다. 이 경우, 취약점 탐지 시스템은 해당 패턴에 기반하여 표 1의 인스트럭션 매스에서 클래스 'cfindMe'의 메서드 'mfindMe'가 해당 메서드 'init'를 호출함을 탐지할 수 있고, 탐지 결과로서 'called from cfindMe->mfindMe'와 같은 메시지를 제공할 수 있다.
[155]
아래 표 3은 인스트럭션 매스의 제2 예를 표 4는 패턴의 제2 예를 각각 나타내고 있다.
[156]
[표3]
Class cfindMe{ public void mfindMe{SSLContext sc = SSLContext.getInstance("TLS");TrustManager tm = TrustManagerFactory.getTrustManagers();sc.init(null, tm, new java.security.SecureRandom()); }}

[157]
[표4]
DexFindApi : DexCalledAPI :: ClassName (Ljavax/net/ssl/SSLContext) MethodName(init) DexTraceArgument :: ArgumentIndex(2): ArgumentType(Ljavax/net/ssl/TrustManager) FromApiList :: FromApiList[0]{ClassName(Ljavax/net/ssl/TrustManagerFactory), MethodName(getTrustManagers) }: Exception(true)

[158]
표 4의 패턴은 클래스 'Liavax/net/ssl/SSLContext'의 메서드 'init'를 호출하는 API를 찾아 메서드 'init'의 인덱스 '2'의 타입 'Ljavax/net/ssl/TrustManager'의 인수를 추적하되, ApiList에 지정된 클래스 'Ljavax/net/ssl/TrustManagerFactory'와 메서드 'getTrustManagers'에 대해서는 예외(true)로 취급하는 패턴을 의미할 수 있다.
[159]
표 3을 살펴보면, 클래스 'Liavax/net/ssl/SSLContext'의 메서드 'init'를 호출하는 API는 클래스 'cfindMe'의 메서드 'mfindMe'이고, 메서드 'init'의 인덱스 '2'의 타입 'Ljavax/net/ssl/TrustManager'의 인수가 'tm'임을 알 수 있다. 그러나 클래스 'Ljavax/net/ssl/TrustManagerFactory'의 메서드 'getTrustManagers'에 대해서는 예외처리를 하기 때문에, 인수 'tm'이나 클래스 'cfindMe'의 메서드 'mfindMe'가 탐지되지 않고, 예외처리될 수 있다.
[160]
아래 표 5는 인스트럭션 매스의 제3 예를 표 6은 패턴의 제3 예를 각각 나타내고 있다.
[161]
[표5]
Class cfindMe{public void mfindMe{SSLContext sc = SSLContext.getInstance("TLS");sc.init(null, null, new java.security.SecureRandom());}}

[162]
[표6]
DexFindApi : DexCalledAPI :: ClassName (Ljavax/net/ssl/SSLContext) MethodName(init) DexTraceArgument :: ArgumentIndex(2) DexArgumentFrom :: FromNull

[163]
표 6의 패턴은 클래스 'Liavax/net/ssl/SSLContext'의 메서드 'init'를 호출하는 API를 찾고, 메서드 'init'의 인덱스 '2'의 인수를 추적하되, 널(null)로부터의 인수인지를 찾는 패턴을 의미할 수 있다.
[164]
표 5의 인스트럭션 매스를 살펴보면, 클래스 'Liavax/net/ssl/SSLContext'의 메서드 'init'를 호출하는 API는 클래스 'cfindMe'의 메서드 'mfindMe'이고, 메서드 'init'의 인덱스 '2'의 인수가 널(null)임을 알 수 있다. 따라서, 'DexCalledAPI'에 따라 클래스 'cfindMe'의 메서드 'mfindMe'가 해당 메서드 'init'를 호출함을 탐지할 수 있고, 'DexTraceArgument' 및 'DexArgumentFrom'에 따라 널(null)로부터의 인수가 메서드 'init'의 인덱스 2에 존재함을 탐지할 수 있다. 이때, 탐지 결과로서 'called from cfindMe->mfindMe' 메시지 및 'argument from null' 메시지가 제공될 수 있다.
[165]
아래 표 7은 인스트럭션 매스의 제4 예를 표 8은 패턴의 제4 예를 각각 나타내고 있다.
[166]
[표7]
Class A {public init(){ String str = "xxx"; C.m(str);}}Class C { public static void m(string input){StringBuilder str = new StringBuilder(input);str.append("xx");System.loadlibrary(str); }}

[167]
[표8]
DexFindApi : DexCalledAPI :: ClassName (System) MethodName(loadLibrary) DexTraceArgument :: ArgumentIndex(1)

[168]
표 8의 패턴은 클래스 'System'의 메서드 'loadLibrary'를 호출하는 API를 찾고, 메서드 'loadLibrary'의 인덱스 '1'의 인수를 추적하는 패턴을 의미할 수 있다.
[169]
표 7의 인스트럭션 매스에 따르면, 클래스 'System'의 메서드 'loadLibrary'를 호출하는 API는 클래스 'C'의 메서드 'm'임을 알 수 있다. 이때, 메서드 'loadLibrary'의 인덱스 '1'의 인수는 'str'이며, 인수 'str'은 메서드 m을 호출하는 클래스 'A'의 메서드 'init'에서 "xxx"이고, 클래스 'C'의 메서드 'm'에서 "xx"가 'append'됨을 알 수 있다. 이러한 인수 'str'에 대한 추적은 앞서 설명한 바와 같이 미리 생성 및 관리되는 메서드들간의 호출 관계를 이용하여 이루어질 수 있다.
[170]
이때 패턴에 대한 탐지 결과는 아래 표 9의 메시지와 같이 제공될 수 있다.
[171]
[표9]
called from C->m argument str is string str+="xx" str=input(parameter) Parameter is "xxx" in A-> init

[172]
'called from C->m'는 클래스 'System'의 메서드 'loadLibrary'를 호출하는 API가 클래스 C의 메서드 m임을 나타낼 수 있다. 'argument str is string'는 인수 'str'의 타입이 'string'임을 나타낼 수 있다. 또한, 'str+="xx"'는 표 7의 메서드 'str.append("xx");'에 의해 인수 'str'에 "xx"가 덧붙여짐을 의미할 수 있다. 또한, str=input(parameter)는 인수 'str'이 파라미터 'input'으로서 전달되었음을 의미할 수 있으며, 'Parameter is "xxx" in A->init' 전달된 파라미터 'input'은 클래스 'A'의 메서드 'init'에서 "xxx" 임을 의미할 수 있다. 따라서, 클래스 'System'의 메서드 'loadLibrary'의 인덱스 '1'의 인수인 'str'이 현재 'string' 타입의 값 "xxxxx"를 가짐을 알 수 있다.
[173]
아래 표 10은 인스트럭션 매스의 제5 예를 표 11은 패턴의 제5 예를 각각 나타내고 있다.
[174]
[표10]
Class cfindMe{ public void mfindMe{SSLContext sc = SSLContext.getInstance("TLS");TrustManager tm = SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER;sc.init(null, tm, new java.security.SecureRandom()); }}

[175]
[표11]
DexFindApi : DexCalledAPI :: ClassName (Liavax/net/ssl/TrustManager) MethodName(init) DexTraceArgument :: ArgumentIndex(2) DexArgumentFrom :Exception(false): FromFieldList FromField[0]{ ClassName(Lorg/apache/http/conn/ssl/SSLSocketFactory), FieldName(ALLOW_ALL_HOSTNAME_VERIFIER)}

[176]
표 11의 패턴은 클래스 'Liavax/net/ssl/SSLContext'의 메서드 'init'를 호출하는 API를 찾고, 메서드 'init'의 인덱스 '2'의 인수를 추적하되, 'FromFieldList'를 통해 지정되는 필드들에 대해서는 예외 처리를 하지 않는 패턴을 의미할 수 있다.
[177]
표 10의 인스트럭션 매스를 통해 클래스 'Liavax/net/ssl/SSLContext'의 메서드 'init'를 호출하는 API가 클래스 'cfindMe'의 메서드 'mfindMe'임을 알 수 있으며, 메서드 'init'의 인덱스 '2'의 인수가 'tm'임을 알 수 있다.
[178]
이때, 클래스 'Lorg/apache/http/conn/ssl/SSLSocketFactory'의 필드 'ALLOW_ALL_HOSTNAME_VERIFIER'는 예외처리를 하지 않기 때문에 클래스 'Liavax/net/ssl/SSLContext'의 메서드 'init'를 호출하는 API가 클래스 'cfindMe'의 메서드 'mfindMe'임을 알리기 위한 메시지(일례로, 'called from cfindMe ->mfindMe')가 탐지 결과로서 제공될 수 있으며, 메서드 'init'의 인덱스 '2'의 인수 'tm'이 필드 'SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER'로부터의 인수임을 알리기 위한 메시지(일례로, 'argument from SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER')가 탐지 결과로서 더 제공될 수 있다.
[179]
다시 도 12를 참조하면, 제12 종류(1220)의 패턴은 메서드의 특정 인스트럭션을 찾는 패턴을 의미할 수 있으며, 아래 패턴 12와 같이 표현될 수 있다.
[180]
[패턴 12]
[181]
DexMethodBody :
[182]
: MethodName (require)
[183]
: MethodName
[184]
: DexInstructionList (require)
[185]
: List<DexInstruction>
[186]
: Except(ture/false)
[187]
: DexInstruction
[188]
: VoidBody
[189]
: InvokeInstruction
[190]
: ClassName(string)
[191]
: MethodName(string)
[192]
여기서, 'DexMethodyBody'는 특정 메서드 내에서 특정 인스트럭션을 찾기 위한 패턴명을 의미할 수 있다. 또한, 'MethodName'은 메서드를 지정하기 위한 팩터를 의미할 수 있다. 또한, 'DexInstructionList'는 탐지하기 위한 인스트럭션을 특정하기 위한 팩터를 의미할 수 있다. 예를 들어 'List<DexInstruction>'은 탐지하기 위한 인스트럭션을 지정 지정하기 위해 이용될 수 있으며, 'Except(true/false)'는 지정된 인스트럭션의 예외 처리 여부를 결정하기 위해 이용될 수 있다. 또한, 'VoidBody'는 void 타입의 인스트럭션을 지정하기 위해 이용될 수 있으며, 'InvokeInstruction'은 호출되는 인스트럭션을 지정하기 위해 이용될 수 있다.
[193]
아래 표 12는 인스트럭션 매스의 제6 예를 표 13은 패턴의 제6 예를 각각 나타내고 있다.
[194]
[표12]
TrustManager[] trustAllCerts = new TrustManager[]{new X509TrustManager() {@Overridepublic void checkServerTrusted(…) { throws IllegalArgumentException { }}}

[195]
[표13]
DexMethodyBody : MethodName :: checkServerTrusted DexInstructionList :: {DexInstruction(VoidBody)}: Except(false)

[196]
표 13의 패턴은 메서드 'checkServerTrusted'가 void 타입인지 여부를 확인하는 패턴을 의미할 수 있다. 표 12의 인스트럭션 매스에서 메서드 'checkServerTrusted'는 void 타입으로 선언되어 있기 때문에 메서드 'checkServerTrusted'가 void 타입임을 알리기 위한 메시지(일례로, 'Body is void')가 제공될 수 있다.
[197]
아래 표 14는 인스트럭션 매스의 제7 예를 표 15는 패턴의 제7 예를 각각 나타내고 있다.
[198]
[표14]
TrustManager[] trustAllCerts = new TrustManager[]{new X509TrustManager() { @Override public void checkServerTrusted( … ) { throws IllegalArgumentException { for (java.security.cert.X509Certificate c : chain) { if(c.getIssuerDN().getName().compareTo("correct")!=0){ throw new CertificateException("None of the TrustManagers trust this certificate chain"); } } } }}

[199]
[표15]
DexMethodyBody : MethodName :: checkServerTrusted DexInstructionList :: {DexInstruction(InvokeInstruction(Ljava/security/cert/CertificateException,<init>)),DexInstruction(InvokeInstruction(Ljava/lang/IllegalArgumentException,<init>))}: Except(false)

[200]
표 13의 패턴은 메서드 'checkServerTrusted'에서 메서드 'Ljava/security/cert/CertificateException'를 호출하는 인스트럭션과 메서드 'Ljava/lang/IllegalArgumentException'를 호출하는 인스트럭션을 찾는 패턴을 의미할 수 있다. 표 14의 인스트럭션 매스와 관련하여, 메서드 'Ljava/security/cert/CertificateException'를 호출하는 인스트럭션이 존재함을 알 수 있다. 따라서, 메서드 'Ljava/security/cert/CertificateException'를 호출하는 인스트럭션이 탐지되었음을 알리기 위한 메시지(일례로, 'Invoke instruction isdetected, CertificateException-><init>')가 제공될 수 있다.
[201]
앞서 간략히 설명한 바와 같이, 패턴들은 결합(join)될 수 있다. 예를 들어, 패턴 'DexFindApi'를 이용하여 특정 클래스 'a'를 찾은 후, 패턴 'DexMethodyBody'를 이용하여 클래스 'a'의 메서드에서 특정 인스트럭션을 찾을 수 있다. 예를 들어, 하나의 룰에 이러한 두 개의 패턴들이 조인되어 포함될 수 있다.
[202]
다시 도 12를 참조하면, 제13 종류(1230)의 패턴은 특정 클래스의 자식 클래스를 찾는 패턴을 의미할 수 있으며, 아래 패턴 13과 같이 표현될 수 있다.
[203]
[패턴 13]
[204]
DexFindSubClass :
[205]
: DexParent (require)
[206]
: ClassName(string)
[207]
여기서, 'DexFindSubClass'는 특정 클래스의 자식 클래스를 찾는 패턴명을 의미할 수 있다. 'DexParent'는 찾고자 하는 자식 클래스의 부모 클래스를 지정하기 위한 팩터를 의미할 수 있다.
[208]
아래 표 16은 인스트럭션 매스의 제8 예를 표 17은 패턴의 제8 예를 각각 나타내고 있다.
[209]
[표16]
Class cfindMe extend IamYourFather {}Class csearchMe extend IamYourFather {}

[210]
[표17]
DexFindSubClass : DexParent :: ClassName(IamYourFather)

[211]
표 17은 클래스 'IamYourFather'를 부모로 갖는 자식 클래스를 찾기 위한 패턴을 의미할 수 있다. 표 16의 인스트럭션 매스와 관련하여, 클래스 'cfindMe'와 클래스 'csearchMe'는 각각 클래스 'IamYourFather'의 자식 노드이기 때문에 클래스 'cfindMe'와 클래스 'csearchMe'가 각각 탐지될 수 있으며, 탐지된 클래스 'cfindMe'와 클래스 'csearchMe'를 알리기 위한 메시지가 제공될 수 있다.
[212]
패턴들간의 결합(join)은 보다 다양하게 활용될 수 있다. 예를 들어, 패턴 'DexFindSubClass'를 이용하여 클래스 'a'를 부모로 갖는 자식 클래스 'b'를 찾은 후, 탐지된 클래스 'b'를 패턴 'DexFindApi'에서의 'ClassName(b)'와 같이 동적 파라미터로 활용될 수 있다.
[213]
도 13은 본 발명의 일실시예에 있어서, so 파일에 대한 패턴의 예를 도시한 도면이다. 도 13은 so 파일(840)에 대한 패턴들(1400)의 종류를 나타내고 있다.
[214]
제14 종류(1310)의 패턴은 so 파일(840)에서 스트링(특정 문자열)을 검색하는 패턴을 의미할 수 있으며, 아래 패턴 14와 같이 표현될 수 있다.
[215]
[패턴 14]
[216]
RetrieveSoContents :
[217]
: Character(string)
[218]
여기서, 패턴 'RetrieveSoContents'는 so 파일(840)에서 스트링을 검색하는 패턴명을 의미할 수 있으며, 'Character(string)'은 so 파일(840)에서 검색하고자 하는 특정 스트링(일례로, 'http://*'와 같은 문자열)을 지정하기 위한 팩터를 의미할 수 있다. 이때, 스트링은 so 파일(840)이 포함하는 '.rdata' 섹션에서 검색될 수 있다.
[219]
제15 종류(1320)의 패턴은 so 파일(840)에서 API를 검색하는 패턴을 의미할 수 있으며, 아래 패턴 15와 같이 표현될 수 있다.
[220]
[패턴 15]
[221]
RetrieveApiContents :
[222]
: APIType(iat) Name(strcpy)
[223]
여기서, 패턴 'RetrieveApiContents'는 so 파일(840)에서 API를 검색하는 패턴명을 의미할 수 있으며, 'APIType()'은 API의 타입을 IAT(Import Address Table)과 EAT(Export Address Table) 중 하나로 설정하기 위한 팩터를, 'Name()'은 검색하고자 하는 API의 이름을 지정하기 위한 팩터를 각각 의미할 수 있다.
[224]
도 14는 본 발명의 일실시예에 있어서, dll 파일에 대한 패턴의 예를 도시한 도면이다. 도 14은 dll 파일(850)에 대한 패턴(1400)의 종류를 나타내고 있다.
[225]
제16 종류(1410)의 패턴은 dll 파일(850)에서 스트링(특정 문자열)을 검색하기 위한 패턴을 의미할 수 있으며, 아래 패턴 16과 같이 표현될 수 있다.
[226]
[패턴 16]
[227]
RetrieveDllContents :
[228]
: Character(string)
[229]
여기서, 패턴 'RetrieveDllContents'는 dll 파일(850)에서 스트링을 검색하는 패턴명을 의미할 수 있으며, 'Character(string)'은 dll 파일(850)에서 검색하고자 하는 특정 스트링(일례로, 'http://*'와 같은 문자열)을 지정하기 위한 팩터를 의미할 수 있다.
[230]
패턴에서 파라미터들은 앞서 설명한 바와 같이 동적으로 결정될 수 있다. 예를 들어, 패턴 a와 패턴 b의 결합을 통해 패턴 a를 통해 추출되는 값이 패턴 b를 위한 파라미터로 동적으로 활용될 수 있다.
[231]
상술한 패턴 1 내지 패턴 16은 APK를 위한 일실시예로서 다른 패키지 파일을 위해서는 다른 패턴이 활용될 수 있다. 취약점 탐지 시스템은 이러한 패턴을 등록받거나 등록된 패턴을 편집할 수 있는 에디터 기능을 관리자나 이용자에게 제공할 수 있다. 예를 들어, 어플리케이션에 대한 새로운 취약점이 알려지는 경우, 새롭게 알려지는 취약점을 탐지할 수 있도록 에디터 기능을 통해 새로운 패턴이 등록될 수 있으며, 취약점 탐지 시스템은 새로운 패턴을 통해 어플리케이션의 패키지 파일들을 분석하여 취약점을 탐지할 수 있다.
[232]
또 다른 실시예에서 패턴의 종류들은 아래 표 18과 같이 나타날 수 있다.
[233]
[표18]
Type 탐지대상
find_api dex
find_sub dex
method_body dex
method_annotation dex
exist_api dex
exist_field dex
manifest AndroidManifest.xml
xml *.xml
dll *.dll
so *.so
find_file 모든 파일

[234]
표 18의 패턴들 중 패턴 'dex(find_api)'은 앞서 설명한 패턴 11 'DexFindApi'에 대응할 수 있다. 이러한 패턴 'dex(find_api)'는 메서드 내에서 지정된 api의 호출을 탐지하기 위한 패턴일 수 있다.
[235]
또한, 패턴 'dex(find_sub)'은 앞서 설명한 패턴 13 'DexFindSubClass'에 대응할 수 있으며, 지정된 클래스를 상속받아 구현한 자식 클래스들을 탐지하기 위해 이용될 수 있다.
[236]
또한, 패턴 'dex(method_body)'은 앞서 설명한 패턴 12 'DexMethodBody'에 대응할 수 있으며, aptjem 내의 인보크 인스트럭션(invoke instruction), 인스트럭션 개수, 메서드 이름 등을 비교 및 탐지하기 위해 이용될 수 있다.
[237]
또한, 패턴 'dex(method_annotation)'은 Java에서 메서드에 지정된 주석(annotation)을 탐지하기 위해 이용될 수 있다.
[238]
또한, 패턴 'dex(exist_api)'는 특정 클래스 및/또는 메서드가 존재하는지를 탐색하기 위해 이용될 수 있다. 예를 들어, 이후 설명될 논리 연산을 이용한 패턴들의 조합을 이용하는 경우, 패턴 조합 (dex(exist_api) sub dex(find_api))는 왼쪽 패턴인 'dex(exist_api)'를 통해 탐색된 클래스를 대상으로 오른쪽 패턴인 'dex(find_api)'를 통해 지정된 api 호출을 탐색할 수 있다.
[239]
또한, 패턴 'dex(exist_field)'는 특정 클래스의 멤버가 존재하는지를 탐색하기 위해 이용될 수 있다. 예를 들어, 패턴 'dex(exist_field)'는 '클래스 → 멤버이름'과 같은 형태의 값을, 해당 멤버의 값과 비교할 정규표현식을 지정함으로써 지정된 정규표현식에 해당하는 멤버가 탐색될 수 있다.
[240]
또한, 패턴 'manifest'는 AndroidManifest.xml의 항목들과의 비교를 위해 이용될 수 있다.
[241]
또한, 패턴 'xml', 'so', 'dll', 'find_file'은 각각 xml 파일, so 파일, dll 파일 및 모든 파일에서 탐색을 수행하기 위해 이용될 수 있다. 예를 들어, dll 파일에서 탐색을 수행하는 예에 대해서는 앞서 패턴 16 (RetrieveDllContents)을 통해 자세히 설명한 바 있다.
[242]
또한, 패턴들은 논리 연산과 괄호를 이용하여 조합되어 활용될 수도 있다. 예를 들어, 아래 표 19는 패턴들의 조합을 위해 활용 가능한 논리 연산의 예를 나타내고 있다.
[243]
[표19]
Type 설명 예제
or 일반적인 논리 연산의 or true or true = truefalse or true = true
and 일반적인 논리 연산의 and true and false = falsetrue and true = true
sub 왼쪽 패턴이 탐지되면 그 탐지 결과가 오른쪽 패턴의 패턴으로 사용됨. true and true = truefalse and true = false

[244]
예를 들어, (패턴 A or 패턴 B)에서 패턴 A가 탐지되면 이미 'true'이기 때문에 패턴 B에 대한 탐지는 수행되지 않을 수 있다. 또한, (패턴 A sub 패턴 B)에서 패턴 A가 'false'라면 패턴 B에 대한 탐지는 수행되지 않을 수 있다. 이러한 논리 연산을 이용한 패턴들의 조합에 대한 보다 구체적인 예로, 패턴 조합 (dex(find_sub_class) sub dex(find_api))를 들 수 있다. 해당 패턴 조합에서는 왼쪽의 패턴 'dex(find_sub_class)'를 통해 모든 액티비티들의 자식들을 탐색하게 되고, 왼쪽의 패턴을 통해 탐색된 클래스들이 오른쪽 패턴을 위한 클래스들로 이용될 수 있다. 다시 말해, 오른쪽 패턴 'dex(find_api)'는 왼쪽 패턴을 통해 탐색된 클래스들에서 api를 탐색하게 된다.
[245]
도 15는 본 발명의 일실시예에 따른 서버의 프로세서가 포함할 수 있는 구성요소의 예를 도시한 블록도이고, 도 16은 본 발명의 일실시예에 따른 서버가 수행할 수 있는 취약점 탐지 방법의 예를 도시한 흐름도이다.
[246]
본 발명의 실시예들에 따른 취약점 탐지 시스템은 앞서 설명한 서버(150)와 같은 컴퓨터 장치의 형태로 구현될 수 있다. 또한, 도 15에 도시된 바와 같이 서버(150)의 프로세서(222)는 취약점 탐지 시스템을 구현하기 위한 구성요소들로서 탐지 패턴 관리부(1510), 패키지 파일 등록부(1520) 및 취약점 정보 탐지부(1530)를 포함할 수 있다. 이러한 프로세서(222) 및 프로세서(222)의 구성요소들은 도 16의 취약점 탐지 방법이 포함하는 단계들(1610 내지 1630)을 수행할 수 있다. 이때, 프로세서(222) 및 프로세서(222)의 구성요소들은 메모리(221)가 포함하는 운영체제의 코드나 적어도 하나의 프로그램의 코드에 따른 제어 명령(instruction)을 실행하도록 구현될 수 있다. 여기서, 프로세서(222)의 구성요소들은 서버(150)에 저장된 코드가 제공하는 제어 명령에 따라 프로세서(222)에 의해 수행되는 프로세서(222)의 서로 다른 기능들(different functions)의 표현들일 수 있다. 예를 들어, 프로세서(222)가 상술한 제어 명령에 따라 탐지 패턴들을 관리하는 프로세서(222)의 기능적 표현으로 탐지 패턴 관리부(1510)가 사용될 수 있다.
[247]
단계(1610)에서 탐지 패턴 관리부(1510)는 어플리케이션의 설치 및 구동을 위한 패키지 파일이 포함하는 파일들 및 파일들이 포함하는 코드들 중 적어도 하나와 관련하여, 어플리케이션의 취약점 진단을 위한 기 설정된 탐지 패턴들을 관리할 수 있다. 탐지 패턴들에 대해서는 앞서 자세한 실시예들을 설명하였으며, 취약점에 따라 보다 다양한 실시예들이 도출될 수 있음을 앞서 설명한 실시예들을 통해 당업자가 쉽게 이해할 수 있을 것이다.
[248]
이때, 탐지 패턴 관리부(1510)는 단계(1610)에서 새로운 탐지 패턴을 등록받거나 또는 등록된 탐지 패턴을 편집하기 위한 에디터 기능을 제공하고, 제공된 에디터 기능을 통해 등록 또는 편집된 탐지 패턴에 대한 정보를 저장 및 관리할 수 있다. 에디터 기능은 일례로 특정 웹페이지의 형태나 특정 어플리케이션의 형태로 취약점 탐지 시스템의 관리자나 이용자에게 제공될 수 있다. 예를 들어, 관리자의 단말에 설치되는 특정 어플리케이션을 통해 관리자의 단말과 취약점 탐지 시스템이 통신할 수 있고, 특정 어플리케이션에서 등록 또는 편집되는 탐지 패턴에 대한 정보가 네트워크를 통해 취약점 탐지 시스템으로 전송될 수 있다. 이때, 탐지 패턴 관리부(1510)는 새로운 탐지 패턴을 등록하거나 또는 편집된 탐지 패턴을 갱신할 수 있다.
[249]
앞선 실시예들에서는 패턴이 포함하는 팩터의 파라미터가 기설정될 수도 있으나, 필요에 따라 동적으로 결정될 수도 있음을 설명하였고, 파라미터가 동적으로 결정될 수 있음에 따라 보다 다양한 방식으로 탐지 패턴이 구현될 수 있음을 설명하였다.
[250]
단계(1620)에서 패키지 파일 등록부(1520)는 어플리케이션의 설치 및 구동을 위해 이용자들에게 배포하기 위한 패키지 파일을 등록할 수 있다. 서버(150)는 이미 설명한 바와 같이 취약점 탐지 시스템이 포함되는 형태로 구현될 수 있다. 예를 들어, 어플리케이션 퍼블리셔의 시스템과 취약점 탐지 시스템이 결합된 형태로 서버(150)가 구현될 수 있다. 이때, 패키지 파일은 어플리케이션 퍼블리셔가 이용자들에게 배포하기 위해 개발자측으로부터 제공받아 등록될 수 있다.
[251]
이때, 등록되는 패키지 파일에서 각각의 파일들이 식별될 수 있으며, 클래스들과 메서드들이 식별될 수 있다. 또한, 메서드들 각각은 분기명령(분기문)에 기반하여 인스트럭션 매스의 형태로 구분될 수 있으며, 인스트럭션 매스들간의 호출 관계 및/또는 메서드들간의 호출 관계가 트리 구조와 같은 데이터 구조의 형태로 저장 및 관리될 수 있다. 이러한 호출 관계에 대한 정보는 인수(argument)의 추적이나 호출된 API 등을 검색하기 위해 활용될 수 있다.
[252]
단계(1630)에서 취약점 정보 탐지부(1530)는 탐지 패턴들 중 적어도 하나의 탐지 패턴에 따라 등록된 패키지 파일을 분석하여 적어도 하나의 탐지 패턴별로 취약점 정보를 탐지할 수 있다. 이러한 취약점 정보의 탐지에 대해서는 앞서 다양한 실시예들을 통해 자세히 설명한 바 있다. 이때, 취약점 정보 탐지부(1530)는 복수의 탐지 패턴을 결합(join)하여 제1 탐지 패턴에 따라 등록된 패키지 파일에서 탐지된 제1 정보를 제2 탐지 패턴이 포함하는 팩터의 파라미터로 동적으로 설정하고, 탐지된 제1 정보가 파라미터로 설정된 팩터를 포함하는 제2 탐지 패턴에 따라 등록된 패키지 파일에서 취약점 정보를 탐지할 수 있다.
[253]
탐지 패턴은 등록된 패키지 파일이 포함하는 파일들 중 적어도 하나의 파일로부터 특정 문자열을 검색하는 패턴을 포함할 수 있다. 예를 들어, 앞서 설명한 패턴 1, 패턴 14 및 패턴 16은 파일에서 특정 문자열(또는 스트링)을 검색하는 패턴에 대해 설명하고 있다. 특히 패턴 1은 등록된 패키지 파일이 포함하는 파일들 중 특정 타입의 파일을 지정하기 위한 팩터를 포함함을 설명하였다.
[254]
또한, 탐지 패턴은 등록된 패키지 파일이 포함하는 파일들 중 특정 타입의 파일 및 특정 파일 이름의 파일 중 적어도 하나를 검색하기 위한 패턴을 포함할 수 있다. 예를 들어, 앞서 설명한 패턴 2는 지정된 타입의 파일 및/또는 지정된 파일 이름의 파일을 검색하기 위한 패턴에 대해 설명하고 있다.
[255]
또한, 탐지 패턴은 APK(Android application package)가 포함하는 안드로이드 매니페스트 파일에서 퍼미션(permission)을 검색하기 위한 패턴, 액티비티(activity)를 검색하기 위한 패턴, SDK(Software Development Kit) API(Application Programming Interface) 버전을 검색하기 위한 패턴, 메인 어플리케이션(main application)을 검색하기 위한 패턴, 서비스를 검색하기 위한 패턴, 리시버(receiver)를 검색하기 위한 패턴 및 프로바이더(provider)를 검색하기 위한 패턴 중 적어도 하나의 패턴을 포함할 수 있다. 이러한 패턴들은 패턴 3 내지 패턴 10을 통해 자세히 설명한 바 있다.
[256]
또한, 탐지 패턴은 지정된 클래스 및 지정된 메서드 중 적어도 하나에서 호출된 API를 검색하는 패턴을 포함할 수 있다. 이때, 호출된 API를 검색하기 위한 패턴은 클래스 및 메서드 중 적어도 하나를 지정하는 팩터, 지정된 메서드의 인수(argument)를 추적하기 위해 상기 인수의 인덱스 및 타입 중 적어도 하나를 지정하는 팩터 및 지정된 메서드의 인수에 대해 지정된 API, 지정된 필드 및 널(null) 중 적어도 하나로부터 전달된 인수를 탐지하기 위해, API, 필드 및 널(null) 중 적어도 하나를 지정하는 팩터 중 적어도 하나의 팩터를 포함할 수 있다. 이러한 패턴에 대해서는 패턴 11을 통해 자세히 설명한 바 있다.
[257]
또한, 탐지 패턴은 지정된 메서드로부터 지정된 인스트럭션을 검색하는 패턴을 포함할 수 있다. 이때, 특정 인스트럭션을 검색하기 위한 패턴은 검색할 인스트럭션을 지정하는 팩터, 검색할 인스트럭션의 타입을 지정하는 팩터 및 검색할 인스트럭션이 호출하는 클래스와 메서드를 지정하는 팩터 중 적어도 하나의 팩터를 포함할 수 있다. 이러한 패턴에 대해서는 패턴 12를 통해 자세히 설명한 바 있다.
[258]
또한, 탐지 패턴은 지정된 클래스의 자식 클래스를 검색하는 패턴 및/또는 등록된 패키지 파일이 포함하는 파일들 중 적어도 하나의 파일에서 API를 검색하는 패턴을 포함할 수 있다. 이러한 패턴들에 대해서는 패턴 13 및 패턴 15를 통해 자세히 설명한 바 있다.
[259]
이상에서와 같이, 본 발명의 실시예들에 따르면, 어플리케이션의 취약점(vulnerability)을 진단하기 위한 탐색 패턴을 미리 설정하고, 설정된 탐지 패턴에 기반하여 배포를 위해 등록되는 어플리케이션의 패키지 파일에 대한 취약점을 탐지할 수 있다.
[260]
이상에서 설명된 시스템 또는 장치는 하드웨어 구성요소, 소프트웨어 구성요소 또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 예를 들어, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPGA(field programmable gate array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 어플리케이션을 수행할 수 있다. 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다. 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다. 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 콘트롤러를 포함할 수 있다. 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.
[261]
소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치에 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록매체에 저장될 수 있다.
[262]
실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 이러한 기록매체는 단일 또는 수개 하드웨어가 결합된 형태의 다양한 기록수단 또는 저장수단일 수 있으며, 어떤 컴퓨터 시스템에 직접 접속되는 매체에 한정되지 않고, 네트워크 상에 분산 존재하는 것일 수도 있다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다.

발명의 실시를 위한 형태

[263]
이상과 같이 실시예들이 비록 한정된 실시예와 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.
[264]
그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

청구범위

[청구항 1]
어플리케이션의 취약점을 탐지하는 방법에 있어서, 어플리케이션의 설치 및 구동을 위한 패키지 파일이 포함하는 파일들 및 상기 파일들이 포함하는 코드들 중 적어도 하나와 관련하여, 상기 어플리케이션의 취약점 진단을 위한 기 설정된 탐지 패턴들을 관리하는 단계; 어플리케이션의 설치 및 구동을 위해 이용자들에게 배포하기 위한 패키지 파일을 등록하는 단계; 및 상기 탐지 패턴들 중 적어도 하나의 탐지 패턴에 따라 상기 등록된 패키지 파일을 분석하여 상기 적어도 하나의 탐지 패턴별로 취약점 정보를 탐지하는 단계 를 포함하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 2]
제1항에 있어서, 상기 기 설정된 탐지 패턴들을 관리하는 단계는, 새로운 탐지 패턴을 등록받거나 또는 등록된 탐지 패턴을 편집하기 위한 에디터 기능을 제공하고, 상기 제공된 에디터 기능을 통해 등록 또는 편집된 탐지 패턴에 대한 정보를 저장 및 관리하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 3]
제1항에 있어서, 상기 적어도 하나의 탐지 패턴별로 취약점 정보를 탐지하는 단계는, 복수의 탐지 패턴을 결합(join)하여 제1 탐지 패턴에 따라 상기 등록된 패키지 파일에서 탐지된 제1 정보를 제2 탐지 패턴이 포함하는 팩터의 파라미터로 동적으로 설정하고, 상기 탐지된 제1 정보가 파라미터로 설정된 팩터를 포함하는 상기 제2 탐지 패턴에 따라 상기 등록된 패키지 파일에서 취약점 정보를 탐지하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 4]
제1항에 있어서, 상기 탐지 패턴은 상기 등록된 패키지 파일이 포함하는 파일들 중 적어도 하나의 파일로부터 특정 문자열을 검색하는 패턴을 포함하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 5]
제4항에 있어서, 상기 특정 문자열을 검색하기 위한 패턴은 상기 등록된 패키지 파일이 포함하는 파일들 중 특정 타입의 파일을 지정하기 위한 팩터를 포함하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 6]
제1항에 있어서, 상기 탐지 패턴은 상기 등록된 패키지 파일이 포함하는 파일들 중 지정된 타입의 파일 및 지정된 파일 이름의 파일 중 적어도 하나를 검색하기 위한 패턴을 포함하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 7]
제1항에 있어서, 상기 탐지 패턴은 APK(Android application package)가 포함하는 안드로이드 매니페스트 파일에서 퍼미션(permission)을 검색하기 위한 패턴, 액티비티(activity)를 검색하기 위한 패턴, SDK(Software Development Kit) API(Application Programming Interface) 버전을 검색하기 위한 패턴, 메인 어플리케이션(main application)을 검색하기 위한 패턴, 서비스를 검색하기 위한 패턴, 리시버(receiver)를 검색하기 위한 패턴 및 프로바이더(provider)를 검색하기 위한 패턴 중 적어도 하나의 패턴을 포함하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 8]
제1항에 있어서, 상기 탐지 패턴은 지정된 클래스 및 지정된 메서드 중 적어도 하나에서 호출된 API를 검색하는 패턴을 포함하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 9]
제8항에 있어서, 상기 호출된 API를 검색하기 위한 패턴은 클래스 및 메서드 중 적어도 하나를 지정하는 팩터를 포함하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 10]
제8항에 있어서, 상기 호출된 API를 검색하기 위한 패턴은 상기 지정된 메서드의 인수(argument)를 추적하기 위해 상기 인수의 인덱스 및 타입 중 적어도 하나를 지정하는 팩터를 포함하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 11]
제8항에 있어서, 상기 호출된 API를 검색하기 위한 패턴은 상기 지정된 메서드의 인수에 대해 지정된 API, 지정된 필드 및 널(null) 중 적어도 하나로부터 전달된 인수를 탐지하기 위해, API, 필드 및 널(null) 중 적어도 하나를 지정하는 팩터를 포함하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 12]
제1항에 있어서, 상기 탐지 패턴은 지정된 메서드로부터 지정된 인스트럭션을 검색하는 패턴을 포함하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 13]
제12항에 있어서, 상기 특정 인스트럭션을 검색하기 위한 패턴은 검색할 인스트럭션을 지정하는 팩터, 검색할 인스트럭션의 타입을 지정하는 팩터 및 검색할 인스트럭션이 호출하는 클래스와 메서드를 지정하는 팩터 중 적어도 하나의 팩터를 포함하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 14]
제1항에 있어서, 상기 탐지 패턴은 지정된 클래스의 자식 클래스를 검색하는 패턴을 포함하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 15]
제1항에 있어서, 상기 탐지 패턴은 상기 등록된 패키지 파일이 포함하는 파일들 중 적어도 하나의 파일에서 API를 검색하는 패턴을 포함하는 것을 특징으로 하는 취약점 탐지 방법.
[청구항 16]
제1항 내지 제15항 중 어느 한 항의 방법을 컴퓨터에 실행시키기 위한 컴퓨터 프로그램이 기록되어 있는 것을 특징으로 하는 컴퓨터 판독 가능한 기록매체.
[청구항 17]
어플리케이션의 취약점을 탐지하는 시스템에 있어서, 컴퓨터에서 판독 가능한 명령을 실행하도록 구현되는 적어도 하나의 프로세서 를 포함하고, 상기 적어도 하나의 프로세서는, 어플리케이션의 설치 및 구동을 위한 패키지 파일이 포함하는 파일들 및 상기 파일들이 포함하는 코드들 중 적어도 하나와 관련하여, 상기 어플리케이션의 취약점 진단을 위한 기 설정된 탐지 패턴들을 관리하고, 어플리케이션의 설치 및 구동을 위해 이용자들에게 배포하기 위한 패키지 파일을 등록하고, 상기 탐지 패턴들 중 적어도 하나의 탐지 패턴에 따라 상기 등록된 패키지 파일을 분석하여 상기 적어도 하나의 탐지 패턴별로 취약점 정보를 탐지하는 것 을 특징으로 하는 취약점 탐지 시스템.
[청구항 18]
제17항에 있어서, 상기 적어도 하나의 프로세서는, 상기 기 설정된 탐지 패턴들을 관리하기 위해, 새로운 탐지 패턴을 등록받거나 또는 등록된 탐지 패턴을 편집하기 위한 에디터 기능을 제공하고, 상기 제공된 에디터 기능을 통해 등록 또는 편집된 탐지 패턴에 대한 정보를 저장 및 관리하는 것 을 특징으로 하는 취약점 탐지 시스템.
[청구항 19]
제17항에 있어서, 상기 적어도 하나의 프로세서는, 상기 적어도 하나의 탐지 패턴별로 취약점 정보를 탐지하기 위해, 복수의 탐지 패턴을 결합(join)하여 제1 탐지 패턴에 따라 상기 등록된 패키지 파일에서 탐지된 제1 정보를 제2 탐지 패턴이 포함하는 팩터의 파라미터로 동적으로 설정하고, 상기 탐지된 제1 정보가 파라미터로 설정된 팩터를 포함하는 상기 제2 탐지 패턴에 따라 상기 등록된 패키지 파일에서 취약점 정보를 탐지하는 것 을 특징으로 하는 취약점 탐지 시스템.

도면

[도1]

[도2]

[도3]

[도4]

[도5]

[도6]

[도7]

[도8]

[도9]

[도10]

[도11]

[도12]

[도13]

[도14]

[도15]

[도16]