KR20230080860A - 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법 및 시스템 - Google Patents

Abstract

이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법 및 시스템이 제시된다. 본 발명의 일 실시예에 따른 컴퓨터 장치에 의해 수행되는 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법은, 베이스밴드의 특성을 네트워크 통신을 위한 모뎀으로 활용하여 베이스밴드 소프트웨어를 셀룰러 규격과 비교 분석하는 단계를 포함하고, 상기 셀룰러 규격의 메시지 구조와 비교 분석하는 단계는, 상기 셀룰러 규격의 표준화된 메시지 구조를 활용하여, 상기 베이스밴드 소프트웨어에서 구현된 메시지 구조를 자동으로 검사할 수 있다.

Description

이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법 및 시스템{Method and System for Automatically Analyzing Bugs in Cellular Baseband Software using Comparative Analysis based on Cellular Specifications}

본 발명의 실시예들은 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법 및 시스템에 관한 것으로, 더욱 상세하게는 베이스밴드 펌웨어와 셀룰러 규격의 비교 분석을 수행하는 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법 및 시스템에 관한 것이다.

스마트폰과 같은 셀룰러 장치의 베이스밴드 프로세서(Baseband Processor, BP)는 셀룰러 네트워크에서 중요한 역할을 한다. 비록 사용자들이 주로 애플리케이션 프로세서에서 실행되는 사용자 애플리케이션의 인터페이스와 상호작용하지만, 모든 애플리케이션 데이터는 그것의 무선 인터페이스를 사용하기 위해 BP에 의해 전송된다. BP는 소프트웨어를 실행하는데, 이것은 일반적으로 무선 통신 관리를 위한 실시간 운영 체제이다. 따라서, 그것은 낮은 수준의 디지털 신호 처리와 복잡한 셀룰러 프로토콜 스택(cellular protocol stack)을 포함한다. 사용자에게 원활한 네트워크 서비스를 제공하기 위해, 베이스밴드 소프트웨어는 계층 3(L3)에서 수많은 셀룰러 제어부 메시지를 사용하여 코어 네트워크와 지속적으로 통신한다.

베이스밴드 소프트웨어는 악용될 경우 전송 데이터를 모니터링하고 수정하는 데 사용할 수 있기 때문에 유혹적인 공격 대상이다. 따라서 종래에는 특히 L3 프로토콜의 보안을 분석하기 위한 몇 가지 접근 방식을 제안했다. 구현 시 보안 버그를 발견하기 위해 종래에는 fuzzer를 사용하여 SMS 또는 셀 브로드캐스트 메시지와 같은 특정 프로토콜을 동적으로 분석하거나, 애드혹(ad-hoc) 방식으로 베이스밴드 소프트웨어의 작은 부분을 수동으로 검사했다.

이러한 접근 방식은 주로 세 가지 기술적 문제로 어려움을 겪는다. 즉, 베이스밴드 펌웨어(baseband firmware)의 모호성, 수동 분석의 제한된 적용 가능성, 그리고 자동화의 어려움이다. 첫째, 공급업체가 세부 사항을 공개하기를 꺼려하기 때문에 베이스밴드 펌웨어의 구조는 불분명하다. 둘째, 이러한 불명확함을 발견하기 위해서는 수동 분석이 불가피하며, 이는 다양한 베이스밴드 모델 또는 버전에 걸쳐 수많은 기능(즉, 90K 이상)을 조사하기 위한 상당한 반복적인 노력이 필요하다. 셋째, 자동화는 필요하기는 하지만 중요한 것은 또한 아니다. 베이스밴드 소프트웨어의 크기는 매우 크고(즉, 수십 MB) 셀룰러 프로토콜은 정적으로 분석되거나 fuzzer에 의해 동적으로 트리거될 수 없는 수많은 복잡한 상태를 포함한다. 또한, 버그를 식별하려면 프로그램 충돌이나 눈에 띄는 비정상적인 동작과 같은 명시적인 오라클(oracle)이 필요하므로 몇 가지 버그 유형으로 제한된다. 따라서 기존 접근 방식은 단일 공급업체 내에서 두 가지 장치 모델 또는 버전만 분석할 수 있다.

N. Golde and D. Komaromy, "Breaking Band: reverse engineering and exploiting the shannon baseband," REcon, 2016.

본 발명의 실시예들은 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법 및 시스템에 관하여 기술하며, 보다 구체적으로 셀룰러 베이스밴드 소프트웨어의 버그를 발견하기 위한 베이스밴드 펌웨어와 셀룰러 규격의 비교 분석을 자동으로 수행하는 기술을 제공한다.

본 발명의 실시예들은 규격의 표준화된 메시지 구조를 활용하여 베이스밴드 소프트웨어에서 구현된 메시지 구조를 체계적으로 검사함으로써, 추출된 메시지 구조를 구문론 및 의미론적으로 규격과 비교 분석한 후 불일치를 보고하는, 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법 및 시스템을 제공하는데 있다.

본 발명의 일 실시예에 따른 컴퓨터 장치에 의해 수행되는 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법은, 베이스밴드의 특성을 네트워크 통신을 위한 모뎀으로 활용하여 베이스밴드 소프트웨어를 셀룰러 규격과 비교 분석하는 단계를 포함하고, 상기 셀룰러 규격의 메시지 구조와 비교 분석하는 단계는, 상기 셀룰러 규격의 표준화된 메시지 구조를 활용하여, 상기 베이스밴드 소프트웨어에서 구현된 메시지 구조를 자동으로 검사할 수 있다.

상기 비교 분석을 통해 상기 베이스밴드 소프트웨어의 메시지 구조에서 상기 셀룰러 규격을 준수하지 않는 불일치를 식별하는 단계를 더 포함할 수 있다.

상기 베이스밴드 소프트웨어를 셀룰러 규격과 비교 분석하는 단계는, 상기 베이스밴드 소프트웨어를 분석하여 메시지 디코더를 식별하고, 상기 베이스밴드 소프트웨어에 내장된 메시지 구조를 추출하는 단계; 및 추출된 상기 베이스밴드 소프트웨어에 내장된 메시지 구조를 상기 셀룰러 규격의 메시지 구조와 비교 분석하는 단계를 포함할 수 있다.

상기 셀룰러 규격의 메시지 구조와 비교 분석하는 단계는, 상기 내장된 프로토콜 구조가 구문적으로 상기 셀룰러 규격과 동일한지 여부를 비교 분석할 수 있다.

상기 셀룰러 규격의 메시지 구조와 비교 분석하는 단계는, 상기 메시지 디코더의 기능이 기본 논리가 의미론적으로 기호 실행을 활용하는 상기 셀룰러 규격을 준수하는지 여부를 비교 분석할 수 있다.

상기 불일치를 분석하여 기능 또는 보안 버그를 생성할 수 있는지 확인하는 단계를 더 포함할 수 있다.

상기 불일치를 식별하는 단계는, 상기 베이스밴드 소프트웨어의 메시지 구조에서 상기 셀룰러 규격의 메시지 구조에 매핑되지 않은 나머지 정보 요소(information element, IE)를 누락된 불일치 또는 알 수 없는 불일치로 보고할 수 있다.

상기 불일치를 식별하는 단계는, 다수개의 상기 베이스밴드 소프트웨어의 계층 3(L3) 메시지에서 불일치를 자동으로 식별하고, 분석을 위한 버그 가능성이 있는 지점을 표시할 수 있다.

본 발명의 다른 실시예에 따른 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템은, 베이스밴드의 특성을 네트워크 통신을 위한 모뎀으로 활용하여 베이스밴드 소프트웨어를 셀룰러 규격과 비교 분석하는 비교 분석부를 포함하고, 상기 비교 분석부는, 상기 셀룰러 규격의 표준화된 메시지 구조를 활용하여, 상기 베이스밴드 소프트웨어에서 구현된 메시지 구조를 자동으로 검사할 수 있다.

상기 비교 분석을 통해 상기 베이스밴드 소프트웨어의 메시지 구조에서 상기 셀룰러 규격을 준수하지 않는 불일치를 식별하는 불일치 식별부를 더 포함할 수 있다.

상기 비교 분석부는, 상기 베이스밴드 소프트웨어를 분석하여 메시지 디코더를 식별하고, 상기 베이스밴드 소프트웨어에 내장된 메시지 구조를 추출하고, 추출된 상기 베이스밴드 소프트웨어에 내장된 메시지 구조를 상기 셀룰러 규격의 메시지 구조와 비교 분석할 수 있다.

상기 비교 분석부는, 상기 내장된 프로토콜 구조가 구문적으로 상기 셀룰러 규격과 동일한지 여부를 비교 분석할 수 있다.

상기 비교 분석부는, 상기 메시지 디코더의 기능이 기본 논리가 의미론적으로 기호 실행을 활용하는 상기 셀룰러 규격을 준수하는지 여부를 비교 분석할 수 있다.

상기 불일치를 분석하여 기능 또는 보안 버그를 생성할 수 있는지 확인하는 버그 생성 확인부를 더 포함할 수 있다.

상기 불일치 식별부는, 상기 베이스밴드 소프트웨어의 메시지 구조에서 상기 셀룰러 규격의 메시지 구조에 매핑되지 않은 나머지 정보 요소(information element, IE)를 누락된 불일치 또는 알 수 없는 불일치로 보고할 수 있다.

상기 불일치 식별부는, 다수개의 상기 베이스밴드 소프트웨어의 계층 3(L3) 메시지에서 불일치를 자동으로 식별하고, 분석을 위한 버그 가능성이 있는 지점을 표시할 수 있다.

본 발명의 또 다른 실시예에 따른 컴퓨터 장치에 의해 수행되는 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법은, 규격과 바이너리별 메타데이터가 있는 베이스밴드 펌웨어에서 메시지 구조를 추출하는 단계; 및 상기 규격의 메시지 구조를 상기 베이스밴드 펌웨어의 바이너리 임베디드 메시지 구조와 구문적으로 비교하고 기호 실행을 사용하여 구현 논리를 의미론적으로 분석하는 단계를 포함하여 이루어질 수 있다.

또한, 상기 비교 및 분석을 통해 상기 규격의 메시지 구조와 상기 베이스밴드 펌웨어의 메시지 구조의 불일치를 식별하는 단계를 더 포함할 수 있다.

본 발명의 실시예들에 따르면 규격의 표준화된 메시지 구조를 활용하여 베이스밴드 소프트웨어에서 구현된 메시지 구조를 체계적으로 검사함으로써, 추출된 메시지 구조를 구문론 및 의미론적으로 규격과 비교 분석한 후 불일치를 보고하는, 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법 및 시스템을 제공할 수 있다.

도 1은 본 발명의 일 실시예에 따른 셀룰러 네트워크 구조를 개략적으로 나타내는 도면이다.
도 2는 본 발명의 일 실시예에 따른 EMM 절차에서의 ATTACH REJECT 메시지 구조를 나타내는 도면이다.
도 3은 본 발명의 일 실시예에 따른 수동 펌웨어 분석과 자동화된 BASESPEC을 나타내는 도면이다.
도 4는 본 발명의 일 실시예에 따른 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법을 나타내는 흐름도이다.
도 5는 본 발명의 일 실시예에 따른 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템을 나타내는 블록도이다.
도 6을 본 발명의 일 실시예에 따른 메시지 구조를 나타내는 도면이다.
도 7은 본 발명의 일 실시예에 따른 구문 비교의 예시를 나타내는 도면이다.
도 8은 본 발명의 일 실시예에 따른 의미론적 분석을 나타내는 도면이다.
도 9는 본 발명의 일 실시예에 따른 디코더의 불일치와 처리기 기능의 영향 사이의 관계를 나타낸다.

