Với thị phần ước tính từ 70% đến 80%, Android đã trở thành hệ điều hành phổ biến nhất cho điện thoại thông minh và máy tính bảng. 1 tỷ thiết bị Android trong năm 2017 và với hơn 50 tỷ lượt tải xuống các ứng dụng kể từ khi điện thoại Android đầu tiên được phát hành vào năm 2008, mở ra các hoạt động xấu của các hacker mũ đen ngắm vào các thiết bị Android. Các nhà nghiên cứu về mối đe dọa di động thực sự nhận ra sự gia tăng đáng báo động của phần mềm độc hại Android từ năm 2012 đến 2013 và ước tính số lượng ứng dụng độc hại được phát hiện hiện nằm trong khoảng từ 120.000 đến 718.000. Vào mùa hè năm 2012, cuộc tấn công Eurograbber tinh vi cho thấy phần mềm độc hại trên thiết bị di động có thể là một doanh nghiệp thiệt hại vô cùng lớn bằng cách đánh cắp khoảng 36.000.000 € từ các khách hàng ngân hàng ở Ý, Đức, Tây Ban Nha và Hà Lan.
Do thiết kế mở của Android, nó cho phép người dùng cài đặt các ứng dụng không nhất thiết phải bắt nguồn từ Google Play. Với hơn 1 triệu ứng dụng có sẵn để tải xuống qua kênh chính thức của Google là CHPlay và gần một triệu ứng dụng khác được chia sẽ bởi bên thứ ba, ước tính rằng có hơn 20.000 ứng dụng mới được phát hành mỗi tháng. Điều này đòi hỏi việc phân tích mã độc được đặt lên rất cao. Google đã đưa ra Bouncer vào tháng 2 năm 2012, một dịch vụ kiểm tra các ứng dụng được đăng tải lên Google Play Store để phát hiện phần mềm độc hại. Tuy nhiên, nghiên cứu đã chỉ ra rằng tỷ lệ phát hiện Bouncer MySpace vẫn còn khá thấp và có thể dễ dàng bỏ qua những phần mềm độc hại. Một nhóm lớn các nghiên cứu tương tự về phần mềm độc hại trên Android đã được đề xuất, nhưng không ai cung cấp được một giải pháp toàn diện để kiểm tra chính xác về các ứng dụng được đăng tải lên Google Play. Không chỉ vậy, việc phát triển không ngừng của các phần mềm cũng đi kèm với sự phát triển không ngừng của mã độc. Vì vậy việc phân tích, đánh giá chính xác một cách tự động các phần mềm trên nền tảng Android có phải là phần mềm độc hại hay không là việc vô cùng khó khan. Do đó việc phân tích mã độc thủ công luôn phải được nghiên cứu, phát triển. Việc này còn cung cấp các phương pháp để các phần mềm phân tích tự động phần mềm có độc hại hay không có thể hoạt động chuẩn xác hơn.
Do việc phân tích mã độc là một lĩnh vực vô cùng lớn và đòi hiểu thời gian và công sức cũng như những kiến thức về nhiều mảng khác nhau như các kiến thức liên quan về nền tảng hệ điều hành Android là Linux, kiến thức về mã độc nói chung, cách mã độc tồn tại, thực thi trên điện thoại thông minh nói riêng và sử dụng một số công cụ phát hiện, phân tích, gỡ bỏ mã độc sẽ trình bày ở phần sau như APKTOOL, Dex2Jar, ID-GUI, DroidBox,….Ngoài ra cũng cần phải có kiến thức về ngôn ngữ lập trình java, C, C++.
Cấu trúc của hệ điều hành Android
Cấu trúc của phần mềm Android được minh họa trong hình 2.1.Tầng Applications và Aplications Framework được viết bằng Java được biên dịch và thực thi bằng máy ảo Dalvik. Tầng Libraries được viết bằng Native C/C++ bao gồm cá thư viện được lóp bên trên gọi để thực thi. Tầng Kernel chính là firmware (Software for hardware) của các thiết bị Android bao gồm các driver.
Cấu trúc của phần mềm Android
Nhân Linux
Đây là một phần rất nhỏ nhưng lại vô cùng quan trọng trong một hệ điều hành. Phần lõi này chịu trách nhiệm tương tác với phần cứng, cung cấp các dịch vụ để khởi động lại hệ thống. Nó kiêm luôn cả việc quản lí CPU và bộ nhớ của máy tính. Mọi thao tác với phần cứng của thiết bị đều phải thông qua tầng này. Đối với mỗi một thiết bị Android khác nhau sẽ sử dụng một Kernel version khác nhau.
Tuy nhiên để có thể tạo ra một hệ điều hành phù hợp với điện thoại, phần Linux kernel đã được thay đổi bởi nhà phát triển. Đó là việc them vào các thư viện mới, API và các công cụ được thiết kế riêng biệt cho Android như wakelocks(cơ chế phát hiện các ứng dụng cần phải có thiết bị phù hợp), hệ thống quản lí bộ nhớ tích cực, Binder IPC diver,…nhưng sự thay đổi này là không nhiều.
Việc một số mã độc tấn công chiếm quyền root chính là kiểm soát phần kernel khiến cho các phần diệt mã độc không thể phát hiện ra được do không có quyền để kiểm tra.
Thư viện
Việc giao tiếp với kernel bắt buộc phải thông qua một số lời gọi API. Các API này được xây dựng sẵn và ở trong các thư viện. Các file thư viện (.dll) hầu hết là các thư viện của linux như OpenSSL2, WebKit3, Bzip24 … được sửa lại để hỗ trợ phần cứng ARM và Adnroid thực hiện các tác vụ trên nền tảng Linux.
Một số kĩ thuật của mã độc có thể tác động vào các thư viện này và thay đổi chức năng của các hàm này tùy theo mục đích của hacker.
Android runtime
Đây là một phần mềm trung gian bao gồm máy ảo Dalvik và một bộ Core Libraries. Máy ảo Dalvik chịu trách nhiệm thực thi các ứng dụng được viết bằng ngôn ngữ lập trình Java và được thảo luận chi tiết hơn trong phần sau. Các thư viện lõi (core libraries) là một triển khai API mục đích chung và có thể được sử dụng bởi các ứng dụng được thực hiện bởi Dalvik VM. Android phân biệt hai loại core libraries:
– Các thư viện dành riêng cho máy ảo Dalvik.
– Thư viện khả năng tương tác ngôn ngữ lập trình Java.
Bộ đầu tiên cho phép xử lý hoặc sửa đổi thông tin dành riêng cho VM và chủ yếu được sử dụng khi các bytecode cần được load vào bộ nhớ.
Bộ thứ hai cung cấp môi trường cho các lập trình viên Java và đến từ Apache Harmony Harmony5. Nó triển khai hầu hết các gói Java phổ biến như java.lang và java.util.
Applications Framework
Khung ứng dụng cung cấp khung cho các ứng dụng dưới dạng các gói Android. Hầu hết các thành phần trong lớp này được triển khai dưới dạng các ứng dụng và chạy các ứng dụng ở dạng nền trên thiết bị. Một số thành phần chịu trách nhiệm quản lý các chức năng cơ bản của điện thoại như nhận cuộc gọi hoặc tin nhắn văn bản hoặc giám sát việc sử dụng pin. Một vài thành phần đáng được chú ý hơn:
Activity Manager: Quản lý hoạt động (AM) là trình quản lý giống như quy trình theo dõi các ứng dụng đang hoạt động. Nó chịu trách nhiệm kill các quá trình nền (background process) nếu thiết bị hết bộ nhớ. Nó cũng có khả năng phát hiện các ứng dụng không phản hồi khi ứng dụng không phản hồi với sự kiện đầu vào trong vòng 5 giây (chẳng hạn như nhấn phím hoặc chạm vào màn hình). Sau đó, nó nhắc một hộp thoại Ứng dụng Không Phản hồi (ANR).
ANR dialog
Content Providers: Đây là một trong những khối xây dựng chính cho các ứng dụng Android. Chúng được sử dụng để chia sẽ dữ liệu giữa nhiều ứng dụng. Ví dụ như danh sách số điện thoại có thể được chia sẻ cho nhiều ứng dụng như zaloo, messenger…
Telephony Manager: Ứng dụng quản lí điện thoại cung cấp quyền truy cập vào thông tin về các dịch vụ điện thoại trên thiết bị như IMEI của máy, vị trí, quyền truy cập danh bạ, lịch sử cuộc gọi, quản lí các file trên thiết bị…
Location Manager: Trình quản lý vị trí cung cấp quyền truy cập vào các dịch vụ định vị hệ thống, cho phép các ứng dụng có được các bản cập nhật định kỳ của thiết bị Vị trí địa lý bằng cách sử dụng cảm biến GPS của thiết bị.
Ứng dụng
Các ứng dụng hoặc ứng dụng được xây dựng dựa trên framework của Adnroid và chịu trách nhiệm cho sự tương tác giữa người dùng và thiết bị. Người dùng bình thường sẽ chỉ có quyền thao tác với tầng này. Các ứng dụng được cài đặt sẵn cung cấp một số tác vụ cơ bản mà người dùng muốn thực hiện (gọi điện thoại, duyệt web, đọc email, v.v.), nhưng người dùng có thể tự do cài đặt các ứng dụng của bên thứ ba để sử dụng các tính năng khác (ví dụ: game, xem video, đọc tin tức, sử dụng điều hướng GPS, v.v.). Các ứng dụng Android sẽ được trình bày chi tiết hơn ở phần sau.
Máy ảo Dalvik
Java được biết đến với khẩu hiệu “viết một lần, chạy mọi nơi” (write once, run anywhere). Tính năng này của hệ sinh thái Java có được nhờ một tầng máy ảo đứng giữa tầng ứng dụng (viết bằng Java) và tầng hệ điều hành (nhiều loại khác nhau), gọi là máy ảo Java – JVM (Java Virtual Machine). Máy ảo Java chạy rất ổn định và đồng nhất trên các môi trường khác nhau. Google đã chọn Java làm ngôn ngữ phát triển ứng dụng cho hệ điều hành Android, tuy nhiên lại từ bỏ cả phiên bản Java di động (JME) lẫn máy ảo Java (JVM) để phát triển một máy ảo riêng – máy ảo Dalvik và tập thư viện Java chuẩn được viết lại và thu gọn hơn.
Ứng dụng Android được phát triển bằng ngôn ngữ Java, sau đó được biên dịch thành dạng mã nhị phân Java (Java bytecode). Các file nhị phân .class (tương thích với JVM) này sẽ được chuyển đổi thành 1 file nhị phân dùng cho máy ảo Dalvik – .dex (Dalvik EXecutable) trước khi được cài lên thiết bị. Các tập tin .dex được thiết kế để phù hợp hơn với các thiết bị hạn chế về bộ nhớ cũng như hiệu năng xử lý.
Kiến trúc
Hệ điều hành Android được thiết kế hướng đến rất nhiều các loại thiết bị khác nhau, từ những thiết bị giá rẻ, cấu hình thấp (low-end) đến những siêu phẩm đắt tiền (high-end). Bên cạnh đó, các ứng dụng Android phải được chạy trong “hộp cát” với độ bảo mật cao, hiệu năng tốt và ổn định, vì vậy việc sử dụng một máy ảo làm môi trường thực thi là điều tất yếu. Tuy nhiên việc sử dụng máy ảo thường sẽ làm giảm hiệu năng của hệ thống. Giải pháp máy ảo Dalvik của Google được đưa ra nhằm cân bằng giữa 2 điểm này:
Mỗi ứng dụng Android được chạy trong tiến trình riêng, với một thực thể (instance) của máy ảo Dalvik riêng. Dalvik được thiết kế để hệ điều hành có thể chạy nhiều thực thể của máy ảo một cách hiệu quả với file thực thi Dalvik (.dek file) được thiết kế để tối ưu hóa bộ nhớ cần sử dụng. Máy ảo Dalvik là máy ảo dựa trên thanh ghi (register-based), khác với máy ảo Java chạy dựa trên cấu trúc ngăn xếp (stack-based).
Máy ảo Dalvik sử dụng hạt nhân Linux cho các việc liên quan đến lớp dưới của hệ thống như quản lý tiểu trình (threading), quản lý bộ nhớ cấp thấp… Do mỗi ứng dụng chạy trên một thực thể máy ảo riêng, hệ thống Android không những cần tối ưu việc chạy nhiều máy ảo và còn phải giảm tối đa thời gian khởi tạo máy ảo mới. Phần dưới đây sẽ xem xét 4 điểm chính trong thiết kế máy ảo mà Google đã chọn lựa để đạt được hiệu năng và độ bảo mật cần thiết: cấu trúc file .dex, Zygote, cấu trúc dựa trên thanh ghi và bảo mật.
Định dạng file .dex
Trong môi trường Java truyền thống, mã nguồn Java được biên dịch thành dạng bytecode, ở đó mỗi class trong mã nguồn được biên dịch thành một file .class riêng. Trong hệ thống Android, mã nguồn Java cũng được biên dịch thành các file .class riêng. Tuy nhiên trước khi có thể được cài đặt lên thiết bị, các file này phải được chuyển đổi thành file thực thi Dalvik (.dex) bằng công cụ “dx” có trong Android SDK. File thực thi Dalvik có thể chứa nhiều class bên trong và mỗi ứng dụng Android chỉ chứa một file .dex duy nhất.
File thực thi Dalvik được thiết kế nhắm đến việc tối ưu bộ nhớ trên cơ sở chia sẻ (dùng chung) dữ liệu. Biểu đồ dưới đây phân biệt cấu trúc file .dex với file .class truyền thống.
Cấu trúc file của Java và file thực thi Dalvik
Cơ chế chính của file .dex cho việc tiết kiệm bộ nhớ là dùng chung các vùng nhớ chứa hằng số cho tất cả các class. Các vùng nhớ cho hằng số này được chia theo từng loại dữ liệu (hằng số chuỗi, tên trường, tên class, tên method…). Trong mã lệnh của các class bên dưới sẽ không cần ghi lại các tên/hằng số này mà chỉ chứa chỉ số (số nguyên) của nó trong vùng hằng số.
Đối với các file .class truyền thống, mỗi class file chứa vùng nhớ riêng cho các hằng số của class đó. Vùng nhớ này không đồng nhất vì nó chứa tất cả các loại hằng số, không phân biệt theo loại như trong trường hợp của .dex file. Việc lặp lại khai báo các hằng số này ở nhiều file .class khiến tổng kích thước các file .class lớn hơn nhiều so với file thực thi Dalvik.
Theo số liệu thống kê, trung bình trong mỗi file .class, 61% kích thước của file là các hằng số (!!!), mã của các phương thức (method) chỉ chứa khoảng 33%, còn lại 5% cho các phần khác của class. Như vậy việc tiết kiệm vùng nhớ cho hằng số dẫn đến việc tiết kiệm đáng kể kích thước file thực thi (thông thường là khoảng 50%), từ đó tiết kiệm được lượng bộ nhớ cần cấp phát lúc thực thi ứng dụng.
Zygote
Các ứng dụng Android được chạy trong các thực thể máy ảo riêng, vì vậy máy ảo phải được “khởi động” nhanh và sử dụng tối thiểu bộ nhớ cần thiết. Để đạt được điều này, hệ thống Android đưa ra một cơ chế giúp các thực thể máy ảo có thể chia sẻ mã lệnh dùng chung và “khởi động” nhanh, gọi là Zygote.
Hầu hết các ứng dụng Android đều dùng chung một số thư viện lõi và cấu trúc bộ nhớ heap kèm theo nó. Thêm vào đó, vùng nhớ heap của các thư viện lõi này thường chỉ được truy xuất chỉ đọc (read-only). Lợi dụng điểm này, Zygote, một tiến trình máy ảo Dalvik được khởi chạy lúc khởi động thiết bị, nạp sẵn các thư viện lõi của hệ điều hành mà các ứng dụng thường xuyên sử dụng, để sẵn sàng cho các máy ảo sử dụng. Mỗi lần một ứng dụng được chạy, hệ thống sẽ khởi động một máy ảo mới, tuy nhiên máy ảo này sẽ không cần chứa những thư viện lõi, mà sử dụng luôn thư viện lõi trong Zygote, khiến thời gian khởi tạo máy ảo là tối thiểu.
Các thư viện lõi trong hầu hết các trường hợp là “chỉ đọc” chứ không bị ghi đè bởi ứng dụng. Trong trường hợp ứng dụng có nhu cầu ghi vào vùng nhớ heap của các thư viện lõi này, một bản sao của vùng nhớ Zygote sẽ được tạo ra riêng cho tiến trình của ứng dụng đó. Cơ chế “sao chép khi ghi” (copy-on-write) này giúp tối ưu hóa việc sử dụng chung mã lệnh của thư viện lõi mà vẫn đảm bảo tính bảo mật giữa các ứng dụng: việc thay đổi dữ liệu trong bộ nhớ của ứng dụng này không ảnh hưởng đến các ứng dụng khác.
Trong JVM truyền thống, mỗi thực thể của máy ảo Java sẽ có một tập các thư viện lõi riêng cùng vùng nhớ tương ứng cho chúng, không có sự chia sẻ bộ nhớ giữa các thực thể của máy ảo.
Bảo mật
Mặc định theo kiến trúc bảo mật của hệ điều hành Android, mỗi ứng dụng không có quyền thực thi bất cứ thao tác nào ảnh hưởng đến các ứng dụng khác, đến hệ điều hành hay người dùng, bao gồm: đọc/ghi dữ liệu cá nhân (như danh bạ, email…), đọc/ghi file dữ liệu của ứng dụng khác, thực hiện kết nối mạng, giữ màn hình luôn sáng…
Tính năng này được thực hiện từ tầng hệ điều hành và tầng khung ứng dụng (application framework) chứ không phải bên trong máy ảo Dalvik. Mỗi ứng dụng được chạy trong một máy ảo riêng, máy ảo này lại được chạy trong một tiến trình riêng. Mỗi tiến trình được chạy dưới một mã người dùng (user ID) riêng, được sinh ra lúc cài đặt và được phân quyền chỉ được truy cập một số tính năng nhất định của hệ điều hành và các tập tin riêng của mình. Nếu ứng dụng có các yêu cầu đặc biệt đến các tính năng khác của hệ thống thì phải khai báo các quyền tương ứng trong file mô tả ứng dụng (AndroidManifest.xml) và sẽ được cấp các quyền này lúc cài đặt nếu được sự đồng ý từ người dùng.
Ứng dụng
Các ứng dụng Android được đóng gói dưới dạng file APK. File APK chứa tất cả dữ liệu, tài nguyên, thư viện của bên thứ 3 và một file mô tả chức năng của ứng dụng. Hình 2.3 miêu tả một quá trình cơ bản khi biên dịch mã nguồn Java sang các file APK.
Quá trình biên dịch Java sang APK file
Để đảm bảo tính bảo mật, các ứng dụng đều chạy trong một môi trường máy ảo. Trong quá trình cài đặt, các ứng dụng nhận được Linux user ID từ hệ điều hành Android. Quyền cho các file trong ứng dụng đó được cài đặt không cho ứng dụng khác truy cập vào. Ngoài ra khi bắt đầu, các ứng dụng hoạt động trong một máy ảo riêng được hệ điều hành cấp. Các ứng dụng khác nhau sẽ chạy hoàn toàn độc lập với nhau. Theo tài liệu Andorid công bố thì điều này thực hiện nguyên tắc đặc quyền tối thiểu: mỗi ứng dụng chỉ có quyền truy cập vào các thành phàn mà nó yêu cầu thực hiện công việc của minh.
Các thành phần của ứng dụng
Dưới đây là một số thành phần chính được sử dụng để xây dựng các ứng dụng Android.
Activities: Một hoạt động đại diện cho một màn hình chính duy nhất với giao diện người dùng. Các ứng dụng khác nhau sẽ có các hoạt động khác nhau. Mỗi hoạt động độc lập với các hoạt động khác và nếu ứng dụng cho phép nó có thể mở một ứng dụng khác. Ví dụ một ứng dụng messenger có thể mở một ứng dụng duyệt web như chrome.
Services: Dịch vụ là cac thành phần chạy ngầm để thực hiện các hoạt động dài hạn và không cung cấp giao diện cho người dùng. Ví dụ ứng dụng âm nhạc sẽ có một dịch vụ âm nhạc chịu trạch nhiệm phát nhạc ở chế độ ngầm trong khi người dùng có thể sử dụng một ứng dụng khác. Các dịch vụ có thể được khởi động bởi các thành phần khác của ứng dụng, chẳng hạn như hoạt động quảng cáo.
Content providers: Dịch vu cung cấp thông tin được sử dụng để chia sẻ dữ liệu giữa nhiều ứng dụng. Nó quản lý một bộ dữ liệu ứng dụng được chia sẻ thông tin liên lạc. Ví dụ ứng dụng phát nhạc có thể sử dụng nhà cung cấp nội dung để lưu trữ thông tin về bài hát hiện tại đang được phát, sau đó ứng dụng xã hội có thể được sử dụng để cập nhật trạng thái nghe nhạc hiện tại của người dùng.
Manifest
Mỗi ứng dụng trên Android đều có một file AndroidManifest.xml thông báo cho hệ thống về các thành phần ứng dụng. Các hoạt động và dịch vụ không được khai báo trong bảng kê khai sẽ không được thực thi. Tuy nhiên, các dịch vụ quản cáo có thể không cần khai báo trong phần kê khai các dịch vụ này. Nó có thể được đăng ký động thông qua phương thức registerReceiver (). File kê khai cũng chỉ định các yêu cầu của ứng dụng, chẳng hạn như các yêu cầu phần cứng đặc biệt (ví dụ: có máy ảnh hoặc cảm biến GPS) hoặc phiên bản API (phiên bản Android) tối thiểu cần thiết để chạy ứng dụng này. Để truy cập các thành phần được bảo vệ (ví dụ: quyền truy cập máy ảnh hoặc truy cập vào danh sách liên hệ của người dùng), một ứng dụng cần phải được cấp phép. Tất cả các quyền cần thiết phải được xác định trong ứng dụng Android Androidififest.xml. Bằng cách này, trong quá trình cài đặt, hệ điều hành Android có thể nhắc nhở người dùng về các quyền đã sử dụng mà sau đó người dùng phải cấp quyền truy cập ứng dụng để sử dụng các thành phần này. Trong hệ điều hành, các thành phần được bảo vệ là thành phần của Linux group ID. Bằng cách cấp quyền cho ứng dụng, máy ảo được cung cấp để chạy ứng dụng được cấp quyền như những ứng dụng khác và do đó có thể truy cập các thành phần bị hạn chế.
File Androidififest.xml giống như header cho một ứng dụng Android. Nó cung cấp chức năng, hành vi, quyền truy cập vào các chức năng khác trong thiết bị để thực thi các chức năng.
Native code
Native code có thể hữu ích cho một số loại ứng dụng sử dụng các Native code như C và C ++ để chúng có thể sử dụng lại các thư viện mã hiện có được viết bằng các ngôn ngữ này. Các ứng dụng điển hình cho việc sử dụng native code là các ứng dụng hoạt động ở tầng thấp của CPU như xử lý tín hiệu, game engines, v.v. Không giống như Java bytecode, native code chạy trực tiếp trên bộ xử lý và do đó không được máy ảo Dalvik biên dịch.
Distribution
Người dùng Android có thể tự do cài đặt bất kỳ ứng dụng ( của bên thứ ba) nào thông qua Google Play Store (trước đây gọi là Android Market). Google Play là một nền tảng phân phối ứng dụng trực tuyến nơi người dùng có thể tải xuống và cài đặt các ứng dụng miễn phí hoặc trả phí từ các nhà phát triển khác nhau (bao gồm cả Google). Để bảo vệ Cửa hàng Play khỏi các ứng dụng độc hại, Google sử dụng hệ thống chống mã độc tự động được phát triển nội bộ có tên Google Bouncer (được thảo luận chi tiết hơn trong phần sau). Người dùng có thể cài đặt các ứng dụng từ các nguồn khác ngoài Google Play. Đối với điều này, người dùng phải kích hoạt tùy chọn nguồn không xác định trong tổng quan về cài đặt của thiết bị và chấp nhận rõ ràng các rủi ro khi thực hiện. Bằng cách sử dụng các nguồn cài đặt bên ngoài, người dùng có thể cài đặt các tệp APK được tải xuống trực tiếp từ web hoặc chọn sử dụng thị trường của bên thứ ba. Các thị trường bên thứ ba này đôi khi cung cấp một loại ứng dụng chuyên biệt, chẳng hạn như cửa hàng ứng dụng dành cho người lớn MiKandi hoặc người dùng mục tiêu từ các quốc gia cụ thể, như cửa hàng ứng dụng Trung Quốc Anzhi12 và Xiaomi13 (một nhà sản xuất điện thoại nổi tiếng của Trung Quốc).
Bảo mật trong thiết bị Android
Các mô hình bảo mật được thiết kế để ngăn chặn các cuộc tấn công như Social engineering mà mục đích là cài ứng dụng của bên thứ 3. Nó kết hợp một số biện pháp bảo vệ làm giảm khả năng bị ảnh hưởng bởi phần mềm độc hại cũng như các trường hợp bị lây nhiễm. Dưới đây là một số biện pháp quan trọng mà Google phát triển để bảo vệ người dùng Android khỏi các mối đe dọa khác nhau:
Google kết hợp mốt số điều khiển chẳng hạn như không cho phép các ứng dụng khác nhau có avatar giống nhau hoặc cùng tên. Việc này sẽ ngăn chặn việc phát tán các ứng dụng có nội dung bất hợp pháp, ứng dụng cá cược thực, ứng dụng có nội dung khiêu dâm, kích động chiến tranh…. Ngoài ra nó còn thực hiện một chức năng xác minh chữ kí số (signatures) của ứng dụng với danh sách các phần mềm độc hại mà Google thu thập được.
– Mỗi ứng dụng khi thực thi sẽ được cấp một máy ảo riêng biệt và ngăn các ứng dụng khác nhau sử dụng tài nguyên của nhau
– Các nhà phát triển ứng dụng còn kết hợp mô hình cho phép (hỏi ý kiến người dùng trước khi thực hiện một chức năng bị hạn chế) và chắc năng mã hóa thông tin
– Kết hợp các phương pháp như ASLR, ProPolice, Sercurity-IOP với mục đích giảm thiểu rủi ro trong việc quản lí bộ nhớ và việc tấn công vào bộ nhớ.
– Mã hóa tất cả các thông tin trong thiết bị di động và thẻ SD.
– Theo mặc định, Android không cho phép người dùng cài đặt các ứng dụng không rõ nguồn gốc. Tuy nhiên người dùng có thể tắt chức năng này.
– Cập nhật các phiên bản mới nhất của Android mỗi khi Google đưa ra các bản vá hoặc các phiên bản nâng cấp.
Việc tạo mật khẩu và xác thực nhiều lớp là bắt buộc cho việc giao dịch liên quan đến tài chính để ngăn chặn việc tự động mua bán của các phần mềm độc hại.
Tuy nhiên các ứng dụng tất cả các ựng dụng được đăng lên các cửa hàng của Android thì không cần giấy chứng nhận để đảm bảo ứng dụng đó không gây ra bất kì rủi ro nào cho người dùng.
Việc tùy chỉnh quyền có thể mang đến một rủi ro nhất định cho những người dùng không nhiều kiến thức về an toàn thông tin.
Trong phần sau mình sẽ tiếp tục giới thiệu về cấu trúc file APK !