평가

Android 앱을 정적으로 분석하는 프레임워크이다. FlowDroid의 앱-레벨 분석을 컴포넌트-레벨로 가져오면서 적절한 모방을 한 것으로 보이는데, 그 과정에서 수많은 문제점들이 생겨났고, 그걸 어떻게 어떻게 효과적으로 해결한 모습이 돋보인다.

특히 native 라이브러리 문제를 해결하기 위해서 직접 하나하나 모델링 과정을 거쳐서 제공한 것은 정말 대단하다. (연구하면서 얼마나 갈렸을까..) DFG를 구성하기 위해서 <lhs, rhs> 형태의 notion을 개발하여 새로운 문법(?)을 만든 것도 정말 대단하다. 엄청나게 많은 시행착오와 고민이 있었을 것으로 예상된다.

논문 전반적으로 챌린지를 먼저 제시하고, 이후에 해결책을 제시하는 구조로 되어 있어 읽기에 편안했다, 두괄식으로 글을 쓴 것도 그렇다. 또한 논문 전체 내용을 관통하는, 혹은 몇 개의 섹터에서 동시에 참조할 수 있는 범용성 넓은 사례를 제시하여서 깔끔했다!

마지막으로 무언가 새로운 내용을 제시할 때에는, 그리고 그 내용이 자신이 있을 때에는 reference가 마지막으로 가는 구성이 깔끔한 것 같다. reference가 챕터 2에 와버리면 집중력이 챕터 3까지 오기 전에 분산되기 때문에 하고자 하는 얘기를 더 집중력있게 할 수 없다.

0. Abstract

[Amandroid는 안드로이드 앱에 대한 정적 분석 프레임워크임.]
Amandroid는 안드로이드 앱을 context-sensitive하게 보안성을 점검할 수 있는 framework이다. input으로 주어지는 App에 대해서 data flow와 data 의존성 점검을 수행하며, inter-component communication activities도 추적한다. Amandroid는 컴포넌트 수준의 정보를 앱 수준의 정보로 바꾸어놓아, 앱 내부 분석과 앱간 분석을 가능하게 한다.

In this paper,

• 현대 하드웨어 컴퓨팅 리소스를 활용해서 포괄적인 앱 분석(정적 분석)이 실현 가능함을 증명하였다.
• 누구나 다양한 종류의 보안성 점검에 이 도구를 이용할 수 있음을 입증하였다. - 누구나 100줄 정도의 추가적인 코딩만 하면 가능함.
• Amandroid를 이용한 이러한 분석 결과는 이전 연구들보다 낫거나 더 앞섰다.

[Amandroid 분석 잘해요. 앱에 대해서 보안성 점검을 해볼 수 있어요~]
Amandroid의 분석이 직접적으로 컴포넌트 내부의 컨트롤과 데이터 플로우를 조절하기 때문에, 서로 비슷한 앱들로부터 존재하는 여러개의 컴포넌트들 간의 상호작용으로 부터 오는 보안성의 문제를 지적하는 데에 활용될 수 있다. Amandroid의 분석은 안드로이드 런타임 시스템과 라이브러리에 기반하여 잘 구체화 되고 합리적인 추정에 기반해서 특정한 보안성의 문제가 없다는 것을 보장해줄 수 있다.

1. Introduction

[정적 분석만의 장점들이 있는데, 단점은 시간이 넘 많이 든다.]
안드로이드는 유명하고 마켓도 크다. 앱들에서 보안 문제가 아주 많다. 안드로이드 앱들의 보안 문제는 Dalvik bytecode의 정적 분석으로부터 발견할 수 있고, 그걸 해왔던 연구들도 많다. 동적 분석에 비해 정적 분석이 가지는 장점은, 악성 앱이 테스팅 환경에 따라 그들의 동작을 바꾸면서 탐지를 회피하지 못한다는 것이다. 또한 정적 분석은 앱의 행동에 대해서 포괄적인 그림을 볼 수 있다, 정적 분석에 비해는. 코드 행동을 결정하는 내재적인 불확실성 때문에, 모든 정적 분석은 분석 시간과 분석 결과의 정확도가 비례한다. 정확성은 이렇게 정량화될 수 있다.
A: missed behaviors(앱에서는 탐지 못했는데, 취약점인 것. false negatives)
B: false alarms(앱에서는 탐지 했는데, 취약점이 아닌 것. false positives)

Challenges