이하, 첨부된 도면을 참조하여 실시예들을 설명한다. 그러나, 기술되는 실시예들은 여러 가지 다른 형태로 변형될 수 있으며, 본 발명의 범위가 이하 설명되는 실시예들에 의하여 한정되는 것은 아니다. 또한, 여러 실시예들은 당해 기술분야에서 평균적인 지식을 가진 자에게 본 발명을 더욱 완전하게 설명하기 위해서 제공되는 것이다. 도면에서 요소들의 형상 및 크기 등은 보다 명확한 설명을 위해 과장될 수 있다.

셀룰러 베이스밴드는 모바일 통신에서 중요한 역할을 한다. 그러나 여러 가지 이유로 보안을 평가하는 것은 상당히 어렵다. 베이스밴드 펌웨어가 모호하고 복잡하기 때문에 수동 분석은 불가피하지만, 이러한 분석은 다양한 모델이나 버전을 다루려면 반복적인 노력이 필요하다. 펌웨어가 상당히 크고 복잡한 셀룰러 프로토콜과 관련된 수많은 기능을 포함하고 있기 때문에 분석을 자동화하는 것도 중요하지 않다. 따라서 베이스밴드 분석에 대한 기존 접근 방식은 단일 공급업체 내의 두 가지 모델 또는 버전으로만 제한된다.

본 발명의 실시예에서는 베이스밴드 소프트웨어와 셀룰러 규격의 비교 분석을 수행하는 BASESPEC라는 새로운 접근방식을 제안한다. BASESPEC는 규격의 표준화된 메시지 구조를 활용함으로써, 베이스밴드 소프트웨어에서 구현된 메시지 구조를 체계적으로 검사한다. 메시지 구조가 대상 펌웨어에 어떻게 포함되어 있는지 결정하기 위해서는 수동적이면서도 일회성 분석 노력이 필요하다. 그런 다음, BASESPEC는 추출된 메시지 구조를 구문론 및 의미론적으로 규격과 비교하고 마지막으로 불일치를 보고한다. 이러한 불일치는 개발자의 실수를 나타내며, 이는 베이스밴드의 규격 준수를 위반하거나 잠재적인 취약성을 암시한다.

실시예들에 따르면 상위 3개 공급업체 중 한 곳의 9개 모델의 18개 베이스밴드 펌웨어 이미지로 BASESPEC를 평가한 결과 수백 개의 불일치를 발견했다. 이러한 불일치를 분석하여 5개의 기능 오류와 4개의 메모리 관련 취약성 등 9개의 오류 사례를 발견했다. 특히, 이 중 두 가지는 중요한 원격 코드 실행 0-days이다. 또한, 실시예들에 따르면 다른 공급업체의 3개 모델에 BASESPEC를 적용한 결과, BASESPEC은 여러 불일치를 발견했고 그 중 2개는 버퍼 오버플로우 버그(buffer overflow bug)를 발견하게 했다.

아래의 본 발명의 실시예들은 베이스밴드의 특성을 네트워크 통신을 위한 모뎀으로 활용하여 베이스밴드 구현 및 셀룰러 규격의 비교 분석을 수행하는 BASESPEC이라는 새로운 시스템을 제안한다.

BASESPEC은 주요 직관은, 베이스밴드 소프트웨어의 메시지 디코더가 수신 메시지를 구문 분석하기 위해 기계 친화적인 구조에 프로토콜 규격을 내장한다는 점이다. 따라서 내장된 프로토콜 구조를 쉽게 추출하고 규격에 대한 참조와 비교할 수 있다. 이를 통해 BASESPEC은 전체 비교 프로세스를 자동화하고 규격을 준수하지 않는 프로토콜 구현에서 불일치를 명시적으로 발견할 수 있다. 이러한 불일치는 프로토콜 구조를 내장할 때 개발자의 실수를 직접적으로 지적하거나 잠재적인 취약성을 암시할 수 있다.

비교 분석을 위해 BASESPEC은, 먼저 베이스밴드 펌웨어를 분석하여 메시지 디코더를 식별하고 펌웨어에 내장된 프로토콜 구조를 추출한다. 그런 다음, 추출된 구조와 규격의 두 가지 측면에서 비교한다. 1) 내장된 구조가 구문적으로 규격과 동일한지 여부 및 2) 디코더 기능이 의미론적으로 규격을 따르는지 여부이다. 따라서 실제 구현과 규격 간의 비교 분석을 통해 불일치를 명확하게 식별할 수 있다. 그런 다음, 이러한 불일치를 수동으로 분석하여 기능 또는 보안 버그를 생성할 수 있는지 확인한다. BASESPEC은 디코더 기능을 찾고 메시지 구조가 펌웨어에 포함된 방식을 결정하기 위해 대상 펌웨어의 초기 분석이 필요하다. 이 경우 상당한 수작업이 필요할 수 있지만 이 분석은 일회성 작업일 뿐이다. 이 분석을 통해 얻은 지식은 다른 베이스밴드 모델 또는 버전에 재사용될 수 있다. 이는 주 디코딩 논리가 공급업체 내의 다양한 베이스밴드 모델 또는 버전에 걸쳐 거의 변경되지 않기 때문이다. 한편, 자동화된 비교 절차는 펌웨어를 분석한 후 다른 공급업체에서 재사용할 수 있다.

BASESPEC의 프로토타입을 사용하여 상위 3개 공급업체 중 한 곳의 9개 장치 모델의 18개 베이스밴드 펌웨어 이미지에서 표준 L3 메시지 구현을 분석했다. BASESPE은 베이스밴드 구현에서 기능적 오류와 잠재적으로 취약한 지점을 모두 나타내는 수백 개의 불일치를 식별했다. 실시예들에 따르면 그들의 기능적, 보안적 영향을 조사하여 33개의 메시지에 영향을 미치는 9개의 오류 사례를 발견했다. 이 사례들 중 5개는 기능적 오류이고 4개는 메모리 관련 취약성이다. 특히, 2개의 취약성은 중요한 원격 코드 실행(RCE) 0-days이다. BASESPEC의 적용 가능성을 평가하기 위해 상위 3개 공급업체의 3개 모델에 BASESPEC를 적용했다. 이 분석을 통해 BASESPEC는 여러 불일치를 확인했으며, 그 중 두 가지는 버퍼 오버플로우를 발견하게 했다.

요약하자면, 본 발명의 기여는 다음과 같다.

본 발명의 실시예들은 셀룰러 베이스밴드 소프트웨어의 버그를 발견하기 위한 BASESPEC이라는 새로운 접근방식을 제안한다. 여기서, BASESPEC는 베이스밴드 소프트웨어와 문서화된 규격의 임베디드 규격에 대한 비교 분석을 수행한다.

또한, 실시예들은 BASESPEC의 실용성을 입증한다. 상위 3개 공급업체 중 한 곳의 9개 모델의 18개 베이스밴드 펌웨어 이미지에서 BASESPEC의 자동화된 프로토타입을 실행함으로써 규격에 부합하지 않는 수백 개의 불일치를 식별했다.

또한, 실시예들에 따르면 불일치를 추가로 분석하여 9개의 오류 사례를 발견했는데, 그 중 5개는 기능 오류이며 4개는 2개의 RCE 0-days를 포함하는 취약점이다.

또한, 실시예들에 따르면 다른 공급업체의 3개 펌웨어 이미지에 BASESPEC을 적용하면 여러 개의 불일치가 확인되었으며, 이 중 2개는 버퍼 오버플로우 버그를 발생시킨다.

도 1은 본 발명의 일 실시예에 따른 셀룰러 네트워크 구조를 개략적으로 나타내는 도면이다.

도 1을 참조하면, 셀룰러 네트워크는 세 가지 주요 구성 요소, 즉 셀룰러 장치(Cellular Device, 120), 기지국(Base Station, 110) 및 코어 네트워크(Core Network, 130)를 가지고 있다. 이러한 구성 요소들은 셀 생성에 따라 다른 용어를 사용한다. 여기서는 단순성을 위해 일반적인 용어를 사용한다. 예를 들어, NodeB, eNodeB, gNodeB는 각각 3G, 4G, 5G의 기지국(110)을 나타낸다.

셀룰러 장치(120)는 셀룰러 네트워크의 가장자리에 위치한 모든 장치를 말하며 사용자가 셀룰러 서비스에 액세스할 수 있도록 한다. 가장 일반적인 장치는 스마트폰이다. 셀룰러 장치(120)에는 일반적으로 성능을 위한 두 개의 별도의 프로세서가 있다. 모바일 운영 체제와 사용자 애플리케이션이 실행되는 애플리케이션 프로세서(application processor, AP) 및 무선/디지털 신호 처리가 수행되는 셀룰러 베이스밴드 프로세서(Baseband Processor, BP)이다.

기지국(110)은 셀룰러 장치(120)에 무선 연결을 제공한다. 무선 인터페이스를 통해 코어 네트워크(130)에서 셀룰러 장치(120)로, 그리고 그 반대로 메시지를 전송한다. 따라서, 사용자에게 더 나은 서비스 품질을 제공하기 위해 무선 자원을 관리할 책임이 있다. 코어 네트워크(130)는 중요한 사용자 식별 및 암호화 및 무결성 검사와 같은 보안 서비스를 포함하는 이동성 관리 및 세션 관리와 같은 핵심 절차를 제공한다.

그리고, 셀룰러 프로토콜 스택(121)에는 OSI 모델로 여러 계층(layer)이 있다. 셀룰러 네트워크의 무선 인터페이스는 OSI 모델의 계층 1, 2에 있다. 다양한 핵심 절차 메시지가 계층 3에서 전달된다. 이러한 계층을 적절하게 처리하기 위해, 셀룰러 장치(120)의 베이스밴드는 셀룰러 프로토콜 스택(121)도 구현한다. 또한, 셀 범위와 로밍에 대한 하위 호환성을 제공하기 위해 최신 4G/5G 셀룰러 장치도 이전의 2G/3G 셀룰러 기술을 지원한다.

아래에서는 셀룰러 규격 및 표준 계층 3 메시지에 대해 설명한다.

셀룰러 규격은 ETSI와 같은 7개의 통신 표준 개발 기관을 통합하는 3세대 파트너십 프로젝트(3rd Generation Partnership Project, 3GPP)라고 불리는 국제간 작업 그룹에 의해 정의된다. 100개 이상의 규격서가 있으며 대부분의 문서는 수백 페이지이다. 엄청난 양과 복잡성 때문에 종래 기술에서 많은 실수가 관찰되었다.

규격에 있는 다양한 프로토콜과 메시지들 중에서, 표준 계층 3(L3) 메시지는 사용자의 개인 정보를 보호하기 위한 이동성 관리, 세션 관리 또는 심지어 암호화 작업과 같은 복잡한 핵심 절차에서 사용된다. 따라서, 처리 루틴에서 여러 가지 취약성이 발견되었다. 표준 L3 메시지는 GSM 또는 LTE와 같은 특정 셀룰러 세대에 국한될 뿐만 아니라, 세대를 거쳐 여러 다른 프로토콜을 포함한다. [표 1]에는 L3 프로토콜, 프로토콜 판별기(PD) 및 규격서 번호가 나열되어 있다. 각 규격서는 해당 프로토콜의 세부 메시지 형식 및 방향을 정의한다. L3 메시지는 셀룰러 장치(즉, 다운링크) 또는 코어 네트워크(즉, 업링크)로 전송될 수 있다. 또한, L3 메시지는 전송되는 방향에 따라 형식이 다를 수 있다. 이하, [표 1]에 열거된 약어를 사용하여 각 L3 프로토콜을 나타낸다.

