Ma Doc Android

BAN CƠ YẾU CHÍNH PHỦ
HỌC VIỆN KỸ THUẬT MẬT MÃ

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
AN TOÀN HỆ ĐIỀU HÀNH
Đề tài
TÌM HIỂU HỆ ĐIỀU HÀNH ANDROID VÀ MỘT SỐ LỖ HỔNG BẢO MẬT
TRÊN HỆ ĐIỀU HÀNH ANDROID
Ngành: Công nghệ thông tin

Chuyên ngành: An toàn thông tin
Sinh viên thực hiện:

- Ngô Thị Khả Anh
- Hoàng Thị Cúc
- Huỳnh Anh Thư Sinh
- Nguyễn Thu Thảo
Cán bộ hướng dẫn :
Tp HCM ngày tháng năm

Mục lục
Danh mục các từ viết tắt ........................................................................................... iii

Danh mục hình vẽ .................................................................................................... iv
Danh mục bảng biểu.................................................................................................. v
Lời nói đầu ............................................................................................................... vi
Chương 1. .................................................................................................................. 1
TỔNG QUAN HỆ ĐIỀU HÀNH ANDROID VÀ CÁC KIẾN TRÚC BẢO MẬT
CỦA HỆ ĐIỀU HÀNH ANDROID ......................................................................... 1
1.1 Tổng quan về Hệ điều hành Android .............................................................. 1
1.2 Đặc điểm chung của hệ điều hành Android .................................................... 1
1.2.1. Tính mở ................................................................................................... 1
1.2.2. Tính ngang bằng của các ứng dụng ........................................................ 2
1.2.3. Phá vỡ rào cản phát triển ứng dụng......................................................... 2
1.2.4. Dễ dàng và nhanh chóng xây dựng ứng dụng ......................................... 2
1.2.5. Công cụ hỗ trợ lập trình Android ............................................................ 2
1.3. Kiến Trúc Bảo Mật HĐH Android ............................................................... 2
1.3.1. Tổng quan về kiến trúc hệ thống Android .............................................. 3
1.3.2. Hiểu biết về ranh giới bảo mật và thực thi .............................................. 4
1.3.3. Hộp cát(sandbox) của Android. .............................................................. 4
1.3.4. Các quyền trong Android. ....................................................................... 6
1.3.5. Các thành phần ứng dụng ........................................................................ 8
1.3.6. ADB ...................................................................................................... 12
1.3.7. Daemon Volume ................................................................................... 13
1.3.8. Dịch vụ khác.......................................................................................... 13
1.3.9. Kernel .................................................................................................... 15
1.3.10. Android Fork ....................................................................................... 15
1.3.11. Binder .................................................................................................. 16
1.3.12. Ashmem .............................................................................................. 17
1.3.13. Pmem ................................................................................................... 17
1.3.14. Logger ................................................................................................. 17
Chương 2. ................................................................................................................ 18
TỔNG QUAN VỀ MÃ ĐỘC TRÊN ANDROID ................................................... 18
i
2.1. Cơ chế hoạt động của Malware .................................................................... 20
2.1.1. Lược đồ đặt tên cho Malware ............................................................... 20
2.1.2. Các loại phần mềm độc hại ................................................................... 21
2.1.3. Phương pháp phát tán Malware ............................................................ 27
2.2. Một số loại mã độc thường thấy trên Android ............................................. 32
2.2.1. Phần mềm âm thầm trừ tiền vào tài khoản điện thoại........................... 32
2.2.2. Ransomware .......................................................................................... 33
2.2.3. Lỗ hổng WebView ................................................................................ 34
2.2.4. Điện thoại tắt nhưng thật ra không tắt................................................... 34
2.2.5. App nhìn có vẻ "vô hại" nhưng lại chứa mã độc .................................. 35
2.2.6. Tống tiền ............................................................................................... 35
2.2.7. Lỗ hổng Android Installer Hijacking .................................................... 35
Chương 3. ................................................................................................................ 37
PHƯƠNG PHÁP PHÂN TÍCH MÃ ĐỘC ............................................................. 37
3.1. Phương pháp phân tích tĩnh ......................................................................... 37
3.2. Phương pháp phân tích động........................................................................ 40
3.2.1. Phát hiện và phân tích mã độc động thông qua việc khai phá thông tin
từ các khối điều khiển tiến trình của hệ điều hành Linux ............................... 40
3.2.2. Công cụ , mã nguồn hỗ trợ .................................................................... 48
3.3. So sánh giữa phân tích tĩnh và phân tích động ............................................ 50
3.3.1: Ưu nhược điểm của phân tích tĩnh và phân tích động .......................... 50
Chương 4. ................................................................................................................ 52
XÂY DƯNG CHƯƠNG TRÌNH PHÂN TÍCH MÃ ĐỘC DỰA TRÊN MÃ
NGUỒN TRACEDROID........................................................................................ 52
4.1. Tổng quan ..................................................................................................... 52
4.2. Mô hình thử nghiệm ..................................................................................... 52
4.3. Kiến trúc của chương trình tracedroid ......................................................... 53
4.3. Thử nghiệm .................................................................................................. 57
4.4. Kết quả đạt được .......................................................................................... 58
KẾT LUẬN ............................................................................................................. 60
TÀI LIỆU THAM KHẢO ....................................................................................... 62
ii
Danh mục các từ viết tắt
Từ viết tắt Nội dung

ADB Android Debugging Bride
API Application Programming Interface
CPU Central Processing Unit
IMEL International Mobile Equipment Identity
IPC Inter_Process Communication
IPL Initial Program Load
JDK Java Development Kit
JTAG Joint Test Action Group
MAC Mandatory Access Control
NIST National Institute of Standards and
Technology
RAM Random Access Memory
ROM Read Only Memory
SMS Short Message Service
SDK Software Development Kit
SPL Second Program Load
iii
Danh mục hình vẽ
Hình 1.1. Những lớp bao gồm trong bộ phần mềm Android .................................... 3
Hình 1.2. Định nghĩa cho AID trong hệ thống.......................................................... 5
Hình 1.3. Quyền tập tin hệ thống .............................................................................. 7
Hình 1.4. Những hoạt động được định nghĩa DEFI trong manifest ......................... 9
Hình 1.5. Lập một Receiver trong manifest ............................................................ 10
Hình 1.6. Dịch vụ .................................................................................................... 10
Hình 1.7. Sử dụng lệnh ps ....................................................................................... 12
Hình 2.11. Kiến trúc đăng nhập hệ thống Android ................................................. 18
Hình 2.1. Phân loại Malware theo hoạt động của chúng ........................................ 22
Hình 2.2. Biểu đồ Andriod Malware....................................................................... 23
Hình 2.3. biểu đồ về hành vi và mức độ của ad_library ......................................... 24
Hình 2.4. Ví dụ về mã độc Rogue-AV .................................................................... 25
Hình 2.5. Mã độc được đóng gói và bơm vào ứng dụng ........................................ 29
Hình 2.6. Android “Master Key” vulnerability....................................................... 30
Hình 2.7. Khai báo thẻ quảng cáo trong AndroidManifest.xml.............................. 31
Hình 2.8. Biểu đồ các loại Malware Android dùng để tấn công thiết bị ............... 33
Hình 2.9. Thông báo của Svpeng ............................................................................ 34
Hình 3.1. Giao diện khi mở file classes-dex2jar ..................................................... 38
Hình 3.2. Giao diện tìm kiếm các từ khóa .............................................................. 39
Hình 3.3. Hàm gọi đến tin nhắn SMS ..................................................................... 39
Hình 3.4. phân tích quá trình lành tính và độc hại .................................................. 41
Hình 3.5. Biểu đồ so sánh tiến trình lành tính và độc hại ....................................... 43
Hình 3.6. Sơ đồ khối của cấu trúc cơ chế phát hiện mã độc động .......................... 44
Hình 3.7. Các thống kê các thông số trong danh sách ngắn ................................... 46
Hình 4.1. sơ đồ thử nghiệm sử dụng tracedroid ...................................................... 52
Hình 4.2. Sơ đồ khối của Tracedroid ...................................................................... 53
Hình 4.3. Static Analysis ......................................................................................... 54
Hình 4.4. Hành động chính của khối Stimulation ................................................... 54
Hình 4.5. Monkey log của file mã độc Trojan.Camera_funny.apk ........................ 55
Hình 4.6. Tracedroid kế thừa và mở rộng các Android Profiler ............................. 55
Hình 4.7. callgraph .................................................................................................. 56
Hình 4.8. Màn hình gửi file APK ở client............................................................... 57
Hình 4.9. File APK đã được phân tích xong ........................................................... 57
iv
Danh mục bảng biểu
Bảng 1.1. Các quản lý và mô tả vai trò quản trị trong khung chương trình. .............. 12
Bảng 1.2. Các dịch vụ ................................................................................................. 14
Bảng 1.3. Một số bổ sung thay đổi về nhân hệ thống. ................................................ 15
Bảng 2.1. Phân loại mã độc trong Android theo trang web forenics .......................... 20
Bảng 2.2. Phân loại Malware theo cách thức lây lan .................................................. 28
v
Lời nói đầu
Sự phát triển lớn mạnh của hệ đều hành mở Android khiến cho sự phát triển của
các phần mềm độc hại cũng tăng theo một cách nhanh chóng. Ngay cả google play
– chợ ứng dụng Android của google cũng không thể đảm bảo rằng tất cả các ứng
dụng được đưa lên không chứa phần mềm độc hại. Ngoài ra, còn rất nhiều các chợ
ứng dụng trôi nổi khác mà các ứng dụng không được kiểm soát khiến cho nguy cơ
lây lan mã độc ngày càng cao.
Mã độc hại trên Android đang ngày càng trở thành nỗi lo sợ đối với những
người dùng. Khi bị nhiễm mã độc người dùng có thể bị đánh cắp dữ liệu thông tin
nhạy cảm, bị trừ tiền trong tài khoản, bị mất các tệp tin quan trọng hoặc tệ hơn là
gián điệp và vô hiệu hóa thiết bị. Vì vậy “Nghiên cứu giải pháp lọc mã độc động
trên điện thoại thông minh chạy hệ điều hành Android” là đồ án rất cần thiết.
Mục tiêu của đồ án là nghiên cứu và thiết kế giải pháp lọc mã độc dựa trên kỹ
thuật phân tích động. Lập trình và cài đặt chương trình lọc mã độc động trên điện
thoại thông minh chạy hệ điều hành Android. Cấu trúc của đồ án chia thành bốn
chương.
Chương 1, Tổng quan về mã độc trên Android, có nội dung giới thiệu về các loại
mã độc đang có trên Android.
Chương 2, Tổng quan về hệ điều hành Android và các cấu trúc bảo mật trong
Android, đề cập đến các cấu trúc bảo mật trong hệ điều hành Android và đặc điểm
của hệ điều hành Android.
Chương 3, Nghiên cứu các giải pháp phân tích mã độc trên Android, trong đó có
phân tích tĩnh và phân tích động , so sánh ưu nhược điểm giữa 2 loại giải pháp.
Chương 4, Cũng là chương cuối cùng , nghiên cứu triển khai giải pháp phân
tích động dựa trên mã nguồn mở Tracedroid, thực nghiêm phân tích một số mã
độc.
Để được hoàn thành đề tài này là nhờ công lao lớn của các thầy cô giảng viên
trong trường Học Viện Kỹ Thuật Mật Mã nói chung và các thầy cô trong khoa an
toàn thông tin nói riêng đã truyền đạt cho em kiến thức, kinh nghiệm quý báu trong
thời gian học tập.
vi
Nghiên cứu giải pháp lọc mã độc động trên điện thoại thông minh chạy hệ điều hành Android
Trang 0
Chương 1.
TỔNG QUAN HỆ ĐIỀU HÀNH ANDROID VÀ CÁC KIẾN TRÚC
BẢO MẬT CỦA HỆ ĐIỀU HÀNH ANDROID
1.1 Tổng quan về Hệ điều hành Android

Android được phát triển bởi tập đoàn Google, phiên bản đầu tiên ra đời năm
2008. Được xây dựng trên một nền tảng mở, và một bộ thư viện đa năng, mạnh mẽ
với nguyên lý mở, Android đã nhanh chóng được cộng đồng lập trình viên di động
hưởng ứng mạnh mẽ. Nền tảng Android tích hợp nhiều tính năng nổi bật:
 Android là một hệ điều hành nhân Linux, đảm bảo sự tương tác với phần
cứng, quản lý bộ nhớ, điều khiển các tiến trình tối ưu cho thiết bị di động.
 Bộ ứng dụng khung cho phép sử dụng lại và thay thế các thành phần riêng
lẻ.
 Máy ảo Dalvik được tối ưu cho các thiết bị di động, chạy các ứng dụng lập
trình trên ngôn ngữ Java.
 Các thư viện cho phát triển ứng dụng mã nguồn mở bao gồm SQLite,
WebKit, OpenGL và trình quản lý đa phương tiện.
 Hỗ trợ các chuẩn đa phương tiện phổ biến, thoại trên nền GSM, Bluetooth
EDGE, 3G và Wifi
 Hỗ trợ Camera, GPS, la bàn, máy đo gia tốc…
 Bộ phát triển ứng dụng SDK đầy đủ gồm thiết bị giả lập, công cụ sửa lỗi,
tích hợp với Eclipse SDK.
Android cung cấp một tập hợp đầy đủ các phần mềm cho thiết bị di động bao
gồm: hệ điều hành, các khung ứng dụng và các ứng dụng cơ bản.
1.2 Đặc điểm chung của hệ điều hành Android
1.2.1. Tính mở
Android được xây dựng từ dưới đi lên cho phép người phát triển tạo các
ứng dụng di động hấp dẫn với đầy đủ các điểm mạnh của các thiết bị cầm tay
hiện có. Android hoàn toàn mở, một ứng dụng có thể gọi tới bất kể một chức
năng lõi của điện thoại như tạo cuộc gọi, gửi tin nhắn hay sử dụng máy ảnh,
cho phép người phát triển tạo phong phú hơn, liên kết hơn các tính năng cho
người dùng. Android được xây dựng trên nhân Linux mở. Thêm nữa, nó sử
dụng một máy ảo đã được tối ưu hóa bộ nhớ và phần cứng với môi trường di
động. Android mà một mã nguồn mở, nó có thể được mở rộng để kết hợp tự
Trang 1
do giữa các công nghệ nổi trội. Nền tảng này sẽ tiếp tục phát triển bởi cộng
đồng phát triển để tạo ra các ứng dụng di động hoàn hảo.
1.2.2. Tính ngang bằng của các ứng dụng
Với Android, không có sự khác nhau giữa các ứng dụng điện thoại cơ
bản với ứng dụng của bên thứ ba. Chúng được xây dựng để truy cập như nhau
tới một loạt các ứng dụng và dịch vụ của điện thoại. Với các thiết bị được xây
dựng trên nền tảng Android, người dùng có thể đáp ứng đầy đủ các nhu cầu
mà họ thích. Chúng ta có thể đổi màn hình nền, kiểu gọi điện thoại, hay bất kể
ứng dụng nào. Chúng ta thậm chí có thể hướng dẫn điện thoại chỉ xem những
ảnh mình thích.
1.2.3. Phá vỡ rào cản phát triển ứng dụng
Android phá vỡ rào cản để tạo ứng dụng mới và cải tiến. Một người phát
triển có thể kết hợp thông tin từ trang web với dữ liệu trên điện thoại cá nhân
– chẳng hạn như danh bạ, lịch hay vị trí trên bản đồ – để cung cấp chính xác
hơn cho người khác. Với Android, người phát triển có thể xây dựng một ứng
dụng cho phép người dùng xem vị trí của những người mà chúng ta quan tâm
và thông báo khi họ đang ở vị trí lân cận. Tất cả được lập trình dễ dàng thông
qua sự hỗ trợ của MapView và dịch vụ định vị toàn cầu GPS.X 1.2.4. Dễ dàng
và nhanh chóng xây dựng ứng dụng
Android cung cấp bộ thư viện giao diện lập trình ứng dụng đồ sộ và các
công cụ để viết các ứng dụng phức tạp. Ví dụ, Android có thể cho phép người
phát triển biết được vị trí của thiết bị và cho phép các thiết bị giao tiếp với
nhau để có thể tạo nên mạng xã hội chia sẻ ngang hàng rộng khắp. Thêm nữa,
Android còn bao gồm một bộ công cụ đầy đủ giúp cho việc phát triển trở nên
dễ dàng.1.2.5. Công cụ hỗ trợ lập trình Android
1.3. Kiến Trúc Bảo Mật HĐH Android
Android bao gồm một số cơ chế đóng một vai trò quan trọng trong việc kiểm
tra an ninh và thực thi. Giống như bất kỳ hệ điều hành hiện đại nào, nhiều thành
phần trong số những cơ chế tương tác với nhau, trao đổi thông tin về đối tượng
(ứng dụng / người), các vật thể(các ứng dụng khác, files, thiết bị), và các hoạt động
được thực hiện (đọc, viết, xóa,...). Thông thường, thực thi không xảy ra sự cố
nhưng đôi khi, có những lỗ hổng cung cấp cơ hội cho sự tấn công . Chương này
thảo luận về thiết kế và kiến trúc an ninh của Android, thiết lập giai đoạn cho việc
phân tích các tình huống tấn công của nền tảng Android.
Trang 2
1.3.1. Tổng quan về kiến trúc hệ thống Android