[1) A,B 정확성 잡기 2) 라이브러리 코드가 너무 커! 3) ICC 통신 어려워]
정적 분석에 대한 현실적인 도전과제는 B를 줄이는 것이다, A도 놓치지 않으면서. 이것은 안드로이드의 특징 때문에 더욱 중요하다.
1) 안드로이드는 이벤트-베이스의 시스템이다. 컨트롤 플로우는 다양한 함수 호출을 유발할 수 있는 앱의 환경으로부터 유발된다. 너무 많은 거짓을(A) 소개하지 않으면서 가능한 컨트롤 플로우들을 잡아내는 것이 중요한 도전과제이다.
2) 안드로이드 런타임은 앱이 의존하고 있는 라이브러리의 방대한 코드를 포함한다. 이벤트-드라이븐 속성은 컨트롤-플로우의 많은 부분이 안드로이드 라이브러리를 포함하도록 만든다. 라이브러리의 모든 코드를 분석하는 것은 분석의 신뢰성은 높이는데, 너무 무거운 작업이 될 것이다.
3) 안드로이드는 컴포넌트 기반 시스템이고, 대규모의 컴포넌트간-통신(ICC)을 사용한다. 예를 들어 컴포넌트는 다른 컴포넌트에게 Intent를 보낼 수 있다. Intent의 대상은 Intent 내부에서 직접 구체화될 수 도 있고, 런타임에 지정될 수도 있다. 모든 ICC 흐름을 잡는 것이 정적 분석에서 주요한 도전과제이다.

이전의 연구들은 위 도전과제들을 처리하려고 시도하였다. FlowDroid, Epicc, CHEX 뭐 등등등.. 이러한 선행연구들은 우리 연구에 영감을 줬다. 우리의 Amandroid - 안드로이드 애플리케이션을 위한 컴포넌트 기반의 데이터 플로우 분석 프레임워크. 오픈소스!

Contributions

[와 이게 무슨 말이야]
[앱 컴포넌트를 기반으로 내부 플로우 그래프인 ICFG를 만들고, 이를 기반으로 각 컴포넌트마다 DFG를 만듬. DFG를 기반으로 각 컴포넌트마다 DDG를 만듬. (그와는 별개로)각 컴포넌트마다 컴포넌트간의 통신을 나열한 ST를 만드는데, ST와 DDG를 결합하면 App-level의 분석을 수행할 수 있다. (그러니까 DDG까지는 컴포넌트 레벨이고, ST가 컴포넌트 간 통신이니까, 둘을 합치면 앱을 전반적으로 분석할 수 있다는 것 같음.)]
1) Amandroid는 모든 프로그램 포인트와 호출 context에서 모든 오브젝트와 필드를 위한 points-to(?) 정보를 계산한다. points-to 정보는 보안 문제들을 분석하는 데에 유용하다. Amandroid는 적은 노력으로 넓은 범위의 보안 문제를 해결할 수 있다. 큰 앱에서도 잘 적용된다.
2) points-to 정보 계산의 일부분으로, inter-procedural control flow graph(ICFG)를 만드는데, flow와 맥락에 sensitive하다. 이게 이전 연구에 비해 우리 연구가 뛰어난데, 정확성이 높다.
3) 앱 컴포넌트마다, Data Flow Graph(DFG)를 만드는데, 각 컴포넌트의 ICFG 들을 각각의 노드의 fact set에 도달하도록 구성되어있다(??). 그리고나서 Amandorid는 각 앱의 컴포넌트에 대한 Data Dependence Graph(DDG)를 DFG로 구성한다. 더욱이 Amandroid는 컴포넌트 간의 통신을 나열한 Summary Table(ST)도 만드는데, Intent나 RPC, static field들도 포함함. Amandroid는 간단한 문자열 분석도 하는데, Intent/RPC 호출 파라미터를 추론하거나, ICC 소스와 타겟간에 유사성을 찾는데에 활용된다. 많은 앱들의 많은 컴포넌트들의 ST들을 이용하여, Amandroidsms component-level의 DDG를 App-level의 DDG로 전환하여, 앱 내부 분석 및 앱간 분석을 가능하게 한다.
4) 분석가는 관심있는 보안 문제를 탐지하기 위해 플러그인을 추가할 수 있다. DFG와 DDG를 query하여(?) 보안 문제들을 해결할 수 있음을 증명하였다.

[우리 도구 짱 잘해요~]
4600개의 리얼-월드 앱과 AMD dataset으로부터 2300개의 악성 앱을 분석하였다. Amandroid가 분석도 잘 하고, 보안성도 잘 잡더라. 데이터 유출, injection, API 악용 등등. 앱 하나 분석하는데 몇 분 정도밖에 안걸림. 구체화된 분석을 위한 코딩도 약 100줄 정도로 쉬움. 시간도 매우 짧음.
가장 최신의 분석 도구인 IccTA와 DroidSafe와 비교해봤는데, 컴포넌트 간 통신을 잡기 때문에 더 넓은 보안 문제를 해결할 수 있었음. Amandroid를 통해서 이전에 발견되지 않았던 심각한 보안 문제도 잡았음.