[표 1]

각 표준 L3 메시지에는 해당 규격서 [표 1]에 정의된 특정 형식이 있다. 표준 L3 메시지는 PD 및 메시지 ID를 포함하는 2 바이트 헤더로 시작한다. PD 및 메시지 ID의 튜플을 사용하면 수신자 베이스밴드가 메시지를 디코딩하기 위해 지정된 메시지의 형식을 결정할 수 있다. 메시지의 각 연속 필드를 표준 정보 요소(information element, IE)라고 한다.

표준 IE에는 IE 식별자(IE identifier, IEI), 길이 표시자(length indicator, LI), 및 값(각각 유형(type, T), 길이(length, L), 값(value, V))의 세 부분이 있을 수 있다. IE는 IEI의 발생에 따라 명령(imperative)이거나 비명령(non-imperative)일 수 있다. 명령 IE는 IEI가 없는 반면, 비명령 IE는 IEI가 있어야 한다. 메시지에서, 명령 IE는 비명령 IE보다 먼저 고정된 순서로 나타나야 하므로 IEI 없이 구별할 수 있다. LI는 값 부분의 바이트 수를 나타내는 반면, 규격의 IE 길이는 모든 부분의 바이트 수를 나타낸다. IE 형식은 T, V, TV, LV, TLV, LV-E, TLV-E의 7가지이다. 여기서 T, L, V는 각각 IEI, LI, 값의 발생을 나타낸다. -E 접미사는 1 바이트 LI를 2 바이트 LI로 확장하며, 길이는 0에서 65535 사이이다.

도 2는 본 발명의 일 실시예에 따른 EMM 절차에서의 ATTACH REJECT 메시지 구조를 나타내는 도면이다.

도 2를 참조하면, 원시 패킷 데이터가 있는 EMM 절차에서 ATTACH REJECT라는 예제 메시지를 보여준다. 메시지 구조의 각 행은 IE를 나타낸다. 헤더는 4 비트 PD(0x7), 4 비트 보안 헤더 유형(0x0), 및 8 비트 메시지 ID(0x44)로 구성된다. 또한, 명령 IE에는 비헤더 부분 IE, EMM 원인이 포함된다. 그런 다음, 패킷은 ESM 메시지 컨테이너와 T3346 값으로 계속되며, 이 중 IEI는 각각 0x78 및 0x5f이다. ESM 메시지 컨테이너 IE의 형식은 TLV-E이므로, LI는 0에서 65535까지의 길이를 나타낼 수 있다. T3346 값 IE의 길이는 LI가 걸리더라도 3으로 고정된다.

아래에서는 베이스밴드 프로세서에 대해 설명한다.

셀룰러 장치에서 BP는 디지털 신호 처리를 포함한 셀룰러 통신을 위한 모든 무선 기능을 관리하는 전용 프로세서이다. 무선 통신을 위한 실시간 요구 사항을 충족시키기 위해, 그것은 그것의 펌웨어로서 실시간 운영체제를 실행한다. 따라서, 그것의 펌웨어는 단일 실행 파일로 작동하며 런타임에 메모리에 로드된다. 그러므로, 여기에서는 베이스밴드 펌웨어를 베이스밴드 바이너리(baseband binary)로 부른다.

베이스밴드 소프트웨어는 일반적으로 독점적이며 제조업체는 소스 코드와 같은 세부 정보를 공개적으로 공유하지 않는다. 예를 들어 Qualcomm의 Snapdragon, MediaTe의 Helio와 삼성의 Exynos는 BP를 포함하는 3대 시스템-온-어-칩(system-on-a-chip) 제품이다. 그러나 이들 제조업체 중 누구도 자세한 정보를 공유하지 않는다. 따라서 연구자들은 베이스밴드 소프트웨어의 보안 문제를 분석하고 식별하기 위해 역엔지니어링을 수행하는 경우가 많다. 또한, 각 베이스밴드는 설계 선택에 따라 다른 구조를 가질 수 있다. 그러므로 베이스밴드 분석에는 대상 베이스밴드 구조를 지원하는 적절한 도구가 필요하다.

베이스밴드에서 L3 메시지는 PD 및 메시지 ID에 의해 먼저 분류된다. 그런 다음, 베이스밴드는 미리 정의된 메시지 구조를 사용하여 IE의 정보를 얻기 위해 메시지를 구문 분석하고 디코딩한다. 메시지를 디코딩한 후 디코딩된 IE마다 적절한 작업을 수행하고, 마지막으로 규격에 정의된 대로 메시지를 처리한다. 이후, 디코딩 절차에 관련된 기능을 L3 메시지 디코더, 메시지 처리를 위한 기능을 IE 및 메시지 처리기라고 한다.

베이스밴드 펌웨어에서 버그를 찾는 데 있어 기존 접근 방식을 방해하는 기술적 과제에는 주로 세 가지가 있다.

첫째, 베이스밴드 펌웨어의 모호성이다. 셀룰러 베이스밴드 펌웨어는 공급업체가 자사의 독점적 구현을 보호하기 위해 세부 사항을 공개하지 않기 때문에 대부분 알려지지 않은 상태이다. 이러한 모호성은 펌웨어 분석을 심각하게 방해하므로 분석에 상당한 수동 작업이 필요하다. 수동 작업을 줄이기 위해 메모리 덤프는 초기화 단계를 이미 처리했으며 런타임 정보를 포함하는 경우가 많다. 그러나 이러한 기능을 얻으려면 실제 장치 및 특수 기능(예컨대, 이전 안드로이드 장치에서만 사용 가능한 숨겨진 덤프 메뉴) 또는 이를 트리거하기 위한 취약성이 필요하다. JTAG와 같은 하드웨어 디버그 인터페이스를 사용하는 것을 고려할 수 있지만 최신 장치에서는 사용할 수 없다. 또한, IDA Pro와 같은 최첨단 바이너리 분석 도구로는 메모리 덤프도 분석할 수 없다. 예를 들어 정적 분석의 기본인 함수 식별은 펌웨어의 모호성 때문에 실패하는 경우가 많다.

둘째, 수동 분석의 적용 가능성 제한이다. 베이스밴드 펌웨어의 불명확함을 밝혀내기 위해 연구자들은 수동 분석에 초점을 맞추었다. 그러나 수백 개의 L3 메시지에 대한 수많은 기능을 수동으로 조사하는 것은 거의 불가능하기 때문에 이 방법은 확장성과 적용성에 근본적으로 한계가 있다. 따라서 유사한 유형의 취약성조차 발견되지 않은 상태로 남아 있는 경우가 많다. 또한, 모바일 장치가 소프트웨어와 하드웨어에서 빠르게 발전함에 따라 펌웨어 바이너리는 서로 상당한 차이를 가지고 있다. 따라서 단일 공급업체 내에서조차 다양한 장치 모델 또는 버전의 펌웨어를 검사하는 것은 여전히 어려운 과제이며, 추가적인 심각한 수동 작업이 필요하다.

셋째, 자동 분석의 어려움이다. 확장성과 적용 가능성을 달성하려면 베이스밴드 분석을 자동화하는 것이 명령이다. 자동화된 분석은 크게 정적 분석과 동적 분석으로 나눌 수 있지만 두 방법 모두 몇 가지 과제가 있다. 정적 분석은 베이스밴드 펌웨어가 매우 크며(즉, 수십 MB), 암호화 작업과 같이 분석할 수많은 사소한 기능이 포함되어 있다. 더욱이, 셀룰러 규격은 100개가 넘는 문서로 작성되어 매우 복잡하기 때문에 분석 규칙을 만드는 것은 어려운 일이다. 따라서 기존 연구는 실제 또는 에뮬레이트 하드웨어(emulated hardware)를 사용한 동적 분석(예컨대, fuzzing)에 크게 의존한다. 안타깝게도 베이스밴드의 많은 취약성은 복잡한 상태 때문에 동적으로 트리거하기 어렵다. 또한, 이러한 접근 방식은 버그를 식별하기 위해 프로그램 충돌과 같은 명시적 오라클에 의존하므로 버그를 몇 가지 버그 유형으로 제한한다.

이러한 과제를 해결하기 위해, 본 발명의 실시예들은 베이스밴드 펌웨어와 셀룰러 규격의 비교 분석을 수행하는 BASESPEC이라는 새로운 접근방식을 제안한다. BASESPEC은 네트워크 통신에서 메시지 디코더의 자연적인 특성을 활용한다. 본 발명의 주요 직관은 1) 네트워크 통신의 메시지 디코더는 메시지 필드를 식별하고 구문 분석할 수 있도록 구현에 규격을 내장해야 한다는 것이다. 2) 그러한 내장 메시지 구조가 기계 친화적인 형태로 존재하므로, 실시예들은 확실히 그것들을 추출할 수 있다. 3) 추출된 구조에서의 비교 분석은 규격서와 관련하여 잘못 삽입된 구조를 식별할 수 있다. 4) 디코딩 루틴의 주요 논리가 거의 변하지 않기 때문에 메시지 구조는 유사하게 다양한 장치 모델/변환에서 추출될 수 있다. 이후, 베이스밴드 펌웨어의 내장 규격과 메시지 구조를 바이너리 임베디드 규격/메시지라고 부른다.

도 3은 본 발명의 일 실시예에 따른 수동 펌웨어 분석과 자동화된 BASESPEC을 나타내는 도면이다.

도 3을 참조하면, 실시예들의 접근 방식은 크게 수동 펌웨어 분석(310)과 완전 자동화된 BASESPEC(320)의 두 부분으로 나뉜다.

수동 펌웨어 분석(310)은 주로 메시지 디코더의 위치와 바이너리별 메타데이터(binary-specific metadata)라고 부르는 베이스밴드 펌웨어에 규격이 내장되어 있는 방법을 탐색한다. 디코딩 절차의 주요 논리는 동일한 공급업체 내의 다양한 장치 모델 또는 버전에 걸쳐 거의 변경되지 않기 때문에 이 절차는 수동이지만 일회성 작업이다.

그런 다음, 완전 자동화된 BASESPEC(320)은 이러한 결과를 구문/의미론적 비교에 활용한다. 특히, 완전 자동화된 BASESPEC(320)은 대상 베이스밴드 바이너리에서 디코더 함수 주소와 임베디드 메시지 구조의 추출을 자동화한다. 구문 비교는 문자 그대로 바이너리 임베디드 규격이 설명서의 규격과 일치하는지 여부를 검증한다. 한편, 의미론적 비교는 디코더 기능의 기본 논리가 기호 실행을 활용하는 규격을 올바르게 준수하는지 여부를 조사한다. 마지막으로, 개발자의 실수를 나타내는 불일치를 보고하며, 이는 규격 준수를 위반하거나 나중에 분석하기 위해 잠재적으로 취약한 지점을 암시할 수 있다. 따라서 보고된 불일치의 영향을 받는 메시지만 분석하면 된다.