Các kiến trúc Android nhìn chung đã có lúc được mô tả như là “Android
trên Linux”.
Tuy nhiên, đây là một sự nhầm lẫn và hoàn toàn không công bằng với sự
phức tạp và kiến trúc của nền tảng này. Tổng thể kiến trúc bao gồm các thành phần
rơi vào 5 lớp chính, bao gồm cả các ứng dụng Android, Khung Android, máy ảo
Dalvik, không gian người dùng mã nguồn gốc, và nhân Linux.:
Hình 1.1. Những lớp bao gồm trong bộ phần mềm Android
Các ứng dụng Android cho phép các nhà phát triển mở rộng và cải thiện các
chức năng của một thiết bị. Android Framework cung cấp cho các nhà phát triển
với các API có quyền truy cập vào tất cả các cơ sở khác nhau mà một thiết bị
Android đã cung cấp "liên kết" giữa các ứng dụng và các máy ảo Dalvik. Điều này
bao gồm các khối cấu trúc để cho phép các nhà phát triển thực hiện các tác vụ
thông thường như quản lý các yếu tố giao diện người dùng (UI) , truy cập vào các
cửa hàng dữ liệu được chia sẻ, và đi qua các thông điệp giữa các thành phần ứng
dụng.
Cả Android và Android Framework được phát triển trong các ngôn ngữ lập
trình Java và thực hiện bên trong máy ảo Dalvik (DalvikVM). Máy ảo này (VM)
được thiết kế đặc biệt để cung cấp một lớp trừu tượng hiệu quả cho hệ thống điều
hành cơ bản. Các DalvikVM là một VM đăng ký dựa trên diễn giải Dalvik
Trang 3
Executable (DEX) định dạng mã byte. Đổi lại, các DalvikVM dựa trên các chức
năng được cung cấp bởi một số hỗ trợ các thư viện mã nguồn gốc.
Các không gian người dùng thành phần mã nguồn gốc của Android bao gồm
các dịch vụ hệ thống, chẳng hạn như Vold và DBUS; Service, dhcpd và
wpa_supplicant mạng, và thư viện, libc bionic, WebKit, và OpenSSL. Một số các
dịch vụ và các thư viện giao tiếp với dịch vụ cấp nhân và trình điều khiển, trong
khi những dịch vụ khác chỉ đơn giản là tạo thuận lợi cho hoạt động cơ bản của cấp
dưới để quản lý mã.
Nền tảng Android là nhân Linux. Android đã nhiều lần bổ sung và thay đổi đối
với nhân gốc, trong đó có những tác động an ninh của chính họ. Trình điều khiển
cấp nhân cũng cung cấp các chức năng bổ sung, chẳng hạn như truy cập camera,
Wi-Fi và truy cập thiết bị mạng khác. Lưu ý đặc biệt là trình điều khiển Binder,
thực hiện truyền thông liên tiến trình - Inter-Process Communication (IPC).
1.3.2. Hiểu biết về ranh giới bảo mật và thực thi
Ranh giới bảo mật, đôi khi được gọi là biên giới tin cậy, là vị trí trong một hệ
thống mà mức độ tin cậy hai bên ở đó khác nhau. Một ví dụ tuyệt vời là ranh giới
giữa không gian nhân và không gian người sử dụng. Mã trong không gian nhân là
đáng tin cậy để thực hiện các hoạt động cấp thấp trên phần cứng và truy cập vào tất
cả các bộ nhớ ảo và vật lý. Tuy nhiên, mã không gian người dùng không thể truy
cập vào tất cả các bộ nhớ do ranh giới được thực thi bởi các đơn vị xử lý trung tâm
(CPU).
Các hệ điều hành Android sử dụng hai phần riêng biệt, nhưng hợp tác, cấp
phép các mô hình. Ở cấp độ thấp, nhân Linux thực thi quyền sử dụng người dùng
và nhóm. Mô hình quyền này được thừa hưởng từ Linux và thực thi các quyền truy
cập vào file hệ thống, cũng như các tài nguyên khác của hệ điều hành Android.
Điều này thường được gọi là sandbox của Android. Thời gian chạy Android, theo
cách của khung DalvikVM và Android, thực thi mô hình thứ hai. Mô hình này, đó
là tiếp xúc với người sử dụng khi họ cài đặt ứng dụng, xác đinh quyền của ứng
dụng đó và hạn chế khả năng của các ứng dụng Android. Một số cấp phép từ các
mô hình thứ hai thực sự ánh xạ trực tiếp đến người sử dụng cụ thể, các nhóm, và
khả năng trên hệ điều hành.
1.3.3. Hộp cát(sandbox) của Android.

Nó kế thừa từ nền tảng Linux trên nền Android thông qua các tiến trình của
Unix nhưng bị cô lập thông qua nguyên tắc đặc quyền tối thiểu. Cụ thể, có thể cho
phép các tiến trình đang chạy như người dùng riêng biệt không thể can thiệp lẫn
Trang 4
nhau, chẳng hạn như gửi tín hiệu hoặc truy cập vào một không gian bộ nhớ của
người khác. Nhiều sandbox của Android được xác định trên một vài khái niệm cơ
bản: tiêu chuẩn Linux cho các tiến trình riêng biệt, ID người dùng duy nhất (UID)
cho hầu hết các tiến trình, và hệ thống tập tin được kiểm soát chặt chẽ.
Android chia sẻ mô hình UID/GID (GID) của Linux, nhưng không có mật khẩu
và nhóm các tập tin truyền thống cho mã nguồn của người dùng và nhóm. Thay
vào đó, Android định nghĩa một bản đồ thông qua tên để định danh duy nhất được
gọi là Android ID (AID). Việc lập bản đồ AID ban đầu lưu trữ dành riêng, mục
đính cho đặc quyền và hệ thống quan trọng của người dùng, chẳng hạn như người
sử dụng hệ thống / nhóm. Android cũng bảo đảm phạm vi AID sử dụng để trích lập
dự phòng các UID ứng dụng. Các phiên bản của Android 4.1 sau khi bổ xung thêm
AID cho nhiều người dùng và tiến trình riêng biệt của người dùng(ví dụ, cho thêm
hộp cát cho ứng dụng Chrome). Chúng ta có thể tìm thấy định nghĩa cho AID ở /
core / include / private / android_filesystem_config.h
Hình 1.2. Định nghĩa cho AID trong hệ thống

Ngoài AID, Android sử dụng các nhóm bổ xung để cho phép các quy trình có
thể truy cập các tài nguyên được chia sẻ hoặc bảo vệ. Ví dụ, thành viên trong nhóm
sdcard_rw cho phép một quá trình để đọc và ghi vào thư mục /sdcard, các tùy chọn
Trang 5
gắn kết của nó hạn chế các nhóm có thể đọc và ghi. Điều này cũng tương tự như
cách các nhóm bổ xung được sử dụng trong nhiều phiên bản của Linux.
Bên cạnh việc thực thi truy cập tập tin hệ thống, các nhóm bổ xung cũng có thể
được sử dụng để cấp quyền bổ xung cho các tiến trình. Các nhóm AID_INET, ví
dụ, cho phép người dùng mở các AF_INET và AF_INET6 .
Trong phiên bản 4.3 và các phiên bản cao hơn, Android tăng cường việc sử
dụng các khả năng của Linux. Ví dụ, Android 4.3 đã thay đổi /system/bin/run-as
từ UID root để sử dụng khả năng Linux truy cập tài nguyên đặc quyền. Ở đây, khả
năng này tạo điều kiện truy cập vào các tập tin packages.list.
Khi các ứng dụng thực thi UID, GID và các nhóm bổ xung được gán cho tiến
trình mới được tạo ra. Chạy một UID và GID duy nhất cho phép hệ điều hành thực
thi hạn chế cấp thấp hơn trong nhân, và cho thời gian chạy để kiểm soát sự tương
tác giữa các ứng dụng. Đây là mấu chốt của sandbox Android.
1.3.4. Các quyền trong Android.
Các quyền truy cập trong Android rất đa dạng: Có quyền truy cập API, quyền
cho hệ thống tập tin, và quyền chp IPC. Như đã đề cập trước đó, một số tài khoản
cấp cao có khả năng trở lại điều hành cấp thấp hơn. Điều này có thể bao gồm các
hoạt động như mở khe cắm, thiết bị Bluetooth, và một số đường dẫn đến tập tin hệ
thống .
Để xác định các quyền của người sử dụng ứng dụng và nhóm phụ, Android xử
lý quyền truy cập cấp cao qui định tại một gói ứng dụng của tập tin
AndroidManifest .xml . Quyền ứng dụng "được lấy ra từ manifest của ứng dụng
khi cài đặt bởi các Package Manager và được lưu trữ trong
/data/system/packages.xml. Những mục này sau đó được sử dụng để cấp quyền
thích hợp tại quá trình của ứng dụng (chẳng hạn như thiết lập các GID bổ sung).
Các ánh xạ permission-to-group được lưu trữ trong /etc/permission/
platform.xml. Chúng được sử dụng để xác định các ID để thiết lập cho ứng dụng.
Các quyền quy định tại các mục sau đó được thi hành theo một trong hai cách.
Loại thứ nhất là kiểm tra được thực hiện tại thời điểm một phương pháp gọi nhất
định và được thực thi bởi thời gian chạy. Loại thứ hai của việc kiểm tra được thực
thi ở một mức độ thấp hơn trong hệ điều hành bởi một thư viện hoặc trong chính
bản thân nó.
1.3.4.1. Các quyền cho các hàm API
API Permissions bao gồm những người được sử dụng để kiểm soát quyền truy
cập vào chức năng bên trong Android API/framework, và trong một số trường hợp
là các khung chương trình của bên thứ ba. Một ví dụ về một sự cho phép API phổ
Trang 6
biến là READ_PHONE_STATE, được định nghĩa trong tài liệu Android như cho
phép "chỉ đọc truy cập vào trạng thái điện thoại." Một ứng dụng yêu cầu và sau đó
được cấp do đó cho phép này sẽ có thể gọi một loạt các phương pháp liên quan để
truy vấn thông tin điện thoại. Điều này sẽ bao gồm các phương thức trong lớp
TelephonyManager, như getDeviceSoftwareVersion, getDeviceId …
Như đã đề cập trước đó, một số điều khoản API tương ứng với cấp cơ chế thực
thi ở mức nhân của hệ điều hành. Ví dụ, khi được cấp phép INTERNET nghĩa là
UID của ứng dụng yêu cầu được thêm vào như là một thành viên của nhóm inet
(GID 3003). Thành viên trong nhóm này cấp cho người dùng khả năng để mở trình
kết nối AF_INET và AF_INET6 , điều đó là cần thiết cho các chức năng cấp cao
hơn API, chẳng hạn như việc tạo ra một đối tượng HttpURLConnection.
1.3.4.2. Các quyền đối với tập tin hệ thống
Ứng dụng Sandbox của Android được hỗ trợ rất nhiều bởi nhiều quyền đối với
tập tin hệ thống liên kết chặt chẽ với Unix. UID và GID được xác định duy nhất
cho các ứng dụng , theo mặc định, các quyền được thiết lập để cho phép chỉ truy
cập vào đường dẫn lưu trữ dữ liệu của mình trên các tập tin hệ thống. Lưu ý các
UID và GIDs (trong cột thứ hai và thứ ba) trong danh sách thư mục sau đây.
Chúng là duy nhất cho các thư mục này và các quyền hạn của chỉ ra chỉ những
UID và GIDs trên mơi có thể truy cập vào các nội dung trong đó:
Hình 1.3. Quyền tập tin hệ thống

Sau đó, các tập tin được tạo ra bởi các ứng dụng sẽ được thiết lập quyền hạn
cho các tập tin đó.
Chúng ta thấy rằng thẻ SD được gắn với GID 1015, tương ứng với các nhóm
sdcard_rw. Các ứng dụng yêu cầu sự cho phép WRITE_EXTERNAL_STORAGE
sẽ có UID của họ được thêm vào nhóm này, cấp cho họ quyền được phép truy cập
vào đường dẫn này.
1.3.4.3. Các quyền IPC
Trang 7
Quyền IPC liên quan trực tiếp đến thông tin liên lạc giữa các thành phần ứng
dụng (và một số hệ thống cơ sở IPC), mặc dù có một số chồng chéo với các điều
khoản API. Việc kê khai và thực thi các quyền này có thể xảy ra ở các cấp độ khác
nhau, bao gồm cả thời gian chạy, chức năng thư viện, hoặc trực tiếp trong các ứng
dụng riêng của mình. Cụ thể, tập quyền này áp dụng cho các thành phần ứng dụng
Android lớn được xây dựng dựa trên cơ chế Binder IPC của Android. Các chi tiết
của các thành phần và Binder được trình bày sau trong chương này.
1.3.5. Các thành phần ứng dụng
Mặc dù các ứng dụng Android gồm nhiều phần, phần này nêu bật những điều
được chú ý trên hầu hết các ứng dụng, không phụ thuộc vào phiên bản hướng tới
của Android. Chúng bao gồm các AndroidManifest, Intents, Activity,
BroadcastReceivers, Service và Content Proviceder.
a. AndroidManifest.xml
Tất cả các gói ứng dụng Android (APK) phải bao gồm các tập tin .xml
AndroidManifest. File XML này có chứa một tập hợp thông tin về các ứng dụng,
bao gồm những vấn đề sau:
 Tên gói duy nhất (ví dụ, com.wiley.SomeApp) và thông tin phiên bản
 Các hoạt động, dịch vụ, BroadcastReceivers, và định nghĩa Instrumentation.
 Định nghĩa các quyền(cả những yêu cầu ứng dụng, và quyền tùy chỉnh nó
định nghĩa).
 Thông tin về thư viện bên ngoài đóng gói và được sử dụng bởi các ứng
dụng.
 Chỉ thị hỗ trợ bổ xung, chẳng hạn như thông tin được chia sẻ UID, vị trí cài