2. Motivating Example

[안드로이드 앱, 컴포넌트 기반, 라이프사이클에 따른 이벤트 callback 등 기본 지식, 왜 컴포넌트-레벨로 모델링을 했는지]
안드로이드 앱들은 컴포넌트 기반인데, 각 컴포넌트는 각각 독립적으로 맡은 업무가 있다. 안드로이드 앱은 main 메소드를 가지지 않고, 컴포넌트의 라이프 사이클에 따라서 다양한 callback 메소드를 통해 호출된다. 컴포넌트들은 최근에 전송된(?) Intent들을 기억하고 전달하는데, 컴포넌트-레벨에서의 environment이다. 컴포넌트 간에도 컨트롤 플로우, 데이터 플로우가 있음. Figure 1에 대한 설명 ~~
정적 분석도구는 컴포넌트 라이프사이클 메소드들을 잘 분석해야 하는데, FlowDroid와 다르게 우리 도구는 컴포넌트-레벨로 분석을 한다.

[컴포넌트-간 통신에서 주고받는 RPC, Intent, static variable 등 분석 필요]
컴포넌트-간 통신 채널로 주고받는 데이터와 컨트롤 플로우도 분석해야 한다. 컴포넌트가 다른 컴포넌트를 실행하기도 하고, 실행 종료 후 돌아오는 결과값(혹은 Intent)를 반환받기도 하는데, "stateful"한 분석을 위해서는 이를 모두 알고 있어야 함. RPC(Remote procedure call) 채널도 분석해야하는데, (앱 외부의 컴포넌트 호출을 RPC라고 부르는 듯함) 외부 컴포넌트의 메소드와 분석 도구를 연결해야 한다. 그밖에도 여러 변수들도 주고받는데 이것도 처리가 필요하다.

3. The Amandroid Approch

Figure2에서 Amandroid의 pipeline을 볼 수 있다.

1) 앱의 Dalvik 바이트코드를 IR로 변경
2) 안드로이드 시스템과의 상호작용을 모방하는 envirenment model 생성
3) 컴포넌트 별로 DFG 생성. DFG는 컴포넌트의 컨트롤 플로우 그래프에 points-to 정보를 더한 것임. DFG상단에 DDG를 만듬. 컴포넌트간 통신을 나열한 ST를 만듬. DDG를 다 합치면 앱-레벨의 DDG 완성
4) Amandroid는 이렇게 다양한 종류의 보안성 점검이 가능~

3.1. IR Translation

apk에서 IR로 바꾸는 데에 dex2IR 도구를 활용했다고 함.

3.2. Environment Modeling

[컴포넌트를 둘러싼 환경을 모델링하는데, FlowDroid의 앱-레벨 모델링을 컴포넌트-레벨의 모델링으로 변환해서 이용함. 만드는 과정은 아래 참조(사실 잘 모르겠음)]
앱이 모든 코드를 가지고 있는 것이 아니라, 안드로이드 시스템이 제공하는 환경에 있는 코드를 사용할 때가 있다. FlowDroid에서의 안드로이드 환경 모델링 기법을 약간의 중요한 extension을 추가하여 가져다 썼다.

안드로이드 액티비티의 라이프사이클과 콜백-함수에 대한 설명(생략)
Amandroid는 FlowDroid의 앱-레벨 모델과 달리 컴포넌트-레벨의 모델을 제시했는데, 컴포넌트의 라이프사이클에 맞춘 모든 콜백 함수를 포함하여, 모든 가능한 경우를 포함하였다. 이게 더 효과적이고 좋다~ 추가적으로 환경은 컴포넌트로부터 받은 Intent를 계속 기억해야 한다. 그래야 나중에 필요할 때 사용할 수 있다.

Amandroid는 컴포넌트에 대한 환경을 자동으로 만드는데, 그 과정은 '액티비티를 시작한 intent'를 변수로 하는 빈 함수(Env_C)를 만든다. apk의 리소스 파일로부터 기본 정보를 수집하고, 이 정보를 통해 callback 함수를 수집한다. 컴포넌트 C의 타입에 따른 라이프사이클 함수들로 Env_C의 바디를 생성한다. 마지막으로 incremental fasion(?)로 다른 콜백 함수들을 수집한다. 이 모든 과정은 데이터 플로우 분석 이전에 수행된다.