실시예들은 앞에서 언급된 과제를 다음과 같이 다룬다. 먼저, 펌웨어, 특히 L3 메시지 디코더를 수동으로 분석하여 펌웨어의 모호성을 파악한다. 이 분석은 다른 베이스밴드 펌웨어에 재사용될 수 있다. 즉, 일회성 작업이다. 둘째, 완전 자동화된 BASESPEC(320)은 수많은 L3 메시지에서 불일치를 자동으로 식별하고 분석을 위한 버그 가능성이 있는 지점을 드러내므로 효율적이고 실용적인 분석을 가능하게 한다. 실제로 완전 자동화된 BASESPEC(320)에서 보고한 불일치를 분석하여 9개의 오류 사례를 발견했는데, 이 중 5개는 기능 오류이고 4개는 2개의 RCE 0-days을 포함한 취약성이다. 마지막으로, 주 디코딩 논리가 거의 변경되지 않기 때문에 완전 자동화된 BASESPEC(320)은 자동화가 있는 다양한 장치 모델 또는 버전에 적용할 수 있다. 디코더를 분석하기 위해 일회성 수동 작업이 필요하더라도 다른 공급업체의 펌웨어에도 적용할 수 있다.

셀룰러 네트워크의 다양한 프로토콜 중에서 표준 L3 메시지를 대상으로 선택한다. 이러한 메시지는 다양한 프로토콜을 포함하며 셀룰러 핵심 절차에서 중요한 역할을 한다. L3 프로토콜은 수많은 복잡한 논리 및 데이터 구조를 가지고 있기 때문에, 몇 가지 취약성이 발견되었다. 따라서 [표 1]에 열거된 표준 L3 메시지 분석에 중점을 둔다. L3 프로토콜의 모든 메시지가 표준 L3 메시지로 표시되는 것은 아니다. 이러한 기타 메시지는 본 발명의 범위를 벗어난다.

실시예들에 따르면 셀룰러 베이스밴드의 경우, 주로 상위 3개 모바일 프로세서 공급업체 중 한 곳(즉, 공급업체1)에 초점을 맞추고 있다. 구조가 ARM.1인 여러 최신 장치 모델에서 베이스밴드 펌웨어를 분석한다. 그러나 실시예들에 따른 접근 방식은 다른 베이스밴드 펌웨어에 적용될 수 있지만 펌웨어의 모호성을 밝혀내기 위해서는 상당한 수동적 노력이 필요할 수 있다. 또한, 상위 3개 공급업체 중 하나(즉, 공급업체2)의 펌웨어를 분석하여 BASESPEC을 성공적으로 적용했다.

도 4는 본 발명의 일 실시예에 따른 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법을 나타내는 흐름도이다.

도 4를 참조하면, 본 발명의 일 실시예에 따른 컴퓨터 장치에 의해 수행되는 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법은, 베이스밴드의 특성을 네트워크 통신을 위한 모뎀으로 활용하여 베이스밴드 소프트웨어를 셀룰러 규격과 비교 분석하는 단계(S110)를 포함하고, 셀룰러 규격의 메시지 구조와 비교 분석하는 단계는, 셀룰러 규격의 표준화된 메시지 구조를 활용하여, 베이스밴드 소프트웨어에서 구현된 메시지 구조를 자동으로 검사할 수 있다.

또한, 실시예에 따라 비교 분석을 통해 베이스밴드 소프트웨어의 메시지 구조에서 셀룰러 규격을 준수하지 않는 불일치를 식별하는 단계(S120)를 더 포함할 수 있다.

또한, 실시예에 따라 불일치를 분석하여 기능 또는 보안 버그를 생성할 수 있는지 확인하는 단계(S130)를 더 포함할 수 있다.

본 발명의 일 실시예에 따른 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법은 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템을 예를 들어 보다 구체적으로 설명할 수 있다.

도 5는 본 발명의 일 실시예에 따른 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템을 나타내는 블록도이다.

도 5를 참조하면, 본 발명의 일 실시예에 따른 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템(500)은 비교 분석부(510)를 포함하여 이루어질 수 있다. 실시예에 따라 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템(500)은 불일치 식별부(520) 및 버그 생성 확인부(530)를 더 포함할 수 있다.

단계(S110)에서, 비교 분석부(510)는 베이스밴드의 특성을 네트워크 통신을 위한 모뎀으로 활용하여 베이스밴드 소프트웨어를 셀룰러 규격과 비교 분석할 수 있다. 이 때, 비교 분석부(510)는 셀룰러 규격의 표준화된 메시지 구조를 활용하여, 베이스밴드 소프트웨어에서 구현된 메시지 구조를 자동으로 검사할 수 있다.

보다 구체적으로, 비교 분석부(510)는 베이스밴드 소프트웨어를 분석하여 메시지 디코더를 식별하고, 베이스밴드 소프트웨어에 내장된 메시지 구조를 추출하고, 추출된 베이스밴드 소프트웨어에 내장된 메시지 구조를 셀룰러 규격의 메시지 구조와 비교 분석할 수 있다.

비교 분석부(510)는 베이스밴드 소프트웨어를 셀룰러 규격과 구문적 및 의미론적으로 비교 분석할 수 있다. 비교 분석부(510)는 내장된 프로토콜 구조가 구문적으로 셀룰러 규격과 동일한지 여부를 비교 분석할 수 있다. 또한, 비교 분석부(510)는 메시지 디코더의 기능이 기본 논리가 의미론적으로 기호 실행을 활용하는 셀룰러 규격을 준수하는지 여부를 비교 분석할 수 있다.

단계(S120)에서, 불일치 식별부(520)는 비교 분석을 통해 베이스밴드 소프트웨어의 메시지 구조에서 셀룰러 규격을 준수하지 않는 불일치를 식별할 수 있다. 보다 구체적으로, 불일치 식별부(520)는 베이스밴드 소프트웨어의 메시지 구조에서 셀룰러 규격의 메시지 구조에 매핑되지 않은 나머지 정보 요소(IE)를 누락된 불일치 또는 알 수 없는 불일치로 보고할 수 있다.

이 때, 불일치 식별부(520)는 다수개의 베이스밴드 소프트웨어의 계층 3(L3) 메시지에서 불일치를 자동으로 식별하고, 분석을 위한 버그 가능성이 있는 지점을 표시할 수 있다.

단계(S130)에서, 버그 생성 확인부(530)는 불일치를 분석하여 기능 또는 보안 버그를 생성할 수 있는지 확인할 수 있다.

본 발명의 다른 실시예에 따른 컴퓨터 장치에 의해 수행되는 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법은, 규격과 바이너리별 메타데이터가 있는 베이스밴드 펌웨어에서 메시지 구조를 추출하는 단계, 및 규격의 메시지 구조를 베이스밴드 펌웨어의 바이너리 임베디드 메시지 구조와 구문적으로 비교하고 기호 실행을 사용하여 구현 논리를 의미론적으로 분석하는 단계를 포함하여 이루어질 수 있다.

또한, 비교 및 분석을 통해 규격의 메시지 구조와 베이스밴드 펌웨어의 메시지 구조의 불일치를 식별하는 단계를 더 포함할 수 있다.

본 발명의 다른 실시예에 따른 컴퓨터 장치에 의해 수행되는 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법은 앞에서 설명한 일 실시예에 따른 컴퓨터 장치에 의해 수행되는 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법과 그 구성이 중복되어 상세한 설명은 생략하기로 한다. 예컨대, 규격은 셀룰러 규격을 포함할 수 있으며, 베이스밴드 펌웨어는 베이스 소프트웨어에 포함될 수 있다.

아래에서 본 발명의 일 실시예에 따른 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법 및 시스템을 보다 구체적으로 설명한다.

펌웨어 모호성의 수동 발견

여기에서는 베이스밴드 펌웨어의 모호성을 파악하기 위한 접근 방식을 자세히 설명한다. IDA Pro라는 최첨단 정적 분석 도구에서 몇 가지 문제를 처리하고, L3 디코딩 함수를 찾고, 메시지 구조가 내장된 방식을 결정하는 방법을 설명한다. 베이스밴드 펌웨어의 모호성과 복잡성으로 인해 수동 분석이 명령이라는 점이다. 그러나 분석 절차는 일회성 작업이며, 그 중 결과는 동일한 공급업체 내의 여러 메시지, 모델 또는 버전에 재사용될 수 있다. 여기에서는 주로 공급업체1의 펌웨어 분석 경험을 공유한다. 그러나 L3 메시지 디코딩 논리를 결정하기 위해서는 상당한 노력이 필요할 수 있지만 다른 공급업체의 펌웨어에도 유사한 접근 방식을 적용할 수 있다.

먼저, 펌웨어를 획득한다.

실시예들에 따르면 적용성과 접근성 때문에 물리적 장치를 요구하지 않고 베이스밴드 펌웨어를 분석 대상으로 선택했다. 베이스밴드 펌웨어를 얻는 방법은 주로 메모리 덤프와 펌웨어 영상 두 가지가 있다. 이전 연구(비특허문헌 1)는 펌웨어 초기화에 복잡한 분석이 필요 없는 런타임 메모리 상태, 메모리 레이아웃 및 전역 변수를 포함하므로 메모리 덤프에 의존했다. 그러나 이 방법은 메모리를 덤프하려면 실제 장치가 필요하므로 확장성과 적용성이 크게 저하된다. 게다가, 실시예들에 따르면 JTAG와 같은 메모리 덤프나 하드웨어 디버그 인터페이스를 트리거하기 위한 숨겨진 메뉴가 최근의 장치들에서 비활성화되었다는 것을 발견했다.

따라서 업데이트를 위해 펌웨어 이미지를 유지하는 타사 웹 사이트를 사용하기로 결정했다. 공급업체의 클라우드 저장소에서 최신 펌웨어 이미지를 다운로드할 수도 있다. 그러나 타사 저장소는 제품 모델 및 버전별로 잘 구성된 펌웨어 이미지 목록을 제공한다. 그 중에서 [표 2]에 열거된 최신 플래그십 모델의 이미지를 선택했다. 초기 펌웨어 분석을 위해서는 하나의 영상만 분석하여 그 불명확함을 분해해야 한다. 그런 다음, 동일한 공급업체 내의 다른 이미지에 지식을 적용할 수 있다. 따라서 최신 모델(즉, [표 2]의 모델 A)의 최신 버전을 분석하기로 결정했다.

[표 2]

그리고, 전처리를 포함한다.

실시예들은 최첨단 바이너리 분석 도구인 IDA Pro를 사용하여 베이스밴드 펌웨어를 분석한다. IDA Pro는 유망한 도구이지만 1) 메모리 레이아웃 분석 및 2) 기능 식별을 위한 추가 전처리 단계가 필요하다. IDA Pro는 베이스밴드 펌웨어의 여러 런타임 메커니즘 때문에 90K 기능 중 수백 개만 정확하게 식별한다. 그러한 한계는 이미 어려운 것으로 알려져 있다. IDA의 자동 분석은 전처리 없이 임베디드 장치의 공통 진입점인 인터럽트 처리기에서 시작하는 450개의 기능만 탐지할 수 있다([표 2] 참조). 따라서 다음과 같이 두 가지 전처리 단계를 설계한다.

첫째, 메모리 레이아웃 분석을 할 수 있다. 분석을 위해 베이스밴드 펌웨어를 적절한 메모리 레이아웃에 로드해야 한다. 그렇지 않으면 펌웨어의 데이터나 함수 포인터가 잘못된 메모리 주소를 가리키게 되어 추가 분석이 상당히 방해된다. 실제로, IDA를 사용하여 펌웨어를 열었을 때, 대부분의 함수에서 데이터/함수 포인터는 데이터에 접근하거나 유효하지 않은 메모리 주소에 있는 다른 함수들을 호출하려고 시도했다.