đặt ưa thích, và giao diện người dùng thông tin.
Một phần đặc biệt thú vị là các thuộc tính sharedUserId. Đơn giản chỉ cần đưa
vào, khi hai ứng dụng có tên giống nhau, họ có thể chỉ định một định danh người
dùng giống hệt nhau trong bản khai của mình. Trong trường hợp này, cả hai ứng
dụng thực thi dưới UID như nhau. Điều này sau đó cho phép các ứng dụng truy
cập vào các kho lưu trữ dữ liệu của một tập tin hệ thống.
Các tập tin manifest thường tự động tạo ra bởi các môi trường phát triển, chẳng
hạn như Eclipse hoặc Android Studio, và được chuyển đổi từ XML sang XML nhị
phân trong quá trình xây dựng.
b. Intents
Trang 8
Một phần quan trọng của giao tiếp giữa các ứng dụng là Intents. Đây là những
đối tượng thông báo có chứa thông tin về một hoạt động được thực hiện, các mục
tiêu thành phần tùy chọn trên đó để hành động, và cờ bổ ung hoặc thông tin hỗ trợ
khác gần như tất cả các hành động phổ biến, chẳng hạn như cách khai thác một liên
kết trong một tin nhắn qua thư để khởi động trình duyệt, thông báo cho các ứng
dụng tin nhắn SMS đã đến, cài đặt và gỡ bỏ các ứng dụng liên quan đến-Intents.
Điều này cũng giống như là một cơ sở IPC hoặc gọi thủ tục từ xa (RPC), nơi
các thành phần ứng dụng "có thể tương tác lập trình với nhau, cách gọi chức năng
và chia sẻ dữ liệu. Với việc thi hành các sandbox ở một mức độ thấp hơn (hệ thống
tập tin, AIDs, vv), các ứng dụng thường tương tác thông qua API này. Thời gian
chạy Android hoạt động như một màn hình chiếu, thực thi quyền kiểm tra cho
Intents, nếu người gọi được gọi xác định yêu cầu sự cho phép để gửi hoặc nhận
thông điệp.
Khi kê khai các thành phần cụ thể trong một manifest, nó có thể chỉ định một
bộ lọc intents, tuyên bố các tiêu chí mà các thiết bị đầu cuối xử lý. Bộ lọc Intent
được đặc biệt sử dụng khi giao dịch với ý định rằng không có một điểm đến cụ thể,
được gọi là ý đồ ngầm.
c. Activities
Một Activity là một thành phần ứng dụng người dùng phải hướng đến, hoặc
giao diện người dùng. Được xây dựng trên lớp Activity cơ sở, hoạt động bao gồm
một cửa sổ, cùng với giao diện người dùng phù hợp. Quản lý cấp thấp hơn của hoạt
động được xử lý bởi các dịch vụ quản lý hoạt động một cách thích hợp được đặt
tên, cũng quá trình Intents được gửi để gọi hoạt động ở giữa hoặc thậm chí trong
các ứng dụng. Những hoạt động được định nghĩa DEFI trong manifest của ứng
dụng, theo cách đó:
Hình 1.4. Những hoạt động được định nghĩa DEFI trong manifest
Trang 9
Ở đây chúng ta thấy các hoạt động, cùng với thông tin giao diện người dùng /UI,
màn hình định hướng, .... Các thuộc tính đáng chú ý là launchMode, vì nó ảnh
hưởng đến việc làm thế nào một Activity được đưa ra. Trong trường hợp này, giá
trị singleTask chỉ ra rằng chỉ có một thể hiện của hoạt động đặc biệt này có thể tồn
tại ở một thời điểm, ngược lại với khởi chạy trường hợp riêng biệt cho mỗi lời gọi.
Các ví dụ hiện tại (nếu có) của ứng dụng sẽ tiếp nhận và xử lý các ý định đó gọi
hoạt động này.
d. Broadcast Receivers
Một dạng khác của thiết bị đầu cuối IPC là Broadcast Receiver, thường thấy
nơi các ứng dụng muốn nhận một Intent ngầm phù hợp với một số tiêu chí khác. Ví
dụ, một ứng dụng muốn nhận được các Intent kết hợp với một tin nhắn SMS sẽ lập
một Receiver trong manifest của nó với một bộ lọc phù hợp với ý định hành động:
Hình 1.5. Lập một Receiver trong manifest