3.3. Component-Based Analysis

[컴포넌트 분석 과정에 대한 개괄. 섹션 4에서 자세히 설명한다고 함]
각 컴포넌트의 환경을 분석의 entry point로 사용하고 데이터 흐름 분석, 데이터 의존성 분석을 수행함.
DFG(data flow graph)는 컴포넌트가 도달가능한 모든 메소드를 나타낸 컨트롤 플로우 그래프를 포함하고, 객체의 생성 지점들을 추적한다. 그런 후에 DDG(data dependence graph)를 DFG 상단에 생성하여 정보 흐름을 명확하게 한다(?)
컴포넌트들의 가능한 통신 채널들을 나열한 ST(summary table)도 생성한다. 필요하다면, DDG과 ST를 합쳐 앱-레벨의 DDG도 생성한다. 섹션 4에서 자세히 설명.

3.4. Using Amandroid for Security Analyses

[이용 방법(예시)]
Data leak Detection - 로그인 정보나 위치정보 등. DDG로부터 탐지 가능. source와 sink가 있다면 source에서 sink로 이어지는 path를 찾을 수 있다. DDG는 explicit information leaks만 탐지할 수 있다. 컨트롤(?)을 통한 정보 유출을 탐지하기 위해서는 control dependence graph를 만들어야 할 수도 있다.

Data Injection Detection - 앱이 공격자로 하여금 데이터를 어떠한 내부 데이터 구조에 삽입하게 함으로써 취약할 수 있는데, 이거를 intent injection이라고 부른다. 공격자가 조작되어 만들어진 intent를 취약한 앱의 public component에 넣으면, 그 다음 intent에서 (민감한) 정보를 반환한다. 그 다음 intent가 중요한 정보의 목적지를 바꿀 수 있도록 조작하면, 백업 서버의 URL, 파일 이름, 문자 수신 번호 등등을 변경할 수도 있다. source를 공격자가 공격 가능한 부분으로 지정하고, sink를 보안에 치명적인 것들로 설정하여서 데이터-의존 경로가 source와 sink 사이에 존재한다면 공격자가 조작가능할 가능성이 있다.

Detecting Misuse/Abuse of APIs - 개발자가 잘못 이용한 API를 찾아낼 수도 있다. Amandroid는 DFG들을 질의하는 과정을 통해 API가 가능한 파라미터 밸류들을 사용했는지를 확인할 수 있다.

4. Component-based Analysis

[points-to 정보를 한 번에 계산하는 것의 장점. (points-to가 뭐지..?)]
object의 points-to 정보를 결정하는 것은 중요한데, 미리 모든 오브젝트의 points-to 정보를 한번에 계산해두어, 일반적인 프레임워크로 만들어두는 것이 추후 분석에 유리하다. 기존 도구인 Soot, Wala는 모든 object-to 정보를 한 번에 계산하는 기능이 없다. 하드웨어 발전으로 인해서 가능해졌다.
일반적으로 Amandroid의 분석은 DFG를 정확하게 만드는 데에 집중한다. ICFG를 만들면 flow-sensitive와 context-sensitive한 데이터 흐름 분석을 동시에 이룰 수 있는데, 함수 호출 구현을 알려면 데이터 타입을 정확하게 알아야 하기 때문이다. control와 data 흐름을 동시에 분석하는 이것은 실용적이고 효율적이기까지 하다. 분석단계는 다음과 같다.
1) DFG(data flow graph)를 각 컴포넌트마다 생성
2) DDG(data dependency graph)를 각 컴포넌트마다 생성
3) (선택적으로) 컴포넌트간 분석

4.1. Component-Level Data Flow Graph

Notations(표기법)

[일부 이해 못 했으나, 아래 예시 참고]
전혀 이해 못 함ㅠㅠ

Amandroid는 points-to facts에 대해 정보를 추적하는데, <lhs, rhs>의 형태로 되어 있다. rhs는 object나 aggregate를 나타낸다. IR에서 모든 명령어는 N이라는 넘버를 부여받아 LN의 형태로 사용된다. 이 숫자는 해당 위치에서 생성된 새로운 object를 대표하기 위해 사용되고, 그것을 instance N이라고 부른다. 예를 들어 Figure 3에서 <i1, 6>은 L6이라는 위치에서 생성된 instance 6을 의미한다.
□N은 Location N에서 받을 수 있는 가능한 어떤 값을 나타낸다. RPC 통신에서는 어떤 값을 받을지 모르기 때문에 사용한다. 예를 들어 <imei2, □37>이라고 하면, Location 37에서 RPC 통신을 통해 받을 수 있는 문자열 변수를 의미한다. (“key”, □37)와 같은 튜플 인스턴스는 키-밸류 쌍을 의미한다.
lhs에도 2가지 타입이 있는데, varible-fact는 말그대로 lhs가 변수일 때이다. heap-fact 타입은 lhs가 object field이거나 array element일 때이다.

