Khóa luận tốt nghiệp An toàn thông tin: Xây dựng công cụ phát hiện ứng dụng Android đóng gói lại

Vì vậy, việc phát hiện được ứng dụng Android tệp APK là ứng dụng đóng gói lại là một bước quan trọng, là bước đầu xác định các ứng dụng có khả năngchứa mã độc, phục vụ cho công tác phân

ĐẠI HỌC QUOC GIA TP HO CHÍ MINH

TRUONG DAI HOC CONG NGHE THONG TIN

KHOA MANG MAY TINH VA TRUYEN THONG

THIEU THAI AN NGUYEN PHAN BACH

KHOA LUAN TOT NGHIEP

XAY DUNG CONG CU PHAT HIEN UNG DUNG

ANDROID DONG GOI LAI

Building a tool used to detect Android repackaged applications

KY SƯ NGANH AN TOAN THONG TIN

TP HO CHi MINH, 2021

ĐẠI HỌC QUOC GIA TP HO CHÍ MINH

TRUONG DAI HỌC CÔNG NGHỆ THONG TIN

KHOA MANG MAY TINH VA TRUYEN THONG

THIEU THAI AN - 17520222 NGUYEN PHAN BACH - 17520031

KHOA LUAN TOT NGHIEP

XAY DUNG CONG CU PHAT HIEN UNG DUNG

ANDROID DONG GOI LAI

Building a tool used to detect Android repackaged applications

KY SU NGANH AN TOAN THONG TIN

GIANG VIEN HUONG DAN

TS NGUYEN TAN CAM

TP HO CHi MINH, 2021

THONG TIN HOI DONG CHAM KHÓA LUẬN TOT NGHIỆP

Hội đồng cham khóa luận tốt nghiệp, thành lập theo Quyết định số

Ti8ầy của Hiệu trưởng Trường Đại học Công nghệ Thông tin.

LOI CAM ON

Để hoàn thành khóa luận tốt nghiệp này, chúng em xin gửi lời cảm ơn đến Bangiám hiệu Trường Đại học Công nghệ Thông tin — Đại học Quốc Gia Thành Phó HồChí Minh vì đã tạo điều kiện học tập, nghiên cứu tốt nhất Cảm ơn quý thầy côgiảng dạy tại trường nói chung và Khoa Mạng máy tính & Truyền thông nói riêng

vì đã truyền đạt những kiến thức chuyên môn bồ ích, những kinh nghiệm quý báu

mà chúng em đã học hỏi được trong suốt quá trình học tập, rèn luyện tại trường

Chúng em xin đặc biệt gửi lời cảm ơn đến TS Nguyễn Tân Cầm đã quan tâm, địnhhướng và hướng dẫn tận tình trong suốt quá trình thực hiện khóa luận

Bên cạnh đó, chúng em cũng xin cảm ơn gia đình, bạn bè đã đồng hành cùng

chúng em trong quá trình thực hiện khóa luận Cảm ơn các anh chị ở Trung tâm An

ninh mạng CNSC đã tạo điều kiện và luôn nhiệt tình hỗ trợ, giải đáp các thắc mắc

về khóa luận trong quá trình làm thực tập sinh tại trung tâm

Cuối cùng, do kiến thức chuyên môn còn hạn chế nên khóa luận chắc chắn

không tránh khỏi những thiếu sót Rất mong nhận được nhận xét, ý kiến đóng góp,

từ quý thầy cô trong hội đồng đề khóa luận được hoàn thiện hơn

MỤC LỤCChương 1 TONG QUAN VỀ VẤN ĐỀ NGHIÊN CỨU - : 2

1.1 Tầm quan quan trọng và ý nghĩa của vấn dé cần nghiên cứu 21.2 Mục tiêu đề tài

1.3 Đối tượng của dé tài eeeeeeeeererrrrrrrrrrrrrereo.f

1.4 Phạm vi của dé tài

1.5 Phương pháp nghiên cứu, thực hiện dé tài - s-eesex

1.6 Tình hình nghiên cứu và các công trình liên quan -.-.- 2 1.6.1 DroidMOSS ceeeriiiiiiiiiiiiiiiriiiiriioD.

1.6.4 DNADOId < : s .ccese-e<eeterereeseeermrtrrrrsrsraeiiitirersrsasrinirtrrrransssse Â

1⁄7 Cấu trúc khóa luận eeeererrrrrrre 1

Chương 2 CƠ SỞ LÝ THUYẾT -5stterererererrresrereeee LO

2.1 Gói ứng dụng Android (Android application package) 16

2.2 Dalvik và Dalvik byteCode ccceeeeeeereeerteeeeesrrirrrrrrrrrssir TỔ,

2.3 Đóng gói lại ứng dung Android (Android app repackaging).

2.4 Thành phần của ứng dụng Android -. eeeeeeeeeeerseer 21

2.5 Activity Transition Graph và công cụ A?E

2.7 Thuật toán VF2

Chương 3 PHƯƠNG PHAP VÀ QUY TRINH THỰC HIỆN 35

3.1.1 Xây dựng view graph e.ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss OO.

3.1.2 Xây dựng thuộc tính cạnh -c-ccse:-ee+ccvevveeeserrrrrrrtersee

3.1.3 Xây dựng thuộc tính node

3.2 So sánh và phát hiện feature view graph tương đông

-Chương 4 KET QUA THU NGHIỆM VÀ THẢO

DANH MỤC HÌNH

Hình 1.1: Mô hình DroidMOSS - 5522 22x22 rời 6

Hình 1.2:Mô hình Fuzzy Hashing - ¿- + 6S S122 2g iec 7

Hình 1.3: Mô hình kiến trúc AppInk ¿-+2++++222++++t2vvvrrerrrvrrrrrrs §

Hình 1.4: Mô hình của AnDarwin [ Í|] -¿- ¿c5 x key II

Hình 2.1: Cấu trúc file APK .¿-©22222++22E2++t222E11122221111222111 2221122221 16 Hình 2.2: Các thành phần của ứng dụng Android - ¿ -+22sczz+czsscez 21

Hình 2.3: Sơ đồ cơ chế phân tích tĩnh của công cụ A°E - cc+5ccsscez 23

Hình 2.4: Ví dụ về Java Reflection

Hình 2.5: Sơ đồ mô tả kỹ thuật chèn nhánh giả với khối màu lục là mã rác không

bao giờ được thực thi ¿-¿- +5: + St k4 1T 1H12 21111101 011011110102 uy 27

Hình 2.6: Thuật toán VF2