Thiết lập yêu cầu cho phép trên Broadcast Receivers có thể hạn chế các ứng
dụng có thể gửi Intents đến điểm cuối.
e. Services
Services là thành phần ứng dụng mà không có một giao diện, ngay cả khi
người dùng không tương tác trực tiếp với các ứng dụng của Services. Một số ví dụ
về các dịch vụ phổ biến trên Android bao gồm các SmsReceiverService và
BluetoothOppService. Mặc dù mỗi một dịch vụ này chạy nằm ngoài tầm nhìn trực
tiếp của người dùng, như các thành phần ứng dụng Android khác mà họ có thể tận
dụng lợi thế của các cơ sở IPC bằng cách gửi và nhận Intents.
Dịch vụ cũng phải được khai báo trong manifest của ứng dụng. Ví dụ, đây là
một định nghĩa đơn giản cho một dịch vụ cũng có tính năng một bộ lọc :
Hình 1.6. Dịch vụ
Trang 10
Services có thể thường được dừng lại, bắt đầu, hoặc bị ràng buộc, tất cả bằng
cách của Intents. Trong trường hợp sau cùng, liên kết với một dịch vụ, một tập hợp
thêm của IPC hoặc thủ tục RPC có thể có sẵn . Những thủ tục này cụ thể để thực
hiện một dịch vụ, và tận dụng sâu hơn về các dịch vụ Binder.
f. Content Providers
Content Providers hoạt động như một giao diện có cấu trúc để phổ biến, lưu trữ
dữ liệu được chia sẻ. Ứng dụng cũng có thể tạo ra bởi các nhà cung cấp nội dung
của riêng mình, và có thể tùy chọn tiếp xúc với các ứng dụng khác. Các dữ liệu từ
các nhà cung cấp thường được hỗ trợ bởi một cơ sở dữ liệu SQLite hoặc một
đường dẫn trực tiếp đến tập tin hệ thống ví dụ, một chỉ mục phương tiện truyền
thông máy nghe nhạc và chia sẻ các đường dẫn đến các tập tin MP3.
Cũng giống như các thành phần ứng dụng khác, khả năng đọc và ghi của các
Content Providers có thể bị hạn chế bởi các điều khoản.
Ứng dụng này đưa ra một nhà cung cấp, tên MyProvider, tương ứng với các lớp
thực hiện các chức năng cung cấp dịch vụ. Sau đó, nó công bố một
writePermission của com.wiley.example.permission. WRITE, chỉ ra rằng chỉ có
các ứng dụng mang tùy chỉnh này có thể viết thư cho nhà cung cấp . Cuối cùng, nó
xác định các bộ phận chức năng hay thống nhất nội dung tài nguyên (URI) mà nhà
cung cấp này sẽ cho hành động. Nội dung URI có dạng: content:// [authorityname]
/ và có thể bao gồm thêm các thông tin đường dẫn / tham số, có ảnh hưởng xấu đến
việc cung cấp dịch vụ cơ bản (ví dụ, content: // com.wiley.example.data / foo).
g. Android Framework
Liên kết giữa các ứng dụng và thời gian chạy, Android Frameword cung cấp
các một khung chương trình cho các nhà phát triển để thực hiện các tác vụ thông
thường. Nhiệm vụ có thể bao gồm việc quản lý các giao diện người dùng, truy cập
vào các cửa hàng dữ liệu được chia sẻ, và đi qua các thông điệp giữa các thành
phần ứng dụng. Nó bao gồm mã ứng dụng được thực thi trong máy ảo Dalvik.
Khung chương trình là những thành phần trong không gian tên android. *, như
android.content hoặc android.telephony. Android cũng cung cấp nhiều lớp Java
tiêu chuẩn (trong không gian tên java. * Và javax. ), cũng như các gói của bên thứ
ba bổ xung, chẳng hạn như các thư viện client Apache HTTP và phân tích cú pháp
SAX XML. Khung Android cũng bao gồm các dịch vụ sử dụng để quản lý và tạo
điều kiện cho nhiều chức năng được cung cấp bởi các lớp bên trong. Những khung
chương trình giúp cho việc quản bị được bắt đầu bởi system_serversau khi khởi
động hệ thống.
Trang 11
Bảng 1.1. Các quản lý và mô tả vai trò quản trị trong khung chương trình.
Chúng ta có thể thấy một số nhà quản trị xuất hiện dưới dạng chủ đề trong quá
trình system_server bằng cách sử dụng lệnh ps, xác định PID system_server và các
tùy chọn -t:
Hình 1.7. Sử dụng lệnh ps

1.3.6. ADB
Các ADB(Android Debugging Bridge),bao gồm cả các daemon adbd trên thiết
bị Android, máy chủ adb trên máy trạm, và tương ứng adb dòng lệnh của sự cố.
Các máy chủ quản lý kết nối giữa khách hàng và các daemon chạy trên thiết bị
mục tiêu, tạo điều kiện cho các tác vụ như thực hiện một shell ứng dụng gỡ lỗi
(thông qua chính sách Java Debug Wire Protocol); chuyển tiếp khe cắm và cổng
chuyển tập tin và cài đặt/gỡ bỏ cài đặt các gói ứng dụng.
Ví du: Chúng ta có thể chạy các lệnh adb lệnh để liệt kê các thiết bị kèm theo
của Chúng ta. Như ADB chưa được chạy trên máy chủ của chúng tôi, nó được
khởi tạo, lắng nghe trên 5037/tcp cho các kết nối máy chủ. Tiếp theo, Chúng ta có
Trang 12
thể chỉ định một mục tiêu thiết bị bằng số serial của nó và chạy adb shell, tạo cho
Chúng ta một lệnh shell trên thiết bị:
Hình 1.8. Lệnh shell trên thiết bị

Chúng ta có thể thấy rằng cũng daemon ADB, adbd, đang chạy trên thiết bị
đích của grepping cho quá trình (hoặc trong trường hợp này, sử dụng pgrep)
1.3.7. Daemon Volume
Các Daemon Volume, hoặc Vold, chịu trách nhiệm cho việc cài đặt hệ thống tập
tin khác nhau trên Android. Ví dụ khi một thẻ SD được cắm vào Vold xử lý sự
kiện đó bằng cách kiểm tra hệ thống tập tin của thẻ SD(chẳng hạn như thông qua
phát động fsck) và gắn thẻ vào đường dẫn thích hợp (ví dụ /mnt/sdcard). Khi thẻ
được rút ra (bằng tay bởi người sử dụng) Vold sẽ loại bỏ gắn kết của thiết bị. Các
Volume Daemon cũng xử lý gắn kết và loại bỏ gắn kết các tập tin Android Secure
Container (ASEC). Chúng được sử dụng để mã hóa các gói ứng dụng khi chúng
được lưu trữ trên hệ thống tập tin không an toàn như FAT. Chúng được gắn kết
qua các thiết bị loopback tại thời gian tải ứng dụng, thường vào thư mục
/mnt/ASEC. Opaque Binary Blobs (OBBs) cũng được gắn kết và lắp ráp bởi các
Daemon Volume. Những tập tin này được đóng gói với một ứng dụng để lưu trữ
dữ liệu được mã hóa với một khoá bí mật. Không giống như các khoang chứa
ASEC, tuy nhiên, các cuộc gọi đến và gắn kết OBBs unmount được thực hiện bởi
các ứng dụng của nó, chứ không phải là hệ thống.
1.3.8. Dịch vụ khác
Có rất nhiều dịch vụ khác chạy trên nhiều thiết bị Android Bảng 2-2 nêu bật
một số các dịch vụ này, mục đích của họ, và cấp đặc quyền của họ trên hệ thống
(UID, GID, và mọi nhóm phụ cho người dùng đó, mà có thể được quy định trong
các tập tin init.rc của hệ thống).
Trang 13
Bảng 1.2. Các dịch vụ

So sánh danh sách tiến trình, init.rc, và tập tin hệ thống của các thiết bị khác
nhau như của một thiết bị Nexus thường cho thấy rất nhiều dịch vụ không đạt tiêu
Trang 14
chuẩn. Đây là đặc biệt hấp dẫn bởi vì mã nguồn có thể không có cùng chất lượng
của các dịch vụ cốt lõi hiện nay trong tất cả các thiết bị Android.
1.3.9. Kernel
Mặc dù nhân Linux là nền tảng của Android, nhưng có một số khác biệt đáng
kể giữa các nhân Linux được sử dụng bởi Android. Phần này giải thích một số
những thay đổi, đặc biệt là những chi tiết cần để bảo mật Android.
1.3.10. Android Fork
Ban đầu, Google đã tạo ra một Android -Centric là nhân Linux, nhưng nhiều
sửa đổi và bổ sung không tương thích với phiên bản linux. Nói chung, điều này
bao gồm khoảng 250 bản vá lỗi, từ hỗ trợ hệ thống tập tin và mạng tinh chỉnh để
xử lý và thiết bị quản lý bộ nhớ. Hầu hết các bản vá lỗi "đại diện cho một hạn chế
mà các nhà phát triển Android tìm thấy trong nhân Linux." Trong tháng 3 năm
2012, các nhà bảo trì nhân Linux sát nhập các thay đổi kernel của Android cụ thể
vào nhân Linux. Bảng 2-3 nêu bật một số bổ sung / thay đổi.
Bảng 1.3. Một số bổ sung thay đổi về nhân hệ thống.
Trang 15
1.3.11. Binder
Có lẽ một trong những bổ sung quan trọng nhất đối với nhân Linux của
Android là một trình điều khiển được gọi là Binder. Binder là một cơ chế IPC dựa
trên một phiên bản sửa đổi của OpenBinder, ban đầu được phát triển bởi Be và sau
đó Palm. Android của Binder là tương đối nhỏ (khoảng 4.000 dòng mã nguồn trên
hai tập tin), nhưng là then chốt cho nhiều chức năng của Android.
Tóm lại, nhân Binder tạo điều kiện cho các kiến trúc tổng thể Binder. Các
Binder-như là một kiến trúc hoạt động trong một mô hình client-server. Nó cho
phép một quá trình gọi phương thức trong quá trình đồng bộ "từ xa". Các kiến trúc
Binder tóm tắt một cách nền cơ bản các chi tiết, làm các phương pháp như họ là
các cuộc gọi hàm cục bộ. Hình 2-3 cho thấy dòng chảy thông tin liên lạc của
Binder.
Hình 1.9.Dòng chảy liên lạc của Binder

Binder cũng sử dụng quá trình ID (PID) và thông tin UID như một phương tiện
để xác định quá trình gọi, cho phép các callee để đưa ra quyết định về việc kiểm
soát truy cập. Điều này thường xảy ra thông qua các cuộc gọi đến các phương pháp
như Binder .getCallingUid và Binder.getCallingPid, hoặc qua kiểm tra cấp cao hơn
như checkCallingPermission.
Ở một mức độ cao hơn, tiếp xúc phương pháp IPC chẳng hạn là những cung
cấp bởi dịch vụ ràng buộc, thường được cất vào một giao diện trừu tượng thông
qua giao diện Android Definition Language (AIDL). AIDL cho phép cho hai ứng
dụng để sử dụng "thỏa thuận" hoặc các giao diện chuẩn cho việc gửi và nhận dữ
Trang 16
liệu, vẫn giữ giao diện riêng biệt từ việc thực hiện. AIDL giống như tập tin
Interface Definition Language khác hoặc tập tin tiêu đề C / C ++.
1.3.12. Ashmem
Anonymous Shared Memory, gọi tắt là ashmem , là một bổ sung cho nhân
Linux của Android. Trình điều khiển ashmem cơ bản cung cấp một tập tin, giao
diện bộ nhớ chia sẻ tài liệu tham khảo. Anonymous Shared Memory, hoặc ashmem,
là một bổ xung cho nhân Android Linux. Trình điều khiển ashmem cơ bản cung
cấp một tập tin dựa trên, giao diện bộ nhớ chia sẻ tài liệu tham khảo. Nó sử dụng
phổ biến ở hầu khắp các thành phần cốt lõi của Android, như Flinger Surface,
Audio Flinger, hệ thống máy chủ, và các DalvikVM. Bởi vì ashmem được thiết kế
để tự động co lại trên bộ nhớ cache và đòi lại vùng nhớ khi bộ nhớ toàn hệ thống
có sẵn thấp, nó rất thích hợp cho các môi trường bộ nhớ thấp.
Ở mức độ thấp, sử dụng ashmem đơn giản là gọi ashmem_create_region, và sử
dụng mmap trên mô tả tập tin trả về:
Ở một mức độ cao hơn, Android Framwork cung cấp lớp MemoryFile, phục vụ
như là một vỏ bọc xung quanh các trình điều khiển ashmem. Hơn nữa, quá trình có
thể sử dụng các cơ sở Binder để sau này chia sẻ các đối tượng bộ nhớ, tận dụng các
tính năng bảo mật của Binder để hạn chế truy cập. Ngẫu nhiên, ashmem được
chứng minh là nguồn gốc của một lỗ hổng khá nghiêm trọng vào đầu năm 2011,
cho phép cho một sự leo thang đặc quyền thông qua các thuộc tính Android.
1.3.13. Pmem
Một trình điều khiển tùy chỉnh của Android cụ thể là PMEM, có thể quản lý
lượng lớn bộ nhớ vật lý khác nhau, tiếp giáp giữa 1 megabyte (MB) và 16MB
(hoặc nhiều hơn, tùy thuộc vào việc thực hiện). Các khu vực này là đặc biệt, trong
đó chúng được chia sẻ giữa các quá trình sử dụng không gian và điều khiển nhân
khác (chẳng hạn như trình điều khiển GPU). Không giống như ashmem, trình điều
khiển PMEM đòi hỏi quá trình phân bổ cho tổ chức một tập tin để mô tả bộ nhớ
heap PMEM cho đến khi tất cả các tài liệu tham khảo khác đều đóng.
1.3.14. Logger
Mặc dù nhân của Android vẫn duy trì dựa trên cơ chế Linux kernel-logging
riêng của nó, nó cũng sử dụng một hệ thống khai thác con, thường gọi là logger.
Trình điều khiển này hoạt động hỗ trợ cho các lệnh logcat, được sử dụng để xem
các bộ đệm log. Nó cung cấp bốn bộ đệm đăng nhập riêng biệt, tùy thuộc vào loại
Trang 17
thông tin: main, radio, sự kiện, và hệ thống. Hình 2-4 cho thấy sự giảm sút các sự
kiện nhật ký và các thành phần hỗ trợ logger.
Hình 2.8. Kiến trúc đăng nhập hệ thống Android

Hệ thống bộ đệm cũng là một nguồn cung cấp nhiều thông tin, cụ thể là các sự
kiện toàn hệ thống được tạo ra bởi các quá trình của hệ thống. Các quá trình này sử
dụng các phương pháp println_native trong lớp android.util.Slog. Phương pháp này
lần lượt gọi mã riêng cụ thể để đăng nhập vào bộ đệm đặc biệt này.
Thông điệp đăng nhập có thể được lấy ra bằng cách sử dụng lệnh logcat, với cả
các bộ đệm chính và hệ thống là nguồn mặc định.
Lệnh logcat thường được thực hiện nên ADB cung cấp một phím tắt để chạy
nó trên một thiết bị đích..
Chương 2.
TỔNG QUAN VỀ MÃ ĐỘC TRÊN ANDROID
Giới thiệu chương:

Malware ngày nay không chỉ xuất hiện trên máy tính, nó còn tồn tại trên cả thiết
bị di động nữa. Trong số các nền tảng di động hiện nay thì Android thường bị tấn
công do có lượng người dùng lớn nhất, lại sở hữu một số tính năng mang tính
"mở" hơn so với iOS hay Windows Phone.
Với việc Android tiếp tục trở thành “mồi ngon” của hacker trong việc phát tán
các loại mã độc, có vẻ như Android đang dần trở thành một “Windows thứ 2”
Trang 18
trong lĩnh vực bảo mật , khi sự phổ biến của nền tảng này đang thu hút tối đa sự
chú ý của các tin tặc, đồng thời việc quản lý các ứng dụng cho Android một cách
lỏng lẻo càng tạo điều kiện cho mã độc được phát tán dễ dàng hơn trên nền tảng di
động này. Android là một môi trường lý tưởng cho mã độc phát triển vì:
 Phần lớn các smartphone đều hỗ trợ các ứng dụng email, internet
baking…sử dụng các ứng dụng này đồng nghĩa với việc cung cấp thông tin
cá nhân.
 Android hiện tại giữ vị trí số một trong các hệ điều hành dành cho
smartphone và máy tính bảng.
 Android là một hệ điều hành mở.
Có nhiều cách phân loại mã độc trong android:
 Nghiên cứu của Troy Vennon dựa vào cách hoạt động lây nhiễm của mã độc
đã chia ra làm bốn loại.
 Nghiên cứu của K.H.Khan & M.N.Tahir phân loai mã độc làm 6 nhóm.
 Trang web forenics chuyên nghiên cứu về mã độc dựa vào mục tiêu của mã
độc để chia ra làm 9 họ:
Đánh cấp thông tin cá nhân 51,3%
Gửi tin nhắn trái phép (IMEL,..) 30,1%
Botnet(spam, thư rác,..) 23,5%
Truy cập Root 18,3%
Tải từ Google-Play 11,3%
Cài đặt các ứng dụng khác 10,4%
Trang 19
Đánh cấp định vị của người dung 8,7%
Cài đặt các ứng dụng hỗ trợ hacker 7,8%
Trojans (tiếp cận các dịch vụ ngân hàng trực 3,5%

tiếp)
Bảng 2.1. Phân loại mã độc trong Android theo trang web forenics
2.1. Cơ chế hoạt động của Malware
Malware hoạt động qua hai giai đoạn:
 Giai đoạn đầu: Malware được nhúng vào trong một ứng dụng và sẽ chiếm
được quyền root vào thiết bị của chúng ta ngay sau khi chúng ta chạy ứng dụng đó
trong lần sử dụng đầu tiên.
 Giai đoạn 2: Malware tự động cài đặt một ứng dụng thứ 2 với một
permission đặc biệt cho phép quyền uninstall. Một khi các ứng dụng thứ 2 được cài
đặt, nó có thể gửi các thông tin nhạy cảm tới một máy chủ từ xa và âm thầm tải
thêm các ứng dụng khác. Việc cài đặt ứng dụng hệ thống này nhằm ngăn ngừa
người dùng xem hoặc gỡ bỏ cài đặt các ứng dụng mà không được phép.
Không giống như giai đoạn đầu, người dùng phải khởi động ứng dụng để bắt
đầu việc lây nhiễm. Ở giai đoạn thứ hai ứng dụng tự động làm một số việc như là
confirm, check-in. Một điều nữa khiến cho chúng ta không thể biết chúng hoạt
động lúc nào (hầu hết vào khoảng thời gian từ 11h đêm tới 8h sáng ngày hôm sau).
Đây là khoảng thời gian mà điện thoại ít được sử dụng nhất. Điều này làm cho
người dùng khó khăn hơn trong việc phát hiện một hành vi bất thường trên chiếc
smartphone của mình. 1.1. Lược đồ đặt tên cho Malware
Malware xuất phát từ cụm từ Malicious Software có nghĩa là phần mềm độc
hại. Malware là cụm từ dùng để chỉ chung tất cả những phần mềm, công cụ, đoạn
mã,.... Có khả năng làm hại máy tính hay gây ảnh hưởng trái phép tới người dùng.
Đề án đặt tên phần mềm độc hại đã được đề xuất bởi Skuslason và Bontchev
trong năm 1991 (Skulason & Bontchev, 1991). Hiện nay, đề án này vẫn được coi là
tiêu chuẩn hiện hành duy nhất mà hầu hết các công ty bảo mật máy tính và các nhà
nghiên cứu chấp nhận sử dụng . (Szor, 2005)
Ngày nay, đặt tên phần mềm độc hại thường được viết tắt dưới dạng tối giản:
<malware_type>:// <nền tảng> / <family_name><biến>
ví dụ như Trojan: //Android/DroidKungFu.A
Trang 20
Trong thực tế, nhiều biến thể hơi khác nhau của chương trình đặt tên này đã
được thông qua bởi các công ty an ninh máy tính và các nhà nghiên cứu khác nhau,
chẳng hạn như:
Trojan: Android / DroidKungFu.A
Android / Trojan.DroidKungFu.A
Android.Trojan.DroidKungFu.A
Android.DroidKungFu.A [Trojan]
Ở đây, chúng tôi sử dụng sơ đồ đặt tên chuẩn của Skusla_son và Bontchev đề
xuất.
2.1.2. Các loại phần mềm độc hại

Đầu tiên có thể phân loại Malware theo hành vi (hoạt động) gây hại của chúng.
Do kiến trúc thiết kế/giới hạn. Android không là virus máy tính theo nghĩa hẹp của
từ này (tức là "một mã độc có thể tự nhân bản chính nó và có thể tiến hóa " (Szor,
2005)).
Trang 21
Hình 2.1. Phân loại Malware theo hoạt động của chúng
Trong Android hầu hết các loại phần mềm độc hại hiện đang thừa hưởng trực
tiếp từ mã độc tren môi trường máy tính để bàn(ví dụ như Adware hoặc Rogue-
AV), thậm chí một số phần mềm có khả năng bổ sung trên không gian di động (ví
dụ khả năng gửi tin nhắn SMS và thực hiện các cuộc gọi điện thoại ở trên cùng 1
thiết bị). Tuy nhiên, cũng có những loại phần mềm độc hại chỉ hoạt động được trên
không gian di động (ví dụ như Trojan-SMS).
Hầu hết các mã độc Android là phiên bản "Trojanised" hiện tại của các ứng
dụng hợp pháp. Đặc biệt, các nhà nghiên cứu đã thu thập được dữ liệu của 1.500
mẫu, từ dự án Android Malware Genome (Y. Zhou & Jiang, 2012), Contagio
Mobile (Mila, 2013) và các nguồn trực tuyến khác. Phân chia các mẫu thu thập
theo loại, chúng tôi đã thấy 826 mẫu Trojan (chia thành 33 loại), 359 mẫu
Backdoor (chia thành 17 loại), 98 mẫu Trojan-Spy (chia thành 25 loại) và 95 mẫu
TrojanSMS (chia thành 24 loại) (xem Hình 2.5).
Trang 22
Hình 2.2. Biểu đồ Andriod Malware

Đặc biệt, những loại phổ biến nhất là:
 Adware: nó là một dạng mã độc có thể tự động hiển thị thông điệp gây phiền
nhiễu, thường gây khó chịu cho người sử dụng thông qua các quảng cáo không
mong muốn để tạo ra doanh thu cho tác giả của nó.
Trong Android, nhiều ứng dụng được phân phối kèm theo một phiên bản miễn
phí hoặc dùng thử có chứa chương trình quảng cáo. Một số thư viện quảng cáo
(được định nghĩa là "linh hoạt") tuy nhiên, có thể gây rò rỉ thông tin cá nhân, thông
tin nhạy cảm hoặc thể hiện hành vi gây phiền nhiễu, như: hiển thị quảng cáo trên
thanh thông báo hoặc màn hình, tạo ra các biểu tượng quảng cáo hoặc thay đổi
trình duyệt web. Theo Symantec, trong năm 2013, đã có 65 thư viện quảng cáo
được biết đến trong đó có hơn 50% trong số đó được phân loại linh
hoạt. (Uscilowski, 2013)
Hơn nữa, chính sách kiểm duyệt (hoặc không kiểm duyệt) của Google đối với
lĩnh vực quảng cáo trong ứng dụng đang góp phần làm gia tăng đáng kể về số
lượng các phần mềm quảng cáo tại cửa hàng Google Play. Ví dụ: Trojan:
//Android/FakeMarket.A
 Backdoor: nó là dạng mã độc - còn được gọi là công cụ quản trị từ
xa (RAT) - cho phép kẻ tấn công chiếm quyền điều khiển thiết bị (khi không được
sự đồng ý hoặc xác nhận của người sử dụng) và thực hiện nhiều hoạt động gây hại
khác nhau từ một vị trí từ xa, chẳng hạn như: ngăn chặn các cuộc gọi điện thoại và
tin nhắn SMS, thực hiện cuộc gọi điện thoại, gửi Tin nhắn SMS, mở trang web, tải
về và cài đặt các ứng dụng khác, xóa các tập tin, thu thập và gửi thông tin lại cho
những kẻ tấn công.
Trang 23
Hình 2.3. biểu đồ về hành vi và mức độ của ad_library

Các thiết bị nạn nhân (gọi là bot) nhận lệnh từ kẻ tấn công (gọi là botmaster)
thông qua một thông qua máy chủ điều khiển (C & C) server và thực thi các hành
động mà hacker mong muốn.
Một ví dụ về một Backdoor là Backdoor://Android/OBad.A, được coi là một
trong những mã độc Android phức tạp nhất hiện nay. Mã độc này có khả năng tải
về và cài đặt các loại mã độc khác, lây lan các mã độc đã tải về thông qua
Bluetooth, gửi tin nhắn SMS đến các số premium-rate, kết nối với các trang web
cụ thể, mở một shell từ xa, thu thập và chuyển tiếp đến máy chủ C & C các thông
tin cá nhân của các nạn nhân bao gồm: địa chỉ MAC Bluetooth, hệ điều hành của
điện thoại di động, số điện thoại, số IMEI và số dư tài khoản người
dùng. (Unuchek, 2013)
 Rogue (còn được gọi là FraudTool): nó là một mã độc thực hiện nhiệm vụ
lừa đảo người dùng, nó đóng giả là một phần mềm thông dụng hoặc đáng tin cậy
để đánh cắp tiền và/hoặc dữ liệu bí mật. Ví dụ như Rogue://Android/FakeFlash.A,
mã độc cố gắng thuyết phục nạn nhân của nó phải trả 5 Euro để tải về ứng dụng
Adobe Flash Player. Adobe không đươc cung cấp ứng dụng "standalone" trên
Google Play Store nữa. Tuy nhiên, chức năng Flash Player đã được tích hợp vào
các ứng dụng Adobe AIR, và có thể là tải miễn phí trên Google Play Store. (SB
2014)
 Rogue-AV (còn được gọi là FakeAV): nó là sub-type của Rogue. Loại
Rogue này giả mạo là một giải pháp chống virus và phát hiện các mối đe
dọa trên các thiết bị của nạn nhân và yêu cầu nạn nhân phải trả tiền để loại
bỏ các mối đe dọa không tồn tại. (Corrons & Correll, 2010; Stone-Gross
Trang 24
et al., 2013). Ví dụ như mã độc Rogue-AV://Android/AndroidDefeder.A

(xem Hình 1.4). (Rovelli, 2013c; Ducklin, 2013)
Hình 2.4. Ví dụ về mã độc Rogue-AV

 Rootkit: nó là mã độc hoạt động ở mức kernel của hệ điều hành mở
Android, do đó, rất khó để phát hiện và loại bỏ chúng.
Mặc dù đã có nhiều nghiên cứu đề cập đên vấn đề này (Oi, 2011; Jiang,
2012a; BRODBECK, 2012; Ayer, nd), chúng tôi mới tìm thấy duy nhất một loại
Rootkits "trong tự nhiên" được biết đến hiện nay như Rootkit: // Android /
Oldboot. (Xiao, Đồng, Zhang, và Jiang, 2014)
 Trojan (hoặc Trojan Horse): Trojan là một mã độc hoạt động nhằm chống
lại hoặc gây tổn hại đến người dùng, chúng có vẻ ngoài hợp pháp nhưng luôn ẩn
chứa mặt xấu xa bên trong. Để thuyết phục người sử dụng cài đặt, Trojan thường
cải trang như một ứng dụng hấp dẫn, chẳng hạn như trò chơi điện tử hoặc một ứng
dụng để cải thiện hiệu suất hoặc an toàn của Thiết bị. Nhờ đóng gói lại trong môi
trường Android, nó phổ biến dưới dạng phiên bản "Trojanised" hợp pháp của ứng
dụng.
Trojan được phân chia theo hành động gây hại của nó. Ví dụ, nếu mã độc
hướng đến việc đạt được doanh thu tài chính và hành động gây hại chỉ liên quan
đến gửi tin nhắn SMS đến các số premium-rate, thì Trojan này được phân loại như
là một Trojan-SMS. Tương tự như vậy, một Trojan chỉ nhằm mục đích do thám
nạn nhân của nó và đánh cắp thông tin cá nhân và thông tin nhạy cảm của họ được
phân loại như là một Trojan-Spy. Tuy nhiên, không phải tất cả các Trojans đều có
thể phân phân loại.Thật vậy, hầu hết các Trojan sử dụng để thực hiện nhiều hành
động gây hại khác, do đó, không thể dán nhãn cụ thể. Hơn nữa trong Android, hầu
Trang 25
hết các Trojan có khả năng botnet - nghĩa là chúng có thể mở một backdoor(cửa
sau) từ đó gửi và nhận lệnh
 Trojan-Banker: là một mã độc thuộc dạng Trojan nhằm đánh cắp thông
tin tài khoản ngân hàng trực tuyến của nạn nhân (ví dụ như tên người dùng
và mật khẩu) và/hoặc dữ liệu khác liên quan đến thanh toán trực tuyến
(thông tin thẻ tín dụng hoặc tin nhắn SMS, mật khẩu). Các dữ liệu thu thập
được sau đó chuyển tiếp đến (C & C) máy chủ ở xa thông qua một kênh
truyền thông như: HTTP, SMTP hoặc tin nhắn SMS.
Ví dụ Trojan-Banker://Android/ZitMo, loại mã độc chặn tất cả các tin
nhắn SMS và chuyển chúng đến một máy chủ C & C, thông qua các kênh
HTTP POST hoặc tin nhắn SMS tùy thuộc vào các biến thể. Các Trojan-
Banker://Android/ZitMo đại diện cho ví dụ cổ điển về tấn công Man-in-
the-Mobile thông qua việc huỷ tin nhắn SMS dựa trên việc xác thực hai
nhân tố. (Rovelli, 2013e; Castillo, 2011; Maslennikov, 2011; Barroso,
2010)
 Trojan-Downloader: là một dạng Trojan cho phép tải và cài đặt các ứng
dụng độc hại lên thiết bị mà không cần quan tâm đến người dùng của thiết
bị. Các thông tin về các ứng dụng được tải về và lưu trên thiết bị nơi lưu trữ
ứng dụng có thể được mã hóa cứng trong chính Trojan-Downloader hoặc
lấy từ web.
Ví dụ như Trojan-Downloader://Android/DroidDream.A và
TrojanDownloader://Android/RootSmart.A. Để đạt được các đặc quyền
root, đầu tiên tiến hành sử dụng mã độc Exploit://Android/Exploid trong
trường hợp thất bại sử dụng mã độc
Exploit://Android/RageAgainstTheCage. Để đạt được quyền root trên thiết
bị.
Trong trường hợp thành công, nó sẽ cài đặt các mã độc (trong thư
mục hệ thống) một ứng dụng thứ hai sẽ được khởi tạo và quản lý việc
download các ứng dụng khác (Lookout, 2011; Svajcer, 2011). Tiếp theo nó
sẽ kiểm tra xem thiết bị có thể khai thác không (phiên bản Android 2.3.4
trở xuống) và nếu nó chưa bị expoit trước đó, khi đó tải phần mềm độc hại
và thực hiện các Exploit://Android/GingerBreak để đoạt quyền truy cập
root. Sau đó, nó sẽ download một công cụ quản trị từ xa (RAT) và bắt đầu
cài đặt các ứng dụng độc hại khác. (Mullaney, 2012; Jiang, 2012b;
Spreitzenbarth, 2012.
 Trojan-Password: Là một dạng Trojan nhằm đánh cắp thông tin tài khoản
của nạn nhân (tên người dùng và mật khẩu). Một ví dụ về một phần mềm
Trang 26
độc hại này Trojan-Password://Android/FakeNetflix.A, mã độc này cố

gắng đánh cắp thông tin tài khoản Netflix và gửi qua HTTP đến cho
hacker. (Asrar & Imano, 2011)
 Trojan-SMS: Là dạng Trojan thực hiện các hành động gây hại để đạt được
mục đích về tài chính có liên quan chặt chẽ đến các tin nhắn SMS (ví dụ
như gửi Tin nhắn SMS đến các số primium-rate). Một ví dụ về mã đọc này
là Trojan-SMS://Android/Agent.B, nó sẽ tìm cách để đăng ký người sử
dụng(không rõ giới tính)với các dịch vụ thanh toán tự động trả lời qua tin
nhắn SMS cụ thể. (Rovelli, 2013a)
 Trojan-Spy (còn được gọi là phần mềm gián điệp): Là loại Trojan nhằm
mục đích để do thám hành động của nạn nhân" (như gửi/nhận tin nhắn
SMS hoặc thực hiện/nhận cuộc gọi điện thoại) để thu thập thông tin cá
nhân và thông tin nhạy cảm của họ (hệ điều hành điện thoại di động, số
điện thoại, số IMEI, số dư tài khoản, địa chỉ liên lạc và vị trí hiện tại). Các
dữ liệu thu thâp sau đó chuyển tiếp đến máy chủ (C & C) từ xa thông qua
kênh truyền thông như: HTTP, SMTP hay SMS.
Ví dụ mã độc Trojan-Spy://Android/SMSAgent.B, thu thập tất cả các
tin nhắn SMS của người sử dụng và chuyển chúng qua email đến một địa
chỉ cụ thể. (Rovelli, 2013b).
2.1.3. Phương pháp phát tán Malware
Malware có thể được phân loại theo cách thức lây lan. Ngoài ra trong các
hình thức phân loại mã độc trên hệ điều hành Android có hai phương pháp nhân
bản phổ biến: trong không gian máy tính để bàn (ví dụ như drive-by download) và
trong không gian Android (ví dụ như đóng gói lại).
Trang 27
Bảng 2.2. Phân loại Malware theo cách thức lây lan
 Drive-by Download: Là các kiểu tấn công trong đó một ứng dụng được tải
về và cài đặt trên thiết bị mà không được sự cho phép hoặc sự hay biết của người
dùng Android. Tấn cộng dạng Drive-by Download thường xảy ra do người dùng
nhấp vào một pop-up lừa đảo hoặc do một phần mềm độc hại đã được cài đặt trên
thiết bị.
Ví dụ về tấn công drive-by download là:
TrojanBanker://Win32/Zeus. Khi một nhân viên ngân hàng sử dụng một máy
tính bị nhiễm Trojan-Banker://Win32/Zeus để thực hiện các nghiệp vụ ngân hàng,
anh/cô ấy sẽ được chuyển hướng để tải về một ứng dụng điện thoại di động cụ thể
để với thong báo giúp nâng cao sự an toàn của ngân hàng trực tuyến. Tuy nhiên,
các ứng dụng được tải về là mã độc Trojan-Banker://Android/ZitMo, loại mã độc
này chặn tất cả các tin nhắn SMS gửi đến và chuyển chúng đến một máy chủ C &
C để hủy SMS dựa trên việc xác thực hai yếu tố. (Rovelli, 2013e; Maslennikov,
2011)
Trang 28
 Malicious Ad Libraries: Là một dạng mã độc thực hiện những cuộc tấn
công gần đây nhất được phát hiện trong không gian Android. Trong cuộc tấn công
này, mã độc được phát tán thông qua các thư viện quảng cáo được sử dụng bởi ứng
dụng lành tính (không độc hại). Thật vậy trong Android, nhiều ứng dụng được
phân phối thường kèm theo một phiên bản miễn phí bao gồm ứng dụng quảng
cáo. Những quảng cáo hiển thị, tuy nhiên, không được kiểm soát bởi các nhà phát
triển ứng dụng mà do thư viện quảng cáo chọn. Thư viện quảng cáo độc hại hiển
thị quảng cáo bình thường cho đến khi đạt được đủ số người sử dụng, sau đó chúng
bắt đầu hiển thị quảng cáo gây hiểu nhầm rằng có một số thông tin cần cập nhật và
thông quá đó nó sẽ phần mềm độc hại lên thiết bị.
Vào tháng Tư, Panda Security cho biết họ đã tìm thấy 32 ứng dụng có sẵn
trong Google Play đã sử dụng thư viện quảng cáo độc hại. Tổng số lượt tải về các
ứng dụng thông qua Google Play đạt 9.000.000. (Panda Security, 2013b)
 Đóng gói: Là dạng tấn công phổ biến nhất được sử dụng trong môi trường
Android. Nhờ việc đóng gói lại, các Malicious Payload có thể được tiêm vào các
ứng dụng lành tính(xem hình 1.5).
Hình 2.5. Mã độc được đóng gói và bơm vào ứng dụng
Về cơ bản, gói apk của một ứng dụng lành tính được lấy tải về từ Android
Market (thường là Google Play Store) và được tháo rời (thường là bytecode Dalvik
được chuyển đổi thành JAR hoặc mã smali). Sau đó, Malicious Payload được tiêm
vào và các gói apk được đóng gói lại. Cuối cùng phiên bản mới "Trojanised" của
ứng dụng được gửi đến một hoặc nhiều Android Market của bên thứ ba.
Trang 29
Một ví dụ điển hình là Trojan-Downloader://Android/RootSmart.A, một phiên

bản đóng gói lại của ứng dụng có tên QuickSettings. (Mullaney, 2012; Jiang,
2012b)
Tổng cộng có 1083 trong 1260 (86%) các mẫu được thu thập bởi Zhou et
al. trong Android Malware Genome Project của họ được đóng gói lại (Y. Zhou &
Giang, 2012). Nhiều frameworks được thiết kế đặc biệt để phát hiện các ứng dụng
đóng gói lại đã được đề xuất, như DroidMOSS (W. Zhou, Zhou, Jiang, & Ning,
2012) và DNADroid (Crussell, Gibler, & Chen, 2012)
Điều quan trọng phải lưu ý rằng, trong các kỹ thuật đóng gói cổ điển, do thiết
kế nền tảng của Android, các phiên bản "Trojanised" của ứng dụng ban đầu không
sử dụng chữ ký số với chứng nhận riêng của ứng dụng. Thật vậy hiện nay tất cả
các ứng dụng Android được cài đặt phải có chữ ký số với một giấy chứng nhận có
khóa riêng được phân phối bởi nhà phát triển của ứng dụng (Các dự án mã nguồn
mở Android, 2013r). Nếu không có sự phù hợp giữa các chứng chỉ và các gói apk
tương ứng, ứng dụng bị sẽ bị từ chối. Đây rõ ràng là trở ngại lớn của các tấn công
đóng gói cổ điển, kể từ khi phương pháo kiểm tra file chứng nhận của ứng dụng
(tức là CERT.RSA) được áp dụng ngay lập tức có thể cho biết nó được tạo ra bởi
các nhà sản suất hợp pháp hay không.
 Android "Master Key" vulnerability: nó là một trong những tấn công
đóng gói lại gần đây nhất được phát hiện trong không gian Android cho phép kẻ
tấn công tiêm mã độc vào một gói APK mà không cần có chữ ký số. Thật vậy, nếu
hai tập tin có cùng tên sẽ được đặt trong một gói Apk (xem Hình 1-6), các phiên
bản Android đầu tiên xác minh chữ ký số sau đó mới tiến hành cài đặt. Vì vậy
trong trường hợp các hệ thống ban đầu được xác nhận là hợp pháp nhưng quá trình
cài đặt lại là các phiên bản "Trojanised" . (Forristal, 2013; Sophos, 2013a)
Loại mã độc đầu tiên sử dụng kỹ thuật này là Trojan://Android/Skullkey.A,
nó cho phép điều khiển các thiết bị bị nhiễm từ xa, đánh cắp dữ liệu nhạy cảm và
gửi tin nhắn SMS đến các đầu số giá trị gia tăng. (Symantec Security Response,
2013)
Hình 2.6. Android “Master Key” vulnerability
Trang 30
 Update: là một dạng tấn công, trong đó, thay vì tiêm toàn bộ Malicious
Payload vào một gói apk, thì nó chỉ tiêm vào thành phần cập nhật. update này sẽ
có trách nhiệm tải Malicious Payload trong thời gian chạy. Ví dụ kinh điển về một
cuộc tấn công update được đưa ra bởi một số biến thể
của Trojan://Android.BaseBridge, Khi ứng dụng chạy lần đầu tiên hộp thoại được
hiển thị thông báo một phiên bản mới của ứng dụng có sẵn được hiển thị. Các
phiên bản mới thực sự được lưu trữ bên trong gói apk của ứng dụng như là một tập
tin tài nguyên. Nếu người dùng chấp nhận cài đặt "update", các ứng dụng có chứa
Malicious Payload sẽ được cài đặt. (Y. Zhou & Jiang, 2012; NQ Mobile, 2012)
 Usurping ads: Là một cuộc tấn công đóng gói lại trong đó các thay đổi
liên quan tới ID của nhà sản xuất trong tập tin AndroidManifest.xml.
Như đã nói, trong Android, nhiều ứng dụng tận dụng lợi thế của ứng dụng
quảng cáo. Để làm được điều đó, các nhà phát triển phải đăng ký một hoặc nhiều
mạng quảng cáo hơn, nơi lần lượt gán một hoặc nhiều ID nhà xuất bản cho mỗi
nhà phát triển. Những ID nhà sản xuất này được sử dụng để xác định đúng hướng
và phát triển doanh thu cho người dùng thông qua việc nhấp chuột và lưu lượng
quảng cáo. Thư viện quảng cáo này thường đòi hỏi thông tin của các nhà phát triển
bao gồm ID nhà xuất bản của mình vào các thẻ meta trong file
AndroidManifest.xml (xem Hình 1-7). Do đó, bằng cách thay thế các ID nhà xuất
bản ban đầu với những ID của tội phạm mạng, các ứng dụng đóng gói sẽ xử lý
chính xác như bản gốc nhưng doanh thu quảng cáo sẽ được thu thập bởi các tội
phạm mạng. (W. Zhou et al., 2012)
Hình 2.7. Khai báo thẻ quảng cáo trong AndroidManifest.xml

 Standalone:Là một dạng tấn công trong đó một ứng dụng làm rối người sử
dụng cho các download hoạt động. Nó thường là trường hợp của phần mềm độc
hại giả dạng ứng dụng là hợp pháp (ví dụ như Rogue hoặc Trojan) hoặc thực sự
cung cấp các chức năng như tuyên bố, nhưng âm thầm tải và cài đặt mã độc lên
thiết bị, chúng cũng thực hiện các hành động gây hại khác.
Trang 31
Malicious ToS: Là một dạng tấn công mới nhất được phát hiện trong không
gian Android. Trong cuộc tấn công này, các ứng dụng độc hại cố gắng thu hút
người dùng bắt người dùng phải chấp nhận sai lầm trong Thỏa thuận dịch vụ (ToS)
- thường là thu nhỏ quá mức để có thể đọc được, Ví dụ, người dùng vô tình chấp
nhận để được đăng ký với các đầu số giá trị gia tăng dịch vụ tin nhắn
SMS. (Corrons, 2013b)
2.2. Một số loại mã độc thường thấy trên Android
2.2.1. Phần mềm âm thầm trừ tiền vào tài khoản điện thoại
Malware này xuất hiện rất phổ biến, và nó đã được phát hiện ở Việt Nam từ
năm 2011. Câu chuyện bắt đầu bằng việc nhiều người dùng Android ở Việt Nam bị
trừ tiền cước điện thoại một cách oan uổng sau khi họ cài một số phần mềm miễn
phí trên kho ứng dụng. Các phần mềm này có nguồn gốc từ Việt Nam, và trên thế
giới cũng đã ghi nhận nhiều trường hợp tương tự. Các app này sẽ tự động gửi tin
nhắn từ điện thoại của chúng ta đến một tổng đài, và cứ mỗi tin như thế chúng ta bị
trừ từ vài nghìn đến chục nghìn đồng (thường thấy nhất là con số 15.000 đồng).
Và thế là vào một ngày đẹp trời, có một tin nhắn trả về thông báo rằng: "chúc
mừng Chúng ta đã đăng kí dịch vụ thành công!" cùng với đó là 15.000 đã bốc hơi
khỏi tài khoản, trong khi chúng ta không đăng kí dịch vụ nào cả. Ngoài ra câu
chuyện chưa dừng ở đó, sau đó thì chúng ta còn bị spam với rất nhiều các tin nhắn
quảng cáo, đơn giản vì số điện thoại của chúng ta đã được thu nhập và phát tán rồi.
Một nghiên cứu chung giữa Kaspersky và INTERPOL vào tháng 10 năm
2014 còn cho thấy rằng Việt Nam nằm trong nhóm các nước dễ bị tấn công bằng
phần mềm mã độc SMS với tỉ lệ 2,41%. Một số quốc gia khác cũng nằm trong
nhóm này bao gồm Kazakhstan (5.71%), Ukraine (3.32%), Tây Ban Nha (3.19%),
Anh Quốc (3.02%), Malaysia (2.3%), Đức (2%), Ấn Độ (1.55%) và Pháp (1.32%).
Trang 32
Hình 2.8. Biểu đồ các loại Malware Android dùng để tấn công thiết bị
2.2.2. Ransomware
Loại malware này sẽ khóa thiết bị của chúng ta lại bằng cách nào đó cho đến
khi chúng ta đồng ý trả một số tiền chuộc hay làm một vài thứ theo yêu cầu của
tin tặc. Nó bắt đầu xuất hiện trên Android vào năm 2014 với một phần mềm
mang tên Svpeng. Với những người dùng ở Nga, mỗi khi họ chạy Google Play
lên thì Svpeng sẽ hiển thị một hộp thoại bắt nhập thông tin thẻ tín dụng vào thì
mới cho dùng tiếp. Còn với người dùng tại Mỹ và Anh thì Svpeng giả dạng như
là FBI, nó sẽ khóa thiết bị lại với cáo buộc có nội dung khiêu dâm trẻ em
(nhưng thực chất không có). Người dùng buộc phải trả một khoản tiền "phạt" để
có thể sử dụng máy.
Trang 33
Hình 2.9. Thông báo của Svpeng

Bằng cách này hacker đã chiếm được thẻ và chiếm đoạt tiền từ nó. Nghiêm
trọng hơn, Svpeng còn kiểm tra xem có một app ngân hàng nào đó được cài trên
máy của người dùng hay không nhưng hiện chưa rõ nó tính làm gì với thông tin
này.
Đến tháng 4 năm nay, cảnh sát Nga đã bắt được tác giả của Svpeng, và
người này chỉ mới 25 tuổi. Tính đến khi bị bắt, hắn ta đã trộm được hơn 50 triệu
rub, tương đương 930.000 USD, và làm lây nhiễm 350.000 thiết bị Android.
2.2.3. Lỗ hổng WebView
Lỗ hổng bảo mật này có thể bị khai thác với các máy chạy Android 4.3 trở
xuống thông qua một thành phần gọi là WebView. Đây là thành phần cho phép app
hiển thị trang web ngay bên trong nó mà không phải mở trình duyệt lên. Vấn đề là
Webview có thể bị lợi dụng để thực thi một đoạn mã JavaScript độc hại khi chúng
ta truy cập vào một website có ý đồ xấu, và tin tặc có thể vượt qua hoàn toàn
những cơ chế bảo mật được viết ra để bảo vệ chúng ta. Lên tới Android 4.4 và cả
5.0, Google đã đưa ra một thành phần khác thay thế. Chuyện sẽ không có gì đáng
nói nếu ít người dùng Android 4.3 Jelly Bean trở xuống, nhưng thực chất vẫn còn
đến khoảng 950 triệu người đang sử dụng phiên bản Android này. Và nghiêm
trọng hơn, Google không có kế hoạch đưa ra bản vá lỗi nào cả.
2.2.4. Điện thoại tắt nhưng thật ra không tắt

Android/PowerOffHijack là một malware có khả năng can thiệp vào quy trình
shutdown của thiết bị. Nó làm cho chúng ta tưởng như là đã tắt máy rồi nhưng thực
chất không phải như thế. Và trong quãng thời gian đó, malware có thể lén thực
Trang 34
hiện cuộc gọi, chụp ảnh, kích hoạt microphone và làm nhiều thứ khác mà chúng ta
không hề hay biết. Android/PowerOffHijack ảnh hưởng các máy chạy Android 5.0
trở lên và cần đến quyền root để hoạt động. Tính đến ngày 18/2 năm nay, có
khoảng 10.000 máy đã bị nhiễm. Nhưng chúng ta không nên quá lo lắng, bởi
malware này chỉ bị phát tán qua một kho app Trung Quốc chứ không có mặt trên
Google Play.
2.2.5. App nhìn có vẻ "vô hại" nhưng lại chứa mã độc
Loại này gần gần giống như loại đầu tiên mà chúng ta đã đề cập đến ở trên,
nhưng nó không chỉ nhắn tin và làm chúng ta mất tiền cước, thay vào đó những
malware dạng này còn có thể lấy trộm thông tin và chạy đủ thứ loại mã độc mà
chúng ta không hề hay biết. Mới đây có một vài app chơi game solitaire, app thử
IQ và một app nói về lịch sử bị Google gỡ bỏ khỏi Play Store vì những hành vi nói
trên. Điều đáng nói là thời gian đầu chúng chạy bình thường, êm đẹp và vui vẻ chứ
không có dấu hiệu gì nguy hiểm cả. Thậm chí đã có đến 5 triệu lượt tải về, một con
số rất lớn. Mãi đến một thời gian sau nó mới kích hoạt một thông báo lên, và nếu
chúng ta click vào thì app sẽ mở ra một trang web giả mạo nhằm đánh cắp thông
tin của chúng ta. Trong một số trường hợp khác, chúng có thể kích hoạt việc tải về
và cài đặt một số phần mềm trái phép.
2.2.6. Tống tiền
Tội phạm mạng tại Hàn Quốc đã tạo ra những hồ sơ trên mạng xã hội giả
mạo những cô gái hấp dẫn, và chúng đã bị sử dụng để dụ người ta thực hiện cách
hành vi khiêu dâm online. Sau đó tin tặc sẽ tống tiền những người này bằng cách
đe dọa sẽ tung video hoặc báo cho người thân, bạn bè của nạn nhân biết. Nhưng
làm sao tin tặc biết được thông tin của những người đó. Đây chính là "đất dụng
võ" của malware.
Trong lúc chat với người dùng, tin tặc giả vờ rằng chất lượng âm thanh có
vấn đề và dụ người dùng tải về một app chat khác. Thực chất app này chính là
malware và nó sẽ đột nhập vào danh bạ, lấy cắp thông tin rồi gửi về cho kẻ tống
tiền.
2.2.7. Lỗ hổng Android Installer Hijacking
Nhiều thiết bị Android có thể bị khai thác bằng lỗ hổng này. Nói ngắn gọn,
Android Installer Hijacking diễn ra khi chúng ta download một app "lành mạnh"
nhưng trình cài đặt bị can thiệp để lén cài những app mà chúng ta không muốn.
Quá trình lén cài diễn ra khi chúng ta đang đọc permisson(quyền truy cập) của app,
và thông qua đó tin tặc có thể cài thêm malware hoặc cấp các permission(quyền
truy cập) cần thiết cho malware. Installer Hijacking thường gặp ở các kho app của
Trang 35
bên thứ ba, và với các thiết bị chạy Android 4.3 trở xuống. Nếu chúng ta sử dụng
Google Play Store thì không phải lo về vấn đề này.
Trang 36
Chương 3.
PHƯƠNG PHÁP PHÂN TÍCH MÃ ĐỘC
Giới thiệu chương:

Để đánh giá một ứng dụng android có an toàn hay không thì cần có các giải pháp
cụ thể. Chương này sẽ đi sâu vào các giải pháp phân tích mã độc từ đó tìm ra cách
phát hiện mã độc trên ứng dụng android.
Có hai giải pháp phân tích mã độc
- phương pháp phân tích tĩnh
- phương pháp phân tích động
3.1. Phương pháp phân tích tĩnh
Phân tích tĩnh bằng cách decompile một ứng dụng Android thành smali hoặc java
code để tiến hành theo dõi sự hoạt động của ứng dụng cũng như những tương tác
của nó với hệ thống.
Ta sử dụng các công cụ: IDA 6 pro, APK inspector, Dex2jar, Dexdump, APKtool
Ứng dụng Android thường được viết bằng java và thực thi trên Virtual Machine,
byte code chạy trên Dalvik Virtual Machine (DVM) được chuyển đổi từ JVM byte
code truyền thống sang dex-format(.dex file)bởi convertion tool dx ( lưu trữ tại
android-sdk/platforms/android-X/tools/lib với các phiên bản trước đây, ở phiên bản
Android SDK mới nhất được lưu tại android-sdk/platform-tools/lib/).
Để thực hiện phân tích tĩnh ta phải decompile ứng dụng thành mã code có thể đọc
được: thành mã JVM bytecode hoặc Smali code.
Chúng ta cùng nhau phân tích ứng dụng dưới dạng JVM bytecode vì sử dụng nó
dễ hơn nhiều so với việc phân tích với Smali code.
Để phân tích dưới dạng JVM bytecode ta kết hợp sử dụng Dex2jar và JD-GUI:
- Dex2jar dùng để convert từ .Dex sang JVM bytecode (.jar)
- JD-GUI dùng để đọc JVM bytecode(.jar) từ đó chúng ta có thể hiểu được cách
thức hoạt động và các biến trong chương trình.
Bước 1: Lấy tập tin .apk và decompile
Ta sử dụng 1 mẫu Android malware để phân tích.
Trang 37
Thông tin mẫu:

SHA256:550b3c6b8766fca70d3a8f7d5e00cf50527a3df208e6e2812e
7eab8f1bd55ec2
File name: 550b3c6b8766fca70d3a8f7d5e00cf50527a3df208e6e2812e
7eab8f1bd55ec2.apk
Android Packages được đóng gói với thuật toán ZIP nên ta có thể giải nén file
APK như giải nén file ZIP thông thường (sử dụng 7zip hoặc với winrar thì chỉ cần
đổi tên file .apk thành .zip). Commands convert file classes.dex trong thư mục giải
nén với dex2jar tool , chuyển đổi dex-format thành file jar chưa java byte code
.class. Chúng ta vào cmd thực hiện:
Kết quả sau khi convert sẽ được lưu tại thư mục người dùng hiện tại trên máy tính
với tên classes-dex2jar.
Bước 2: phân tích ứng dụng
Ta sử dụng công cụ JD-GUI(java decompiler) để mở file classes-dex2jar.
Hình 3.1. Giao diện khi mở file classes-dex2jar

Quá trình phân tích tĩnh thường hướng tới các từ khóa gắn với tên của các hàm
API có tác động xấu tới người dùng như : ‘Send,Get’ hoặc ‘license’ và
‘donate’…đối với dòng mã độc tống tiền. Phân tích dựa theo các Receiver và
service : tiến hành phân tích các hành vi thực hiện bên trong các hàm onReceiver
hoặc onStartcommand để lần theo các lời gọi hàm và tìm ra các hành vi độc hại.
Trang 38
Hình 3.2. Giao diện tìm kiếm các từ khóa

Với từ khóa ‘send’ ta tìm được lời gọi hàm sendSMS trong file
com.dloader.main.class.
Hình 3.3. Hàm gọi đến tin nhắn SMS
Trang 39
Lần ngược theo dấu vết gọi hàm sendSMS ta tìm được trình tự gọi hàm như sau :
onCreate -> loadconfig() -> initData() -> showDialogConfirm -> handleAction
-> handleActionASMS -> sendSMS.
Kết luận là mẫu ứng dụng mã độc mà ta phân tích gửi tin nhắn tới đầu số tính phí.
Như vậy trong phần này đã tìm hiểu về phương pháp phân tích tĩnh cùng các kỹ
thuật để lấy được mã nguồn của một ứng dụng bất kỳ. Qua đó có thể kiểm tra được
ứng dụng đó có chưa các mã độc, các dòng lệnh có hại cho người dùng, . . . Tiếp
theo sẽ trình bày về kỹ thuật phân tích động. Hướng tiếp cận của phương pháp này
là cài đặt trực tiếp ứng dụng lên môi trường đánh giá, thực hiện duyệt tất cả các
chức năng của chương trình đồng thời sử dụng các công cụ để giám sát, thay đổi
dữ liệu của chương trình đánh giá băng cách duyệt tất cả các chức năng của
chương trình, sử dụng các công cụ Intercept Proxy, Wireshark để giám sát tất cả
kết nối giữa ứng dụng và máy chủ, xác định lỗi của chương trình.
3.2. Phương pháp phân tích động
Quá trình phân tích động nhằm giám sát và kiểm tra hành vi của ứng dụng(mã
độc), như ứng dụng đó được thực thi trên hệ thống (thiết bị android), bằng cách sử
dụng Virtual Machine hoặc Sandbox. Quá trình phân tích bao gồm việc thực thi
ứng dụng độc hại và theo dõi system log, network log.2.1. Phát hiện và phân tích
mã độc động thông qua việc khai phá thông tin từ các khối điều khiển tiến trình
của hệ điều hành Linux
3.2.1.1. Điều tra phân tích hành vi của tiến trình lành tính và độc hại
Một hệ thống được xây dựng một cách trực quan để trả lời một câu hỏi khó: Tại
sao genetic footfrint của một tiến trình độc hại lại khác tiến trình lành tính. Các
cuộc điều tra đang tiến hành để phân tích hành vi thực hiện của lành tính và của
phần mềm độc hại. Cả tiến trình lành tính và độc hại được loại chọn từ các loại
khác nhau. Các tiến trình lành tính thuộc về soạn thảo văn bản, tiện tích hình ảnh
và các loại tiện ích hệ thống trong khi tiến trình phần mềm độc hại thuộc về
Trojan, worm và các loại virus. Một mô tả ngắn gọn của từng loại tiến trình được
cung cấp sẽ tương ứng với hành vi và genetic footfrint của chúng.
 Các tiến trình lành tính
Hwclock (CLK). Tiện ích này truy cập vào đồng hồ phần cứng của hệ thống. Nó
hiển thị thời gian hiện hành và chịu trách nhiệm cho việc đồng bộ hóa các hệ thống
và phần cứng đồng hồ theo định kỳ.
ED. Nó là một trình biên tập văn bản dòng lệnh có thể tạo, hiển thị và chỉnh sửa
tập tin văn bản. Khi nó được gọi với một cái tên, nó sao chép văn bản gốc vào bộ
nhớ đệm và tất cả các thay đổi được thực hiện tiếp theo cho đến khi được lưu một
cách rõ ràng.
ppmtoterm (PPMT). Đây là một tiện ích hình ảnh dòng lệnh dùng để chuyển đổi
một hình ảnh .ppm sang hình ảnh ANSI ISO 6429 ASCII và hiển thị nó trên các
thiết bị đầu cuối của Linux OS. Nó thực hiện xấp xỉ màu, đo khoảnh cách tối thiểu
Trang 40
giữa Descartes vector RGB và tạo ra bảng màu nally. Không giống như các trình
biên tập văn bản ED , nó thực hiện tất cả các bước nêu trên một cách tự động.
 Các tiến trình phần mềm độc hại
Linux.Backdoor.kaiten.a (TKTN). Nó là một trojan horse [Symantec,2010a] mở
ra một backdoor trên máy tính nạn nhân và sử dụng máy trạm IRC để kết nối đến
máy chủ IRC trên cổng TCP 6667. Nó kết nối với một kênh IRC định trước và
nghe lệnh, sau đó được sử dụng để thực hiện các hoạt động độc hại trên máy nạn
nhân. Nó thực hiện các hoạt động độc hại sau đây:
(1) khởi động các cuộc tấn công DDOS bằng cờ SYN và các gói UDP
(2) tải và thực thi các kịch bản từ xa và các tập tin
(3) thay đổi biệt danh của khách hàng
(4) thay đổi máy chủ
(5) Đánh lừa một địa chỉ IP
(6) Huỷ tiến trình đang chạy
(7) tạo flood
(8) thay đổi tập tin hệ thống : ect/rc/d/rc.local và ect/rc.conf .
Hình 3.4. phân tích quá trình lành tính và độc hại
 Điều tra phân tích

Các điều tra phân tích được trình bày trên ba tham số của Linux task_struct để
xây dựng một cái nhìn sâu sắc vào các hành vi thực hiện của tiến trình lành tính và
độc hại. Mục đích là để có được sự hiểu biết rằng làm thế nào các hành vi thực
Trang 41
hiện của một tiến trình tương ứng với các thông số task_struct. Các thông số mẫu
là:
(1) số khung trang sở hữu của một tiến trình
(2) số chuyển đổi bối cảnh không tình nguyện của tiến trình
(3) số chuyển đổi bối cảnh tình nguyện của tiến trình.
Một phân tích chuỗi thời gian của các tiến trình này được thực hiện. Để hiển thị
các sơ đồ khác nhau, chỉ có hai tiến trình được thể hiện trong một sơ đồ. ( Nó cho
thấy rằng một khi các thông số của bốn tiến trình được vẽ trên một sơ đồ duy nhất,
thì tính rõ ràng của sơ đồ bị suy giảm nghiêm trọng).
Khung trang thuộc sở hữu của một tiến trình. Thật thú vị khi để ý hai hình
3.4(a) và 3.4(d). Chương trình lành tính thì cấp phát bộ nhớ khi bắt đầu thực hiện
và khi sử dụng không thay đổi trong khoảng thời gian vài phần nghìn giây. Còn
phần mềm độc hại thì muốn gây thiệt hại càng nhanh càng tốt, do đó, sử dụng bộ
nhớ của nó cho thấy sự dao đông.(để ý thấy bộ dữ liệu của 3 phần mềm độc hại
mẫu được chọn hoàn thành trong ít hơn 10ms. Hơn nữa, tiến trình lành tính – CLK
và ED – hiển thị một sơ đồ sử dụng bộ nhớ thống nhất trong khoảng thời gian nhỏ .
Trong khi phần mềm độc hại VX23 cho thấy một sự dao động. Khi mà WSRO bắt
đầu gây hại , sử dụng bộ nhớ của nó cũng cho thấy sự dao động trong thời gian
nhỏ.
Chuyển đổi bối cảnh tình nguyện và không tình nguyện. Một chuyển đổi bối
cảnh tình nguyện có nghĩa là một tiến trình tuyên bố từ bỏ quyền kiểm soát các bộ
vi xử lý trước khi hết thời gian lượng tử được cấp cho nó. Mặt khác, nếu một lịch
trình can thiệp vào một tiến trình đang chạy trước khi hết thời gian lượng tử được
cấp cho nó thì đó gọi là chuyển đổi bối cảnh không tự nguyện.
Khi xem hình 3.4(b) và 3.4(c) các tiến trình lành tính chủ yếu thực hiện một cách
không tham lam, do đó chúng có số lượng bối cảnh chuyển đổi tình nguyện ngày
càng tăng còn số lượng chuyển đổi bối cảnh không tình nguyện gần như bằng
không. Mặt khác, khi nhìn vào hình 3.4(e) và 3.4(f) ta thấy các chương trình độc
hại chủ yếu hoạt động trong chế độ tham lam, kết quả là số lượng chuyển đổi bối
cảnh không tình nguyện ngày càng tăng còn số lượng chuyển đổi bối cảnh tình
nguyện gần như bằng không. Những phân tích trên cho thấy một cái nhìn sâu sắc
sơ bộ rằng Lunix task_struct có thể sử dụng để phân biệt tiến trình lành tính và độc
hại.
Trang 42
Hình 3.5. Biểu đồ so sánh tiến trình lành tính và độc hại
Để khái quát khẳng định đã đề cập ở trên, các biểu đồ của các tham số cấu trúc ba
công việc được vẽ của 20 tiến trình lành tính và độc hại trong hình 3.5. (lưu ý rằng
các tiến trình được chọn ngẫu nhiên từ bộ dữ liệu được chọn). Từ hình 3.5(a) và
3.5(b), nó cho thấy rằng các thông số hiwater_rrs của tiến trình lành tính có chênh
lệch lớn, bộ nhớ được cấp phát liên tục. Ngược lại, sơ đồ của tiến trình độc hại cho
thấy bộ nhớ được cấp phát vẫn không thay đổi. Hơn nữa, chương trình độc hại có
hiwater_rrs trại dài trên miền (0-250) ngắn hơn chương trình lành tính (0-2000).
Tương tự như vậy, hình 3.5(c) đến 3.5(f) chuyển đổi bối cảnh tình nguyện và
không tình nguyện của tiến trình lành tính và độc hại. Ta thấy tiến tình lành tính có
xu hướng chuyển đổi bối cảnh tình nguyện hơn tiến trình độc hại. Các hành vi
Trang 43
tương tự có thế được suy ra từ hình 3.5(e) và 3.5(f), nó cho thấy tiến trình lành tính
hiếm khi bị chặn bởi lịch trình của hệ điều hành. Các tiến trình độc hại có thị hiếu
chiếm giữ CPU cao hơn nên thường xuyên bị chặn. Ngoài ra , Nó còn cho thấy các
tiến trình độc hại chủ yếu kết thúc một cách nhanh chóng (trong vòng 200ms) và
phần lớn chúng có ít 50 chuyển đổi bối cảnh. Trong khi đó tiến trình lành tính có
đến 2000 chuyển đổi bối cảnh (hoặc nhiều hơn).
Có thể kết luận rằng các điều tra phân tích và biểu đồ đã xác định rằng: một số
thông số task_struct của linux đặc trưng cho một tiến trình lành tính hoặc độc hại.
3.2.1.3. Cấu trúc khung của cơ chế phát hiện mã độc động
Trong phần này, cấu trúc của cơ chế được trình bày bao gồm 3 phần: (1) tính
năng Logger, (2) tính năng phân tích và (3) tính năng phân loại. Trong phần dưới
trình bày một phương pháp để chọn các tính năng mà xác định các genetic
footfrint. Hơn nữa, một hệ thống phân tích được thực hiện trên các bộ tính năng để
chọn 1 một phân loại phù hợp . Cấu trúc của cơ chế được trình bày trong hình 3.6.
Hình 3.6. Sơ đồ khối của cấu trúc cơ chế phát hiện mã độc động
 Tính năng Logger
Công việc của tính năng Logger là định kỳ dump 118 trường cấu trúc task_struct
Linux. Một số thông số đáng chú ý nhất là Số khung trang , chuyển đổi bối cảnh
tình nguyện và không tình nguyện, số các trang bảng khóa , số lượng các trang lỗi,
bộ nhớ ảo được sử dụng, thời gian CPU trong hệ thống, chế độ của một tiến trình,
số lượng các trang bảng vv…Các thông số được Logger sử dụng để để tùy biến các
cuộc gọi hệ thống hạt nhân Linux. Các thông tin mong muốn được trích xuất ra từ
cấu trúc task_struct của một tiến trình sau mỗi phần nghìn giây trong 15 giây. Các
cuộc gọi hệ thống là một phần đặc hữu của hạt nhân, vì vậy chúng có thể truy cập
trực tiếp vào cấu trúc của hạt nhân. Hạt nhân Linux lưu giữ trạng thái của một tiến
trình trong một danh sách liên kết kép và một biến toàn cục của cấu trúc
task_struct tên là - current - cung cấp quyền truy cập vào các nhiệm vụ của tiến
trình hiện hành. Bằng cách này, các tiến trình trong danh sách liên kết tiếp theo
hoặc trước đó cũng bị truy cập vào. Một cuộc gọi hệ thống được tùy biến để theo
Trang 44
dõi tiến trình này bởi tên của nó có trong danh sách của hạt nhân Linux. Ngay sau
khi tìm được tiến trình cần tìm, nó có thể ghi các trường cấu trúc task_struct vào
một tệp tin riêng biệt và đặt tên như tiến trình đang chạy. Thông qua cuộc gọi hệ
thống này, tối đa có 15000 mẫu cho mỗi tiến trình được dump. Các tiến trình đó
hoàn thành trước, tất nhiên có số lượng mẫu tương ứng với tổng thời gian thực
hiện của chúng. Phương pháp này được sử dụng để dump các thông số task
structure cho 105 mẫu lành tính và 114 mẫu độc hại.
 Tính năng phân tích
Để tính năng có danh sách ngắn và tiềm năng phân loại cao, tính năng tiền xử lý
được thực hiện theo hai bước sau: (1) Xác định và lọc các trường không liên quan
đến hành vi của một tiến trình, và (2) thực hiện phân tích chuỗi thời gian của các
trường còn lại để xác định các tính năng với tiềm năng phân loại cao. Các trường
mà không phụ thuộc vào hành vi của một tiến trình là các trường không đổi, các
mã định dạng tiến trình, các cờ vv…; Do đó, điều quan trọng là phải loại bỏ chúng
khỏi bộ thiết lập của tính năng để chúng không làm lệch hướng phân tích. Trong
trường hợp của Linux có 23 thông số là các loại offsets, 9 là cờ và 50 là các hằng
hoặc số không cho thấy sự phân biệt , chỉ có 36 thông số là được dùng để sử dụng
trong bước hai.
Trang 45
Hình 3.7. Các thống kê các thông số trong danh sách ngắn
Những genetic footfrint được tạo ra và các tính năng cuối cùng được thế hiện
trong bảng 3.2. Bây giờ chúng ta tập trung phân loại theo ba yêu cầu: (1) số lần thử
nghiệm thấp, (2) tỷ lệ phát hiện cao và (3) tỷ lệ báo động sai thấp.
Bảng 3.1. Mô tả về các trường cấu thành genetic footfrint
 Tác động của việc tăng thời gian phát hiện vào tính chính xác của phân loại
Quan sát trong bảng 3.3 ta thấy khi thời gian phát hiện tăng 10-30 độ chính xác
tổng thể được cải thiện 1-2%. Hơn nữa khi thời gian tăng 30-100 độ chính xác
cũng tăng theo.
Trang 46
Sở dĩ như vậy vì phần mềm độc hại muốn gây thiệt hại càng nhanh càng tốt ,
trong các số liệu được lựa chọn cho thấy phần mềm độc hại hoàn thành trong ít
hơn 100ms và hầu hết bắt đầu gây hại ngay khi bắt đầu khởi động. Kết quả là
chúng có thể bị phát hiện trong vòng 30ms.
 Phát hiện tiến trình kiểu backdoor
Khi xem xét các hành vi của backdoor , chúng có thể bắt đầu hoạt động nguy
hiểm đầu tiên sau 1000ms. Hãy nhớ là kỹ thuật phát hiện không chỉ kiểm tra 1 lần
đầu tiên vào lúc bắt đầu tiến trình mà nó phải liên tục trượt “window” để gọi bộ
phân loại. Kết quả là hệ thống sẽ phát hiện được sự bất thường trong mỗi 30ms khi
khởi động (ví dụ 1 kích thước “window” là 30ms). Như đã thấy trong hình 2.4(l)
tham số exec_vm của một linux backdoor Excedoor hoạt động như các tiến trình
lành tính cho đến thời gian 3148 thì bắt đầu gây hại.
 Mức báo động giả đề xuất của hệ thống
Được mô tả trong bảng 3.3. Đối với kích thước cửa sổ là 100ms FAR của J48 và
J-Rip là 4% và 0%, giảm 2-6% nếu chọn kích thước của sổ là 10ms. Điều này cho
thấy rằng , 10ms kích thước tương đối nhỏ đối với cửa sổ và trong khoảng thời
gian này, hành vi thực sự của tiến trình không thể được thực hiện. Nhầm lẫn thấp
rất quan trọng trọng khi sử dụng. Vì nếu mức độ nhầm lẫn cao thì người dùng sẽ
thấy khó chịu khi ứng dụng hợp pháp của họ thường bị dừng lại.
 Phát hiện chương trình độc hại nhỏ
Thống kê cho thấy rằng, 17 (15%) chương trình mã độc kết thúc dưới 100ms, 11
chương trình mã độc kết thúc dưới 30ms và 3 chương trình mã độc kết thúc dưới
10ms. Chúng trở thành một thách thức thực sự để phát hiện ra chúng khi chúng
hoạt động. Thống kê cho thấy trong 17 chương trình mã độc hoàn thành dưới
100ms thì có 3 phân loại sai, 1 trong 3 là mã độc hoàn thành dưới 10ms (nó trở
thành trở ngại khi hệ thống đưa ra quyết định trước khi chấm dứt một mã độc hại).
Kết quả là , DR cho tệp dữ liệu đầy thử thách này là 93,7% điều này chứng minh
rằng kỹ thuật được đề xuất có thể phân loại được những mã độc kết thúc nhanh.
 Lượng thời gian hệ thống xử lý cho kỹ thuật được đề xuất
Trong một hệ thống chạy trực tuyến , đo lượng thời gian hệ thống xử lý là rất
quan trọng. Tổng lượng sử dụng là tổng thời gian các tính năng logging và testing.
Thời gian training là không quan trọng vì nó chỉ xảy ra một lần mỗi giờ. Thời gian
tính năng logging là 40 micro giây cho mỗi lần (nó bao gồm thời gian chuyển đổi
bối cảnh là 6 micro giây). J48 và R-Rip mất 18ms và 30ms cho giai đoạn training.
Mất 45 và 100 micro giây cho testing. Nếu thời gian logging được thêm vào thời
gian testing thì J48 và J-Rip mất 85 và 140 micro giây cho mỗi lần. Kết quả này là
đủ để những module được nhúng trong nhân Linux có thể phân tích và phát hiện
trực tuyến.
 So sánh tính chính xác của đề án đề xuất với các đề án dựa vào các giải
pháp khác.
Trang 47
Bảng 3.2. So sánh các kỹ thuật khác nhau dựa vào trình tự hệ thống
Các kỹ thuật được lựa chọn để so sánh là J48 , JRip, Bayesnet và IMAD đều là
các kỹ thuật dựa vào các cuộc gọi hệ thống để phân loại phần mềm độc hại và lành
tính.
IMAD là chương trình phát hiện phần mềm độc hại thời gian thực hiêu quả. Nó
sử dụng n-gram và tối ưu hóa quá trình học hỏi ( sử dụng một thuật toán di truyền)
cho chuỗi cuộc gọi hệ thống có mặt trong cả hai tiến trình lành tính và độc hại. Nó
chỉnh các thông số khác nhau để tăng tính chính xác của phân loại.
Để đánh giá những kỹ thuật này , chúng ta thực hiện chúng trên hệ điều hành
linux và theo dõi quá trình thực hiện. Độ chính xac (DA) và tỷ lệ báo động giả
(FAR) của các kỹ thuật được trình bày trong bảng 3.4.
3.2.2. Công cụ , mã nguồn hỗ trợ
3.2.2.1. AASandbox
Ra mắt vào tháng 10 năm 2010 do Blasing là người đầu tiên trình bày một nền
tảng phân tích động cho các ứng dụng Android. Nó sử dụng phân tích tĩnh để quét
mô hình của phần mềm độc hại và phân tích động để can thiệp vào ghi nhận các
tương tác ở mức thấp. AASandbox sử dụng các dấu vết của các cuộc gọi hệ thống
để phát hiện các ứng dụng đáng ngờ. Không may là không có phần mềm độc hại
được biết sẵn nào của Android có sẵn tại thời điểm để đánh giá kỹ thuật này.
AASandbox dường như bị bỏ dở đến ngày nay.
3.2.2.2. TaintDroid
Cũng trong tháng 10 năm 2010, Enck giới thiệu TaintDroid : một bản mod của
hệ điều hành Android dùng để theo dõi các vết nhơ trong thời gian chạy để phát
hiện dò rỉ thông tin riêng tư. Theo thời gian, nó được thông qua như một bổ sung
hữu ích cho việc phân tích động các ứng dụng trên Android. TaintDroid được thực
hiện như một sửa đổi của Dalvik VM nên nó không theo dõi được vết nhơ trong
mã nguồn gốc và có tỷ lệ sai cực cao với 35%.
Trang 48
Hình 3.8. Kiến trúc của TaintDroid

3.2.2.3. DroidBox
DroidBox được phát triển bởi Patrik Lantz như một phần của Google summer
of code (GSoC) . Nó kết hợp taintdroid với những thay đổi của các thư viện lõi của
Android. Các sửa đổi của hệ điều hành Android được DroidBox ghi lại trong thời
gian chạy ứng dụng.
- đọc và ghi file
- Cryptography API hoạt động
- mở kết nối mạng
- lưu lượng mạng ra
- thông tin dò rỉ thông qua mạng, các tập tin và tin nhắn SMS ( sử dụng
taintdroid)
- tìm cách để gửi tin nhắn
- các cuộc gọi điện được thực hiện
Nó cũng cung cấp trực quan các kết quả phân tích , thực hiện và cài đặt ứng dụng
tự động.
3.2.2.5. Andrubis
Vào tháng sáu năm 2012, hệ thống bảo vệ quốc tế Lab phát hành Andrubis: một
nền tảng phân tích động các ứng dụng Android. Andrubis là người đầu tiên cung
cấp một giao diện web công bố công khai, nơi người dùng có thể gửi các ứng dụng
Trang 49
Android lên để phân tích động. Khi phân tích xong, nó sẽ gửi một báo cáo XML có
chứa các hành vi và dấu vết tĩnh của ứng dụng yêu cầu. Phiên bản đầu tiên của nó
được dựa trên sự thay đổi của thư viện lõi Droibox và được xây dựng trên đầu của
Android 2.1. Andrubis sau đó được cập nhật để chạy theo Android 2.3.4 và sử
dụng VMI để chặn các cuộc gọi hệ thống được thực hiện bởi mã nguồn gốc.
3.3. So sánh giữa phân tích tĩnh và phân tích động
Cả hai phương pháp này cùng có mục đích là giải thích cách hoạt động của mã
độc, tuy nhiên công cụ, thời gian làm việc và kỹ năng cần có thì lại rất khác nhau.
- Phân tích tĩnh thường đòi hỏi người người phân tích xem xét kỹ mã của mã
độc (đã được chuyển sang dạng có thể hiểu được như java , C hay assembly), hiểu
được luồng thực thi và các hành vi của nó thông qua mã đã dịch ngược.
- Phân tích động là phân tích cách hoạt động của mã độc khi nó được thực thi,
nó kết nối đến đâu, lây lan thế nào, cài đặt những gì vào hệ thống, thay đổi thành
phần nào, hoạt động ra sao.
3.3.1. Ưu nhược điểm của phân tích tĩnh và phân tích động
3.3.1.1. Phân tích tĩnh
 Ưu điểm
- Không thực hiện chạy mã độc, giảm thiểu nguy cơ lây lan và phá hủy hệ thống
- Cung cấp cho người phân tích cái nhìn hết sức chính xác về những gì mã độc
làm.
 Nhược điểm
- Khó khăn khi phân tích hết mã độc những loại mã độc phức tạp
- Mã độc được mã hóa, làm rối code thì rất khó để phân tích
- Các mã độc chỉ thực hiện hành vi khi chạy mã nguồn thì khó phân tích
3.3.1.2. Phân tích động
 Ưu điểm
- Quá trình phân tích diễn ra nhanh hơn , dễ dàng hơn
- Giám sát được các hành động của mã độc thông qua việc chạy mã độc
- Xác định được ảnh hưởng của mã độc lên hệ thống android
 Nhược Điểm
- kỹ thuật phân tích động thường phụ thuộc và emulator, trong khi đó có một số
mã độc có khả năng kiểm tra môi trường có phải là emulator hay không từ đó
thay đổi hành vì khác khi chạy trên emulator.
Trang 50
- Việc lựa chọn vị trí gắn tracer cũng ảnh hưởng nhiều đến độ chính xác trong
việc phân tích. Nếu tracer gắn ở lớp cao thì khả năng thu thập hành vi bị giới
hạn. Ngược lại, nếu gắn tracer ở các mức thấp thì thông tin thu thập được nhiều
nhưng gây tốn tài nguyên và thời gian.
Trang 51
Chương 4.
XÂY DƯNG CHƯƠNG TRÌNH PHÂN TÍCH MÃ ĐỘC DỰA
TRÊN MÃ NGUỒN TRACEDROID
4.1. Tổng quan

Do điều kiện về thời gian thực hiện đề tài ngắn, nên sinh viên xây dựng kịch bản
chỉ mang tính chất thử nghiệm về một số cái mà sinh viên nghiên cứu được. Thử
nghiệm gồm 2 phần ứng dụng dùng để gửi file apk nghi ngờ là mã độc lên sever và
sever tracedroid dùng để phân tích file apk nghi ngờ là mã độc. Sau khi phân tích
xong sever sẽ gửi các bản log phân tích về Mail của người gửi. Sau khi nghiên cứu
sinh viên đã phân tích được mã độc trên hệ điều hành Android dựa trên Tracedroid
ở mức độ thử nghiệm một vài dạng tấn công phổ biến trên Android.
4.2. Mô hình thử nghiệm
Hình 4.1. sơ đồ thử nghiệm sử dụng tracedroid
Tracedroid cho phép tải lên bất kỳ tệp tin android APK (ví dụ ứng dụng android
nghi ngờ là mã độc) để phân tích động. Tracedroid ghi lại hành vi mà ứng dụng
thực hiện, chẳng hạn như thông tin liên lạc của mạng, giao diện người dùng, các
cuộc gọi hệ thống và mã java được thực thi. Để kích hoạt hành vi thực tế của ứng
dụng, Tracedroid giả lập một vài hành động, chẳng hạn như người dùng tương tác,
các cuộc gọi đến và tin nhắn SMS, vv. Điều này sẽ làm lộ hầu hết ý đồ độc hại của
1 ứng dụng (nếu có).
Trang 52
4.3. Kiến trúc của chương trình tracedroid
Hình 4.2. Sơ đồ khối của Tracedroid

Bước 1:
Static Analysis: các file apk của các ứng dụng được phân tích tĩnh để tìm ra các
Activities và Services của ứng dụng. Tracedroid sử dụng các công cụ như
AndroGuard và Dex2jar để phân tích. Tracedroid checksum các mã MD5 để tìm
các mẫu có sẵn trong cơ sở dữ liệu.
Trang 53
Hình 4.3. Static Analysis

Bước 2:
Stimulation: Tracedroid kích thích mã độc hoạt động nhờ giả lập các hành động
của người dùng như khởi động lại, gọi điện, gửi tin sms, các cuộc gọi hàm hệ
thống vv , để làm lộ hành vi độc hại của ứng dụng.
Hình 4.4. Hành động chính của khối Stimulation

Monkey Exerciser: Tracedroid tác động vào các giao diện Guis giống như người
dùng bình thường để tìm ra các giao diện đánh lừa người dùng.
Trang 54
Hình 4.5. Monkey log của file mã độc Trojan.Camera_funny.apk

Bước 3:
Tracedroid extending Android’s Profiler implementation: tracedroid kiểm tra
các thông số của các khung stack, xem xét các hàm java , chuyển đổi các chứ ký và
mô tả , phân tích các giá trị trả về và các giá trị ngoại lệ. Tracedroid mô tả các
activities và services được gọi bằng hình ảnh trực quan.
Hình 4.6. Tracedroid kế thừa và mở rộng các Android Profiler
Trang 55
Hình 4.7. callgraph

Post-Processing: Tracedroid tìm kiếm các dấu vết hoạt động đáng ngờ của ứng
dụng.
Bước 4:
Log Output: tất cả các thông số, hình ảnh mà tracedroid đã phân tích được đều
được ghi vào các file riêng biệt và được nén lại rồi gửi cho người đã gửi file APK
cần phân tích qua email.
Trang 56
4.3. Thử nghiệm

Tôi sử dụng một file APK nghi ngờ là mã độc để phân tích để thấy rõ hơn cách
thức làm việc của tracedroid.
Hình 4.8. Màn hình gửi file APK ở client
Hình 4.9. File APK đã được phân tích xong
Mỗi file APK gửi lên để phân tích sẽ được cấp mã MD5, SHA1 và SHA256
dùng để phân biệt từng file . Ngoài ra có thể sử dụng mã MD5, SHA1 và SHA256
để tìm thông tin về file apk đã gửi như thời gian bắt đầu thời gian hoàn thành và
Trang 57
kết quả . Tất cả các thông tin phân tích được sẽ có trong file tar.gz trong mục
Results .
Hình 4.10. Các file dữ liệu tracedroid phân tích được

4.4. Kết quả đạt được
Ở đây tôi cho phân tích mã độc Trojan-camera_funny.apk khi Tracedroid phân
tích xong trong file analysis.log
[19:37:15,829 package] ++ Starting emulator
[19:37:15,829 package] Searching for two available TCP ports
[19:37:15,829 package] Trying port 5923 and 5924
[19:37:15,830 package] Starting the emulator with arguments:
['emulator', '-ports', '5923,5924', '-avd',
'android.2.3.3.5cLVDO', '-system',
'/tracedroid/tap/src/lib/../../lib/images/system.gapps.img', '-
no-audio', '-no-window']
[19:37:15,833 package] Waiting for the emulator to complete
boot procedure
[19:37:57,430 package] Connecting via TCP
[19:37:57,432 package] Unlocking the home screen
[19:37:59,748 package] ++ Figuring out time discrepancy
between host and guest
[19:37:59,985 package] Host - Guest = 0 s
[19:37:59,985 package] ++ Installing APK
[19:38:09,770 package] ++ Install took 9.79s
[19:38:09,771 package] ++ Starting logcat
[19:38:09,794 package] ++ Starting network capture
[19:38:09,809 package] ++ Enabling VM tracing
[19:38:10,295 package] ++ Starting clock
Trang 58
[19:38:10,295 package] - Looking at action: boot

[19:38:10,295 package] ++ Simulating boot
[19:38:10,295 package] +++ Broadcasting BOOT_COMPLETED
[19:38:17,184 package] - Looking at action: incoming_sms
[19:38:17,188 package] ++ Simulating incoming_sms
[19:38:17,188 package] +++ Simulating an incoming text message
[19:38:17,188 package] Sending command: sms send 4224 incoming
text message
[19:38:17,188 package] Received: OK
[19:38:21,192 package] - Looking at action: outgoing_sms
[19:38:21,193 package] ++ Simulating outgoing_sms
[19:38:21,193 package] +++ Simulating an outgoing text message
[19:39:14,397 package] - Looking at action: incoming_call
[19:39:14,409 package] ++ Simulating incoming_call
[19:39:14,409 package] +++ Simulating an incoming call
[19:39:14,409 package] Sending command: gsm call 0624424224
[19:39:14,410 package] Received: OK
[19:39:18,414 package] +++ Accepting the call
[19:39:18,414 package] Sending command: gsm accept 0624424224
Kết luận thử nghiệm:

Ta thấy mã độc đã tìm và tạo kết nối thông qua hai cổng tcp mà nó tìm được là
5923 và 5924. Sau đó nó dùng tài khoản Guest đăng nhập vào hệ thống cài đặt
chương trình và chiếm được quyền root của hệ thống. Sau đó nó cài một chương
trình có giao diện như một chương trình hợp pháp để đánh lừa hệ thống và sau đó
cấu hình để hệ thống tự động gửi tin nhắn đến đầu số tính phí 4224 trừ tiền của
khách hàng có số điện thoại là:0624424224 mà khách hàng không biết.
Trang 59
KẾT LUẬN
Sau khi thực hiện nghiên cứu, thực hiện đề tài thu được các kết quả như sau:
- Tìm hiểu được một cách tổng quan về hệ điều hành Android và các kiến trúc
bảo mật trong hệ điều hành Android
- Tìm hiểu tổng quan về các loại mã độc có trên hệ điều hành Android
- Nghiên cứu được một số phương pháp phân tích mã độc tĩnh và phân tích được
mã độc thông qua phương pháp phân tích động.
- Xây dựng được phương pháp lọc mã độc trên hệ điều hành Android dựa trên
công cụ Tracedroid
Hướng nghiên cứu tiếp theo:
- Nghiên cứu kỹ hơn về mã độc trên môi trường Android và các kỹ thuật phát
hiện mã độc
- Nghiên cứu sâu hơn về Tracedroid
- Xây dựng một số module lọc mã độc nhằm tăng tính hiệu quả và tốc độ lọc mã
độc trên hệ điều hành Android theo thời gian thực.
Trang 60
TÀI LIỆU THAM KHẢO
[1] Victor Vander Veen. Dynamic Analysis of Android Malware. VU University

Amsterdam(2013).
[2] Farrukh Shahzad. Utilizing Structural & In-execution PCB information
Analysis for Malware Detection on Linux based Smartphones & Computer.
National University of Computer and Emerging Sciences(2014).
[3] D.Guillermo Suarez-Tangil. mining structural and behavioral patterns in smart
malware. Universidad Carlos III de Madrid(2014).
[4] Android (operating system), Hanoi , 2-2016.
< http://android.com.>
[5] Nguyễn tín. Phân tích mã độc trên nền tảng android, Hanoi, 2-2016.
< http://trungtin.info/phan-tich-ma-doc-tren-nen-tang-android >
[6] Lenny Zeltser. 8 Articles for learning Android mobile malware Analysis,
Hanoi,2-2016.
< https://digital-forensics.sans.org/blog/2011/06/09/android-mobile-malware-
analysis-article >
[7] Nguyen Minh Duc. Phân tích mã độc trên android và dự đoán xu hướng năm
2015, Hanoi, 2016.
< http://securitydaily.net/phan-tich-ma-doc-tren-android-va-du-doan-xu-huong-
nam-2015 >
Trang 62

Ma Doc Android

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ma Doc Android

Uploaded by

Copyright:

Available Formats

BAN CƠ YẾU CHÍNH PHỦ

HỌC VIỆN KỸ THUẬT MẬT MÃ

AN TOÀN HỆ ĐIỀU HÀNH

Ngành: Công nghệ thông tin

Sinh viên thực hiện:

Cán bộ hướng dẫn :

Tp HCM ngày tháng năm

Danh mục các từ viết tắt ........................................................................................... iii

Từ viết tắt Nội dung

1.1 Tổng quan về Hệ điều hành Android

1.3.1. Tổng quan về kiến trúc hệ thống Android

1.3.3. Hộp cát(sandbox) của Android.

Hình 1.2. Định nghĩa cho AID trong hệ thống

Hình 1.3. Quyền tập tin hệ thống

Hình 1.5. Lập một Receiver trong manifest

Hình 1.6. Dịch vụ

Hình 1.7. Sử dụng lệnh ps

Hình 1.8. Lệnh shell trên thiết bị

Bảng 1.2. Các dịch vụ

Bảng 1.3. Một số bổ sung thay đổi về nhân hệ thống.

Hình 1.9.Dòng chảy liên lạc của Binder

Hình 2.8. Kiến trúc đăng nhập hệ thống Android

Giới thiệu chương:

Đánh cấp thông tin cá nhân 51,3%

Gửi tin nhắn trái phép (IMEL,..) 30,1%

Botnet(spam, thư rác,..) 23,5%

Truy cập Root 18,3%

Tải từ Google-Play 11,3%

Cài đặt các ứng dụng khác 10,4%

Đánh cấp định vị của người dung 8,7%

Cài đặt các ứng dụng hỗ trợ hacker 7,8%

Trojans (tiếp cận các dịch vụ ngân hàng trực 3,5%

2.1.2. Các loại phần mềm độc hại

Hình 2.2. Biểu đồ Andriod Malware

Hình 2.3. biểu đồ về hành vi và mức độ của ad_library

et al., 2013). Ví dụ như mã độc Rogue-AV://Android/AndroidDefeder.A

Hình 2.4. Ví dụ về mã độc Rogue-AV

độc hại này Trojan-Password://Android/FakeNetflix.A, mã độc này cố

Một ví dụ điển hình là Trojan-Downloader://Android/RootSmart.A, một phiên

Hình 2.6. Android “Master Key” vulnerability

Hình 2.7. Khai báo thẻ quảng cáo trong AndroidManifest.xml

Hình 2.9. Thông báo của Svpeng

2.2.4. Điện thoại tắt nhưng thật ra không tắt

Giới thiệu chương:

Thông tin mẫu:

Hình 3.1. Giao diện khi mở file classes-dex2jar

Hình 3.2. Giao diện tìm kiếm các từ khóa

Hình 3.3. Hàm gọi đến tin nhắn SMS

 Điều tra phân tích

Bảng 3.1. Mô tả về các trường cấu thành genetic footfrint

Hình 3.8. Kiến trúc của TaintDroid

4.1. Tổng quan

4.2. Mô hình thử nghiệm

Hình 4.1. sơ đồ thử nghiệm sử dụng tracedroid

4.3. Kiến trúc của chương trình tracedroid

Hình 4.2. Sơ đồ khối của Tracedroid

Hình 4.3. Static Analysis

Hình 4.4. Hành động chính của khối Stimulation

Hình 4.5. Monkey log của file mã độc Trojan.Camera_funny.apk

Hình 4.6. Tracedroid kế thừa và mở rộng các Android Profiler

Hình 4.7. callgraph

4.3. Thử nghiệm

Hình 4.8. Màn hình gửi file APK ở client

Hình 4.9. File APK đã được phân tích xong