Modeling Library and Native Calls

[native 함수는 모델링 불가능. 안드로이드 시스템에서 사용되는 native 함수들 + 자주 사용되는 함수들은 연구진에서 모델링 이미 해 두었음.]
안드로이드는 라이브러리 API가 많은데, 일부는 native하게 구현되어 있다. 일부 앱 개발자들은 native하게 특정 기능을 구현할 때도 있다. Amandroid는 native 코드를 분석하지 않는다. 연구진들이 일부 잘 알려진 native 라이브러리에 대해서는 model을 제시한다. non-native 라이브러리에 대해서도 자주 사용하는 것들에 대해서는 모델을 제시하였다. Amandroid는 안드로이드 라이브러리 함수와 native methods를 모델링하기 위해 다음과 같은 전략을 사용한다.
1) 정적 분석에 중요한 라이브러리 함수의 경우에는, 연구진들이 직접 정확한 모델을 만들어두었거나 문서화 해두었다.
2) 다른 라이브러리 함수들과 native methods들을 위해서는, 일관된 보수적 모델을 사용하는데, 이는 모든 object의 파라미터들과 return object들을 모두 unknown으로 추정하는 것이다.

따라서 이 부분은, i3의 mExtras 필드에 ("key", imei2)의 키-밸류 쌍을 넣은 것이다. putExtra는 안드로이드의 시스템 API라서 연구진들이 모델링을 해 두었다. L39에서 생성된 fact가 ⟨(env, mExtras), (“key”, □37)⟩인데, env의 mExtras 값에 키-밸류 쌍을 넣은 것이다. 여기에서 env는 BarActivity의 environment method의 시작점을 의미한다.

Handling Inter-component Channels

다른 컴포넌트에서 어떤 형태의 데이터를 받을지 알 수 없기 때문에, 위에서 사용했던 보수적인 모델을 사용한다. 더 자세한 내용은 4.3에서 보자~

4.2. Building the Component-Level Data Dependence Graph

[DDG에 대한 정보. DFG를 방향을 가지고 연결한 것. 2가지 종류 있음.]
DDG는 컴포넌트의 DFG로부터 생성되는데, DDG가 있어야 프로그램의 어떤 파트와 어떤 파트가 의존적인지를 알 수 있다. DDG는 방향이 있는 그래프인데, DFG와 노드 셋은 같고, 2가지 종류의 edge가 있다. 1) 오브젝트 의존 엣지 - 인스턴스의 사용 지점과 생성 지점을 연결. 2) 변수 정의-사용 엣지 - 변수의 사용 지점과 정의 지점을 연결
DFG에서 이미 object flow를 잡았기 때문에, 생성된 DDG는 자연스럽게 컴포넌트 내부에서 data 의존성을 잡을 수 있게 된다.

4.3. Linking Inter-component Data Flows

컴포넌트들이 컴포넌트-간 통신(ICC)를 할 때, 분석의 어려움들이 있다.
1) 안드로이드 앱 컴포넌트들이 동시에 실행되어서 그들의 실행 순서가 임의로 구성되거나, 평행할 때가 있다.
2) "re-entrant"를 컴포넌트가 허용하는데, 컴포넌트 A가 컴포넌트 C를 호출하고 상태를 바꿔 놓으면, 다른 컴포넌트 B가 컴포넌트 C에 ICC 호출을 할 때에, A의 이전 ICC 호출에 따른 영향을 받을 수도 있다는 것이다. (A가 C를 바꿔놓는데, 그 영향을 B가 받을 수도 있다는 이야기).

2)에 대한 예시는 get(), set()이다. 먼저 set()한 놈이 지정한 값을 나중에 접근한 get()이 받아가니까.