실시예들에 따르면 이 잘못된 포인터 문제가 scatter-loading으로 인해 발생한다는 것을 발견했고 IDA가 이를 지원하지 못했다. scatter-loading은 실행 시 초기에 로드된 파일을 여러 메모리 영역에 재할당하는 ARM의 로드 메커니즘이다. 이 기술은 데이터 영역의 압축을 지원하여 펌웨어 크기를 줄이기 때문에 ARM 기반 임베디드 시스템에 널리 사용된다. 펌웨어를 구축할 때, armlink라는 이름의 ARM 컴파일러의 구성요소는 런타임에 펌웨어를 초기화하기 위한 scatter-loading 기능을 삽입한다. 이러한 함수는 메모리 레이아웃을 올바르게 설정하기 위해 미리 정의된 표에 따라 메모리 영역을 복사, 압축 해제 또는 0 초기화한다. 따라서 scatter-loading을 처리하지 않으면 전체 바이너리 파일이 단일 연속 메모리 영역에 로드되어 데이터/함수 포인터가 유효하지 않게 된다.

scatter-loading 문제를 처리하고 적절한 메모리 레이아웃을 만들기 위해 scatter-loading 프로세스를 에뮬레이트한다. 특히, 실시예들은 scatter-loading 기능의 동작을 에뮬레이트한다. 즉, 메모리 영역을 복사, 압축 해제 및 0 초기화한다. 이러한 scatter-loading 기능은 고도로 최적화된 형태의 armlink로 사전 정의되므로 대부분의 최신 ARM 내장 장치는 이러한 기능을 재사용한다. 따라서 IDA의 FITH와 유사한 서명을 사용하여 이러한 기능을 탐지할 수 있다. scatter-loading 함수를 감지한 후, 실시예들은 이들의 상호 참조를 분석하고 사전 정의된 scatter-loading 표를 식별한다. 이 표에는 scatter-loading 함수의 실행 순서 및 파라미터를 나타내는 정보가 포함되어 있다. 표에 명시된 scatter-loading 프로세스를 에뮬레이트한다.

둘째, 기능 식별을 할 수 있다. 실시예들에 따른 대상(즉, 공급업체1의 펌웨어)은 ARM 구조를 기반으로 한다. 펌웨어의 기능을 식별하기 위해서는 사전에 바이트 코드를 분해해야 한다. 그러나 ARM 구조가 ARM과 Thumb의 두 가지 명령어 집합을 지원하기 때문에 ARM에서 알 수 없는 바이트를 분해하는 것은 오류가 발생하기 쉽다. ARM 명령어 집합은 32 비트 명령을 실행하는 기본 모드이며, Thumb 명령어 집합은 코드 크기를 줄이기 위해 소형의 16 비트 명령을 지원한다. 동일한 바이트를 두 가지 다른 지침으로 분해할 수 있기 때문에 직접 분해하면 많은 잘못된 분해 코드가 발생할 수 있다.

이 과제를 해결하기 위해 i) 빈번한 함수 프롤로그와 ii) Thumb 모드에서 함수 포인터의 특성을 활용하는 두 가지 간단한 기법을 설계했다. 첫째, 확인된 기능을 조사하여 ARM 모드와 Thumb 모드를 구별할 수 있는 기능 프롤로그 서명을 작성한다. 이러한 프롤로그 서명은 ARM 및 Thumb 모드에서 모두 PUSH 지침으로 구성된다. 그런 다음, 해당 서명을 검색하고 일치하는 서명이 발견되면 일치하는 서명 모드에서 분석하려고 시도한다. 서명 기반 일치에서 false positive(위양성)을 줄이기 위해 프롤로그 함수가 레지스터를 정상적으로 처리하는지 여부를 확인한다. 예를 들어 대부분의 기능은 LR 레지스터를 스택에 밀어 넣지만 PC 레지스터를 밀어 넣지 않으므로 PC 레지스터를 밀어 넣는 프롤로그나 LR 레지스터를 밀어 넣지 않는 프롤로그는 폐기한다.

함수 프롤로그를 탐지한 후 데이터 섹션의 함수 포인터를 분석하여 함수를 추가로 식별한다. 이를 위해 Thumb 모드의 특성을 활용한다. Thumb 모드 함수에 대한 함수 포인터는 홀수 주소를 사용한다. 특히, 포인터 값의 최소 비트는 항상 1이다. 대부분의 데이터는 짝수 주소와 정렬되므로 코드 섹션을 가리키는 홀수 주소는 Thumb 모드 함수 포인터일 수 있다. 그러므로, 실시예들은 그러한 포인터를 통해 간접적으로 호출되는 함수들을 찾을 수 있다.

이러한 전처리 기법은 IDA의 기능 식별 성능을 크게 향상시킨다. IDA Pro에 의해 식별된 기능의 초기 수는 [표 2]에 표시된 것처럼 모델 A에 대해 450개였다. 프롤로그 검출과 포인터 분석으로 구성된 메모리 레이아웃 분석 및 기능 식별을 동일한 펌웨어에 적용했다. 실시예들에 따른 메모리 레이아웃 분석은 504개의 새로운 기능을 발견했고, 실시예들에 따른 기능 식별 기술, 즉 기능 프롤로그 감지와 기능 포인터 분석은 각각 31,955개와 2,526개의 새로운 기능을 발견했다. IDA Pro에 새로 식별된 함수를 부여하면 각 함수의 코드 참조를 추가로 분석하여 더 많은 함수를 재귀적으로 찾는다. 결과적으로, 실시예들에 따른 전처리 단계는 IDA Pro가 결국 91,481개의 기능을 식별하는 데 도움이 되었다. 전처리는 일회성 작업일 뿐이며 다른 수동 작업 없이 다른 장치 모델의 펌웨어에 적용할 수 있다. 실제로 [표 2]에 나열된 다른 최신 모델을 성공적으로 전처리할 수 있다. IDA의 자동 분석을 포함하여 전체 전처리에 소요된 평균 시간은 2,557초였다. 경우에 따라 IDA는 전처리 전에 더 많은 함수를 찾거나(모델 B의 경우), 또는 자동 분석에 더 많은 시간이 필요했다(모델 A의 경우). 실시예들은 이 특이치들을 조사하고 있다.

또한, 계층 3 디코더를 식별한다.

표준 L3 메시지를 조사하려면 먼저 바이너리 분석을 통해 디코딩 논리를 찾아야 한다. 이 디코딩 논리를 디코더 함수로 구현하는 함수를 디코더 함수라고 부른다. 여기에서는 디코더 기능이 L3 메시지 구조에 대한 기계 친화적인 정보를 가지고 있기 때문에 디코더 기능에 초점을 맞춘다. 상술한 바와 같이, L3 프로토콜 메시지는 표준화된 구조를 가지고 있다. 메시지를 올바르게 구문 분석하기 위해 개발자는 규격의 메시지 구조를 기계 친화적인 형식으로 내장한다. 따라서 임베디드 구조를 체계적으로 분석하고 펌웨어가 L3 메시지를 해독하는 방법을 이해할 수 있다.

디코더를 식별하기 위해 개발자가 베이스밴드 바이너리에서 남긴 디버그 정보(예컨대, 로깅 메시지)를 활용한다. 이 디버그 정보는 바이너리가 제거되면 사라지는 -g 옵션으로 컴파일러가 삽입한 정보와는 다르며, 이는 아래에서 보다 상세히 설명한다. 디버그 정보는 임베디드 장치(비특허문헌 1)를 분석할 때 손상된 바이너리에서 특정 함수를 찾는 데 일반적으로 사용되기 때문에 바이너리 분석의 다양한 방법 중에서 이 접근방식을 선택한다. 베이스밴드 펌웨어가 손상되고 90K 이상의 수많은 기능으로 구성되어(30MB 이상) 매우 크기 때문에 이러한 정보 없이 L3 디코더를 찾는 것은 상당히 어렵다. 따라서, 실시예들은 디버그 메시지를 사용하고 자세한 내용을 추가 연구를 위한 예를 아래에 공유한다. 마찬가지로, 디버그 정보의 구조는 다르지만 다른 공급업체의 펌웨어에서 디버그 정보를 사용하여 L3 디코더 기능을 발견했다. 한편, 표준 L3 메시지에 대한 비교 분석을 수행하는 실시예들에 따른 최종 목표는 디코더 기능이 식별되는 방법에 의존하지 않는다. 이 프로세스에는 다른 기술도 사용할 수 있다.

먼저, 베이스밴드 바이너리에서 모든 디버그 정보를 검색한 다음 해당 디버그 정보만 참조하는 함수를 분석한다. 디버그 정보를 검색하는 동안 펌웨어가 특정 구조를 사용하여 디버그 메시지와 정보를 기록한다. 매직 값 DBT로 시작하는 구조는 파일 경로 및 참조되는 줄 번호와 함께 디버그 메시지를 포함한다. 따라서 먼저 DBT를 사용하여 모든 디버그 정보를 검색한다. 수많은 함수가 디버그 정보를 간접적으로 참조하기 때문에(약 10만 건), 실시예들은 디버그 정보와 함수를 정확하게 일치시키기 위해 경량 역 슬라이스 분석을 수행한다. 다음으로, 실시예들은 디버그 정보의 파일 경로를 기반으로 각 함수를 분류하는데, 이는 동일한 계층이나 라이브러리의 함수들이 경로를 공유할 수 있기 때문이다. 분류 후, L3, SS, EMM 또는 NAS와 같은 키워드를 포함하는 디버그 메시지와 경로를 사용하여 L3 함수를 찾는다. 그런 다음, 디코드, 코덱, 여러 IE의 이름 등의 키워드를 사용하여 수신 메시지 디코딩과 관련된 기능을 찾는다. 결과적으로, 실시예들에 따르면 표준 L3 메시지를 분석하는 함수를 식별했다. 실시예들은 단일 디코더 함수가 프로토콜에 관계없이 모든 표준 L3 메시지를 디코딩한다는 것을 발견했다. 이러한 메시지는 동일한 표준 구조를 가지기 때문이다. 따라서 디코더 하나로도 충분히 처리할 수 있다.

그리고, 바이너리 임베디드 메시지 구조를 얻는다.

도 6을 본 발명의 일 실시예에 따른 메시지 구조를 나타내는 도면이다.

마지막으로, 표준 L3 메시지 구조가 베이스밴드 바이너리에 어떻게 내장되는지 결정한다. 이를 위해 디코더 기능과 데이터 참조를 분석한다. 내장된 메시지 구조(620)의 단순화된 구조는 도 6에 도시되어 있으며, 규격서 메시지 구조(610)의 EMM, ATTACH REJECT 메시지 구조를 예로 들 수 있다. 내장된 메시지 구조(620)는 네 가지 유형의 목록으로 계층 구조로 인코딩된다.

첫째, 프로토콜 목록(Protocol List, 621)은 계층의 최상위 목록이다. 그것은 각 L3 프로토콜의 메시지 목록(Msg List, 622)에 대한 포인터를 보유하며 PD에 의해 색인화된다. EMM 프로토콜의 PD가 7이므로 프로토콜 목록의 7번째 항목에 접근한다.

둘째, 각 프로토콜에 대해 Msg 목록(622)이 정의된다. 그것은 프로토콜의 각 메시지의 Msg IE 목록(623)에 대한 포인터를 보유하며 메시지 ID 값에 의해 색인화된다. 이 예에서 EMM, ATTACH REJECT 메시지의 메시지 ID는 0x44이므로, 해당 Msg IE 목록(623)은 0x44를 사용하여 액세스된다.

