ĐẠI HỌC QUỐC GIA TP HCM TRƯỜNG ĐẠI HỌC BÁCH KHOA
NGUYÊN HỮU HỒNG
XAY DUNG DO THI LUONG DIEU KHIEN TU MA NHI
PHAN UNG DUNG ANDROID
Nganh: KHOA HOC MAY TINH Ma sé: 60.48.01
LUAN VAN THAC SI
TP HO CHi MINH, thang 12 nim 2016
Trang 2
ĐẠI HỌC QUỐC GIA TP HCM TRƯỜNG ĐẠI HỌC BÁCH KHOA
NGUYÊN HỮU HỒNG
XAY DUNG DO THI LUONG DIEU KHIEN TU MA NHI
PHAN UNG DUNG ANDROID
Nganh: KHOA HOC MAY TINH Ma sé: 60.48.01
LUAN VAN THAC SI
TP HO CHi MINH, thang 12 nim 2016
Trang 3
CƠNG TRÌNH ĐƯỢC HỒN THÀNH TẠI TRƯỜNG ĐẠI HỌC BÁCH KHOA - ĐHQG - HCM
Cán bộ hướng dẫn khoa hoc: PGS TS Quản Thành Thơ
Cán bộ châm nhận xét 1: TS Võ ThịNgọc Châu Cán bộ chấm nhận xét 2: PGS TS Lê Trung Quân
Luận văn thạc sĩ được bảo vệ tại Trường Đại học Bách Khoa, ĐHQG Tp
HCM ngày 30 tháng 12 năm 2016
Thành phần Hội đồng đánh giá luận văn thạc sĩ gồm: 1 PGS TS Dương Tuấn Anh
2 TS Nguyễn Đức Dũng
3 TS Võ Thị Ngọc Châu 4 PGS TS Lé Trung Quân
5 PGS TS Đỗ Phúc
Xác nhận của Chủ tịch Hội đồng đánh giá luận văn và Trưởng Khoa quản lý
chuyên ngành sau khi luận văn đã được chỉnh sửa (nếu cĩ)
CHỦ TỊCH TRƯỞNG KHOA
Hội đồng Khoa học và Kỹ thuật Máy tính
PGS TS Duong Tuan Anh — s à e.ee.e
Trang 4ĐẠI HỌC QUỐC GIA TP.HCM CỘNG HỊA XÃ HỘI CHỦ NGHĨA VIỆT NAM TRƯỜNG ĐẠI HỌC BÁCH KHOA Độc lập - Tự do - Hạnh phúc
NHIỆM VỤ LUẬN VĂN THẠC SĨ
Họ tên học viên: Nguyễn Hữu Hồng MSHV: 7140234 Ngày, tháng, năm sinh: 21-01-1990 Nơi sinh: Đồng Tháp
Chuyên ngành: Khoa học Máy tính Mã ngành: 60.48.01
I TEN DE TAI:
Xây dung đồ thị luồng điều khiển từ mã nhị phân ứng dụng Android
II NHIEM VU VA NOI DUNG:
Luận văn cĩ nhiệm vụ nghiên cứu về việc xây dựng đồ thị luồng điều khiển từ mã nhị phân của Android
Luận văn để xuất một hướng tiếp cận mới là tập trung xây dựng đồ thị luồng điều khiển cho cả hệ thống và ứng dụng Android, từ đĩ cĩ thể khai thác để tìm ra các rị rỉ bảo mật của hệ điều hành này Bên cạnh đĩ, giúp các
lập trình viên nắm bắt được cách thức giao tiếp giữa hệ thống và ứng dụng Android
Ill NGAY GIAO NHIỆM VỤ: ngày 11 tháng 01 năm 2016
IV NGÀY HỒN THÀNH NHIỆM VỤ: ngày 02 tháng 12 năm 2016
V CÁN BỘ HƯỚNG DẪN: PGS TS Quản Thành Thơ
Tp HCM, ngày tháng năm 2017
CAN BỘ HƯỚNG DẪN TRƯỞNG KHOA
(Họ tên và chữ ký) Khoa học và Kỹ thuật Máy tính (Họ tên và chữ ký)
Trang 5` 7
Loi cam on
Trong quá trình nghiên cứu, tơi nhận được nhiều sự giúp đỡ và đĩng gĩp
từ các giáo sư hướng dẫn, các đồng nghiệp, bạn bè và thành viên trong đình Khi gặp những khĩ khăn trong cơng việc, họ luơn cho tơi lời khuyên chân
thành và hiệu quả để giúp tơi cĩ thể hồn thành tốt nghiên cứu
Tơi vơ cùng biết ơn PGS TS Quản Thành Thơ và PGS TS J[ANG Lingxiao Các giáo sư luơn hướng dẫn ý tưởng và khuyến khích tơi đi xa
hơn trong nghiên cứu Họ cũng hỗ trợ cho tơi nguồn lực cũng như tao cho tơi điều kiện đến thực tập tại trường Singapore Management University trong quá trình thực hiện luận văn này
Tơi muốn gửi lời cảm ơn tới anh Nguyễn Minh Hải, anh Đồn Thành Nam, anh Hồng Văn Đức Thơng, TS Hồng Tuấn Anh, La Thành Tâm,
Phạm Hồng Quang Họ vừa là bạn vừa là đồng nghiệp của tơi trong quá trình
tơi thực tập làm việc tại trường Đại học Bách khoa Tp HCM và Singapore Management Ủniversity Họ luơn giúp đỡ va cho tơi những lời khuyên hữu ích trong suốt quá trình nghiên cứu
Tơi cũng muốn gửi lời cảm ơn chân thành đến PGS TS Rajesh Krishna
BALAN và các đồng nghiệp tại Livelabs Singapore Management University
Họ luơn hỗ trợ và cung cấp các thiết bị, tài nguyên tốt nhất cho tơi ở khi làm
việc tại phịng thí nghiệm
Cuối cùng, tơi xin cảm ơn gia đình tơi đã luơn bên cạnh ủng hộ và tạo
những điều kiện tốt nhất để tơi cĩ thể tập trung cho việc nghiên cứu
Tp HCM, ngày 02 tháng 12 năm 2016
Trang 6Abstract
Android has become the most popular mobile system Millions of applica- tions, including many malwares, haven been developed for it Since Android itself evolves constantly with changing features and higher complexities, it is challenging for application developers to keep up with the changes and maintain the compatibility of their apps across Android versions; and it is challenging for application analysis tools to accurately model and analyze app behaviors across Android versions Even though the overall system ar- chitecture of Android and many APIs are documented, many other APIs and implementation details are not, not to mention potential bugs and vulnera- bilities Techniques and tool supports are thus needed to automatically ex- tract information from different versions of Android to help programmers understand system behaviors and APIs across different versions This pa- per aims to address the need It performs whole-system analysis for differ- ent versions of Android by using both backward and forward static analysis of intra-procedural and inter-procedural control-flow and data-flow graphs It can collect information about functions in Android that can be invoked by ap- plications, which are referred to as publicly accessible functions in this paper Such information can help programmers better understand the ways in which their applications utilize system functions We have analyzed Android ver-
sions 4.1.1, 4.2.2, 4.3, 4.4.4, 5.1.0, 6.0.1, and show basic statistics about the
Trang 7Tĩm tắt
Android đã trở thành một hệ thống di động phổ biến nhất Hàng triệu ứng
dụng kể cả các loại mã độc được phát triển cho nĩ Bởi vì Android liên tục
phát triển với sự thay đổi các tính năng ngày một phức tạp hơn, nĩ trở thành một thách thức cho các nhà phát triển để theo kịp với những thay đổi và duy
trì khả năng tương thích các ứng dụng của họ trên các phiên bản Android khác nhau; đây cũng là một thách thức cho các cơng cụ phân tích ứng dụng,
nhằm mơ phỏng chính xác đồng thời phân tích hành vi ứng dụng trên mỗi phiên bản Android Mặc dù kiến trúc tổng thể và nhiều hàm API được cung
cấp tài liệu, nhưng nhiều API khác lại khơng cĩ tài liệu chi tiết, chưa kể đến các lỗi và lỗ hỏng tiềm ẩn Do đĩ, cần thiết cĩ những kỹ thuật và cơng cụ để
tự động trích xuất thơng tin từ các phiên bản Android khác nhau để giúp các lập trình viên hiểu được hành vi của hệ thống và các API khác nhau Nghiên
cứu này nhằm giải quyết nhu cầu đĩ, thực hiện phân tích tồn bộ hệ thống
trên mỗi phiên bản Android khác nhau, bằng cách sử dụng cả hai phân tích tĩnh ngược và xuơi dịng của intra-procedural và inter-procedural dựa trên đồ
thị luồng điều khiển và dữ liệu Đồng thời cũng thu thập các thơng tin về các
hàm cĩ thể được gọi bởi các ứng dụng, được gọi là hàm truy cập cơng khai
trong nghiên cứu này Những thơng tin này cĩ thể giúp lập trình viên hiểu rõ hơn về cách thức các ứng dụng của họ sử dụng các chức năng trong hệ thống
Chúng tơi đã phân tích trên các phiên bản Android 4.1.1, 4.2.2, 4.3, 4.4.4,
5.1.0, 6.0.1 và đưa ra các số liệu thống kê cơ bản về các hàm truy cập cơng
khai trên những phiên bản này Chúng tơi cũng dùng một ví dụ để minh họa
rằng các thơng tin về hàm truy cập cơng khai cĩ thể hữu ích trong việc xác
định những hàm trong hệ thống khơng được bảo vệ bởi các quyền truy cập
Trang 8Lợi cam đoan
Tơi xin cam đoan những nghiên cứu trong luận văn này hồn tồn được tơi xây dựng và ghi nhận trong quá trình tơi học tập tại Khoa Khoa học và
Kỹ thuật Máy tính, trường Đại học Bách Khoa, Đại học Quốc gia Việt Nam -
TP HCM cũng như quá trình tơi thực tập tại Livelabs, School of Information Systems, Singapore Management University
Một phần của nghiên cứu này đã được cơng bố trong hai báo cáo khoa
học dưới đây:
1 Poster: Android Whole-System Control Flow Analysis for Accurate Application Behavior Modeling In Proceedings of the 14th Annual In- ternational Conference on Mobile Systems, Applications, and Services Companion (MobiSys ’16 Companion) ACM, New York, NY, USA,
30-30 DOI: http://dx.doi.org/10.1145/2938559.2948874
2 Whole-System Analysis For Understanding Publicly Accessible Func- tions In Android In Proceedings of the 11th South East Asean Techni- cal University Consortium Symposium (SEATUC 2017) Ho Chi Minh
City, Vietnam March 2017
Trang 101 GIỚI THIỆU
1 Giới thiệu
1.1 Lí do nghiên cứu
Ra đời năm 2007, hệ điều hành Android đạt được sự phát triển nhanh chĩng, năm 2016 Android đã chiếm 80% thị phần hệ điều hành di động tồn
cầu [_Ì điều hành này cĩ hơn § triệu nhà phát triển ứng dụng tính tới năm L_ ]J Do đĩ, để giúp các lập trình viên, đặc biệt là những người mới
làm quen, phát triển ứng dụng một cách nhanh chĩng thì nắm bắt kiến trúc
của hệ điều hành và tất cả các API được cung cấp là việc cần thiết Khi đĩ, nhà phát triển cĩ thể hiểu được những cách thức mà hệ điều hành quản lý các
ứng dụng và gọi các chức năng muốn sử dụng thơng qua các API này Mặc
dù kiến trúc hệ thống của Android và một số API được cung cấp tài liệu, tuy
nhiên do Android được phát triển trải dài từ phiên bản 1.0 đến Nougat 7.0, vì
vậy gây ra sự khơng tương thích trên các phiên bản và sự thiếu nhất quán giữa các hành vi của mã trong thực tế với tài liệu Ngồi ra cịn cĩ các API khơng
được cơng bồ trong tài liệu nhưng vẫn cĩ thể được sử dụng từ ứng dụng, bên
cạnh đĩ cịn cĩ những lỗi và lỗ hỏng của hệ điều hành bị các ứng dụng khai thác với mục đích xấu
Việc hiểu hành vi của hệ thống và các API trở nên khĩ khăn hơn với
sự phân mảnh của hệ điều hành Android: cĩ hơn 1000 thương hiệu và hơn 24.000 loại điện thoại vào năm 2015 [_ ]; các nhà sản xuất tùy chỉnh hệ thống Android theo những cách khác nhau và thường khơng cung cấp đủ tài liệu cho lập trình viên Việc theo dõi và hiểu được mỗi quan hệ giữa các API
của hệ thơng khác nhau bằng việc đọc từng tài liệu và duyệt thủ cơng trên mã
nguồn là rất tốn thời gian và dễ phát sinh lỗi Những yêu cầu như vậy cần phải được hỗ trợ bởi các cơng cụ cĩ thể hoạt động trên từng phần của hệ thống và
các phiên bản Android khác nhau
Trong lĩnh vực phân tích tĩnh hệ thống và ứng dụng Android, cĩ nhiều
nghiên cứu tập trung vào phân tích ứng dụng Android [ |_ ¡L !L ],những
nghiên cứu này địi hỏi kiến thức chuyên sâu về mơ hình của hệ thống Android
như vịng đời callbacks được sử dụng để quản lý các activity của ứng dụng
Trang 111 GIỚI THIỆU
phát triển và phân mảnh của hệ thống, dẫn đến mơ hình và kết quả phân tích
khơng đủ chính xác
1.2 Mục tiêu nghiên cứu
Mục tiêu cuối cùng của luận văn là xây dựng được một mơ hình tự động cho hệ thống Android, tạo điều kiện để lập trình viên hiểu hành vi hệ thống
và các API Một cách hướng tới mục tiêu này là thực hiện phân tích tồn bộ
chương trình của một phiên bản Android kết hợp với một hoặc nhiều ứng
dụng, nhằm tránh việc xây dựng thủ cơng mơ hình hành vi hệ thống Android
trước khi phân tích ứng dụng Phương pháp này được xem xét dựa trên nghiên cứu của Dacong Yan và các cộng sự, tuy nhiên đi kèm nhiều thách thức khi hiện thực [_ ]
Nghiên cứu này là bước đầu tiên để phân tích tồn bộ hệ thống Android
với từng phiên bản, nhằm tự động giám sát các chức năng của hệ thống An-
droid cĩ thé được truy cập bởi các ứng dụng, cung cấp một “bản đồ điều
hướng” cho những phiên bản Android khác nhau Điều này giúp người lập trình viên hiểu những chức năng cĩ trong từng phiên bản Android, cĩ thể được gọi bằng các API Chúng tơi phân tích trên 6 phiên bản Android: 4.1.1,
4.2.2, 4.3, 4.4.4, 5.1.0, 6.0.1 và phân tách các hàm public từ các phiên bản
này Số lượng các hàm public và kích thước mã nguồn Android tang dan
lên qua từng phiên bản, từ khoảng 53.000 ở phiên bản 4.1.1 lên 74.000 ở
phiên bản 6.0.1 Cùng với những phân tích khác (ví dụ như việc thêm vào các kiểm tra permission nhằm ngăn chặn truy cập vào các hàm public một cách
trái phép, phân tách các hàm public phụ thuộc vào đữ liệu từ ứng dụng), cách
tiếp cận này ngồi việc giúp nhà phát triển hiểu được chức năng hệ thống và
các API, đồng thời giúp tìm ra các API trong hệ thống khơng được bảo vệ cĩ
Trang 122_ CƠ SỞ LÝ THUYÊỄT
2_ Cơ sở lý thuyết
2.1 Tổng quan về Android
Android là một hệ điều hành mã nguồn mở dựa trên Linux, được phát
hành bởi Google vào nam 2007 [ ]], ban đầu Android được xây dựng trên bộ
vi xử ly nén tang ARM, sau này mở rộng lén ca Intel x86, MIPS Do được xây dựng dựa trên nền tảng Linux, nĩ cho phép truy cập vào thiết bị thơng
qua các Linux shell cũng như thực thi các lệnh co ban cua Unix
Steck Android Appe Launcher? Phone AlarmClock
Email Settings Camera Gallery Mms DeskClock — Calendar Browser Bluetooth Caleulator Contracts App API -~ ~ ~=-=~=~~~~=~~eemee~eeeime me me mm mm mm me mm mm mm mm mm mem mm android.” BÌnde# -~ ~~~~=eễễ>~~rmmememeeeeeemeeme me Sysiem Services
Powor Managar MountService Status Bar Manager (Apache Harmony)
Activity Manager Notitication Manager ‘Sensor Service
Package Manager Location Manager Window Manager
Battery Service Surtace Flinger =e
Dalvik / Android Runtime / Zygote
UN) - 2-2-2 nnn nnn ne nnn nnn nen ne ne nnn nn ene ee nnn conn em mieeime mem mi=
Libraries Bionic / Hardware
OpenGL /Webkit/ | | Abstraction Layer | | “ative Daemons ae
Linux Kernel
Wakelocks / Lowmem / Binder / Ashmem / Logger /AAM Console /
Trang 13
2_ CƠ SỞ LÝ THUYÊỄT
Android Java, máy ảo Dalvik va Android Runtime
Về cơ bản, Dalvik là máy ảo Java của Android Nĩ cho phép Android
chạy bytecode được tạo ra từ các ứng dụng trên nền Java bao gồm cả các
thành phần riêng của hệ thống Android, đồng thời cung cấp các hook cần thiết và mơi trường giao tiếp với phần cịn lại của hệ thống bao gồm cả các
thư viện bản địa (native libraries) và các native user-space
Từ phiên bản Android 4.4 trở về trước, mã nguồn Java của hệ thơng An-
droid và các ứng dụng của nhà phát triển được biên dịch thành Dalvik byte-
code (dinh dang DEX) để thực thi trên kiến trúc máy ảo Dalvik (Dalvik Vir-
tuai Machine - DVM) DVM được tơi ưu hĩa cho một CPU di động, chậm
hơn CPU một máy tính cá nhân, và hoạt động với bộ nhớ RAM tương đối nhỏ
khoảng 20MB sau khi các dịch vụ hệ thống cao cấp đã được khởi động [_]
Khác với máy áo Java thơng thường (Java Virtual Machine - JVM), DVM dựa
trên register-based thay vì stack-based DVM được thiết kế để nhân rộng một
cách nhanh chĩng vì mỗi ứng dụng chạy trong một “sandbox”, một dạng con- text cĩ chứa instance riêng được máy ảo gắn cho một định danh người dùng Unix (Unix user ID) dac biét
Năm 2013, Google lần đầu tiên giới thiệu kiến trúc Android Runtime (ART) thay thé cho kiến trúc Dalvik cũ trước đĩ, đây là một bước tiễn quan trọng trong việc tối ưu hĩa phần cứng, cũng như tăng tốc độ thực thi cho ứng
dụng Android Từ phiên bản Android 5.0 trở về sau, DVM đã hồn tồn được
thay thế bởi ART Nếu DVM sử dụng Just-In-Time (JTT) để thơng dịch các ứng dụng mỗi khi chạy (JIT chuyển đổi bytecode thành mã máy) làm hiệu
suất của ứng dụng bị giảm, thì ART giải quyết vẫn đề đĩ với Ahead-Of-Time
(AOT) Khi ứng dụng lần đầu được cài đặt vào máy, Dalvik bytecode sẽ được ART biên dịch một lần duy nhất thành mã máy (dinh dang ELF của Linux) _ ] điều này giúp loại bỏ thời gian chuyển đối của JTT Một số ưu điểm của ART là cải thiện hiệu năng hệ thống, giúp việc khởi động và thực thi các ứng
dụng trở nên nhanh chĩng hơn, tăng tuổi thọ pin và hỗ trợ phần cứng tốt hơn,
tuy nhiên cũng cĩ một số nhược điểm như tăng khơng gian lữu trữ cho mỗi
Trang 142_ CƠ SỞ LÝ THUYÊỄT
Java Native Interface
Bên cạnh DVM và ART, mã viết bằng Java đơi khi cũng cần phải giao
tiếp với mã ngơn ngữ khác để cĩ thể sử dụng các chức năng cấp thấp (low- level), điều này đặc biệt đúng với một mơi trường nhúng như Android Do đĩ, Android cung cấp cơ chế Java Native Interface (ND Về bản chất đây là
một cầu nối cuộc gọi đến các ngơn ngữ khác như C và C++, nĩ tương tự như
P/Invoke trong thế giới NET/C# 2.2 Các dịch vụ hệ thơng
Trong Embedded Android, Karin Yaghmour đã mơ tả tương đối đầy đủ
về các dịch vụ hệ thống (system services) của Android [| |] Cac dich vu hé thống là một điểm khá nhiều thú vị của Android, thậm chí Google khơng đề
cập đến nĩ một cách rõ ràng trong các tài liệu phát triển ứng dụng của họ Cĩ
khoảng từ 50 đến 70 dịch vụ hệ thống, những dịch vụ này kết hợp với nhau để
cung cấp những gì cơ bản nhất cho hệ điều hành hướng đối tượng xây dựng trên nhân Linux này Eyaiom Services Syotem Server Jawe-bulld Services
Media Service Prone App
Power Mareger Mount Service
Activity Manager Notification Manager ¬.~ Flinger Phone Service
a Ployer Service
Package Manager Location Mareger coment taruinn
Battery Service Search Service €-huilt Services Audie Policy Service
Window Maneger Wallpaper Service
Stalua Bar Headset Observer He TH aa Includes:
Clipboard Service = - ElageFrighl
- Audio effects - DAM framework UM - -<~<~~<~<~=<=<=~=~~==~======
Native Methods lor Java-bulld Services
Hardware Absiraclion Layer
LÌ
Trang 152_ CƠ SỞ LÝ THUYÊỄT
trên nền C/C++ và phần lớn các dịch vụ sử dụng Java quan trọng như Activ-
ity Manager, Window Manager, Package Manager, Notification Manager., System Server cũng bao gồm một số mã truy cập thơng quan JNI để dựa vào
Java để giao tiếp với các lớp thấp hơn của Android Bên cạnh là một số dịch vụ truyền thơng được đặt trong Media Server, những dịch vụ này đều được viết bằng C/C++ Cuối cùng là các dịch vụ điện thoại nằm độc lập với các
dịch vụ khác
Phạm vi nghiên cứu của luận văn là tập trung vào việc xây dựng và phân
tích các luồng điều khiển cuộc gọi giữa những dịch vụ hệ thống Java-build với nhau Cơ chế khởi động của hệ thống Android và ứng dụng CPU Boot loader |“ - nh.alzea RAM
~ Pul basic HWW i1 quiegcerri : Launcher
stale - [nit tsar
~ Load kernel and FAM dek - Ragisler on @icki) handlers dump to kerr! T startActivity[) ¥
Kernel Activity Manager
- Init env le run C cade glđr†VIR.yota(} Irr5 E>aH
- Init keamel subsystems - Rang
- Init all drovers imam CATEGORY _HOWE Moauré rant FS — Start “iret prooess † # \
Init Zygate System Server
- beta ey variables - Hagstar “yjale socket
- Create mrcuel poinls - Preload all Java classes For each Service
- Mount Fas > Preload resource - Init service
Setup FS perms > Start System Server Reg wi Service Manager
Set OOM adj Opan sackat
- Start native dasmorns - Laghan for connections Incl stan Activity Manager Lá + + Native daemons lo£k[] SũđTrvi=aqrậannsär - wold - netd - debugged - fle -apo_ process -X Zygote Irtilisorvør bootanimatian - Huietoathd - đtrua-la@rnos - installed - keystore adoc * New app Android Furtimne - Blan & Dasik VM
Trang 162_ CƠ SỞ LÝ THUYÊỄT
LÌ
CPU bắt đầu khởi động, kế đến là Bootloader sẽ thiết lập cho RAM, tải
lên Kernel Tại Kernel sẽ thiết lập các driver và tiến trình cơ bản của hệ
điều hành, đồng thời bắt đầu các daemon cơ bản như servicemanager, medi- aserver, bootanimation, adbd, keystore, app_process, Trong d6 quan trong nhất là app_ process -X Zygote, lệnh này sẽ khởi động Android Runtime, khi
runtine khởi động sẽ gọi hàm main của Zygote và Dalvik VM (với Android
4.4 trở về trước)
Zygote chỉ kích hoạt khi cĩ một ứng dụng mới cần khởi động Để ứng dụng khởi động nhanh hơn, Zygote bắt đầu bằng cách nạp trước tất cả các lớp
Java và tài nguyên mà ứng dụng cần khi chạy Zygote luơn lắng nghe yêu cầu
khởi động một ứng dụng mới ở socket /dev/socket/zygote
Mặc dù, Zygote được thiết kế để lắng nghe các yêu cầu khởi động từ ứng
dụng, nhưng cĩ một ứng dụng đặc biệt mà Zygote khởi động trực tiếp đĩ là System Server Đây là ứng dụng được khởi động đầu tiên từ Zygote và nĩ
vẫn tiếp tục tổn tại như một tiến trình độc lập với cha me System Server bat đầu khởi tạo các dịch vụ hệ thống và đăng ký các dịch vụ đĩ với Service
Manager được khởi động trước đĩ Một trong những dịch vụ mà nĩ khởi tạo
la Activity Manager, viéc khởi tạo kết thúc bằng cách gửi một intent loại Intent.CATEGORY_HOME Đây chính là lúc ứng dụng Launcher cơ bản với
màn hình chính quen thuộc của tất cả người dùng Android được khởi động Khi người dung bam vào một biểu tượng của ứng dụng trên màn hình chính, Launcher sẽ yêu cầu Activity Manager bắt đầu một tiến trình chuyển yêu cầu
tới Zygote, nĩ sẽ kích hoạt chính nĩ và bắt đầu ứng dụng mà người dùng chọn
sau đĩ hiển thị lên màn hình thiết bị của người dùng
Tĩm lại, cĩ thể hiểu Zygote và System Server nắm giữ phần lớn hệ thống
hoạt động của hệ thống Android và ứng dụng, đây chính là trọng tâm của
nghiên cứu đã được nhắc đến ở phần, | sẽ được trình bày chỉ tiết ở phần | |
và _|
Trang 17
2_ CƠ SỞ LÝ THUYÊỄT
2.3 Câu trúc Android Package và định dạng DEX
Một ứng dụng Android được cài đặt vào thiết bị thơng qua một tập tin cĩ định dạng là APK Tập tin Android Package hay APK về cơ bản là một gĩi ZIP chứa các tập tin mơ tả, tài nguyên, thư viện và tập tin classes.dex chứa
Dalvik bytecode của ứng dụng Android Cấu trúc Android Package
Nội dung mỗi tập tin APK thì khác nhau tùy thuộc vào mục đích ứng dụng được tạo ra Tuy nhiên, cấu trúc trình bày ở đây là một vài thành phần quan
trọng của ứng dụng Android META-INF
CERT RSA Chiing chi của ứng dụng Để được chấp nhận cho việc cài đặt, một tập tín APK phải cĩ chữ ký kỹ thuật số được khĩa bởi một khĩa
riêng (private key) của nhà phát triển ứng dụng
CERT SF Tap tin chứa danh sách các tài nguyên của ứng dụng được
mã hĩa bang SHA-1
MANIFEST SF Tap tin manifest cua tng dung
res chứa các tài nguyên của ứng dụng như hình ảnh, âm thanh,
Androi dMani fest xm1 Một tập tin nhị phân khai báo các thành phần
và quyển của ứng dụng khi thực thi trong hệ thống
classes.dex Chứa các lớp của ứng dụng dưới dạng Dalvik Excutable
bytecode Đây là thành phần quan trọng nhất của tập tin APK
resources arsc Chứa các tài nguyên tiền biên dịch của ứng dụng
Bên cạnh đĩ, mỗi ứng dụng thường cĩ mét thu muc lib chứa các mã native tiền biên dịch của một kiến trúc vi xử lý như ARM, x86, MIPS,
Các dịch vụ hệ thống (system services) của Android khơng được lưu dưới định dạng APK mà lưu dưới định dạng JAR nhưng bên trong vẫn chứa classes.dex hay META-INE tương tự như một tập tin APK Những dịch
Trang 182_ CƠ SỞ LÝ THUYÊỄT
Định dạng DEX
Tập tín classes dex là thành phần quan trọng nhất của một chương trình Android kể cả ứng dụng thơng thường hay một dịch vụ hệ thống Do đĩ, nghiên cứu định dạng DEX cùng với cấu trúc của Dalvik opcode cĩ liên
quan chặt chẽ với những cơng cụ hỗ trợ phân tích bytecode hiệu quả Ngồi
ra, việc gây rối rắm cho ứng dụng (obfuscation) cũng được khai thác trên tập tin classes dex nhưng nằm ngồi phạm vi nghiên cứu của luận văn này
So sánh bytecode thơng thường của Java và Dalvik, cĩ thể nhận thấy nĩ tối
ưu hĩa khơng gian dựa trên việc chia sẻ dữ liệu Bộ nhớ được lưu bằng cách
đảm bảo đữ liệu được lặp lại tối thiểu, áp dụng implicit typing và labeling JAR PK clase ex [Hooter }) (eee [ Heterogenous constant pool | ‘al string ide constant pool | /Ƒ- ==—) - type_ids canstant pool : |
> proto_ids constant pool
: P field_ids constant pool
> method_ids constant pool | Class Def Table |
clase | Field List |
tal : Method List class | Code Header claee ` Local Variables J L] L [AR
thơng thường chứa các tập tin c1ass với một tập tin APK chứa các class
tương tự nhưng được đĩng gĩi thành một tập tin duy nhất dex Mỗi tập tin class cĩ heterogeneous constant pool chứa các dữ liệu bị duplicatc
Trang 192_ CƠ SỞ LÝ THUYÊỄT
Ví dụ, cĩ nhiều phương thức với nhiều biến trả về kiểu String, thì kết quả
sé lap lai java.lang.String cho méi dấu hiệu của từng phương thức
(method”s signature) Tập tin dex lưu trữ bộ nhớ hiệu quả chủ yếu từ việc
lưu đữ liệu của các type-specific constant pool Như ví dụ trên, hằng số
Java 1ang.String sẽ được hiện diện duy nhất một lần ở type_ids pool
và sẽ được tham chiếu bởi mỗi phương thức dùng nĩ Một tập tin dex cĩ
số lượng tham chiếu nhiều đáng kể so với một file c1ass Việc thiết kế tối
ưu này của dex vẫn đảm bao chi tiết dữ liệu và cho phép nén một cách hiệu
quả lên đến 44% khi so sánh với kích thước một tập tin nén jar _ ] Như đã trình bày, DVM là một register-based Các register cĩ 32 bít để
lưu các giá trị lớn như số interger hay dấu chấm động Cặp thanh ghi liền kể
được sử dụng để lưu giá trị 64 bit Khơng cĩ yêu cầu liên kết giữa các cặp
thanh ghi [_j| Nếu một phương thức cĩ đối số N, nĩ đặt theo thứ tự từ cuối
của N thanh ghi trong khung gọi (invocation frame) phương thức [|] Cac Introduction tương ứng của phương thức này được định dạng theo trật tự từ
cuối tới đầu cho các đối số của chính nĩ Trong suốt quá trình cài đặt và tối
ưu hĩa, một số introduction cĩ thể thay đổi Tổng cộng cĩ 218 opcode trong Dalvik bytecode [L Ì L ]
Việc hiểu câu trúc Android Package và đặc biệt định dạng DEX là điều
kiện cần thiết cho việc chuyển đối Dalvik bytecode thành một biểu diễn trung gian (intermediate representation) trước khi xây dựng đồ thị luồng điều khiển
(control flow graph - CFG) cho hệ thơng cũng như chương trình Android
Đà thị luơng điều khiển là một đồ thị biễu diễn tất cả các đường đi cĩ thể được đi qua trong quá trình thực thi của một chương
trình
Trang 203 NGHIÊN CỨU LIEN QUAN
3 Nghiên cứu liên quan
Việc phân tích mã thực thi Java bytecode khơng phải là mới trong lĩnh
vực cơng nghệ nhưng các ứng dụng Android tuy được phát triển bằng ngơn ngữ Java lại cĩ sự khác biệt giữa bytecode Java thơng thường với DalvIk như
đã trình bày ở phần _ | Các nghiên cứu phân tích Java bytecode nếu khơng cải tiến và cập nhật hỗ trợ thêm Dalvik thì khơng hoạt động được trực tiếp
trên mã thực thi của Android cụ thể như WALA framework
3.1 Các bước xây dựng và phân tích đồ thị cuộc gọi
Đầu tiên, phải nĩi đến các kỹ thuật biên dịch, cĩ hai phương pháp trong kỹ thuật biên dịch ngược [ ]: phương pháp quét tuyến tính (linear sweep) va
phương pháp duyệt đệ quy (recursive traversal) Nếu phương pháp quét tuyến
tính là giải mã các byte thành câu lệnh hợp ngữ tuần tự từ đầu đến cuối thì phương pháp duyệt đệ quy lại bắt đầu từ điểm vào của ứng dụng, lần theo các nhánh và sử dụng kỹ thuật tìm kiếm theo chiều sâu (depth first search) để giải
mã ứng dụng
Kế đến, về cách xây dựng và phân tích đồ thị cuộc gọi cho Android cĩ khá nhiều cách tiếp cận nhưng đều tập trung vào nguyên lý mơ tả ở hình |
e Bước l1: Giải nén (decompression) tập tin apk đối với ứng dụng An-
droid hoặc tập tin Jar đối với các dịch vụ hệ thống Android
e Bước 2: Dịch ngược (dissasembly) tập tín c1asses dex chứa Dalvik bytecode
e Bước 3: Biểu diễn trung gian (intermediate representation - IR) thơng qua biéu dién bytecode (bytecode representation) kết quả bước 2
e Bước 4: Xây dựng đồ thị cuộc gọi (call graph - CG) từ các IR bước 3 e Bước 5: Áp dụng các kỹ thuật phân tích tĩnh dựa trên CG được xây
dựng ở bước 4
e Bước 6: Phân tích kết quả thu được ở bước 5
Trang 213 NGHIÊN CỨU LIEN QUAN APR / JAR Decompression Y DEX Diesasemnbly ¥ Bylecode Hepreseniatior Call Graph (CG) Construction CG-based Static Analysis Arnvaly sis 5 Results
Hình 5: Các bước xây dựng và phân tích đồ thị cuộc gọi của Android Đồ thị cuộc gọi là một đồ thị luồng điều khiển, đại diện cho mỗi
quan hệ cuộc gọi g1ữa các chương trình con (subroutines) trong
một chương trình máy tính (computer program)
3.2 Cơng cụ và framework phân tích bytecode
Về phía cơng nghiệp, phần lớn các dự án nghiên cứu trên Android chỉ
dừng lại ở mức độ dịch ngược Dalvik bytecode thành hợp ngữ hoặc biểu diễn trung gian Các nghiên cứu này tập trung cho việc tính chỉnh và phân tích các tập tin APK ở mức cơ ban
e dexdump [_ ] Là một phần của Android SDK, đây là cơng cụ đơn giản
nhất để thực hiện việc biên dịch ngược Dalvik bytecode Cơng cụ này dùng thuật tốn quét tuyến tính (linear sweep) trên từng bytecode để
phân tích
e dex2jar [_ ]] Một cơng cụ chuyển đổi bytecode của Dalvik thành Java,
nhưng hạn chế của cơng cụ là khả năng khơi phục mã khơng cao, gây khĩ khăn cho việc phân tích
Trang 223 NGHIÊN CỨU LIEN QUAN
L]
biến nhất trên thế giới Nĩ sử dụng các thuật tốn phức tạp, duyệt đệ quy và khả năng phục hồi của baksmali tốt hơn các cơng cụ khác Một
trong những kế thừa xuất sắc nhất của baksmali là apktool
e IDA Pro [ ] La phan mém thuong mai, IDA Pro từ phiên bản 6.6 đã
hỗ trợ phân tích ứng dụng Android từ Dalvik bytecode va đưa ra được
luồng thực thi cơ bản của ứng dụng, tuy nhiên hạn chế của cơng cụ này
là vấn để chi phí bản quyển lớn, khơng hỗ trợ việc xây dựng và phân tích đồ thị luồng điều khiển (CEFG) cho nhiều ứng dụng đồng thời Ngồi ra do là phần mềm thương mại nên IDA chỉ cung cấp một số API cho việc
phát triển các plugin nên hạn chế cho việc mở rộng nghiên cứu
Về phía học thuật, hai hướng chính trong việc phân tích mã nhị phân là phân tích tĩnh (static analysis) và phân tích động (dynamic analysis), mỗi
hướng cĩ những ưu và khuyết điểm riêng Như phân tích động cĩ thời gian thực hiện ngắn hơn, nhưng chương trình phải thực thi trong một mơi trường
ảo, các ngữ cảnh được giả lập cĩ thể khơng đầy đủ tất cả trạng thái của chương
trình Cịn với phân tích tĩnh cĩ ưu điểm là bao hàm được hết các trạng thái của chương trình, nhưng chính điều này lại cũng chính là hạn chế do sự bùng
nổ về khơng gian trạng thái Nghiên cứu này chỉ giới hạn trong hướng phân
tích tĩnh cho hệ thống và ứng dụng Android
Cĩ hai framework nổi tiếng trong giới học thuật về phân tích tinh bytecode
là WALA va Soot
e WALA [ | Là mét framework dùng để phân tích tĩnh mã thực thi của
Java và Javascript Một số chức năng chính của framework này là xây
dựng CFG, hỗ trợ luồng dữ liệu (data flow) interprocedural và context- sensitive Một hạn chế của WALA là khơng hỗ trợ trực tiếp Dalvik bytecode nên để sử dụng được framework này với ứng dụng Android
địi hỏi phải tự thực hiện quá trình chuyển d6i thanh WALA IR
e Soot[_ ] Được tạo ra bởi Raja Vallée-Rai vào năm 2000, qua thời gian trở thành một framework hiệu quả cho việc phân tích tính Java
bytecode Soot dùng phương pháp tuyến tính để chuyển đổi bytecode
Trang 233 NGHIÊN CỨU LIEN QUAN
thành biểu diễu trung gian Jimple Năm 2012, Bartel và các cộng sự đã
phát triển Dexpler giúp chuyển đối Dalvik bytecode của Android thành
Jimple IR của Soot [ ]], với những đĩng gĩp đĩ, Dexpler đã được tích
hợp như một thành phần của Soot, chính điều này giúp Soot cĩ thể
phân tích được mã Dalvik bytecode mét cach hiéu qua Framework nay được dùng cho việc xây dựng CFG, phân tích điểm (points-to analysis),
đồng thời hỗ trợ phân tích luồng dữ liệu cả intra-procedural lẫn inter-
procedural
Với những ưu điểm của mình, Soot đã được lựa chọn làm nền tang cho
việc xây dựng và phân tích CFG của luận văn này
Đồ thị luơng dữ diệu hay luơng dữ liệu là một đồ thị biểu diễn sự phụ thuộc đữ liệu giữa một số phương thức trong một chương
trình
3.3 Các mục đích nghiên cứu
Một số van đề lớn được khai thác theo hướng phân tích tĩnh mã nhị phân
Android bao gồm:
Ro rỉ dữ liệu riêng tư
Cùng với sự phát triển của ứng dung Android, van dé dữ liệu riêng tư
được tập trung nghiên cứu FlowDroid [_] được Steven Arzt và các cộng sự
giới thiệu năm 2014 là một phương pháp hiệu quả cho phân tích rị rỉ dữ
liệu riêng tư Nghiên cứu thực hiện phân tích về bẩn (taint analysis) cho ứng dung Android với các nhay cam (sensitive) flow-, context-, field-, object- va
bao gồm cả phân tích flow-, lifecycle-, static-, alias-aware, nên cách tiếp cận
này cĩ độ chính xác cao Do FlowDroid mã nguồn mở nên đã được kế thừa
trên một số nghiên cứu mở rộng để tăng chính xác cho kết quả phân tích
L_IL1L 1L 1L]
Trang 243 NGHIÊN CỨU LIEN QUAN
Lỗ hỏng bảo mật
Lỗ hỏng bảo mật luơn là một vẫn để cần được quan tâm, người dùng cần phải được bảo vệ tránh khỏi các phần mềm độc hại khai thác dữ liệu với mục đích xâu như truy cập trái phép vào các nguồn tài nguyên riêng tư hay cần bảo vệ thơng qua các thành phần dễ tổn thương của ứng dụng hoặc tiêm mã độc
để thao tác đữ liệu đầu vào với các mục đích riêng Các nghiên cứu nổi bật
theo hướng này như CHEX [_| t hiện luơng rị rỉ bảo mật dựa trên một
đồ thị hệ thống phụ thuộc HE [ jvàiIC L ] đề xuất kỹ thuật phân tích tĩnh để phát hiện ngữ cảnh của các lỗ hỏng anh phan (inter-component
vulnerabilities) Trén co s6 d6, PCLeaks [_| ực hiện phân tích luồng dữ liệu nhạy cảm trên các lỗ hỏng thành phần đĩ, cho phép nĩ khơng chỉ giúp
biết vẫn đề là gì mà cịn biết những dữ liệu nhạy cảm sẽ bi rị rỉ thơng qua đĩ Cấp quyền sử dụng
Kiểm tra quyền sử dụng là một trụ cột trong vấn để về bảo mật của An- droid Mơ hình quyền sử dụng của Android cĩ chép liên kết đến các tài nguyên nhạy cảm với một tập hợp các quyển phải cĩ để cĩ thể truy cập Tuy nhiên,
nghiên cứu của Bartel và các cộng sự chỉ ra mơ hình quyển sử dụng này cĩ
những rủi ro, từ các ứng dụng được cấp thêm nhiều quyển mà họ thực sự
can [|_| ã độc cĩ thể lợi dụng điểm này để đạt được mục đích gây hại
PSC | ]] cũng thực hiện nghiên cứu với phương pháp bĩc tách các đặc
điểm kỹ thuật của Android dựa trên phân tích tĩnh mã nguồn hệ điều hành
Android
Nhìn chung, các nghiên cứu hiện cĩ phần lớn tập trung vào việc phân tích
Dalvik bytecode trên từng ứng dụng Android riêng rẽ, các hướng nghiên cứu
này cĩ ưu điểm về thời gian thực thi và phân tích nhanh nhưng lại khơng khai
thác một cách đầy đủ quá trình vận hành của ứng dụng với hệ thống, đặc biệt
là các điểm giao tiếp giữa hệ thống và ứng dụng, đây là những hạn chế của
các nhĩm đi trước Nghiên cứu của luận văn này, dựa vào CFG của hệ thống và ứng dụng Android, từ đĩ kết hợp với các thuật tốn phân tích luồng đữ liệu nhằm tìm ra các điểm giao tiếp kể trên Đây là tiền đề cho việc phát hiện các
Trang 253 NGHIÊN CỨU LIEN QUAN
lỗ hỏng của hệ thống Android và ứng dụng, đồng thời kiểm tra được vẫn đề cấp quyền sử dụng Bên cạnh đĩ, dựa vào nghiên cứu cĩ thể xây dựng một
CFG hồn chỉnh gồm hệ thơng Android và nhiều ứng dụng đồng thời, từ đĩ
giải quyết các vẫn để bảo mật trên đa ứng dụng
3.4 Phương pháp phân tích cơ bản
Mỗi nghiên cứu đều cĩ những cơng nghệ và phương pháp riêng để đạt được mục tiêu của mình Tuy nhiên tổng hợp lại cĩ một số phương pháp cơ
bản như:
Mơ tả trừu tượng
Mơ tả trừu tượng (abstract interpretation) là một lý thuyết xấp xỉ ngữ
nghĩa của chương trình, tính đúng đắn của việc phân tích phải được đảm bảo
nhằm tránh các kết quả âm tính (negative results) Một hiện thực cụ thể của mơ tả trừu tượng là thơng qua việc phân tích chương trình hình thức (formal program) Một vài ví dụ như Julia [ _ ]| sử dụng phương pháp này để thực hiện
các phân tích tĩnh ứng dụng Java và Android cho việc kiểm thử phần mềm nhằm tăng cao chất lượng sản phẩm hay ScanDail [ ]| dùng mơ tả trừu tượng để phát hiện rị rỉ riêng tư cho ứng dụng Android
Phân tích vết bẩn
Phân tích vết bẩn (taint analysis) là gồm hai bước, đầu tiên là định nghĩa
các thành phần nhạy cảm và tạo một tập hợp dữ liệu các vết bẩn, sau đĩ kiểm tra nĩ dựa trên phân tích luồng đữ liệu Nếu luồng dữ liệu bẩn dẫn đến một điểm khơng được phép, các hướng dẫn cụ thể sẽ được áp dụng như dừng hành vi và đưa ra cảnh cáo Ví dụ như AppSealer [ ], khi dữ liệu bẩn vi phạm
các chính sách đã định trước, nĩ sẽ ngăn cản và đưa ra cảnh báo với người
dùng qua một pop-up thơng báo Một ví dụ khác là FlowDroid [_ | thực hiện
phân tích tĩnh vết bẩn để phát hiện rị rỉ dữ liệu nhạy cảm như đã trình bày ở phần | | FlowDroid dự trên một tập hợp cĩ sẵn các phương thức source
va sink được trích rút từ Android SDK (đữ liệu này xây dựng trên nghiên cứu của Siegfried Rasthofer và các cộng sự [ ]) Các rị rỉ dữ liệu nhạy cảm
Trang 263 NGHIÊN CỨU LIEN QUAN
được cảnh báo nếu dữ liệu này bắt đầu từ các phương thức source (những dữ liệu nhiễm độc) và cuối cùng cĩ luồng chảy vào các phương thức sink
(vi phạm chính sách bảo mật) Thực thi tượng trưng
Thực thi tượng trưng (symbolic execution) là một hướng tiếp cận tạo giả
sử đầu vào cho chương trình, phương pháp này cĩ nhiều khác biệt với mơ tả trừu tượng Bởi vì nĩ giả định các giá trị đầu vào hơn là cĩ được đầu vào thực
tế như mơ tả trừu tượng thực hiện Một ví dụ như ApplIntent [ ] sử dụng thực
thi tượng trưng để xây dựng một chuỗi các thao tác trên giao diện người dùng
dẫn đến việc truyền dữ liệu Nếu chỉ dựa trên các thực thi tượng trưng đơn giản thì quá tốn thời gian cho nhiều ứng dụng Android, do đĩ ApplIntent đề
ra một số mơ hình thực thi độc đáo để giảm khơng gian tìm kiếm mà khơng
phải hi sinh code coverage
Chia nhỏ chương trình
Chia nho chuong trinh (program slicing) da dudc su dung như một phương
pháp phổ biến trong lĩnh vực phân tích nhằm làm giảm một số hành vi chương
trình, mà nếu cĩ giữ chúng cũng khơng làm thay đổi hành vi chương trình cần
phân tích Như cho một biến v trong chương trình p, một phần chia nhỏ cĩ
thể bao gồm tất cả các câu lệnh trong p bị ảnh hưởng bởi giá trị của v Bằng
phương pháp này Hoffmann và các cộng sự giới thiệu một framework gọi là
SAAF [ ]] tao ra cdc lát cắt của chương trình nhằm phân tích luồng đữ liệu
chảy ngược (backward data-flow) để theo dõi các giá trị tham số của một phương thức Android nhất định
Đo đạc mã
Trong phân tích tính, đo đạc mã (code 1nstrumentation) thường được sử
dụng để giải quyết một số vấn để phức tạp như giao tiếp liên thành phần
(inter-component communication), phan xa (reflection), Steve Arzt va cac
cộng sự đã giới thiệu một số phương tiện để do đạc các ứng dụng Android
Trang 273 NGHIÊN CỨU LIEN QUAN
để làm giảm vẫn đề lan truyền vết bẩn liên thành phần (inter-component taint propagation) trở thành một vẫn để nội thành phần (intra-component)
Kiểm tra mơ hình và kiềm tra loại
Kiểm tra mơ hình (model checking) và kiểm tra loại (type checking) là hai
hướng tiếp cận phổ biến của kiểm thử chương trình (program verification) Nếu kiểm tra loại thường dựa trên cú pháp (syntactic) và mơ dun (modular) thì kiểm tra mơ hình thường được định nghĩa trong một ngữ nghĩa (semantic) hay tồn bộ chương trình (whole-program) Trên thực tế, sự khác biệt này làm
cho hai cách tiếp cận này bổ sung cho nhau: kiểm tra loại thì tốt cho việc giải
thích tại sao một chương trình được chấp nhận, cịn kiểm tra mơ hình lại tốt cho việc giải thích tại sao một chương trình bị từ chối Ví dụ như COVERT
[_ ] đầu tiên trích rút các đặc điểm bảo mật từ một ứng dụng sau đĩ áp dụng kiểm tra mơ hình để xác minh ứng dụng đang phân tích cĩ an tồn hay khơng Con véi kiém tra loai, Cassandra [ ] cho phép người dùng thiết bị di động kiểm tra xem các ứng dụng Android cĩ đáp ứng đủ các yêu cầu về quyển
riêng tư trước khi cài đặt các ứng dụng này
Trang 284_ HƯỚNG TIẾP CẬN 4 Hướng tiếp cận 4.1 Tổng quan hướng tiếp cận xa Te S24" SystemServer.main, "` ` met oat s "tam TH 0Ơ sa TH 3 “*
B Ẫ Android = ` * |, (1) Construction of (2) Understanding publicly accessible functions Relations among jG) Application on 1 1
a | System | [~ > 5J Code | control-ilow graphs at on, ae — >| “| control- and data-flow analysis); (Intra- andinter-procedural | [ > objects and > chede for 5 stem APIs 7 functions " ¥
Hình 6: Tổng quan hướng tiếp cận
Về cơ bản, ý tưởng nghiên cứu của luận văn này được xây dựng trên 3
bước chính như hình _ Ì
e Bước 1: Thu thập mã của mỗi phiên bản Android, xác định tất cả các lớp Java cĩ liên quan, xây dựng đồ thị cuộc gọi cho tồn bộ dịch vụ hệ
thống Android từ điểm vào chính của hệ thống (com android server
SystemServer)
e Bước 2: Xác định các hàm cĩ kha nang tiếp cận cơng khai (publicly
accessible functions), và sử dụng kết hợp phân tích luồng dữ liệu với luồng điều khiển trên đồ thị cuộc gọi (callgraph) nhằm xác định các đối tượng và hàm khác cần thiết cho việc thực hiện cuộc gọi đến mỗi
ham public Việc phân tích này nhằm xây dựng thơng tin về sự phụ
thuộc lẫn nhau giữa các đối tượng và hàm Đồng thời chỉ ra các đường đi trong mã liên kết các yếu tố phụ thuộc lại với nhau
e Bước 3: Phân tích các phụ thuộc và đường đi ở bước 2
Dựa thơng tin thu được ở bước 2, với các phụ thuộc và đường ởi đĩ, nghiên
cứu cĩ thể kiểm tra những hàm pub1ic được bảo vệ bởi hệ thống (ví dụ như
đoạn mã mẫu trong hình | cho thay ham get DevicelId được bảo vệ bởi
quyén truy cap READ_PHONE_ STATE) va phát hiện các API của hệ thống
Trang 294_ HƯỚNG TIẾP CẬN
dùng để truy xuất vào hệ thống hay các tài nguyên riêng tư mà khơng cần
kiểm tra quyền truy cập, những API hệ thống như vậy cĩ thể được gọi từ các
ứng dụng nhưng khơng cần quyển truy cập, gây ra các vẫn để về bảo mật và quyên riêng tư Đồng thời, từ các thơng tin ở bước 2 cĩ thể dùng để xây dựng
một tập hợp các hàm public cĩ dữ liệu phụ thuộc vào ứng dụng, những
hàm này chính là các điểm giao tiếp giữa hệ thơng và ứng dụng đã trình bày ở phần |
4.2 Những thách thức
Chương trình Android cĩ thể hiểu là một dạng mở rộng sử dụng lập trình hướng sự kiện (event-driven programming), các listener được đăng ký để kích
hoạt các loại cuộc gọi nhằm xử lý thơng điệp Bên cạnh đĩ, các broadcast hay
intent cĩ thể được gởi qua lại bởi cả hệ thống và ứng dụng để gọi các hàm
khác nhau dựa trên các intent tương ứng Android cũng hỗ trợ định nghĩa các
cuộc gọi và intent thong qua các tập tin câu hình XML, đây chính là một
thách thức cho việc xây dựng đồ thị cuộc gọi tĩnh một cách chính xác Trong
phạm vi nghiên cứu của luận văn khơng giải quyết những thách thức kể trên,
thay vào đĩ chúng tơi dựa vào khả năng hiện cĩ của Soot để xây dựng đồ thị
cuộc gọi bắt đầu từ SystemServer.main ()
Ngồi ra, việc xây dựng đồ thị cuộc gọi cho các dịch vụ hệ thống Android
đối mặt với nhiều thách thức cơng nghệ khác Một trong số đĩ là sự khác biệt
giữa chương trình Java với Android, ví dụ như Java reflection thường dùng để
nạp một cách tự động các lớp và phương thức mà khơng cần phân tích chuỗi
chính xác của tên phương thức được nạp Chúng tơi dựa trên khả năng phân
tích tĩnh của Soot framework [_ ] và một số mở rộng để giải quyết vấn đề
này
Bên cạnh đĩ, với một hệ thống lớn và được xây dựng qua nhiều năm như Android cũng xuất hiện một thách thức khác là kích thước đồ thị cuộc gọi khá lớn (khoảng trên 1 triệu cạnh và hơn 50 ngàn đỉnh) như hình | | điều này gây
khĩ khăn cho đưa việc dữ liệu đồ thị từ tập tin lên bộ nhớ, cũng như áp dụng
những giải thuật tìm đường và các cơng nghệ khơng tối ưu với đồ thị lớn Để
giải quyết bài tốn này chúng tơi sử dụng một thư viện trung gian cho việc
Trang 304_ HƯỚNG TIẾP CẬN
=
tin cĩ câu trúc đặc biệt pickle cua thu vién, diéu nay gitp cai thién dang
kể thời gian truy xuất đồ thị
Hình 7: Đồ thị cuộc gọi tất cả dịch vụ hệ thống Android
43 Hàm truy cập cơng khai
Điều kiện cơ bản cho một hàm trong hệ thống Android cĩ thể truy cập cơng khai là hàm đĩ phải là một phương thức Java Ngồi ra, điều kiện thứ hai phức tạp hơn là một hàm gọi một hàm truy cập cơng khai cũng là một
hàm truy cập cơng khai hoặc cĩ thể được xây dựng một cách dễ dàng Để
kiểm tra xem một hàm cĩ thỏa mãn hai điều kiện đĩ, nghiên cứu phải thực
hiện đệ quy kiểm tra tất cả các đối tượng liên quan và các hàm cĩ thể truy cập cơng khai, trong đĩ chủ yếu là phân tích luồng dữ liệu ngược với một bộ lọc
áp dụng một số heuristic dựa trên cách lập trình và đặt tên quy ước
Ví dụ, một đối tượng kiểu T thì cần được gọi bởi một hàm pub1 i c tên là
£, sau đĩ cần phải kiểm tra constructor của T hoặc một instance của T cĩ thể trả về thơng qua một vài hàm getter _|xem cĩ phải là truy cập cơng
khai Nếu constructor hoặc getter của hàm địi hỏi các thơng số để
gọi, kiểm tra đệ quy được thực hiện
!Ví dụ như một hàm tên getSomethi ng trả về giá trị kiểu T; những heuristic này tuy khơng hồn chỉnh nhưng làm đơn giản hơn việc phân tích
Trang 314_ HƯỚNG TIẾP CẬN
Để đơn giản việc phân tích và nhận kết quả sơ bộ, nghiên cứu này xem xét một hàm là truy cập cơng khai như là một hàm pub1lic Thêm vào đĩ, cĩ
một số hàm truy cập cơng khai trong hệ thống (khoảng 38-43%) khơng thể truy cập bằng đồ thị cuộc gọi với lối vào là SystemServer.main () Đối
với những hàm này chúng tơi xem xét như là những hàm khơng được gọi bởi
hệ thống và cĩ nhiều khả năng được thiết kế để ứng dụng sử dụng Tĩm lại, chúng tơi xem xét các hàm là truy cập cơng khai miễn nĩ thỏa mãn các điều
kiện nêu trên và la ham public
4.4 Hiểu về hàm hệ thống Android và kiểm tra quyền truy
cập
Chúng tơi xem xét ba loại thơng tin cĩ thể hữu ích trong việc tìm hiểu một
hàm truy cập cơng khai nếu lập trình viên muốn gọi nĩ đúng cách:
(1) Thơng tin về tất cả sự phụ thuộc bao gồm cả đối tượng và những
hàm cần thiết rước khi gọi hàm
(2) Thơng tin về những gì xảy ra bao gồm các đối tượng bị ảnh hưởng
và những hàm được gọi sau khi hàm ban đầu được gọi
(3) Thơng tin về những gì xảy ra bao gồm các đối tượng bị ảnh hưởng và những hàm được gọi bền frong hàm ban dau
Mục (1) cĩ thể thu thập được bằng cách sử dụng phân tích luồng dữ liệu
ngược để xác định các đối tượng và các hàm mà lập trình viên cần phải xây
dựng hoặc trước khi gọi hàm Mục (2) cĩ thể thu thập bởi một phân tích tác động luồng điều khiển và luồng dữ liệu theo hướng tới, cùng với một phân
tích chẩn đốn dựa trên tên đối tượng và hàm, để xác định các đối tượng và chức năng bị ảnh hưởng bên ngồi Mục (3) cĩ thể thu tập bởi một phân tích
tác động tương tự, nhưng tập trung vào các hoạt động bên trong một hàm và
cĩ thể cần thiết nếu người lập trình viên muốn hiểu các hàm bên trong Phần 5|sẽ trình bày các số liệu thống kê về những thơng tin đã được thu thập
Một ứng dụng cụ thể của các thơng tin đĩ, nghiên cứu cĩ thể áp dụng để giải quyết câu hỏi về bảo mật và quyển riêng tư là: cĩ phải tất cả các hàm truy
Trang 324_ HƯỚNG TIẾP CẬN
cập cơng khai cĩ thể truy cập vào hệ thống hoặc tài nguyên cá nhân đều được
bảo vệ bởi các quyển truy cập thích hợp? Cho một hàm truy cập cơng khai £:
(1) nếu các đối tượng và hàm cần thiết để gọi £ khơng cĩ bat ky su bao vệ quyển truy cập nào?
(2) nếu các đối tượng và hàm bên trong £ khơng cĩ bất kỳ sự bảo vệ quyển truy cập nào?
(3) nếu việc gọi hàm £ cĩ thể thay đối một vài đối tượng bên ngồi, sau
đĩ rất cĩ khả năng khơng được bảo vệ bởi một quyển truy cập?
Phần 5.2] minh họa cách kiểm tra quyển truy cập như vậy được thực hiện
thơng qua một ví dụ cụ thể
Trang 335_ ĐÁNH GIÁ
5_ Đánh giá 51 Thiết lập
Hướng tiếp cận của luận văn này sử dụng Soot để xây dựng đồ thị cuộc gọi cho các dịch vụ hệ thống Android và đầu ra là một tập tin cĩ định dạng
dot Kế đến, chúng tơi sử dụng thư viện NetworkX [_ ]J để phân tích đồ thị cuộc gọi như: duyệt đồ thị để tìm đường đi, phân tích in-degree, out-degree,
va dump đồ thị xuống thành tập tin định dạng pickle như đã trình bày ở phần_ |
Đối với việc xây dựng đồ thị cuộc gọi từ Soot, cho mỗi phiên bản Android,
chúng tơi cung cấp cho nĩ tất cả tập tín jar của hệ thống (bao gồm cả
android jar trong Android SDK được bởi Google) Để phân tích các
dịch vụ hệ thống Android từ phiên bản 4.1 đến 4.4.4, chúng tơi sử dụng tất
cả các tập tin hệ thơng bên trong ⁄yséem/framework được trích rút từ giả lập
Google Nexus của phần mềm Genymotion [_ ]; các tập tin này bao gồm cả
classes.dex cua Dalvik Virtual Machine (DVM) Tw phién ban Android
5.0.0 trở về sau, Android thay đối kiến trúc của nĩ, thay thế DVM bởi Android
Runtime (ART) va cac tap tin dex được biên dịch thành tập tin định dạng ELF chứa mã nhị phân của hệ điều hành Linux Vì Soot framework khơng hỗ
trợ tập tín nhị phân của Linux, chúng tơi sử dụng Java bytecode của Android
được Grepcode [ ] cung cấp cho phiên ban Android 5.1.0 và 6.0.1
Thời gian xây dựng và đọc đồ thị cuộc gọi từng là một vấn để thách thức với chúng tơi Thời gian xây dựng các đồ thị này xấp xỉ 15 tiếng cho một phiên bản Kế đến, mất khoảng 10 phút để đọc và chuyển déi tap tin dot
sang pickle théng qua NetworkX, va sau đĩ các thuật tốn duyệt đồ thị
dựa trên bi ck1e cĩ thể thực hiện được một cách nhanh chĩng
5.2 Tom tat ket qua
Đánh giá của chúng tơi giải quyết các câu hỏi nghiên cứu sau:
(1) Lam thé nao để biết tổng số bao nhiêu phương thức pub1ic thay đổi trên mỗi phiên bản Android?
Trang 345_ ĐÁNH GIÁ
(2) Sự phân bổ các degree của phương thức như thế nào?
(3) Chúng ta cĩ thể tìm thấy những hàm truy cập cơng khai khơng được
bảo vệ bởi sự kiểm tra quyển truy cập hay khơng?
Đầu tiên, với câu hỏi (1), thong tin thu được từ nghiên cứu của chúng tơi
sẽ đưa ra được cái nhìn tổng quan về việc thay đổi các phương thức trên từng
phiên bản của Android Đồng thời cũng cung cấp cho các nhà phát triển ứng
dụng thơng tin về những API khơng được cơng bố chính thức Cũng từ đĩ dẫn đến vẫn đề được đặt ra ở câu hỏi (3) là cĩ hay khơng việc tổn tại của những
hàm truy cập cơng khai khơng được bảo vệ như vậy
Kế đến, với câu hỏi (2), kết quả thu được từ các đồ thị cuộc gọi của chúng
tơi sẽ cung cấp những thơng tin về việc phân bổ các degree của từng phương
thức trên mỗi phiên bản Android Việc này giúp những nhĩm phân tích về mã
nguồn Android hiểu thêm về một thơng tin khá thú vị của hệ điều hành này là độ phức tạp của một phương thức thì tỷ lệ nghịch với số lần phương thức
đĩ được gọi bởi một phương thức khác
Cuối cùng, câu hỏi (3) được chúng tơi giải đáp thơng qua một ví dụ cụ
thể về một phương thức cĩ thể được ứng dụng sử dụng để thay đối âm lượng thiết bị di động nhưng khơng cĩ bất cứ sự bảo vệ quyển truy cập nào Điều này chứng minh kết quả của nghiên cứu của chúng tơi cĩ thể mở rộng để tìm ra các lỗ hống về quyền truy cập của hệ điều hành Android một cách tự động
thay vì sử dụng các phương pháp thủ cơng
Các phần kế tiếp sẽ lần lượt đưa ra kết quả của từng câu hỏi nêu trên
Các phương thức trong mỗi phiên bản Android
So sánh Android 4.4.4 với 5.1.0 (đường màu xám điểm tam giác trong hình _}), số lượng phương thức của đồ thị cuộc gọi tăng 14.7%, tỷ lệ này cũng
tương đương với nếu so sánh giữa Android 4.1.1 và 4.4.4 Sự thay đối lớn như
vậy cho thây nhu cầu về một cơng cụ hiệu quả để giúp các lập trình viên hiểu về các hàm của những dịch vụ hệ thống Android
Số lượng các cạnh cũng thay đối đáng kể (ví dụ Android 4.2.2 tăng 10.8%
và 4.4.4 tăng 11.2% so với phiên bản trước đĩ) Sự thay đổi này cũng gĩp phần
vào sự phức tạp của dịch vụ hệ thống Android qua từng phiên bản
Trang 355_ ĐÁNH GIÁ
—* Number of public methods in callgraph Number of methods in callgraph —- Number of public methods =#-Number of methods
—®- Number of edges (right y-axis) 180000 1200000 W 160000 S 1000000 ¥ 5 140000 o œ 120000 800000 © E 100000 $ ‘5 © 80000 600000 2 o 2 60000 — 400000 *€ £ 40000 5 5 200000 Z Z 20000 0 0 4.1.1 4.2.2 4.3.0 4.4.4 5.1.0 6.0.1 Android version
Hình 8: Sự thay đối các phương thức và cạnh qua từng phiên bản Android Đường màu cam điểm dấu x trong hình |S[ trình bày số lượng phương
thức pub1ic trên mỗi phiên bản Android Các phương thức pub1ic chiếm
khoảng 51% trên tất cả các phương thức của dịch vụ hệ thống Android từ
4.1.1 đến 4.4.4 Sau khi DVM được thay thế bằng ART từ phiên bản Android
5.0, tỷ lệ này thay đối lên 54% như trên kết quả nghiên cứu của chúng tơi với Android 5.1.0 và 6.0.1 Những tỷ lệ này chứng minh sự khác biệt giữa kiến
trúc DVM và ART cĩ ảnh hưởng đến các dịch vụ hệ thống của Android
Degrees của các phương thức
Chúng tơi sử dụng sự tương tác degree giữa các phương thức trong đồ thị cuộc gọi để minh họa cho sự phức tạp của các hàm trong dịch vụ hệ thơng Android Hình 9) và 10 thể hiện sự phân bổ của in-degree và out-degree trên
các phiên bản Android 4.1.1, 5.1.0 và 6.0.1 Sự phân bổ này được biểu diễn
tương đương dựa trên một hàm logarit cac gia tri cua in-degree, out-degree
và số lượng các nốt của đồ thị và thể hiện như một quan hệ hàm mũ trong
khoảng từ [1-100], cịn trong khoảng [100-1000] thì các degree phân bổ tập
trung
Một số nốt cĩ in-degree cao như phương thức toString (), append ()
tương ứng trong cac lép Java StringBuilder, Object M6t điểm thú vị
Trang 385_ ĐÁNH GIÁ
là các nốt cĩ out-degree cao cĩ thể khơng phải là một phương thức cĩ độ phức
tạp cao Ví dụ như phương thức equals () toString () trong các lớp An- droid core KeyValueMap, text.SpannableStringBuilder c6 out-
degree gan nhu lớn nhất, phản ánh thực tế rằng nĩ tương tác với nhiều đối tượng kiểu tổng quát nhưng mã của nĩ thì thường ngắn gọn và dễ hiểu Những
phương pháp phức tạp hơn trong thực tế chỉ cĩ khoảng mười out-degree, do
nĩ tương tác với những đối tượng kiểu đặc biệt với nội dung phong phú ví dụ như parseTntent (), getTastTocation () trong các lớp Android
Intent, LocationManagerService
Trong đồ thị cĩ hướng:
- Degree của một đỉnh là số lượng cạnh kết nỗi với nĩ
- In-degree là số lượng cạnh đi vào của một đỉnh
- Owf-đegree là sơ lượng cạnh đi ra từ một đỉnh
Truy xuất vào tài nguyên hệ thống khơng cần quyền truy cập
Thơng tin thu thập của chúng tơi cĩ thể được áp dụng để tìm kiếm các vẫn để nhiều rủi ro về vi phạm an ninh và sự riêng tư Ví dụ như xem xét
một phương thức pub1lic tên gọi setStreamVolume () của lớp dịch vụ
hệ thống com android server audio AudioService, dựa trên đồ
thị cuộc gọi của Android trên phiên bản 4.3, chúng tơi nhận ra phương pháp này gọi nhiều phương thức khác trong lớp dịch vụ hệ thống AudioService
theo thứ tự nhất định, chẳng hạn như ensureVa li dStreamType (), get- DeviceForStream (), rescaleTndex () và cuối cùng là sendVol- umeUpdate () Phuong thitc sendVolumeUpdate () cé thé cap nhat âm lượng của thiết bị mà khơng cần quyển truy cập nào Như vậy cĩ nghĩa
là các ứng dụng cĩ thể truy xuất âm lượng của chính thiết bị mà khơng cần bất cứ quyển truy cập nào Lỗi này đã được chỉnh sửa trên Android
4.4.4, Google sử dụng điều kiện AopOÐsMan-ager.noteOp() != Ap- pOpsManager.MODE_ ALLOWED để kiểm tra quyển truy cập trước khi gọi
rescaleTndex ()
Trang 395_ ĐÁNH GIÁ
cen brica.wardcard drape Ấ ® ru rc sẽ~—-(Í spláx L lái View Category
tam Êahr%a,war đ arớ an Đề ls|EFrage91% 1= nữ Tác k
B1 tÍT b4xÍ + -®~ lick ——,— tk
na ie as ro teeny ia wmCikk—ren
coated ln Tvixv—x} ww rat saÍ +
Pen amide sary -® -|il xedl,asg
com, and raid ‘eo-~ male
Hình 11: Giao tiép dich vu hé théng va ứng dụng
Giao tiếp dịch vụ hệ thống và ứng dụng
Như trình bày ở các phần trước, một trong những mục tiêu nghiên cứu
muốn hướng đến là giúp các lập trình viên hiểu được sự giao tiếp giữa dịch
vụ hệ thống và ứng dụng Khi nắm rõ được sự giao tiếp này người lập trình
viên cĩ thể mở rộng thêm các chức năng của ứng dụng dựa trên những API
đặc biệt trên các dịch vụ hệ thống
Hình 11 mơ tả đường cuộc gọi từ dịch vụ hệ thống tới một ứng dụng Word Card đơn giản, khi hàm onC 1i ck () của lớp CategoryListFrag-
ment$ 3 được gọi với mục đích hiển thị một danh sách (hàm di sp1ay1L1stView-
Category ()), thì cĩ một cuộc gọi từ hàm main () của lớp System-
Server trong dịch vụ hệ thống đi qua lần lượt các hàm initAndI.oop (),
systemReady (), run () của các lớp ServerThread, ActivityMan-
agerServi ce, View$PerformC1 i ck rồi cuối cùng là per£ormŒ 1 1k ()
của lớp View trước khi gọi hàm onC1ick ()
Trang 405_ ĐÁNH GIÁ
53 Thảo luận
Mục đích chính của nghiên cứu chúng tơi là hỗ trợ các nhà phát triển hiểu
về quá trình các dịch vụ hệ thống Android giao tiếp với ứng dụng như đã trình bày ở ví dụ hình _| từ đĩ đưa ra thơng tin về các hàm truy cập cơng khai và
các sự thay đối của Android qua từng phiên bản ở hinh | Những điểm giao
tiếp giữa hệ thơng và ứng dụng hay những API khơng được cơng bồ này giúp
các nhà lập trình cĩ thể mở rộng thêm khả năng ứng dụng của họ thay vì chỉ
dựa vào các thơng tín được cung cấp từ Google
Tuy nhiên những API đĩ mang những rủi ro tiềm ẩn của hệ điều hành
Android, như trong ví dụ đã trình bày ở phần | cơng nghệ của chúng tơi cĩ
thể sử dụng để phát hiện các lỗ hỏng trong hệ thống này Nĩ cũng cĩ nhiều tiềm năng để phát hiện rị rỉ dữ liệu hay vi phạm bảo mật
Lưu ý rằng, cách gọi trực tiếp các hàm truy cập cơng khai trong dịch vụ
hệ thống khơng phải là cách duy nhất các ứng dụng Android gọi các chức
năng của hệ thống Cĩ nhiều cách khác, chẳng hạn như truyền một intent phù
hợp và được xử lý bởi hệ thống, hoặc sử dụng Java reflection để gọi hàm một
cách tự động, Những cách gọi các hàm hệ thống như vậy chưa được phát
hiện như là một hàm truy cập cơng khai của nghiên cứu này, các vẫn để đĩ sẽ
để lại cho những cơng việc trong tương lai