이러한 데이터 흐름을 잡기 위해서 전통적인 접근 방법은 글로벌하게 모든 컴포넌트들을 계산하는 것이었다. 단점은 어떠한 새로운 컴포넌트가 등장했을 때, 전부 다시 계산해야 한다는 것이었는데, 컴포넌트-간 분석 결과를 재사용하기에는 불가능하였다. 따라서 다른 방법을 사용함. DFG를 계산할 때, 어떤 타입의 데이터도 ICC 통신에 들어올 수 있다고 가정하였다. 컴포넌트를 오가는 모든 데이터들을 수집/보관하였다. 분석 단계에서는 받는 지점을 그에 대응하는 보내는 지점의 데이터로 "봉합"하였다.
이러한 접근은 아주 좋았는데, 1) 어떠한 타입의 데이터도 ICC 채널로부터 올 수 있다고 가정하는 것이 정확성을 전혀 떨어뜨리지 않았으며, 2) 각각의 컴포넌트들을 별도로 분석함으로써 재사용이 가능해졌다.
이러한 접근은 컴포넌트-간 앱-간 분석을 지원한다. 우리는 오로지 데이터 흐름 분석을 각 컴포넌트 별로 한 번씩 수행하고, DFG를 ICC 수집/보관 데이터를 저장하면 된다. 컴포넌트-간 분석에서는 모든 컴포넌트들의 DFG가 로드되고, ICC 수집/보관 데이터에 기반해서 보내는 지점과 받는 지점의 데이터 의존성을 찾을 수 있다. ICC 수집/보관 데이터가 데이터 구조에 저장되는 것이 Summary Table(ST)라고 부른다.
ST는 컴포넌트가 다른 컴포넌트와 소통하는 채널들을 모두 리스팅한다. 특히 이러한 정보들을 기록한다. 1) send-points. 어떠한 정보를 보내는지. 2) receive-points. receivers's name.

"봉합" 단계에서는 send-point와 receive-point를 단순히 매치하였다. 함수의 시그니처가 같다. "봉합"에 대해서는 뒤에서 더 얘기해보자.

Intent, RPC, Static Field.

각각에 대해서 ST를 구성하는 법. stitching(봉합) 할 때 어떻게 하는지. 어떤 이슈들이 있고, 어떻게 해결했는지를 제시함.

4.4. Building App-level Data Dependence Graph

컴포넌트의 DDG를 가지고 데이터 의존성을 이어주기만 하면 앱-레벨의 DDG가 완성된다.
아주 쉽죵~

4.5. Inter-app Analysis

앱-간 통신은 특별한 것이 아니고, 컴포넌트-간 통신을 앱 바운더리를 넘나들며 하는 것이다. 따라서 컴포넌트-기반의 분석을 앱-간 분석에 그대로 사용할 수 있다. 그러나 문제가 있다.
1) ICC 채널의 일부만이 앱-간 통신을 위해 이용될 수 있다. RPC나 static field는 앱-간 통신에서 이용할 수 없다.
2) 다양한 앱이 같은 패키지와 클래스 이름을 공유하면서, 도구에게 혼란을 줄 수 있다.

1)을 해결하기 위해서 서로 다른 ICC 채널에 서로 다른 scope를 관리하였다. (앱-간 통신에서 이용할 수 있는 경우와 아닌 경우를 잘 분리해서 했다는 것 같음.) 2)를 해결하기 위해서 서로 다른 앱에서는 서로 다른 클래스 로더를 이용하고, 봉합과정에서 충돌을 포하기 위해 origin information을 추가하였다.

5. Implementation

Scala 언어로 구현되었고, Akka's actor-model을 이용하여 분산 처리를 하려고 하였다. actor-model은 동시 계산을 위한 수학적 모델인데, "actor"을 동시 계산의 일반적인 기초 요소로 대한다. 각각의 actor는 자신만의 state를 보존하면서 서로 message를 통해 소통한다.
Amandroid Supervisor Actor는 유저의 앱 분석 요청을 처리하여 개인 actor들에게 명령을 보내는 역할, (worker actor의) 응답을 기반으로 분석을 다음 단계로 진행하는 역할을 한다. 분석의 각 단계는 동시에 계산을 하는 여러 worker actor를 가진다.
DFG, DDG, 앱 메타데이터가 핵심 정보이다. 핵심 정보들을 저장해두는 것은 시간을 매우 많이 줄일 수 있다. 그러나 DDG는 앱별로 기가바이트가 넘어가므로 DDG 자체는 저장하지 않고, 대신에 dataflow facts만을 저장한다. APK Info Collector Actor와 Points To Analysis Actor는 분석 결과를 stage DB에 저장한다. 이는 Security Analysis Actor가 컴포넌트-레벨의 DFG, DDG를 빌드할 때에 사용된다.
Amandroid는 dataflow-based 분석 이외에도 일반적-목적의 정적 분석 프레임워크로도 사용 가능하다.

6. Experiment and Evaluation

2300개의 구글 플레이에 있는 앱, AMD 데이터셋으로부터 2300개의 악성 앱을 분석하였다. 4가지의 질문을 해보았다.

6.1. Amandroid의 실행 시간은?