셋째, 각 메시지에 대해 Msg IE 목록(623)이 정의된다. 메시지에는 메시지의 각 IE에 대한 명령 플래그와 인덱스가 포함되어 있다. 명령 플래그에는 IE가 메시지에서 명령 또는 비명령으로 인코딩되는지 여부가 표시되며 색인은 전역 IE 목록(624)에서 IE 위치를 나타낸다. 예에서와 같이 EMM, ATTACH REJECT 메시지의 처음 세 IE(PD, 보안 헤더 유형 및 메시지 유형)는 모든 메시지의 공통 IE이므로 Msg IE 목록에 나열되지 않는다.

넷째, 전역(global) IE 목록(624)은 L3 프로토콜에 사용되는 모든 IE에 대한 정보를 포함하고 있으며 각 IE에 할당된 인덱스로 접근한다. 이 정보는 IE의 길이와 IEI로 구성된다. 여기서, 길이는 값 부분의 크기만 나타내지만 규격서의 길이는 IE의 전체 크기를 나타낸다.

이러한 목록을 반복하여 모든 내장된 메시지 구조(620)를 추출한다. 펌웨어 분석을 통해 L3 디코더 주소와 펌웨어의 메시지 구조 정보를 얻는 방법을 확인할 수 있다. 이 지식을 사용하여 아래에 설명된 바와 같이 BASESPEC을 자동화한다.

BASESPEC 설계

여기에서는 BASESPEC의 설계를 상세히 설명한다. 앞에서 설명한 도 3은 BASESPEC의 개요를 보여준다. BASESPEC는 베이스밴드 펌웨어의 메시지 구조와 규격서의 메시지 구조를 비교하여 불일치를 자동으로 보고한다. 이를 위해, BASESPEC는 먼저 규격과 바이너리별 메타데이터가 있는 펌웨어에서 메시지 구조를 추출한다. 그런 다음, 규격의 구조를 바이너리 임베디드 구조 구문적으로 비교하고 기호 실행을 사용하여 구현 논리를 의미론적으로 검토한다. 이러한 비교를 바탕으로 BASESPEC은 규격과 MP 사이의 다양한 유형의 불일치를 보고한다. BASESPEC는 바이너리(즉, 알 수 없는 불일치) 또는 규격(즉, 누락된 불일치)에만 존재하는 의심스러운 IE를 보고한다. 또한, 길이가 다른 IE(즉, 유효하지 않은 불일치)를 보고한다. 불일치 결과를 얻은 후, 실시예들은 그 함축성을 추가로 분석할 수 있다.

먼저, 규격서에서 메시지 구조를 추출한다.

베이스밴드 펌웨어의 L3 메시지 구조를 검사하기 위해 BASESPEC은 규격서에서 참조 구조를 추출한다. 3GPP와 그 협력 기관들은 그들의 웹사이트에 명세 문서를 제공한다. BASESPEC은 [표 1]에 나열된 최신 규격서를 다운로드하고 원시 텍스트 형식으로 변환한다. 그런 다음, 정규 표현을 사용하여 변환된 원시 텍스트에서 메시지 구조를 추출한다. 규격서의 메시지 구조는 도 6에서와 같이 IE 형식의 목록인 메시지 내용과 각 L3 프로토콜에 대한 메시지 유형 목록의 두 부분을 포함한다. BASESPEC은 각 표준 L3 메시지에 대해 이러한 구조를 자동으로 구문 분석한다.

이 텍스트 처리는 사소한 것처럼 보이지만, BASESPEC은 아래에 열거된 몇 가지 문제 상황을 해결해야 한다.

첫째, 변환 오류를 해결해야 한다. 규격서를 원시 텍스트 형식으로 변환하면 몇 가지 유형의 오류가 발생한다. 규격서는 Microsoft Word(예컨대, DOC) 또는 Adobe(예컨대, PDF) 형식과 같이 인간 친화적인 형식으로 작성되어 있다. 시각적 풍부함(예컨대, 표와 도면)은 독자들이 이러한 문서를 더 완전하게 이해하는 데 도움이 된다. 그러나 BASESPEC은 체계적인 분석을 위해 문서를 기계가 이해할 수 있는 형식으로 변환해야 한다. 이러한 인간 친화적인 문서를 원시 텍스트 형식으로 변환하려면 OCR과 같은 오류가 발생하기 쉬운 방법이 필요하다. 따라서 이러한 변환은 종종 부정확하거나 누락된 단어/문장을 포함한 몇 가지 오류를 초래한다.

이러한 변환 오류를 완화하기 위해 BASESPEC은 서로 다른 문서 형식을 함께 사용한다. 3GPP와 ETSI는 동일한 규격서를 3GPP의 DOC 파일과 ETSI의 PDF 파일 두 가지 형식으로 제공한다. 각 형식의 변환 오류는 결정론적이고 보완적이라는 것을 발견했다. 예를 들어 EMM 및 ESM 메시지의 규격서([표 1])를 처리할 때 DOC 파일의 메시지 유형에 대한 표 변환은 실패했지만 PDF 파일 변환은 성공적이었다. 이와는 대조적으로, 메시지 내용을 위해 표를 변환하는 것은 반대의 경우를 보여주었다. 따라서 BASESPEC은 변환된 표의 행 수를 확인하여 서로 다른 변환 결과 사이에서 올바른 원시 텍스트를 선택한다. 행이 더 많은 표가 올바른 텍스트일 가능성이 높다. 놀랍게도, 이 접근법은 오류를 발생시키지 않았다. 변환을 위해 BASESPEC은 DOC와 PDF 파일에 각각 antiword 및 pdftotext를 사용한다.

둘째, 단어 불일치를 해결해야 한다. BASESPEC은 텍스트 처리를 위해 규격서에 일관성이 없는 많은 단어를 다루어야 한다. 규격은 수많은 사람들이 수작업으로 작성하기 때문에 이러한 모순이 불가피하여 규격을 체계적으로 분석하기가 어렵다. 이러한 불일치에는 중복 및/또는 누락 단어 5건, 단어 사이에 잘못된 공백 14건, 축약 사용 5건, 잘못된 구분 기호 14건 및 단일 의미를 나타내는 여러 다른 용어가 포함된다. 예를 들어, RR 메시지인 SYSTEM INFORMATION TYPE 15는 SYSTEM INFORMATION 15로 작성되기도 한다. 또한, 셀룰러 장치로 전송되는 다운링크(DL) 메시지 표시에는 UE, 기지국, MS, DL의 네 가지 다른 이름이 있다. 또한, DTM ASSIGNMENT COMMAND 메시지에는 하나의 IE 형식 길이에서 누락된 구분 기호 '-'가 있다. 일부 표 이름에는 서비스 요청 메시지 내용과 같은 중복 단어가 있다. 실시예들은 이러한 모든 불일치를 해결하고 비교를 위해 메시지 정보를 성공적으로 검색했다. 이 분야의 텍스트 처리를 적용하는 향후 연구를 위해 수정할 수 있도록 3GPP에 문제를 보고했다.

셋째, 불규칙한 IE 형식을 해결해야 한다. 규격서에서 메시지 구조를 추출하는 동안 여러 중첩된 IE와 잘못된 IE 형식을 발견했다. 예를 들어 일부 SMS 메시지에는 중첩 메시지가 있을 수 있으므로 중첩 메시지의 IE를 확인해야 한다. 메시지 구조를 적절하게 비교하기 위해 중첩된 IE를 납작하게 만들었다. 또한, INTER SYSTEM TO UTRAN HANDOVER COMMAND 메시지의 CN-MS 투명 정보 IE에는 IEI가 없으므로 TLV 형식이 유효하지 않다. TLV 형식이 있는 IE에는 IEI가 포함되어야 한다. 그러나, 이는 규격에 정의된 예외적인 경우였다. 여기에서는 결과를 비교할 때 위의 사례들을 처리하기 위해 예외를 두었다.

다음으로, 바이너리별 메타데이터를 추출한다.

추가 분석을 위해 BASESPEC은 구문 비교를 위한 바이너리 임베디드 메시지 구조 정보 및 의미 비교를 위한 L3 디코더 주소 등 바이너리별 메타데이터를 추출한다. 이는 서로 다른 베이스밴드 바이너리에 걸쳐 구별된다. 그러나 BASESPEC은 베이스밴드 바이너리에 관계없이 이 정보를 추출할 수 있으며 다중 베이스밴드 모델 또는 버전에 적용할 수 있다.

펌웨어 영상이 주어지면, BASESPEC은 모든 펌웨어 분석 절차를 수행하고 바이너리별 메타데이터를 추출한다. 펌웨어 전처리 자동화를 위해 BASESPEC은 IDA Pro의 SCIT와 유사하게 scatter-loading과 관련된 기능의 사전 작성된 서명을 검색한다. 그런 다음, 복사, 압축 해제, 0 초기화 기능을 에뮬레이트한다. 그런 다음, BASESPEC은 로드된 펌웨어를 스캔하여 Thumb 모드 기능에 대한 함수 프롤로그와 포인터를 탐지한다. L3 디코더 식별 자동화를 위해 L3 관련 디버그 구조를 올바르게 식별하기 위해 앞뒤 슬라이서를 구현한다. 그런 다음, 디버그 구조를 상호 참조함으로써 L3 디코더를 식별할 수 있다. 마지막으로, BASESPEC은 함수가 L3 메시지를 디코딩하는 동안 구조를 참조할 때 디코더에서 메시지 구조의 주소를 찾는다. 메시지 구조는 구문 비교에 사용되며 디코더에 관한 정보는 의미론적 비교에 사용된다.

그리고, 메시지 구조의 구문을 비교한다.

BASESPEC은 먼저 IE 레벨의 세분성에서 베이스밴드 바이너리로부터 추출한 메시지 구조와 규격서에서 추출한 메시지 구조를 구문적으로 비교한다. 규격의 각 메시지에 대해 BASESPEC은 PD 및 메시지 유형을 사용하여 바이너리에서 해당 메시지를 가져온다. 다음으로, BASESPEC은 유형(즉, 명령 또는 비명령)에 따른 바이너리로부터 규격에서 메시지의 IE를 반복적으로 매핑한다. 마지막으로 BASESPEC은 매핑된 IE를 비교하고 불일치를 보고하며, 이를 구문 불일치라고 한다. 이러한 구문 불일치는 베이스밴드 바이너리에 메시지 구조를 내장하는 개발자의 실수를 직접적으로 식별할 수 있다. 구문 비교 절차를 다음과 같이 자세히 설명한다.

도 7은 본 발명의 일 실시예에 따른 구문 비교의 예시를 나타내는 도면이다.

1) 메시지 가져오기: 규격의 각 메시지에 대해 BASESPEC은 먼저 PD와 메시지 ID를 사용하여 베이스밴드 바이너리에서 해당 메시지 구조를 가져온다. 도 7에 도시된 바와 같이, BASESPEC은 각각 PD(0x7, 710)와 메시지 ID(0x44, 720)를 프로토콜 목록 및 Msg 목록의 지수로 사용하여 EMM ATTACH REJECT 메시지에 해당하는 Msg IE 목록을 가져온다.