Hình 2.7: Năm quy tắc khả thi ( feasibility rule) [16| - -¿-csscz+cc5sce2 32 Hình 2.8: Ví dụ hai sơ đồ đơn giản A và B -22c¿c22222ccvcrvvrrrrrrrrrrrrrrrvee 33

Hình 2.9: Hình minh họa các bước thuật toán VF2 cho ví dụ trên 34

Hình 3.1: Mô hình của công CỤ ¿+ + St EkekskEekrrrrrterrkekrrkrirrre oo Hình 3.2: Mô hình xây dựng view graph và thuộc tính cạnh từ công cụ AŸE 37

Hình 3.3: Ví dụ về kết quả thu được sau khi phân tích tĩnh băng công cụ A3E 38

Hình 3.4: Ví dụ khai báo main activity trong tệp AndroidManifest.xml 38

Hình 3.5: View graph với tên activity class và số node tương ứng - 39

Hình 3.6: Hình minh họa cho view graph thu được -¿-¿- 5 <scccccxscee 39 Hình 3.7 : View graph với tên activity class, số node tương ứng và phương thức [0091101117 41

Hình 3.8: View graph chỉ gồm các node, cach và thuộc tích cach dé chuẩn bị cho Glad Goan Tố ố ố ố 42

Hình 3.9: Hình minh họa view graph với thuộc tính cạnh - 42

Hình 3.10: Mô hình xây dựng thuộc tính node ¿- 55255 5+5++x+ccss+ 43 Hình 3.11: Kết quả phân tích tĩnh của một phương thức trong một activity class bằng công cụ Androguard

Hình 3.12: Các API được gọi trong các activity được lấy làm thuộc tính của các

TIOd€ tƯƠN UNG + 1t 1 v11 TT TT ni 45

Hình 4.1: Các lớp được chèn vào ứng dụng bởi công cụ MSFvenom sau khi được

xử lý bằng công cụ apktOol 2+:2222++2222+++t2222Y222223112221122221 tre 48

Hình 4.2: Các lớp dé hiện quảng cáo Google Admob được chèn vào ứng dụng bằng

công cụ PMT Ads 'TOO] 6 cà k1 vn HH TT TH HH THỦ 49

Hình 4.3: Biểu đồ thời gian thực thi trung bình của thuật toán VF2 trên tổng số

lượng node của từng cặp graph được so sánh ¿-¿- - 5© ++x+x+xexerererveeer 53

DANH MỤC BANG

Bảng 4.1: Kết quả quá trình phát hiện ứng dụng đóng gói lại

DANH MỤC TU VIET TAT

STT | Thuật ngữ Mô tả

1 API Application Programming Interface

2 APK Android application package

3 PDG Program Dependence Graph

4 GUI Graphical User Interface

5 SATG Static Activity Transition Graph

6 CFG Control Flow Graph

TÓM TÁT KHÓA LUẬN

Trong những năm gan đây, sự phát triển của điện thoại thông minh cũng nhưcác ứng dụng di động không ngừng tăng tốc Hầu như ai cũng có cho mình ít nhấtmột chiếc điện thoại thông minh Tuy nhiên, sự phát triển đó cũng làm gia tăng cáchình thức tấn công trên thiết bị di động, đặc biệt là đóng gói lại ứng dụng Những kẻtấn công có thé dé dàng đóng gói lại một ứng dụng dưới tên riêng của chúng hoặcnhúng quảng cáo dé kiếm lợi nhuận Chúng cũng có thé sửa đổi một ứng dụng phd

biến và chèn các đoạn mã độc hại vào ứng dụng gốc và tận dụng sự phổ biến củaứng dụng đó để đẩy nhanh quá trình lan truyền phần mềm độc hại Đặc biệt, với

việc phô biến của ứng dụng trả phí trên điện thoại thông minh và nhiều ứng dụng bịgiới hạn phát hành ở các quốc gia, khiến nhu cầu tìm kiếm ứng dụng từ các nguồnkhác không chính thống cũng tăng lên Trong khóa luận này, chúng em đề xuấtViewDroid [1], một phương pháp tiếp cận dựa trên giao diện người dùng dé phat

hiện đóng gói lại ứng dụng dành cho thiết bị di động Ứng dụng Android chuyênsâu về tương tác với người dùng và chỉ phối sự kiện, tương tác giữa người dùng và

ứng dụng được thực hiện thông qua giao diện người dùng Quan sát này truyền cảmhứng cho việc thiết kế giá trị đặc trưng cho từng ứng dụng Android, cụ thể là câygiao diện đặc trưng (feature view graph), thê hiện hành vi điều hướng của ngườidùng trên các giao diện ứng dụng Feature view graph có thể mô tả các ứng dụngAndroid từ mức trừu tượng cao hơn, giúp ViewDroid có khả năng chống rối mã, cóthể phát hiện các ứng dụng được đóng gói lại ở quy mô lớn một cách hiệu quả [1]

Chương 1 TONG QUAN VE VAN ĐÈ NGHIÊN CỨU

1.1 Tầm quan quan trọng và ý nghĩa của van đề cần nghiên cứu

Ngày nay, sự phát triển của các thiết bị di động đang ngày càng mạnh mẽ

Điện thoại thông minh cũng ngày càng phổ biến, đặc biệt là điện thoại hệ điều hànhAndroid Theo statcounter [2], tính đến hết tháng 5 năm 2021 thì hệ điều hànhAndroid chiếm 72,72% thị phần hệ điều hành di động trên toàn thế giới Do đó,

Android cũng là hệ điều hành dành cho điện thoại thông minh được kẻ tấn công

chọn làm mục tiêu nhiều nhất Gói ứng dụng Android (tức là tệp APK) thực sự làtệp lưu trữ ở định dạng ZIP, bao gồm mã bytecode, tệp tài nguyên và tệp kê khai

(manifest) Thật không may, không giống như các phần mềm thực thi truyền thống,các ứng dụng Android rất dễ bị đóng gói lại Với các công cụ mã nguồn mở như

apktool [3] và jadx [4], người ta có thể dé dàng chèn thêm mã hoặc sửa đồi các tệptài nguyên của ứng dụng góc đề đạt được mục đích riêng của họ Ví dụ, những kẻ

viết mã độc tạo mã quảng cáo trên các ứng dụng phô biến để kiếm tiền hoặc chèn

mã độc dé lấy cắp thông tin riêng tư của người dùng Do đó, phần mềm độc hạiAndroid được đóng gói lại là một trong những mối đe dọa chính đối với bảo mật

Android [5] Theo MalGenome [6], một tập dữ liệu tham khảo trong cộng đồng bảomật Android, có 80% mẫu độc hại được biết là được tạo ra thông qua việc đóng gói

lại các ứng dụng khác Hơn nữa, do sự phổ biến của nền tang Android, nhiều chợứng dụng không chính thống tồn tại Hầu hết trong số họ không thực thi kiểm tra

trên các ứng dụng được liệt kê trên trang web của họ Do đó, mức độ nghiêm trọng

của việc đóng gói lại ứng dụng trong nền tảng Android cao hơn so với bat kỳ nền

tảng di động nào khác.

Vì vậy, việc phát hiện được ứng dụng Android (tệp APK) là ứng dụng đóng

gói lại là một bước quan trọng, là bước đầu xác định các ứng dụng có khả năngchứa mã độc, phục vụ cho công tác phân tích mã động sau này Tuy nhiên, vấn đề

phát hiện đóng gói lại ứng dụng là rất khó khăn Mặt khác, đo số lượng ứng dụng

khổng lồ trên một chợ ứng dụng như Google Play, nên cần phải đáp ứng yêu cầu về

hiệu quả và khả năng mở rộng của một kế hoạch phát hiện Mặt khác, kế hoạch pháthiện phải có khả năng chống lại việc sửa đổi mã và các kỹ thuật làm rối mã tự độnghiện có, vì rất dễ dàng sửa đổi, rối mã và đóng gói lại các ứng dụng Android màkhông có mã nguồn của ứng dụng gốc.

Dé phát hiện ứng dụng đóng gói lại, ta cần trích xuất được các thuộc tinh cầnthiết của ứng dụng để tạo ra nhóm các đặc tính riêng biệt đại diện cho ứng dụng đó,được gọi là vết bớt của ứng dụng Trong đề tài này, chúng em có gắng tái hiện một

mô hình phát hiện đóng gói lại có tên là ViewDroid [I], tận dụng vết bớt dựa trên

giao điện người dùng, gọi là feature view graph để phát hiện ứng dụng được đónggói lại trên nền tảng Android ViewDroid cung cấp một giải pháp thay thế cho các

phương pháp phát hiện ở cấp độ mã (code-level) Phương pháp này dựa trên haiđiểm chính Đầu tiên, các ứng dụng dành cho điện thoại thông minh dựa trên hành

vi của người dùng và sự kiện của Android, tương tác giữa người dùng và ứng dụng

được thực hiện thông qua giao diện người dùng (app views) Một số đặc điểm của

giao diện (ví dụ: chuỗi các sự kiện điều hướng giữa các view) là duy nhất cho mỗiứng dụng được phát triển độc lập Thứ hai, bởi vì những kẻ tắn công muốn tận dụng

sự phổ biến của ứng dụng, họ thường giữ giao diện và chức năng gốc của ứng dụng

được đóng gói lại tương tự như ứng dụng gốc để không bị người dùng phát hiện

Tóm lại, ViewDroid được xây dựng dựa trên một vết bớt được gọi là sơ đồ giaodiện, còn gọi là view graph View graph là sơ đồ được xây dựng từ tất cả các viewthông qua phân tích tĩnh và nắm bắt mối quan hệ điều hướng giữa các view Ngoài

ra, cần có thuộc tính cho cả các node và các cạnh trong view graph dựa trên các APIcủa Android Điều này có thé giúp lọc trước các ứng dụng không có liên quan và cải

thiện hiệu quả của thuật toán so sánh.

Ưu điểm nổi bật của ViewDroid là khả năng chống rối mã tốt View graph làmột đại diện cấp cao hơn về hành vi của ứng dụng so với các vết bớt ở code-level

(ví dụ: chuỗi opcode) Nói cách khác, ViewDroid không cần dữ liệu cấp độ tập

lệnh Do đó, nó có khả năng chống lại rối mã như nhiễu lệnh hay dữ liệu, sắp xếplại thứ tự, phân tách và tổng hợp tập lệnh, v.v Ngoài ra, việc tạo ra đồ thị dựa trên

phân tích tĩnh các API của Android framework (ví dụ: startActivity,

startActivityForResult, OnClickListener) Các API này được cung cấp bởi hệ thốngAndroid và khó bị thay thế hoặc sửa đổi Do đó, view graph mạnh mẽ hơn đối vớicác kỹ thuật xáo trộn như tách, đổi tên và triển khai lại API [1]

1.2 Mục tiêu đề tài

Nghiên cứu, thiết kế, xây dựng công cụ ứng dụng ViewDroid dé phát hiện ứng

dụng Android đóng gói lại giúp cải thiện khả năng chống rối mã

1.3 Đối tượng của đề tài

- Thành phần, cấu trúc của file APK và ứng dụng Android

- Các kỹ thuật, công cụ phân tích tĩnh file APK.

- ViewDroid và các kỹ thuật khác dé phát hiện ứng dụng Android được đóng

gói lại.

- Các kỹ thuật rồi mã với dữ liệu đầu vào là file APK

1.4 Phạm vi của đề tài

- Phương thức đóng gói lại ứng dụng Android.

- Các phương pháp đề phát hiện ứng dụng Android được đóng gói lại

- Các phương pháp rối mã ứng dụng Android mà không cần mã nguồn ứng

dụng.

1.5 Phương pháp nghiên cứu, thực hiện đề tài

- Tìm hiểu, nghiên cứu hoạt động của ứng dụng Android, các thành phan và sự

kiện chính tạo nên hoạt động của ứng dụng.

- Tìm hiểu, nghiên cứu phương thức đóng gói lại ứng dụng Android, các thành

phan bắt buộc, có thể, không thể hoặc khó bi thay đổi trong quá trình đóng gói lại

- Nghiên cứu ViewDroid và một số phương pháp khác đề phát hiện ứng dụng

Android đã được đóng gói lại.

- Tìm hiểu, nghiên cứu các kiểu rối mã tự động ứng dụng Android mà không

cân có mã nguôn ứng dụng.

1.6 Tình hình nghiên cứu và các công trình liên quan

Chúng em thực hiện đề tài này dựa trên bài báo khoa học của Fangfang Zhang

va cộng sự [1] đã thực hiện Về các công trình nghiên cứu liên quan, dưới đâychúng em sẽ nếu một số công trình về phát hiện ứng dụng Android đóng gói lại mà

chúng em đã tìm hiéu

1.6.1 DroidMOSS

DroidMOSS [7] tạo nên dấu vân tay đại diện cho mỗi ứng dụng dựa trên cấp

độ mã (code-level) Mỗi ứng dụng Android về cơ bản là một tệp lưu trữ được nén,

chứa tệp classes.dex và thư mục con META-INE Tệp class.dex chứa mã Dalvik

bytecode dé thực thi trong khi thư mục con META-INF chứa thông tin tác giả Détrích xuất mã Dalvik bytecode từ tệp classes.dex, họ sử dụng các trình dịch ngược

thành mã smali Ban đầu, họ sử dụng mã bytecode Dalvik (với mã opcode và toán

hạng) làm thuộc tính của ứng dụng Tuy nhiên, chọn thuộc tính như vậy thì sẽ

không thể chống lại ngay cả đối với sự xáo trộn đơn giản như thay đổi một số toán

hạng chuỗi (chẳng hạn như tên hoặc URL được mã hóa cứng) Do đó, họ chọn thựchiện trừu tượng hóa hơn nữa bang cách loại bỏ các toán hạng và chỉ giữ lai opcode

Họ cho rằng người đóng gói lại có thể dễ dàng sửa đổi hoặc đổi tên các toán hạng(không quan trọng), nhưng khó hơn nhiều để thay đổi các cấu trúc tập lệnh Ngoài

ra, họ cũng nhận thay rằng các ứng dụng thường cố ý thêm vào các thư viện SDK

quảng cáo khác nhau dé hiển thị quảng cáo Sau khi dịch ngược, các thư viện quảngcáo được chia sẻ này tạo ra nhiễu cho việc trích xuất thuộc tính của ứng dụng một

cách không cần thiết Do đó, họ xây dựng một danh sách trắng để xóa thư việnquảng cáo khỏi mã được trích xuất Đối với thông tin về tác giả, thư mục con

META-INF chứa chứng chỉ nhà phát triển, từ đó họ có thé lấy tên nhà phát trién,

thông tin liên hệ và tô chức, cũng như chữ ký khóa công khai Dé đơn giản họ ánh

xạ mỗi chứng chỉ nhà phát triển thành một mã định danh gồm 32 bit duy nhất (gọi

là ID tác giả) Định danh duy nhất nay sau đó được tích hợp vào chữ ký dé so sánh

Third-party Apps Feature | instruction Fuzzy a Third Party

— |

Extraction [sequence | Hashing | fingerprint | App Signatures

‘Similarity Repackaged Apps

Scoring

AndroidMarket Apps Feature | instruction Fuzzy app

TM"| Extraction [sequence “| Hashing [fingerprint

AndroidMarket

App Signatures Author ID

Hình 1.1: Mô hình DroidMOSS

Đối với mỗi ứng dụng, họ tạo một dấu vân tay từ mã được trích xuất ở trên

bằng cách sử dụng hàm băm Mặc dù việc băm toàn bộ chuỗi mã của một ứng dụng

có thể xác định liệu hai ứng dụng có giống nhau hay không, nhưng cách này không

hữu ích dé xác định xem hai ứng dụng tương đồng Lý do là vì một sửa đổi nhỏ sẽlam thay đổi đáng kể giá trị băm Trong DroidMOSS, họ sử dụng một kỹ thuật băm

được gọi là fuzzy hashing [8] Thay vì xử lý trực tiếp và so sánh toàn bộ chuỗi lệnh

đã trích xuất, cần phải đảm bảo các thay đổi không thé ảnh hưởng đến phan lớn

chuỗi lệnh còn lại Để đạt được điều đó, fuzzy hashing chia chuỗi kiến trúc tập lệnh

thành các phần nhỏ hơn Mỗi phần được coi như một đơn vị độc lập để đóng gópvào dấu vân tay cuối cùng Do đó, nếu quá trình đóng gói lại thay đổi một phần

chuỗi lệnh, nó sẽ chỉ tác động đến phần chứa thay đổi Đối với các phần còn lạikhông bị thay đồi, những đóng góp của chúng cho dau vân tay cuối cùng vẫn có giá

trị và không bị ảnh hưởng thông qua quá trình đóng gói lại, qua đó phản ánh sự

giống nhau giữa ứng dụng gốc và ứng dụng được đóng gói lại Đối với việc xác

định ranh giới của từng mảnh ghép, DroidMOSS sử dụng một cửa sé trượt bắt đầu

từ đầu chuỗi lệnh và di chuyên về phía trước cho đến khi giá trị băm cuộn (rollinghashing value) bằng với diém đặt lại được chọn trước, xác định ranh giới của phần

Nếu giả sử có một lệnh mới được thêm vào mảnh đầu tiên của chuỗi lệnh trong

quá trình đóng gói lại Vì sơ đồ Fuzzy Hashing sử dụng một cửa số trượt đề tínhtoán băm cuộn để xác định ranh giới của mảnh, nên có hai khả năng về vi trí của

lệnh mới trong mảnh đầu tiên, ở bên ngoài hoặc bên trong cửa số trượt cuối cùng

Trường hợp thứ nhất chỉ ảnh hưởng đến giá trị băm được tính toán trong mảnh đầu

tiên trong khi các phần còn lại vẫn nguyên vẹn Trường hợp thứ hai thay đổi giá trịbăm cuộn của cửa sé trượt cuối cùng (của mảnh gốc thứ nhất) Kết quả là, thay vìdừng lại ở ranh giới ban đầu, nó tiếp tục di chuyền về phía trước của cửa sé trượt

cho đến khi nó chạm vào cửa số trượt cuối cùng trong mảnh thứ hai Nói cách khác,

nó hợp nhất hai mảnh đầu tiên thành một và không ảnh hưởng đến việc xác địnhranh giới của các mảnh tiếp theo Do đó, sau khi tổng hợp dấu vân tay cuối cùng, nó

chỉ thay đổi giá trị băm của hai mảnh liên tiếp đầu tiên Tổng kết, dé lấy được dấuvân tay, DroidMOSS cần áp dụng hàm băm truyền thống hai lần Đầu tiên là tính

toán giá trị băm của mỗi mảnh (sau khi ranh giới của nó được xác định) và các giá

trị băm được tính toán của tất cả các mảnh được kết hợp thành dấu vân tay cuốicùng Thứ hai là tính toán giá trị băm trên nội dung của cửa số trượt, được khớp vớiđiểm đặt lại Điểm đặt lại được chọn bằng cách sử dụng một số nguyên tô làm điểmđặt lại để nâng cao tính ngẫu nhiên, tăng tính mạnh mẽ của chương trình chống lạicác nỗ lực chống bị phát hiện của kẻ tấn công đóng gói lại Tuy nhiên, đối với các

phương pháp rối mã tác động lên cấp độ mã (code-level) sẽ có tác động đến giá trịcủa các đoạn hàm băm, gây ảnh hưởng đến độ chính xác khi so sánh

1.6.2 AppInk

AppInk [9] sử dụng thủy van (watermark) để đánh dấu ứng dụng nhằm phát

hiện ứng dụng đóng gói lại.

App Developer`s Side ' Arbitrator's Side

App Sources Manifest App Manifest App

& Resources Generation

Watermark Embedder

Watermark Watermarking Source Code iReleased | Watermark —

Value Code Generation Instrumentation ¡ App Recognizer Value

Hình 1.3: Mô hình kiến trúc Appink

Ở phía nhà phát triển ứng dụng, AppInk bao gồm ba thành phan: tạo ứng dụng

kê khai (manifest app generation), tạo mã thủy vân (watermark code generation) và

nhúng thủy vân (watermark embedding) Đầu vào của thành phần tạo ứng dụng kêkhai là mã nguồn của ứng dụng đích bao gồm các tệp tài nguyên của ứng dụng đó

Quá trình tạo mã thủy vân lấy đầu vào là một đối tượng thủy vân (ví dụ: một sốhoặc một chuỗi ký tự) và xuất ra các đoạn mã thủy vân Thành phần nhúng thủy vân

vào gói ứng dụng mục tiêu lấy ứng dụng kê khai và các phân đoạn mã làm đầu vào

để tạo một gói ứng dụng Android đã được nhúng watermark có thể được phát hành

cho các chợ ứng dụng Ở phía kiểm tra, công cụ nhận dạng thủy vân lấy đầu vào làgói ứng dụng Android đã phát hành và ứng dụng kê khai từ phía nhà phát triển ứngdụng để trích xuất thủy vân được nhúng trong gói ứng dụng Android Dưới đây sẽtrình bày tổng quan về ba thành phần trên.

Tao mã thủy vân (watermark code generation): Nhằm cung cấp giá trị thủy vân

do nhà phát triển ứng dụng chỉ định, thành phần này mã hóa giá trị thủy vân thànhmột cấu trúc sơ đồ đặc biệt và biến sơ đồ thành các đoạn mã thủy vân Đề thủy vân

được nhúng khó bị phát hiện, AppInk chia mã thủy vân thành nhiều đoạn khác

nhau, mỗi đoạn sẽ được chèn vào các vị trí khác nhau của mã nguồn của ứng dụngsốc Khi các đoạn mã này được thực thi sẽ kết hợp với nhau và thực hiện thamchiếu đến các đối tượng cụ thé dé tổng hợp thành giá trị thủy vân ban dau

Tao ứng dụng kê khai (manifest app generation): Chức năng chính của ứng

dụng kê khai là cung cấp đữ liệu đầu vào của người dùng được xác định trước choứng dụng đang được xem xét, điều này sẽ kích hoạt quá trình thực thi của các đoạn

mã được nhúng và do đó khôi phục giá trị thủy vân với sự trợ giúp của trình nhận

dạng thủy vân Đề giảm bớt gánh nặng của các nhà phát triển khi viết ứng dụng kêkhai, AppInk tận dụng tinh chất hướng sự kiện của ứng dụng Android và thế hệtrường hợp thử nghiệm dựa trên mô hình mới nhất dé tự động tạo các sự kiện đầuvào này và làm cho quá trình này hoàn toàn minh bạch đối với các nhà phát triển

ứng dụng.

Nhúng thủy vân (watermark embedding): Bằng cách phân tích cú pháp các tệp

trong ứng dụng kê khai, thành phần này trước tiên xác định các sự kiện đầu vào của

người dùng được mã hóa và sau đó xác định trình xử lý sự kiện tương ứng của

chúng dựa trên mã nguồn của ứng dụng góc Tiếp theo, nó chèn các đoạn mã thủyvân dưới đường dẫn của các trình xử lý sự kiện đã xác định này Sau đó, AppInk

đóng gói nguồn ứng dụng đã sửa đổi thành một ứng dụng đã phát hành, dành cho cả

mục đích xuất bản công khai và kiểm tra Còn ứng dụng kê khai được đóng gói

thành một gói thực thi khác, không được phát hành cho công chúng mà dành riêng

cho việc sử dụng kiểm tra thủy vân

Trình nhận dang thủy vân: Thành phan này là một trình giả lập Android đượcgọi bởi một tập lệnh shell Đầu tiên, tập lệnh cai đặt cả ứng dụng Android và ứng

dụng kê khai trong trình mô phỏng, sau đó khởi động ứng dụng kê khai cung cấpchuỗi sự kiện đầu vào cho ứng dụng Android, sau đó gọi Máy ảo Dalvik mở rộng đểxuất tất cả thông tin tham chiếu đối tượng trong thời gian chạy Từ thông tin này,

AppInk sử dụng một mẫu đặc biệt để phù hợp với cấu trúc watermarking tiềm năng.Nếu cấu trúc thủy vân như vậy được xác định, một quy trình ngược lại của quá trình

tạo mã thủy vân sẽ được gọi dé khôi phục giá trị thủy vân được nhúng

Phương pháp này yêu cầu cấu trúc thủy vân phải được giữ bí mật và phải cómột bên thứ ba đáng tin cây dé tong hợp và kiểm tra các thủy vân của các bên phát

triển ứng dụng khác nhau

1.6.3 AnDarwin

AnDarwin [10] thì tập trung vào kha nang mở rộng của công cụ phát hiện ứng

dụng Android đóng gói lại Cụ thể, khả năng mở rộng ở đây là khả năng giới hạn

các cặp ứng dụng phải so sánh dé đảm báo hiệu suất hoạt động trước một số lượng

khổng 16 các ứng dụng Android Theo tác giả thì mô hình này có bốn giai đoạn, cụthể sẽ được trình bày bên dưới

10

Stage1 Stage2 Stage 3 Stage 4

Identifying Similar Code (LSH)

Hình 1.4: Mô hình cua AnDarwin [L0]

Giai đoạn một là trích xuất Vector ngữ nghĩa (Extracting Semantic Vectors).AnDarwin [10] dựa vào các phương thức trong mã nguồn ứng dụng để xây dựng sơ

đồ phụ thuộc của chương trình (Program Dependence Graph) nhưng chi sử dụng

các phụ thuộc của dữ liệu trong mã Nói một cách đơn giản thì một phụ thuộc dữ

liệu tồn tại khi một biến có giá trị phụ thuộc vào một biến khác Mỗi PDG sau đóđược chia thành các thành phần được kết nối vì nhiều phép tính độc lập dữ liệu có

thể xảy ra trong cùng một phương thức Tác giả gọi các thành phần được kết nối

này là các khối ngữ nghĩa vì mỗi khối nắm bắt một khối xây dựng của phương thức

và đại diện cho thông tin ngữ nghĩa được lưu trữ trong PDG Cuối cùng, AnDarwin[10] tính toán một vector ngữ nghĩa dé đại diện cho mỗi khối ngữ nghĩa Mỗi nút

trong khối ngữ nghĩa đại diện cho một câu lệnh trong phương thức và có một kiểu

tương ứng với câu lệnh đó Dé nắm bắt thông tin này, các vector ngữ nghĩa đượctính toán bằng cách đếm tần số của các nút của mỗi loại trong khối ngữ nghĩa

Giai đoạn hai là xác định mã tương tự (Identifying Similar Code) Để xác địnhtất cả các láng giềng gần nhát, ta có thể có gắng tính toán độ tương đồng theo cặp

giữa tất cả các vector ngữ nghĩa Tuy nhiên, cách tiếp cận này không hề hiệu quả vì

có thể dễ dàng có hàng triệu vector Thay vào đó, tác giả sử dụng thuật toán

11

Locality Sensitive Hashing (LSH), là một thuật toán dé tìm các hàng xóm gần giốngnhất một cách hiệu quả trong một số lượng lớn các vector [11] LSH đạt được điềunày bằng cách băm vector sử dụng nhiều hàm băm từ một họ đặc biệt có xác suất vachạm cao nếu các vector tương tự nhau Dé xác định các láng giềng gần nhất, LSHtrước tiên băm tất cả các vector bằng các hàm băm đặc biệt và sau đó tìm kiếm các

láng giềng gần nhất trong số các trùng lặp băm Điều này cho phép LSH xác địnhcác cụm vector tương tự (bản sao mã) gần đúng mà AnDarwin sẽ sử dụng dé phát

hiện các ứng dụng tương tự Hơn nữa, các khối ngữ nghĩa có kích thước khác nhauquá lớn khó có thể là bản sao mã, chúng ta có thể cải thiện khả năng mở rộng hơn

nữa bằng cách nhóm các vector dựa trên độ lớn của chúng Để đảm bảo rằng các

bản sao mã gần ranh giới nhóm không bị bỏ sót, tác giả tính toán các nhóm sao chochúng chồng chéo lên nhau một chút LSH sau đó có thé phân cụm từng nhóm một

cách nhanh chóng vì mỗi nhóm riêng lẻ nhỏ hơn nhiều so với tập hợp tất cả các

vectơ Hơn nữa, mỗi tính toán LSH là độc lập cho phép tất cả các nhóm được chạySong song.

Giai đoạn ba là bỏ qua thư viện (Excluding Library Code) Để bỏ qua các thư

viện được dùng trong nhiều ứng dụng khác nhau nhằm tránh đương tĩnh giả Thay

vì dùng danh sách trắng (white list), tác giả sử dụng kết quả phân tích ở giai đoạn

hai đề tự động phát hiện thư viện AnDarwin bỏ qua bất kỳ thuộc tính nào xuất hiệntrong nhiều hơn một ngưỡng số lượng ứng dụng

Giai đoạn bốn là phát hiện ứng dụng tương đồng Trong giai đoạn này, tác giả

tiếp cận theo hai hướng gồm phát hiện ứng dụng tương đồng toàn phần và tươngđồng một phần Đề phát hiện tương đồng toàn phần, tác giả sử dụng công thức tính

số điểm tương đồng Jaccard với Fa và Fp là tập các thuộc tính của hai ứng dụng:

ra các cụm tập hợp tương tự Để làm như vậy, họ khởi tạo cấu trúc dữ liệu tìm kếthợp, cho phép hợp nhất cụm nhanh chóng và tra cứu phần tử, với mỗi tập hợp trongmột cụm của chính nó Sau đó, họ xử lý từng cặp X, Y và hợp nhất hai cụm chứa X

và Y nếu chúng chưa nằm trong cùng một cụm Bằng cách hợp nhất các cụm theocách này, mức độ giống nhau trung bình của các bộ trong mỗi cụm sẽ giảm dần vớimỗi cặp được xử lý

1.6.4 DNADroid

Bước đầu tiên của DNADroid [13] là xác định nhóm các ứng dụng xuất hiện

với nhau trên kết quả của công cụ tìm kiếm Công cụ tìm kiếm Solr [14] được

DNADroid sử dụng cho bước này dé lấy metadata (tên, tên người sản xuất, mô tả

, ) của một ứng dụng và trả về các ứng dụng có metadata tương tự Các ứng dụngtương tự nhau được đưa vào một cụm Các trường hợp sai sót có thể xảy ra trong

chính bước đầu tiên nếu các ứng dụng tương tự không xuất hiện trong kết quả củacông cụ tìm kiếm Đây sẽ không được coi là thiếu sót của DNADroid vì

repackaging được coi là một cuộc tan công social engineering và rõ ràng rằng kẻ tancông đang không tiến hành cuộc tấn công một cách hiệu quả Các ứng dụng đượcđóng gói lại không xuất hiện với ứng dụng gốc trong kết quả của công cụ tìm kiếm

có thể sẽ không được tải xuống thường xuyên Trong bước thứ hai, một công cụ táithiết kế được sử dung dé lấy các tệp JAR của ứng dụng và được cung cấp cho

WALA [15] rồi trả về một PDG tương ứng với mỗi phương thức của ứng dụng (tệp

JAR) Chỉ các cặp ứng dụng thuộc cùng một cụm được coi là các cặp đóng gói lại

tiềm năng, do đó, chỉ các PDG của chúng được so sánh Số lượng các cặp được sosánh trong một cụm là bậc hai trong tổng số PDG của các ứng dụng trong cụm

Trước khi so sánh các PDG, DNADroid áp dụng một số bộ lọc loại bỏ các cặp mà

rất khó có thể trở thành các cặp đóng gói lại Cụ thể ,một bộ lọc loại bỏ các PDGnhỏ vì chúng không đủ phong phú đề mô tả bất kỳ chức năng nào của ứng dụng và

có thể dẫn đến dương tính giả Bộ lọc khác loại bỏ các cặp trong đó PDG khác nhau

về loại và tần số mỗi loại nút PDG Ca hai bộ lọc thực sự có thé giúp những kẻ đạo

văn trốn tránh sự phát hiện của DNADroid Tất cả việc cần làm là cấu trúc lại các

13

phương thức trong ứng dụng được đóng gói lại thành nhiều phương thức nhỏ hơn vàđiều này sẽ thay đổi tần suất của các loại nút trong PDG mới nhỏ hơn Trong bước

thứ ba, độ tương đồng giữa các PDG được xác định bằng cách sử dụng thuật toán

VF2 [16] dựa trên đăng câu đồ thị con Sự giống nhau của A với B cho biết có baonhiêu mã của A được tìm thấy trong B Sự tương tự của B với A cho biết có bao

nhiêu mã của B mã được tim thấy ở A Số liệu về độ giống nhau này là không đốixứng và có một lợi ích đáng kề Nếu kẻ đạo văn thêm nhiều mã của riêng mình vào

phiên bản đóng gói lại thì phần trăm ứng dụng được đóng gói lại có thể được tìmthấy tương tự như ứng dụng ban đầu sẽ nhỏ Tuy nhiên, phần trăm ứng dụng gốc sẽkhớp với ứng dụng được đóng gói lại vẫn sẽ lớn [17]

1.7 Cấu trúc khóa luận

Khóa luận gồm 5 chương như sau:

Chương 1: TONG QUAN VE VAN ĐÈ NGHIÊN CỨU

Trinh bay tổng quan về nội dung, mục tiêu và định hướng nghiên cứu của khóa

luận Giới thiệu một số công trình nghiên cứu liên quan có cùng đề tài

Chương 2: CƠ SỞ LÝ THUYÉT

Trình bày các định nghĩa, khái niệm, kiến thức nền tảng để phục vụ cho việc

thực hiện đề tài

Chương 3: PHƯƠNG PHÁP, QUY TRÌNH THỰC HIỆN

Đây là nội dung chính của khóa luận, trình bày phương pháp, các bước chính

để thực hiện đề tài

Chương 4: KET QUA THU NGHIEM VÀ THẢO LUẬN

Trình bày quá trình thực nghiệm và kết quả thu được Từ đó đưa ra nhận xét vềquá trình thực hiện đề tài và kết quả đạt được

Chương 5: KET LUẬN VÀ HƯỚNG PHÁT TRIEN

14

Dua ra kết luận về đề tài, dé xuất một số hướng phát triển để cải thiện, mởrộng đề tài trong tương lai.

15

Chương2 CƠ SỞ LÝ THUYET

2.1 Gói ứng dụng Android (Android application package)

Gói ứng dụng Android (APK) là định dạng tập tin đóng gói sử dụng bởi hệ

điều hành Android khi phân phối và cài đặt ứng dụng di động Tập tin APK tương

tự như các gói phần mềm khác như APPX trên Microsoft Windows hay gói Debtrên các hệ điều hành nền Debian như Ubuntu Để tạo ra tập tin APK, chương trình

Android đầu tiên được biên dịch, sau đó tất cả các thành phần của nó sẽ được đóng

gói lại vào một tập tin.

Hình 2.1: Cầu trúc file APK

Một tập tin APK chứa tất cả mã nguồn (ví dụ như các tập tin dex), tài nguyên,

tài sản, chứng nhận, và tập tin manifest Một tệp APK thường bao gồm các tệp và

thư mục sau:

e = Thu mục META-INE:

16

o MANIFEST.MF: là tệp tin kê khai, liệt kê các tệp tin cầu thành của

chương trình và giá trị băm tương ứng mỗi tệp để đảm bảo tính toàn

vẹn.

o_ Chứng chỉ của ứng dụng dé xác minh chữ ký của nhà phát triển

o CERT.SF: Liệt kệ tất cả các tệp tương ứng đã liệt kê trong

MANIFEST.MF kèm chữ ký của nhà phát triển ứng với từng tệp

e lib: Thư mục chứa mã đã biên dich phụ thuộc vào nền tảng

e res: Thư mục chứa các tài nguyên không được biên dịch thành

resources.arsc.

e assets: Thu mục chứa nội dung ứng dung, bao gồm các file tĩnh như âm

thanh, font chữ,

e AndroidManifest.xml: Một tệp kê khai bể sung của Android, mô tả tên,

phiên bản, quyên truy cập, tệp thư viện được tham chiếu cho ứng dụng

e classes.dex: Các lớp (class) được biên dịch ở định dạng tệp dex có thể hiểu

được bởi máy ảo Dalvik và Android Runtime.

® resources.arsc: Một tệp chứa các tài nguyên được biên dịch trước.

Cụ thé hơn về tệp AndroidManifest.xml, Tệp này mô tả thông tin cần thiết vềứng dụng của bạn cho các công cụ xây dựng Android, hệ điều hành Android và

Google Play Trong số nhiều thứ trong tệp này, nhìn chung thì tệp kê khai này yêucầu khai báo nhưng thông tin như sau:

e Tén gói của ứng dụng, thường khớp với mã namespace Các công cụ xây

dựng Android sử dụng điều này đề xác định vị trí của các thực thể mã khixây dựng dự án Khi đóng gói ứng dụng, các công cụ xây dựng sẽ thay thế

giá trị này bằng ID ứng dụng từ tệp bản dựng Gradle, thứ được sử dụng

làm mã nhận dạng ứng dụng duy nhất trên hệ thống và trên Google Play

e Các thành phần của ứng dụng, bao gồm tất cả các activity, dịch vụ,

broadcast receiver và content provider Mỗi thành phần phải xác định cácthuộc tính cơ bản như tên của lớp Kotlin hoặc Java của nó Nó cũng có thể

17

khai báo các thông tin như câu hình thiết bị mà nó có thể xử lý và các bộloc intent mô tả cách thành phần được khởi động.

e Các quyền mà ứng dụng cần dé truy cập các phần được bảo vệ của hệ

thống hoặc các ứng dụng khác Nó cũng tuyên bố mọi quyền mà các ứngdụng khác phải có nếu họ muốn truy cập nội dung từ ứng dụng này

e Các tính năng phần cứng và phần mềm mà ứng dụng yêu cầu, ảnh hưởng

đến thiết bị nào có thé cài đặt ứng dụng từ Google Play

2.2 Dalvik và Dalvik bytecode

Dalvik là một máy ảo chạy các ứng dụng và mã được viết bằng Java Một trình

biên dịch Java tiêu chuẩn biến mã nguồn bậc cao thành Bytecode, sau đó được biêndịch thành Dalvik bytecode và lưu trong tệp dex mà máy ảo Dalvik có thể đọc và

sử dụng Về bản chất, các tệp lớp (class) được chuyên đổi thành tệp dex (giống nhưtệp jar nếu chúng đang sử dụng máy ảo Java tiêu chuẩn) và sau đó được máy ảo

Dalvik đọc và thực thi Dữ liệu trùng lặp được sử dụng trong các tệp lớp chỉ được

thêm vào một lần trong đầu ra dex, giúp tiết kiệm dung lượng và sử dụng ít chỉ phí

hơn Các tệp thực thi có thé được sửa đổi lại khi cài đặt một ứng dụng dé làm cho

moi thứ thậm chí còn được tối ưu hóa hơn cho thiết bị di động Nói cách khác, khi

ta xây dựng một ứng dụng Java cho máy tính của mình, Máy ảo Java sẽ chạy đầu ra

đã biên dich của mã nguồn Dalvik là phiên bản được tối ưu hóa cho thiết bị di độngcủa Máy ảo Java, được xây dựng bằng mã từ dự án Apache Harmony, là nguồn mở

và chạy tốt hơn so với máy ảo Java tiêu chuẩn trên phần cứng hạn chế của thiết bị diđộng, được thiết kế dé có thể chạy nhiều hơn một phiên bản của máy ảo tại một thời

điểm - tức là đa nhiệm Vì Dalvik là mã nguồn mở nên nó cũng được chuyền sang

các hệ điều hành khác, như hệ điều hành trên BlackBerry PlayBook [18]

Người kế nhiệm của Dalvik là Android Runtime (ART), sử dụng cùng một tệp

bytecode và dex, với sự kế thừa nhằm mục đích cải thiện hiệu suất minh bạch chongười ding cuối Môi trường thời gian chạy mới lần đầu tiên được đưa vào Android

4.4 "KitKat" dưới dạng bản xem trước công nghệ và thay thế hoàn toàn Dalvik

18

trong các phiên bản sau; Android 5.0 "Lollipop" là phiên bản đầu tiên trong đó ART

là môi trường thời gian chạy duy nhat!

Trong Dalvik bytecode, Mô hình máy và các quy ước gọi gan như bắt chướccác kiến trúc thực phô biến và các quy ước gọi kiểu C (C-style) Có nhiều quy ước

và tập bytecode trong Dalvik bytecode nhưng trong phạm vi đề tài nghiên cứu, ta

chỉ tập trung vào tập các kiểu gọi phương thức trong Dalvik bytecode được nêu

dưới đây [19]:

e invoke-virtual: Được sử dụng để gọi một phương thức ảo bình thường (một

phương thức không phải là private, static hoặc final, và cũng không phải là

một phương thức khởi tạo).

©_invoke-super: Khi method_id tham chiếu đến một phương thức của một lớp

không phải lớp interface, invoke-super được sử dụng để gọi phương thức

ảo của lớp cha gần nhất (trái ngược với phương thức có cùng method_id

trong lớp đang gọi) Các hạn chế về phương thức giống như đối với

invoke-virtual Trong tệp Dex phiên bản 037 trở lên, nếu method_id đề cậpđến một phương thức interface, thì invoke-super được sử dụng dé gọi phiên

bản cụ thé nhất, không bị ghi đè phiên ban của phương thức đó được xácđịnh trên interface đó Các hạn chế về phương thức giống như đối với

invoke-virtual Trong các tệp Dex trước phiên bản 037, có method_id

interface là bất hợp pháp và không xác định

© invoke-direct: Được sử dụng dé gọi một phương thức trực tiếp không tĩnh

(non-static direct method) (nghĩa là một thé hiện phương thức ma không

thể ghi đè, cụ thể là một thể hiện phương thức riêng hoặc một phương thức

e invoke-interface: Được sử dụng để gọi một phương thức interface

(interface method), nghĩa là trên một đối tượng có lớp cụ thể không được

biết đến, sử dụng method_id tham chiếu đến một interface

2.3 Đóng gói lại ứng dụng Android (Android app repackaging)

Đóng gói lại ứng dụng Android được hiểu phô biến là hành động sử dụng một

tệp APK bất kỳ, dịch ngược (decompile) chúng và thực hiện một số thay đổi trong

mã hay tài nguyên ứng dụng Sau đó, đóng gói lại thành tệp APK và ký lại với chữ

ký riêng của họ Trong quá trình đóng gói lại các ứng dụng, kẻ tấn công (hoặc kẻđạo văn) có thể thực hiện các sửa đổi khác nhau đối với ứng dụng Những sửa đổiđược thực hiện thường có thé là một hoặc nhiều điều sau:

- Thay thế thư viện API bằng thư viện thuộc sở hữu của họ

- Chuyển hướng doanh thu quảng cáo của ứng dụng nếu ứng dụng sử dụng

một số quảng cáo hoặc thêm một số quảng cáo vào ứng dụng

- Chèn thêm mã độc hại bên trong các phương thức (method) hiện có Thêm

phương thức (method) hoặc lớp (class) đặc biệt để thêm mã độc hại vào ứng dụng

Sau những sửa đổi cần thiết, đối thủ có thể đóng gói lại ứng dụng thành tệp

APK Sau đó, họ ký ứng dụng bằng khóa riêng của họ và khóa công khai trong thư

mục META-INF giờ tương ứng với khóa riêng này Ứng dung này sau đó được pháthành trên một số thị trường không chính thức (ví dụ như chợ ứng dụng không chính

thống: các trang web, blog hướng dẫn cài đặt ứng dụng, ), nơi người dùng trở

thành con môi của họ.

Về vấn đề phát hiện ứng dụng đóng gói lại, điều này còn phụ thuộc vào mức

độ các thay đổi tác động vào mã nguồn, chức năng và hành vi của ứng dụng Nếu kẻ

tấn công thực hiện những thay đổi đáng ké đối với siêu dữ liệu và chức năng của

ứng dụng, khiến ứng dụng không còn giữ được những chức năng và hành vi ban

đầu thì rất khó để phát hiện, thậm chí cũng không thể gọi đó là ứng dụng đóng gói

20

lại Tuy nhiên, trong đa số các trường hợp, việc kẻ xấu thực hiện đóng gói lại ứngdụng là vì họ muốn lợi dụng các lợi ích, công dụng và sự pho biến của ứng dụng để

có thé dé đưa mã độc tiếp cận con mỗi, nhanh chóng phát tán và kéo dai sự tổn tại

của ứng dụng chứa mã động trên điện thoại thông minh của nạn nhân Vì vậy, trong

phạm vi đề tài này sẽ giả định rằng kẻ xấu muốn khai thác sự phổ biến của ứng

dụng góc dé lây nhiễm nhanh chóng mã độc

2.4 Thành phần của ứng dụng Android

Để hoạt động được thì ứng dụng Android sẽ gồm nhiều thành phần phối hợp

với nhau Dưới đây sẽ tập trung vào các thành phần quan trọng cần chú ý trong đề

Hình 2.2: Các thành phan của ứng dung Android

Activity là thành phần chính tạo nên hoạt động của ứng dụng Một Activity cóthể là một module, thành phần chức năng độc lập của ứng dụng mà mỗi Activitythường tương ứng với một cửa số giao diện người dùng (hay còn gọi là View) và

các chức năng đáp lại sự tương tác với người dùng Một ứng dụng có thể có một

hay nhiều Activity Một Activity được xây dựng bằng cách kế thừa lớp Activity,

21

một Activity không thé gọi trực tiếp các phương thức hay truy cập vào dữ liệu củamột Activity khác Thay vào đó, phải dùng tới thành phần gọi là Intent từ Activity

này kích hoạt Activity khác và Content Provider.

Intent là cơ chế để một Activity có thể khởi chạy Activity khác trong ứng

dụng Trong Intent có thông tin về nhiệm vụ, các tùy chọn, dữ liệu để Activity thihành được Intent có thé là dạng tường minh, nghĩa là chúng yêu cầu chạy mộtActivity cụ thé chi ra bởi tên lớp của Activity đó Intent cũng có thé ở dang không

tường mình, bằng cách chỉ cung cấp hoạt động mong muốn, hoặc cung cấp dữ liệu

mà căn cứ vào dữ liệu đó tương ứng với hành động, hệ thống Android ở thời điểm

chạy sẽ chọn Activity để kích hoạt Ngoài ra còn có Broadcast Intent sẽ gửi thông

tỉn ra bên ngoài, gửi đến tất cả các ứng dụng (ứng dụng có đăng ký nhận bằng

tự kiện bằng sử dụng Notification hoặc Toast Service có mức độ ưu tiên cao hơnkhi chạy so với các loại tiến trình khác, cần giải phóng tài nguyên nó được xem xét

kết thúc sau nhất và tất nhiên trong quá trình này Service sẽ tự động khởi động lại

ngay khi có đủ tài nguyên hệ thống

Manifest của ứng dụng định nghĩa trong file định dạng XML, nó mô tả để hệthống Android hiểu khái quát về ứng dụng như các Activity, các Service, Broadcast

Receiver, Content Provider, các quyên truy cập Những thông tin này can thiết dé hệ

thống Android chạy được ứng dụng như mong muốn.

Resource là tập hợp các file tài nguyên như chuỗi ký tự, hình ảnh, font chữ, màu sắc, những thành phần xuất hiện trong giao diện người dùng và được

trình bày với file XML.

22

Khi ứng dụng biên dịch, một lớp có tên là R được tự động tạo ra, nó chứa các

tham khảo trỏ đến tài nguyên của ứng dụng Các file manifest và tài nguyên sẽ đượckết hợp lại với nhau được hiểu là Context ứng dụng Context trong ứng dụng đượcbiểu diễn bằng lớp Context, được sử dụng trong ứng dụng để thông qua nó truy cậptới các loại tài nguyên khi ứng dụng đang chạy Ngoài ra, có nhiều phương thức dựa

vào context dé lay các thông tin về môi trường ứng dụng hoạt động khi chạy

2.5 Activity Transition Graph và công cu A°E

Như đã trình bay, phương pháp ViewDroid dé phát hiện ứng dụng Androidđóng gói lại được nêu trong đề tài sử dụng sơ đồ mối quan hệ điều hướng giữa các

view để tạo nên view graph, thứ làm đặc trưng để đại diện cho mỗi ứng dụng và để

so sánh với các ứng dụng khác Do đó, việc phân tích activity transition graph của

ứng dụng bước quan trọng để trích xuất được những thành phần, thông tin cần thiết

để xây dựng sơ đồ đặc trưng

A: intent=new Intent (A, B)

Track taint through app

A: startActivity(intent)

Hình 2.3: Sơ dé cơ chế phân tích tinh của công cụ AXE

Để phân tích, trích xuất sơ đồ các “view” hay cụ thể hơn là sơ đồ chuyền đổi

giữa các activity (Activity Transition Graph) Chúng em sử dụng chức năng phân tích tĩnh của công cụ Automatic Android App Explorer (A*E) [20] Theo tác giả của

công cụ trên, việc xác định đúng thứ tự mà các yếu tố GUI của ứng dụng Android

sẽ được khám phá là một thách thức Vấn đề chính là luồng điều khiển của các ứngdụng Android không chuẩn: không có hàm mainQ, mà là các ứng dụng tập trung

23

vào các lệnh gọi lại được gọi bởi Android framework để phản hồi lại các hành độngcủa người dùng (ví dụ: sự kiện GUI) hoặc các dịch vụ nên (ví du: Cập nhật vị tríGPS) Điều này làm cho việc lập luận về luồng kiểm soát trong ứng dụng trở nênkhó khăn Ví dụ: nếu activity hiện tại là A và quá trình chuyển đổi sang activity B

có thé xảy ra do tương tác của người dùng, thì các phương thức được liên kết với A

sẽ không trực tiếp gọi ra B Thay vào đó, quá trình chuyển đổi dựa trên logicchuyền giao intent chung Từ đó, việc xây dựng SATG có thể đạt được thông quaphân tích luồng dữ liệu, cụ thể hơn là truy vết dữ liệu (taint tracking) Quay trở lại

ví dụ trước với các activity A và B, bằng cách sử dụng phân tích truy vết dữ liệu

được thiết lập thích hợp để truy vết B; nếu việc truy vết có thể đi đến được yêu cầu

gọi thực tế từ A, điều đó có nghĩa là activity B có thể truy cập được từ A và cạnh A

— B được thêm vào SATG Đối tượng trung gian để chuyển đổi activity được thực

hiện bởi các đối tượng có tên intent Theo tài liệu Android chính thức [21], intent là

“mô tả tóm tắt về một thao tác sẽ được thực hiện” Intent có thể được sử dụng để bắtđầu các hoạt động bằng cách chuyền giao intent làm đối số cho một phương thức

giống như startActivity Intent cũng được sử dung đề khởi động dich vụ hoặc gửi tin

nhắn quảng bá đến các ứng dụng khác Do đó, truy vết thông qua intent là chìa khóa

để hiểu luồng hoạt động Ví dụ cụ thé hon, các khai báo đối tượng Intent như: ( new

Intent() ) sẽ được sắn thẻ là source Tiếp theo, phân tích truy vết sẽ tìm kiếm các

điểm sink, ví dụ như các phương thức startActivity, startActivityForResult vàstartActivitylfNeeded sẽ được gắn thẻ là sink Tất cả quá trình phân tích trên củacông cụ sẽ hoạt động trên mã bytecode Sau khi gắn thẻ các phần source và sink,

phân tích truy vết sẽ truyền tải dữ liệu thực tế thông qua mã ứng dụng và cuối cùng

kiểm tra xem các source được truy vết có đến được sink hay không Đối với tất cả

các cặp (source, sink) đã được phát hiện, một cạnh sẽ được thêm vào trong SATG.

Do đó, nguyên tắc chung để xây dựng SATG là xác định các điểm xây dựng intent

là source và các yêu câu bat dau activity là diém sink.

24

2.6 Rối mã (Obfuscation)

Rối mã trong lập trình là kỹ thuật làm cho mã nguồn trở nên khó đọc hơn và

chống dịch ngược trong khi vẫn giữ được chức năng Đối với ứng dụng Android, rồi

mã có loại là rối mã trên mã nguồn trong giai đoạn phát triển ứng dụng (thường đi

đôi với cả việc rút gọn, tối ưu mã nguồn) và rối mã trên gói ứng dụng Android (tứctệp APK) Trong phạm vi của đề tài này nên chúng em chỉ đề cập đến các công cụ

và kỹ thuật dé rối mã với đầu vào là tệp APK Dưới đây sẽ trình bày một số kỹ thuật

rồi mã phô biến

Thay đổi tên định danh (Identifier Renaming): Trong phát triển phần mềm, để

dễ đọc, tên của các thành phần được định danh (ví dụ như tên biến, tên lớp, tên

hàm, API) thường có ý nghĩa Mặc dù các chúng có thể tuân theo các quy tắc đặt tênkhác nhau (như CamelCase, Hungarian Notation), nhìn chung những cái tên đều có

ý nghĩa giúp các lập trình viên hiểu được logic mã và xác định vị trí các chức năng

mục tiêu một cách nhanh chóng Do đó, để giảm khả năng rò rỉ thông tin, tên của sốnhận dạng có thé được thay thế bằng các chuỗi vô nghĩa [22] Ngoài ra, tên gói, tênlớp (class) của ứng dụng cũng là một đặc điểm thể hiện tên ứng dụng và các chức

năng của ứng dụng đó Vì vậy, đối với kẻ tấn công đóng gói lại ứng dụng thì việc

đổi tên định danh gồm tên gói, tên các lớp, tên phương thức, sau đó cập nhật lạitệp AndroidManifest.xml cũng là một trong nhưng nỗ lực của chúng để chống phát

hiện đóng gói lại.

Mã hóa (Encryption): Mã hóa cũng là một kỹ thuật phổ biến Các nội dung

được mã hóa sẽ được giải mã tại thời điểm chạy ứng dụng Đối với nhà phát triển

thì mã hóa là để tránh lộ thông tin tài nguyên trong gói ứng dụng Đối với kẻ tấncông đóng gói lại ứng dụng, mã hóa là một nỗ lực làm thay đổi nội dung bên trong

gói ứng dụng Một số thành phần có thể được mã hóa trong quá trình đóng gói lạinhư: mã hóa thư viện gốc (native library), mã hóa các tệp asset (hình ảnh, âm thanh,

font chữ, ), mã hóa chuỗi chứa trong tệp tài nguyên string.xml, mã hóa chuỗi hằng

(constant string) trong mã.

25