유저 선택에 따라 정확성-성능 정도를 정할 수 있다. 1개까지의 calling context를 추적하는 것을 기본으로 하엿다. 써드파티 라이브러리를 분석 범위에서 배제할 수도 있다. 실험에서 몇몇 너무 큰 라이브러리들은 배제하였다.
실행시간이 가장 긴 작업은 각 컴포넌트에서 DFG를 만드는 일이었다. DFG만 만들어지면 이어지는 분석은 무시할 만한 수준이었다. 앱을 분석하는 데에 걸린 시간의 중간값은 3분이었다.
new-Amandroid에서 시간이 더 걸렸는데 다음과 같은 이유이다. 1) 안드로이드 앱들의 복잡도가 해가 지나면서 더 증가했고, 데이터셋이 보다 최근에 수집되었다. 2) 새로운 Amandroid가 더 완성된 모델이다, 안드로이드 애플리케이션의 semantics를 모방하는 기능이 추가되었다.

6.2. Amandroid가 존재하는 정적 분석 도구에 비해 얼마나 정확한가?

IccTA와 DroidSafe와 비교하기 위해서 ICC-Bench와 Droid-Bench를 도입했다. 벤치마크 테스트셋은 직접 만든 앱으로 구성되었다. 실제 환경과 다를 수 있고, 비교 목적으로만 사용되는게 낫다.
결과 - 표. Amandroid가 매우매우매우 좋음.

6.3. Amandroid가 현실 세계의 앱들에 존재하는 치명적 보안 이슈들을 발견할 수 있는가?

Amandroid는 확장성이 좋은 프레임워크이고, 분석가로 하여금 플러그인을 추가하는 기능을 제공한다. 연구진이 5개의 보안성 점검 플러그인을 개발하였다.
1) 아이콘 숨김 점검 2) 암호 라이브러리 설정 오류 점검 3) SSL/TLS 설정 오류 점검 4) 데이터 유출 점검 5) Intent Injection 점검

어떻게 어떻게 개발을 해서, 실제 테스트를 했더니 어떤 어떤 결과가 나왔다는 이야기

6.4. Amandroid core framework를 기반으로 새로운 분석을 진행하는데 얼마나 많은 노력이 드는가?

Amandroid의 장점은 간단하고 쉬운 방법으로 다양한 보안 점검을 수행할 수 있는 수단을 제공하는 일반적 프레임워크라는 것이다. 개별 분석을 수행할 때 DFG와 DDG를 이용하는 Checker Plugin을 개발하여 수행한다. 게다가 (도구의) 분석 코어가 DFG와 DDG를 생성하고 나면, 저장되어서 다른 보안성 분석에 재사용될 수 있다.

7. Related Work

FlowDroid로부터 많은 접근 방법을 차용하였음(environment 생성할 대의 콜백 콜렉션 알고리즘 등) FlowDroid는 ICC를 처리하지 않고, 따라서 여러 컴포넌트를 넘나드는 intent와 관련된 security issue들을 처리 불가능. FlowDroid는 flow-insensitive한 분석을 하여 call graph를 만드는데, 이는 이후에 이어지는 IFDS 분석에서 정확성의 문제가 발생할 여지가 있다. Amandroid는 flow- and context- sensitive한 points-to facts를 계산하는 방법으로 call graph를 dataflow 분석과 동일 시간에 진행한다, 따라서 call graph가 보다 정확하고, false positives가 더 적게 생기도록 한다. FlowDroid는 모든 오브젝트에 대해서 alias나 points-to information을 계산하지는 않는데, 컴퓨팅 자원 문제를 고려한 디자인으로 보인다. Amandroid는 모든 오브젝트의 points-to information을 합리적인 컴퓨팅 비용으로 계산한다.

Epicc은 intent의 데이터 구조를 명시적으로 flow function에 모델링함으로써 FlowDroid와 같은 IDE framework를 이용하여 Intent 호출 파라미터를 계산하였다. Epicc은 Intent 파라미터 분석 결과를 Intent call target 문제를 해결하는 데에 사용하지 않았고, 그 결과를 inter-component dataflow 분석에도 사용하지 않았다. Amandroid의 접근 방법은 flow- and context-sensitive한 points-to information을 사용한다, Intent를 위한 별도의 분석 없이도. Amandroid는 Intent 호출 파라미터 정보를 Intent 호출 지점에서 타겟까지 연결하는 데에 이용하여, DFG가 컴포넌트 내부 그리고 외부에서 data flow path를 포함할 수 있게 하였다.