2) IE 매핑: 다음으로, BASESPEC은 각 IE를 Msg IE 목록에서 규격의 IE로 매핑한다. BASESPEC은 명령 IE로서 IE 유형에 따라 이 매핑을 수행하며 비명령 IE는 고유한 형식을 가지고 있다. 명령 IE의 경우, BASESPEC는 메시지에서 고정된 순서를 가지므로 순서에 의존한다. 예를 들어, 도 7에서 BASESPEC는 Msg IE 목록의 첫 번째 항목은 명령 플래그가 설정된 첫 번째 IE인 EM 원인 IE를 나타낸다고 결론짓는다. Msg IE 목록에는 메시지의 헤더 IE(즉, PD 및 메시지 ID)가 이미 Msg IE 목록을 가져오는 데 사용되므로 메시지 ID 뒤에 IE만 포함된다. 임의의 순서로 나타날 수 있는 비명령 IE의 경우, BASESPEC은 식별자인 IEI를 사용한다. 예를 들어, BASESPEC는 도 7의 Msg IE 목록의 두 번째 항목을 ESM 메시지 컨테이너 IE로 간주한다. 왜냐하면 IEI(0x78)가 명세서의 IE와 일치하기 때문이다.

매핑 프로세스 후, BASESPEC은 매핑되지 않은 나머지 IE를 누락 또는 알 수 없는 불일치로 보고한다. 누락된 불일치는 규격에 존재하지만 바이너리로 구현되지 않는 IE를 나타낸다. 한편, 알 수 없는 불일치는 바이너리로 존재하는 IE를 나타낸다. 예를 들어, BASESPEC은 IEI(0x5F)가 Msg IE 목록에 존재하지 않기 때문에 도 7의 T3346 값을 매핑하지 못한다. 따라서 BASESPEC은 이를 누락된 불일치로 보고한다. 마찬가지로, IEI(0xff)는 규격에 해당 IE가 없기 때문에 BASESPEC은 Msg IE 목록의 세 번째 IE를 알 수 없는 불일치로 보고한다.

3) IE 비교: BASESPEC은 매핑에서 IE 쌍을 비교하고 불일치 결과를 보고한다. BASESPEC은 먼저 규격의 IE를 바이너리에 대하여 유사한 형식으로 변환해야 한다. 특히, BASESPEC은 바이너리와 규격의 길이가 다르기 때문에 규격의 IE 길이를 조정한다. 바이너리에서의 길이는 IE의 값 부분(즉, 값의 길이)만 고려하는 반면, 규격에서의 길이는 IEI와 LI(즉, IE 길이)도 포함한다. BASESPEC은 규격)의 형식에 따라 IEI와 LI의 크기를 뺀다. 예를 들어, 도 7에 도시된 바와 같이, BASESPEC은 그것의 형식이 1 바이트 IEI(T)와 2 바이트 확장 LI(-E가 있는 L)를 포함하기 때문에 그것의 값 길이를 계산하기 위해 ESM 메시지 컨테이너 IE의 IE 길이에서 3 바이트를 뺀다. 마찬가지로, BASESPEC은 2 바이트를 T3346 값 IE의 길이로 빼는데, IEI(T)는 1 바이트 LI(L)을 가지고 있다. BASESPEC은 값(V)만 있기 때문에 EMM 원인 IE의 IE 길이를 조정하지 않는다.

그런 다음, BASESPEC는 조정된 IE를 비교한다. 길이가 다를 경우 BASESPEC는 이를 유효하지 않은 불일치로 보고한다. 예를 들어, 도 7에서 EMM 원인 IE의 값 길이는 규격과 바이너리 모두에서 동일하므로 BASESPEC은 불일치를 보고하지 않는다. 한편, 규격(3 바이트)에 있는 ESM 메시지 컨테이너 IE의 최소값 길이는 바이너리(0 바이트)의 길이와 다르므로 BASESPEC은 이를 잘못된 불일치로 표시한다.

또한, 메시지 구조를 의미론적으로 비교한다.

구문 분석 외에도 BASESPEC은 의미론적 분석을 수행한다. 구문 분석이 메시지 구조의 명백한 불일치를 식별할 수 있지만, 베이스밴드 바이너리에서 주어진 메시지에 대한 실제 디코딩 논리는 구문 형식과 다를 수 있다. 이를 위해 의미론적 분석은 디코더 기능에서 수신 메시지가 구문 분석되는 방법에 초점을 맞춘다. BASESPEC은 구현과 규격 사이의 메시지 처리에서 불일치를 발견함으로써 디코더 기능의 의미론적 결함을 드러낸다. 여기에서는 이러한 불일치를 의미론적 불일치라고 부른다. 이러한 의미론적 불일치는 규격과 다른 베이스밴드의 의도하지 않은 동작을 의미할 수 있다.

의미론적 분석을 위해 BASESPEC은 주소를 제공하는 디코더 함수를 상징적으로 실행한다. 그런 다음, BASESPEC은 기호 실행에서 얻어진 제약조건을 그 고유한 역할을 사용하여 IEI와 LI로 변환한다. IEI는 비명령 IE를 구별하는 반면, LI는 값 부분의 크기를 지정한다. 다음으로 BASESPEC은 식별된 IEI와 LI를 기반으로 메시지 구조를 구축하여 구문 비교와 유사한 규격의 구조와 비교한 후 마지막으로 불일치를 보고한다.

도 8은 본 발명의 일 실시예에 따른 의미론적 분석을 나타내는 도면이다.

도 8을 참조하면, 샘플 EMM ATTACH REJECT 메시지를 사용한 L3 디코더 의미론적 분석(810)의 전반적인 절차를 보여준다.

1) 기호 실행: BASESPEC은 제한되지 않은 기호 실행의 개념에 따라 전체 베이스밴드 바이너리 대신 디코더 기능을 분석한다. 제한되지 않은 기호 실행은 확장성을 위해 전체 바이너리를 실행하지 않고 개별 함수를 직접 분석한다. 따라서 BASESPEC은 디코더 함수의 엔트리에서 반환될 때까지 기호 실행을 수행한다. 효율적인 분석을 위해 BASESPEC은 PD와 메시지 유형을 통합하여 한 번에 하나의 L3 메시지를 처리한다. 메시지 본문, 즉 IE는 가능한 IE를 고려하도록 제한되지 않는다. 예를 들어 도 8의 메시지에는 PD(0x7) 및 메시지 유형(0x44)에 대한 구체적인 값이 있다. 이는 EMM ATTACH REJECT 메시지를 나타낸다. 그러나 메시지 본문은 제한되지 않은 기호 변수(v1-v4)로 구성된다.

기호 실행은 기호 변수와 제약 조건을 생성한다. 이 변수들은 IEI와 LI의 디코딩 의미를 포함한다. 각 기호 변수는 IE 필드(즉, IEI, LI 또는 값) 중 하나를 나타내며, 각 제약 조건은 디코더가 필드를 처리하는 방법을 나타낸다. 디코더에서 기호 변수와 연관된 조건부 분기는 이러한 변수의 제약 조건을 생성한다. 이러한 제약 조건들은 비명령 IE의 경우 IEI를 확인하거나 임베디드 메시지 구조에 기초하여 LI를 검증함으로써 만들어질 수 있다. 예를 들어, 도 8의 프로그램 상태는 따르는 경로에 따라 기호 변수의 다른 제약 조건을 포함한다. v2==0x5F의 제약조건을 포함하는 S1 상태는 IEI 값으로 0x5F를 가진 IE를 디코딩하는 경로를 따랐을 수 있다.

2) IEI 및 LI 식별: 기호 상태가 디코더 기능의 끝에 도달하면 BASESPEC은 수집된 기호 변수와 제약조건에서 IEI와 LI를 식별한다. 첫째, BASESPEC은 메모리 주소 지정의 용도를 사용하여 LI를 식별한다. LI가 값 부분의 크기를 지정함에 따라 디코더 함수는 주소 계산에서 LI를 사용하여 다음 IE에 접속한다. 예를 들어, 도 8에서 v3이 주소 A에 위치한 LI라고 가정하자. 그런 다음, v4와 그 다음 바이트는 길이가 v3인 값 부분이다. 그러므로 디코더 함수가 다음 IE에 접속하기를 원할 때, 그것은 A+v3+1을 IE의 주소로 사용할 것이다. 따라서 LI에 대한 기호 변수는 주소에 사용되는지 여부를 확인하여 식별할 수 있다. 또한, -E 접미사 형식을 가진 2 바이트 LI도 유사하게 식별될 수 있다. 마지막 IE의 LI는 이러한 방식으로 식별될 수 없지만, 여기에서는 다른 부분이 식별된 후 마지막 미확인 기호 변수를 LI로 가정할 수 있다.

다음으로, 비명령 IEI의 IEI는 디코딩 루틴에서 사전 정의된 IEI 값과 비교되어야 하므로 간단한 방법으로 식별될 수 있다. 그러므로 기호변수가 LI가 아닌 경우 IEI로 식별되며, 그 값을 엄격히 제한하는 제약조건들이 있다. 도 8과 같이 일부 제약조건은 IEI의 가능한 값인 0x5F, 0x78 또는 0x16으로 v2 값을 엄격히 제한한다. 따라서 v2는 IEI 부분이다. IE의 값 부분은 디코딩 루틴에서 제약되지 않기 때문에 암묵적으로 식별된다. 디코더 함수가 실제 값을 읽지 않고 값 부분의 주소만 출력으로 저장하는 경우에는 기호 변수에 액세스할 수 없다. 값이 다른 메모리 영역에 액세스되고 복사되는 경우 기호 실행 중에 이러한 작업을 식별하고 값 부분을 결정할 수 있다.

3) 경로 증가 시 처리: 기호 실행 과정에서 BASESPEC은 경로 증가를 방지하기 위해 상태 프루닝(pruning)을 수행하는데, 이는 기호 실행 기반 접근법의 잘 알려진 문제이다. 특히 BASESPEC은 오류 처리 논리에 도달한 경로를 제거한다. 디코더 기능이 메시지에서 명백한 오류를 감지하면 복잡한 오류 처리 논리를 호출한다. 이 오류 처리 논리는 합법적인 메시지 디코딩과는 무관하지만 경로 증가를 일으킨다. 따라서 이 경로를 버리고 경로 증가를 방지할 수 있다. 디코더 함수가 오류를 나타내도록 플래그 변수를 설정하므로 플래그 변수로 이러한 경로를 구별할 수 있다. 따라서 BASESPEC은 플래그 변수를 설정한 경로를 프루닝한다.

또한, 경로 증가를 방지하기 위해 각 상태에서 분석되는 비명령 IE의 수를 제한한다. 비명령 IE는 메시지에서 임의의 순서로 나타날 수 있다. 따라서 수많은 조합이 기호 실행에서 나타나고, 이는 결국 복잡한 제약조건을 가진 수많은 상태를 생성한다. 상태 증가를 방지하기 위해, 대부분의 비명령 IE는 선택 사항이며 서로 관련이 없기 때문에 BASESPEC은 독립 상태에서 각각의 비명령 IE를 별도로 분석한다. 특히, BASESPEC은 각 활성 상태의 IEI를 주기적으로 식별하여 여러 비명령 IE에 대한 제약조건을 가진 경우 상태를 제거한다. 모든 명령 IE는 메시지에 표시되어야 하므로 각 상태에서 분석된다.