최근, IccTA와 DroidSafe가 가장 최신의 안드로이드 정적 분석을 하고 있다(?). IccTA는 FlowDroid를 확장하여, 현재 일반적인 Intent 호출과 리턴을 통해 data flow를 추적 가능하다. 그러나 IccTA는 아직 RPC를 통한 정보를 추적가능하지 않다. DroidSafe는 Intent와 RPC 함수를 추적가능하지만, inter-app 분석은 지원하지 않는다.

CHEX라는 정적 분석 scheme은 component hijacking problem을 탐지하기 위해 이용된다. CHEX는 app-splits를 구성하고, 각각은 entry point로부터 도달가능한 코드 세그먼트이다. Wala를 이용해 각각의 split에 대해 data-flow summary를 계산한다. 나뉘어진 summary는 안드로이드 시스템 호출 순서에 위반하지 않는 모든 순열을 거쳐 연결되고, transitive한 information flow가 생성된다. Amandroid는 information flow를 다른 방법으로 계산한다. environment method를 이용하여 올바른 방법으로 관련있는 callback들을 호출하는 각각의 component를 통해 계산함.(Android system specification을 통해서) 그리고 DFG, DDG를 만들어 앱 전체를 완성함. CHEX는 ICC 채널을 통한 data flow를 추적하는 기능을 제공하지 않는다.

Chin at al.은 Intent와 관련된 attack surface를 처음 체계적으로 연구했다. 특히 unauthorized intent receipt와 intent spoofing과 같은 문제점을 확인했다. 보수적인 방법으로 이러한 문제들을 위해 경고를 만들어주는 정적 분석 도구를 만들었다. ComDroid는 flow-sensitive하고 intra-procedual한 정적 분석을 진행하고, 1개의 메소드 호출의 깊이까지 추적하는 제한된 inter-procedural 분석도 존재하였다. Amandroid는 inter-procedural data-flow 분석을 할 수 있고, ICC 채널을 넘나드는 data flow도 분석할 수 있다. 비교 연구를 하고 싶어도 link가 이미 죽어버렸다. 저자에게 연락했으나 정보를 받지 못하였다.

Android 앱의 보안 문제를 지적한 연구들이 많았고, 그 중 일부는 정적 분석 방법을 이용하였다. 이러한 연구들은 특정 보안 문제를 찾는 데에 초점을 맞추었고, 사용된 정적 분석은 안드로이드 앱 실행에서의 inter-component한 본성이라든지, 안드로이드 callback 순서의 정확한 모델링과 같은 중요한 이슈들을 언급한 것으로 보이지 않는다. 반면, Amandroid는 정확하고 일반적인 inter-component 분석 도구이다.

많은 이전의 연구들은 Android 시스템에 존재하는 근본적인 보안 문제에 대해 연구하고, 보안 정책을 강화하기 위해 강화된 infrastructure을 제안하였다. SEAndroid는 Mandatory Access Control을 커널과 미들웨어에 강제로 넣도록 제안하였다. 이 시스템은 앱의 샌드-박싱에 더 좋은 메커니즘을 제공한다. 그러나 MAC는 앱 내부에서 또한 적합한 ICC 채널을 통해 이루어지는 보안 문제를 막을 수 없다. 우리는 Android 시스템에 의한 앱의 샌드박싱(및 격리)이 손상되지 않았다고 가정한다. 따라서 우리의 접근은 이러한 연구들에 보충적이다.

TaintDroid는 동적(런타임) taint-traking과 분석 시스템이다, 유저의 개인 정보의 잠재적 오용을 찾기 위해서. 모든 동적 분석은 회피 공격에 취약하다. 반면, 정적 분석은 앱의 코드를 분석하여 앱의 런타임 행동을 결정하기 때문에, 보안성 분석에 유용하다. 정적 분석과 동적 분석을 동시에 이용하는 것이 더 효율적인 보안 문제 탐지에 유용하다. 우리의 접근은 동적 분석들을 보충할 수 있는 정확하고 일반화된 정적 분석 프레임워크를 만들었다.

8. Conclusions

안드로이드 애플리케이션의 안전한 배포에 이용될 수 있는 정적 분석을 위한 일반적 프레임워크인 Amandroid를 소개하였다. 특히 Amandroid는 컨트롤&데이터 플로우를 컴포넌트를 넘나들며 추적할 수 있고, DFG와 DDG를 통해 앱의 행위의 개요를 파악할 수 있다. 일반적인 프레임워크로서, 구체적인 보안성 점검을 위해 쉽게 확장가능하다. 실험 결과 확장도 잘 하고, 현존하는 다른 도구보다 뛰어남을 증명하였다.

Appendix

아우 힘들어 생략.