4) IE 비교: 비교를 위해 BASESPEC는 확인된 IEI 및 메시지의 LI 값에 기초하여 의미인식 메시지 구조를 구성한다. 기호 실행의 각 상태는 모든 명령 IE와 일부 비명령 IE에 대한 정보를 가지고 있다. BASESPEC은 먼저 다양한 상태로부터 정보를 수집하여 가능한 IE 목록을 작성한다. IEI와 LI의 쌍은 비명령 IE를 구성하며, IEI가 없는 LI는 명령 IE를 구성한다. BASESPEC은 IEI와 LI 부분의 의미론을 분석하며, 그러한 IE가 값 부분만 가지고 있기 때문에 LI가 없는 명령 IE를 식별하지 않는다. 예를 들어, 도 8에서, S1 상태는 v2를 IEI(0x5F)로, v3을 LI로 하는 비명령 IE를 구성한다. S2 상태는 v2가 IEI(0x78)이고 v3:v4가 확장 LI인 비명령 IE로 구성된다. ATTACH REJECT 메시지에도 모든 상태에서 v1이 포함된 명령 IE가 있지만, LI가 없고 값 부분만 있기 때문에 식별되지 않는다. 그런 다음, BASESPEC은 메시지 구조를 도 8의 오른쪽 표로 구성한다. 그것은 길이의 명시적 범위를 보여주기 위해 LI를 구체화한다. 메시지 구조는 디코더의 내부 논리를 반영하기 때문에 의미 인식된다.

마지막으로, BASESPEC은 메시지 구조를 구문 비교에서와 유사하게 규격서와 비교한다. 명령 IE는 고정된 순서로 나타나야 하므로, BASESPEC는 LI가 없는 명령 IE를 건너뛰면서 순차적으로 이들의 LI를 비교한다. 비명령 IE의 경우, BASESPEC는 먼저 IEI를 사용하여 이들을 일치시킨 다음 이들의 LI를 비교한다. BASESPEC은 의미론적 불일치로 일치하지 않는 차이 또는 나머지 IE를 보고한다.

아래에서는 구현 분석을 설명한다.

BASESPEC은 규격과 바이너리 구현 사이의 불일치를 자동으로 발견하지만, 불일치의 영향을 이해하기 위해서는 추가적인 수동 분석이 필요하다. 메시지가 주어지면 디코더 함수는 메시지를 구문 분석하고 메시지의 IE를 해당 처리기 함수에 전달하여 추가 처리를 수행한다. BASESPEC은 메시지의 체계적인 구조를 활용하여 디코딩 루틴을 자동으로 분석한다. 그러나 처리기 함수는 복잡한 의미론(예컨대, 세션 관리 또는 호출 제어)을 가지고 있어 자동으로 정확성을 검증하는 것이 어렵다. 따라서, 실시예들은 그것을 분석하기 위해 수동 분석에 의존한다. 그럼에도 불구하고 BASESPEC에서 보고한 불일치가 이 분석에 힌트를 제공할 수 있다는 점에 주목할 필요가 있다. 실시예들은 복잡한 논리로 전체 기능이 아닌 불일치 IE에 해당하는 루틴만 분석해야 한다.

도 9는 본 발명의 일 실시예에 따른 디코더의 불일치와 처리기 기능의 영향 사이의 관계를 나타낸다.

도 9를 참조하면, 디코더(910)의 불일치와 처리기(920) 기능의 영향 사이의 관계를 나타내며, 특히 누락된 불일치 및 알 수 없는 불일치는 베이스밴드 펌웨어의 기능 오류를 직접적으로 나타낸다. 911과 같이, 누락된 불일치는 양성 IE의 감소를 야기한다. 만약 명령 IE(즉, 필수 필드)가 불일치로 인해 떨어지면 펌웨어가 규격(즉, 기능 오류)을 준수하지 못한다는 것을 보여준다. 또한, 알 수 없는 불일치는 누락된 불일치와 밀접하게 결합된다. 개발자가 실수로 잘못된 IEI 값을 삽입하면 알 수 없는 불일치와 누락된 불일치가 동시에 나타난다. 이러한 경우 알 수 없는 불일치는 기능 오류를 직접적으로 나타낸다.

또한, 유효하지 않은 불일치는 두 가지 영향을 미칠 수 있다. 즉, 디코더가 특정 IE의 길이를 제대로 검증하지 못했다는 것을 본질적으로 나타내기 때문에 기능 오류 또는 메모리 손상을 일으킬 수 있다. IE에 대한 디코더의 길이 제한이 규격에 정의된 것보다 더 엄격한 경우, 양성 IE를 거부하는 기능 오류를 나타내기 때문에 추가 분석이 필요하지 않다(912) 한편, 길이 제한이 더 크면 추가 처리 시 메모리 손상 버그가 발생할 수 있다(913). 예를 들어, 실제 길이가 더 클 수 있지만 개발자가 사양에 따라 특정 IE의 길이를 맹목적으로 가정할 경우 버퍼 오버플로우가 발생할 수 있다. 처리기 기능은 추가 검사를 받을 수 있으므로 잘못된 불일치의 영향을 확인하기 위해 처리기에 대한 수동 분석이 필요하다. 주목할 만한 점은 이러한 유효하지 않은 불일치가 베이스밴드 펌웨어에 메시지 구조를 내장하는 개발자의 실수에 대한 유용한 통찰력을 제공한다는 것이며, 이로 인해 몇 가지 중요한 보안 취약성을 발견할 수 있다는 것이다.

이상에서 설명된 장치는 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 예를 들어, 프로세서, 컨트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPA(field programmable array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 애플리케이션을 수행할 수 있다. 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다. 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다. 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 컨트롤러를 포함할 수 있다. 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.

소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치에 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.

실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다.

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

그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

Claims (18)

1. 컴퓨터 장치에 의해 수행되는 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법에 있어서,
   베이스밴드의 특성을 네트워크 통신을 위한 모뎀으로 활용하여 베이스밴드 소프트웨어를 셀룰러 규격과 비교 분석하는 단계
   를 포함하고,
   상기 셀룰러 규격의 메시지 구조와 비교 분석하는 단계는,
   상기 셀룰러 규격의 표준화된 메시지 구조를 활용하여, 상기 베이스밴드 소프트웨어에서 구현된 메시지 구조를 자동으로 검사하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법.
2. 제1항에 있어서,
   상기 비교 분석을 통해 상기 베이스밴드 소프트웨어의 메시지 구조에서 상기 셀룰러 규격을 준수하지 않는 불일치를 식별하는 단계
   를 더 포함하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법.
3. 제1항에 있어서,
   상기 베이스밴드 소프트웨어를 셀룰러 규격과 비교 분석하는 단계는,
   상기 베이스밴드 소프트웨어를 분석하여 메시지 디코더를 식별하고, 상기 베이스밴드 소프트웨어에 내장된 메시지 구조를 추출하는 단계; 및
   추출된 상기 베이스밴드 소프트웨어에 내장된 메시지 구조를 상기 셀룰러 규격의 메시지 구조와 비교 분석하는 단계
   를 포함하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법.
4. 제3항에 있어서,
   상기 셀룰러 규격의 메시지 구조와 비교 분석하는 단계는,
   상기 내장된 프로토콜 구조가 구문적으로 상기 셀룰러 규격과 동일한지 여부를 비교 분석하는 것
   을 특징으로 하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법.
5. 제3항에 있어서,
   상기 셀룰러 규격의 메시지 구조와 비교 분석하는 단계는,
   상기 메시지 디코더의 기능이 기본 논리가 의미론적으로 기호 실행을 활용하는 상기 셀룰러 규격을 준수하는지 여부를 비교 분석하는 것
   을 특징으로 하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법.
6. 제2항에 있어서,
   상기 불일치를 분석하여 기능 또는 보안 버그를 생성할 수 있는지 확인하는 단계
   를 더 포함하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법.
7. 제2항에 있어서,
   상기 불일치를 식별하는 단계는,
   상기 베이스밴드 소프트웨어의 메시지 구조에서 상기 셀룰러 규격의 메시지 구조에 매핑되지 않은 나머지 정보 요소(information element, IE)를 누락된 불일치 또는 알 수 없는 불일치로 보고하는 것
   을 특징으로 하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법.
8. 제2항에 있어서,
   상기 불일치를 식별하는 단계는,
   다수개의 상기 베이스밴드 소프트웨어의 계층 3(L3) 메시지에서 불일치를 자동으로 식별하고, 분석을 위한 버그 가능성이 있는 지점을 표시하는 것
   을 특징으로 하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법.
9. 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템에 있어서,
   베이스밴드의 특성을 네트워크 통신을 위한 모뎀으로 활용하여 베이스밴드 소프트웨어를 셀룰러 규격과 비교 분석하는 비교 분석부
   를 포함하고,
   상기 비교 분석부는,
   상기 셀룰러 규격의 표준화된 메시지 구조를 활용하여, 상기 베이스밴드 소프트웨어에서 구현된 메시지 구조를 자동으로 검사하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템.
10. 제9항에 있어서,
    상기 비교 분석을 통해 상기 베이스밴드 소프트웨어의 메시지 구조에서 상기 셀룰러 규격을 준수하지 않는 불일치를 식별하는 불일치 식별부
    를 더 포함하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템.
11. 제9항에 있어서,
    상기 비교 분석부는,
    상기 베이스밴드 소프트웨어를 분석하여 메시지 디코더를 식별하고, 상기 베이스밴드 소프트웨어에 내장된 메시지 구조를 추출하고, 추출된 상기 베이스밴드 소프트웨어에 내장된 메시지 구조를 상기 셀룰러 규격의 메시지 구조와 비교 분석하는 것
    을 특징으로 하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템.
12. 제11항에 있어서,
    상기 비교 분석부는,
    상기 내장된 프로토콜 구조가 구문적으로 상기 셀룰러 규격과 동일한지 여부를 비교 분석하는 것
    을 특징으로 하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템.
13. 제11항에 있어서,
    상기 비교 분석부는,
    상기 메시지 디코더의 기능이 기본 논리가 의미론적으로 기호 실행을 활용하는 상기 셀룰러 규격을 준수하는지 여부를 비교 분석하는 것
    을 특징으로 하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템.
14. 제10항에 있어서,
    상기 불일치를 분석하여 기능 또는 보안 버그를 생성할 수 있는지 확인하는 버그 생성 확인부
    를 특징으로 하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템.
15. 제10항에 있어서,
    상기 불일치 식별부는,
    상기 베이스밴드 소프트웨어의 메시지 구조에서 상기 셀룰러 규격의 메시지 구조에 매핑되지 않은 나머지 정보 요소(information element, IE)를 누락된 불일치 또는 알 수 없는 불일치로 보고하는 것
    을 특징으로 하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템.
16. 제10항에 있어서,
    상기 불일치 식별부는,
    다수개의 상기 베이스밴드 소프트웨어의 계층 3(L3) 메시지에서 불일치를 자동으로 식별하고, 분석을 위한 버그 가능성이 있는 지점을 표시하는 것
    을 특징으로 하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 시스템.
17. 컴퓨터 장치에 의해 수행되는 이동통신 표준 문서를 기반으로 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법에 있어서,
    규격과 바이너리별 메타데이터가 있는 베이스밴드 펌웨어에서 메시지 구조를 추출하는 단계; 및
    상기 규격의 메시지 구조를 상기 베이스밴드 펌웨어의 바이너리 임베디드 메시지 구조와 구문적으로 비교하고 기호 실행을 사용하여 구현 논리를 의미론적으로 분석하는 단계
    를 포함하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법.
18. 제17항에 있어서,
    상기 비교 및 분석을 통해 상기 규격의 메시지 구조와 상기 베이스밴드 펌웨어의 메시지 구조의 불일치를 식별하는 단계
    를 더 포함하는, 이동통신 베이스밴드 소프트웨어를 자동으로 비교 분석하는 방법.

Images