Ở khóa luận này, nhóm chúng tôi sẽ phát triển một hệ thống phát hiện ứng dụng độc ại trên thiết bị di động chạy hệ điều hành Android dựa trên kiến trúc học sâu và mô hình học máy.. Sau đ
Machine Learning cho Mobile và Edge Devices
Hiện tại, việc triển khai ứng dụng áp dụng các mô hình học máy giờ đây không chỉ trên các thiết bị có cau hình cao mà còn có thé thực hiện trên điện thoại hoặc thậm chí là các thiết bị IoT Điều này hoàn toàn khả thi nhờ sự hỗ trợ của các thư viện triển khai Machine Learning như PyTorch [20] hoặc Tensorflow [21].
Hau hết các thư viện đều có sự đồng nhất trong quá trình áp dung Machine Learning trên di động Dé có thé đưa được mô hình học máy có kích thước lớn lên thiết bi, chúng phải giảm kích thước bằng cách điều chỉnh các tham sé, sử dụng các
19 kỹ thuật dé tinh chỉnh bộ trọng sé, các lớp trong mô hình sao cho hạn chế việc giảm khả năng xử lí và độ chính xác của mô hình cũ Có thê lí giải băng sơ đô như sau:
Want bigger model Convert float TFLite size reduction? models
Able to re-train the model?
Post-training Want higher accuracy? dynamic range quantization
* Hardware accelerators, such as GPU or DSP, only support a subset of our quantization schemes Make sure to account for your choice of accelerators as well.
Hình 2.5 Bộ sơ do giúp hỗ trợ tỉnh chỉnh mô hình dựa trên kích thước và độ chính xác của mô hình dự kiên dựa trên Tensorflow
|quawriz MODEL (OPTIONAL) model = torch.quantization.convert(mobile_model) // fp32>int8 scripted_model = torch jit.script(modeL)
|mopet OPTIMIZATION (OPTIONAL) opt_model = torch.utils.optimize_for_mobile(scripted_model) torch.jit.save(opt_model, “mobile_model.pt”)
ANDROID - MAVEN | iOS - COCOAPODS Ý # implementation
Hinh 2.6 Quy trinh triển khai dựa trên PyTorch
Trong dé tài này, chúng tôi sử dụng Tensorflow dé luân chuyền mô hình học máy sang thiết bị di động.
Lượng tử hóa sau quá trình huấn luyện (Post-training quantization)
Giai đoạn tiền xử lý . 222+2222x++teEEEtererrrktrrerrrkerrrrr 31 3.2.1.2 Giai đoạn kiỂm tra -.¿ -222+2222+++t2EEEterttrrkxrrerrkkecrrrr 33 3.2.1.3 Xây dựng ứng dụng phát hiện mã độc - ô+ 34
Không giống như giai đoạn tiền xử lí trên máy chủ, vì đây là môi trường AndroidOS với cấu hình phần cứng thấp, chúng tôi phải tìm các giải pháp để giải quyết các van dé nam ở quyền của ứng dụng trong 2.5.
Trong giai đoạn này, chúng tôi gặp hai vấn đề lớn trong việc thiết kế thuật toán:
- _ Vấn đề không thé đưa giống toàn bộ thuật toán trích đặc trưng trên máy chủ áp dụng lên thiết bị di động vì các thuật toán trên máy chủ chủ yếu sử dụng các shell execute dé thực thi duyệt tập tin — điều mà bị giới hạn ở người dùng bình thường của AndroidOS.
- Van dé sử dụng công cụ hỗ trợ, chúng tôi sử dung Apktool — công cụ này được viết hoàn toàn bằng mã nguồn Java để dịch ngược tập tin APK Vì Apktool chủ yêu được thiết kế cho Window, MacOS, Unix va không phù hợp dé chạy trên Android do sự khác biệt về Java Virtual Machine với Dalvik Virtual Machine mặc dù Android cùng nhân Linux Ví dụ hình bên dưới là mã nguồn của apktool có chức năng kiểm tra hệ điều hành và kiến trúc của hệ điều hành đó khiến cho việc sử dụng trên Android là một trở ngại lớn.
31 public class OSDetection { private static final String = System.getProperty -name") toLowerCa: 3 private static final String = System.getProperty( -arch.d toLowerCase(); public static boolean isWi return (0S contains("w public static boolean isMacOSX() { return (05.contains( public static boolean isUnix(} { public static boolean is64Bit() { if (isWindows return arch != null && arch.endswith("64") || wowB4Arch != null && wow64Arch.endsWith("6
J return @qualsiIgnoreCa public static String returnOS() { return F
Hình 3.5 Mã nguồn Apktool Đề giải quyết hai vấn đề lớn trên, chúng tôi đưa ra các giải pháp sau:
- Chinh sửa lại toàn bộ thuật toán trích đặt trưng Trong đó, loại bỏ các phần sử dụng shell execute thay thế bằng các thuật toán tự viết hoặc sử dụng các thư viện Java tự viết.
- Chỉnh sửa lại một phần mã nguồn của apktool Đối với các mã lệnh không thé sử dụng trên nền Android, chúng tôi tìm cách thay thế đồng thời sử dụng thêm một số luồng, loại bỏ các tính năng không cần thiết (do project chỉ cần duy nhất tính năng decompile nên chúng tôi ưu tiên tối ưu option này và chỉ giữ lại AndroidManifest.xml và các tệp smali dé tránh đầy bộ nhớ đồng thời tăng thời gian xử If) sau đó xây dựng lại thành thư viện jar tập tin nhằm có thé sử dụng trên di động và gia tăng tốc độ dịch ngược của apktool.
Sau khi trích hoàn toàn các chuỗi API va Permission, thuật toán sẽ chuyền sang định dạng mảng và tải mô hình đã được huân luyện Đâu vào và đâu ra của mô hình được mô tả như hình bên dưới. import t interpreter = tf.lite.Int (model_path= input_details = interpreter. output_details = interpreter.get_o tf print( ằ input_details) tf print\( „ output_details))
"scales": array([], dtype=float32), 'zera_pnints": array{[], dtype=int32)},
"shape signature": array([ -1, 588], dtype=int32), 'sparsity_parameters": {}}]
Output details: [{‘dtype": ,
"zero_points": array([], dtype=int32)},
"shape": array([1, 2], dtype=int32), array([-1, 2], dtype=int3?),
Hình 3.6 Chi tiết đầu vào và dau ra của model
Kết quả của đầu ra là hai chỉ số dương tính hoặc âm tính Sau đó, ứng dụng sẽ lưu lại thông tin của apk tập tin được kiểm tra dé người dùng khác khi kiểm tra cùng một tệp thì thời gian xử lí sẽ được nhanh hơn.
3.2.1.3 Xây dựng ứng dụng phát hiện mã độc.
Sau khi tập hợp đầy đủ các kỹ thuật và thông tin cần thiết, chúng tôi thực hiện triển khai và bắt đầu xây dựng một ứng dụng Android viết bằng Java Đây được xem là một giao diện người dùng dùng để trực quan hoá quá trình hoạt động của mô hình phát hiện mã độc.
Mục tiêu của ứng dụng này là hoạt động trên hầu hết các thiết bị chạy với nhiều phiên bản hệ điều hành khác nhau của Android.
Quá trình phát triển ứng dụng thực hiện qua các giai đoạn sau:
Giai đoạn 1: Lên ý tưởng và xây dựng giao diện ban đầu. Ở giai đoạn này, chúng tôi muốn tạo 3 tab Mỗi tab có một chức năng riêng: e Tab Home: Có một Button dùng để chọn một tập tin Apk từ hệ thong tap tin của thiết bị Sau đó sẽ đưa tới quá trình phân tích ở giai đoạn sau.
34 e Tab Dashboard: Có một Layout dùng dé hiển thị tat cả các ứng dung đã cài đặt Áp dụng hệ thống phát hiện mã độc dé kiểm tra những ứng dụng đó Kết quả sau cùng sẽ dẫn đến quyết định giữ hoặc gỡ bỏ ứng dụng đó của người dùng. o6
Dashboard comicscreen cardmaker newapp paktor x“?#Ta
Hình 3.8 Giao diện Dashboard e Tab Notification: Dùng dé nhận thông báo từ Server Hiện tai chúng tôi chưa cân sử dụng đên.
Giai đoạn 2: Import tài nguyên và thư viện cần thiết.
Hệ thống sử dụng một bộ từ điển dùng để ánh xạ khi trích xuất đặc trưng, đồng thời áp dụng kỹ thuật trích chon đặc trưng dé lấy ra những đặc trưng hiệu quả. Khi áp dụng lên thiết bị, ta có thể lược bỏ quá trình này bằng cách sử dụng kết quả trên máy chủ và đưa vào thiết bị Như vậy tài nguyên cần thiết bao gồm: e© all api calls.fxt: bộ từ điển đầy đủ. e_ selkbesf.txt: bộ đặc trưng sau khi áp dụng kỹ thuật trích chọn đặc trưng. e_ model.fflite: model học sâu được chuyền từ máy chủ sang định dang cho thiết bị.
Hình 3.9 Các tài nguyên can thiết
Một công cụ quan trọng được nêu trong 3.2.1.1 là apktool Sau khi chỉnh sửa mã nguồn, chúng tôi xây dựng lại thành thư viện jar và import vào ứng dụng.
Giai đoạn 3: Xây dựng mã nguồn cho từng mục đích.
Chúng tôi chia mã nguồn thành hai thành phan: thuật toán phục vụ cho hệ thống phát hiện mã độc và mã nguồn thiết kế giao diện.
Chi tiết mã nguồn ứng dụng như sau: e FeatureExtractor.java: là lớp gồm các hàm dùng dé rút trích các đặc trưng từ xml và smali files. e FileChooserFragment.java: là lớp tạo Fragment chứa button cho việc cấp quyền truy xuất bộ nhớ ngoài dùng dé chọn tap tin APK phân tích. e EileUtils.java: phục vụ cho EileChooserFragment.java, hỗ trợ trong quá trình chọn tập tin từ External Storage hoặc Drive. e Model.java: là lớp khởi tạo model Tensorflow Lite chứa các Constructor, hàm load model và thực thi chạy kiểm tra model. e SHA256.java: lớp chứa hàm hỗ trợ băm một tập tin thông qua thuật toán băm
Mã nguôn giao diện: e Cửa số Home: Tại cửa sô này chủ yêu phục vụ tác vu phân tích đơn mục tiêu, sau khi chọn một tập tin APK, cửa sô sẽ hiên thị quá trình phân tích, các tác vụ và cuôi cùng xuât kêt quả Hình bên dưới sẽ miêu tả cách thức sử dụng và quá trình thực thi tại cửa số Home. oa oe
Checking file has been checked yet?
Name: FIFA Mobile_ v5 com.apk
Hình 3.12 Quá trình kiểm tra một ứng dụng tại cửa số Home
Chỉ tiết các bước thực thi tại Hình 3.12:
THỰC NGHIỆM HE THONG DE XUẤT
Môi trường thực nghiệm - - - cece eeeeteeeteneseeeetsneseaeeeeteeeneseae 43 1 Thực nghiệm trên máy chủ - - - ô5+ 5++x+xe+sEerrkekerererkrke 43 2 Thực nghiệm trờn thiết bị di động -côcsctsseerereeeree 43 4.2 Đánh giá - 222222 222222222111122 12221111120 Eeeee 43 4.2.1 Các chỉ số đánh giá . ccccccccccccvvvrrrrrrrrrrrrrrrrrrerrreg 44 4.2.2 4.3 Kết qua thực nghiệm mô hình phát hiện mã độc đã đề xuất
Toàn bộ hệ thông và các kêt quả mà nhóm đưa ra được xây dựng trên máy chủ và thiệt bi di động có câu hình nhât định So liệu có thê khác hoặc thay đôi nêu triên khai trên các câu hình khác nhau do việc ảnh hưởng của phân cứng hoặc phân mêm liên quan đến khả năng xử lí của hệ thống.
4.1.1 "Thực nghiệm trên máy chủ
Dé triên khai trên thiệt bi di động, việc triên khai và thực nghiệm trên máy chủ là điêu thiệt yêu Đâu ra ở môi trường này là các chỉ sô đánh giá, mô hình chuyên đôi.
- CPU: Processor - Intel(R) Core(TM) | - OS: ParrotOS 4.11.1 i7-2640M CPU @ 2.80GHz - Architecture: x86_64
- RAM: 12GB - Programming Language: Python 3.8
- DISK: 120GB SSD + 600GB HDD
Bang 4.1 Thông tin cầu hình máy chủ
4.1.2 Thực nghiệm trên thiết bị di động
Triển khai trên thiết bị động là nhiệm vụ trọng tâm của nhóm thực hiện đề tài, các chỉ số đầu ra của mô hình thực thi trên thiết bị là thành phần chính để nhóm đánh giá hiệu năng và khả năng phát triển của mô hình.
- CPU: Exynos 8890 4 cores 2.3 GHz|- OS: Android 8
- RAM: 4GB - Programming Language: Java
Bảng 4.2 Thong tin cấu hình thiết bị di động
Trong phần này, chúng tôi tiến hành đánh giá mô hình xây dựng dựa trên bộ dữ liệu mà chúng tôi hiện có Kêt qua chủ yêu bao gôm các khía cạnh về hiệu suât sau trên cả máy chủ và thiệt bị điện thoại: il.
Hiệu suất phát hiện (Detection Performance): Chúng tôi đánh giá mức độ hiệu quả mà mô hình MalDozer có thể phân biệt giữa các ứng dụng độc hại và bình thường thông qua các chỉ số tiêu biểu như Fl-Score, Precision,
Recall và False Negative rate.
Hiệu suất thời gian thực thi (Runtime Performance): Chúng tôi đo thời gian của quá trình tiền xử lý và thời gian mô hình phân tích, phát hiện các mẫu dữ liệu trên thiết bị và kích thước của mẫu phân tích để tìm ra sự tương quan giữa chúng.
4.2.1 Các chỉ số đánh giá
Kết quả đánh giá của chúng tôi được trình bày theo các chỉ số sau:
True positives: chi sé nay đo lường 86 lượng ứng dụng độc hai được phat hiện thành công.
False negatives: chi số này đo lường sỐ lượng ứng dụng độc hại được phát hiện là lành tính.
True negatives: chỉ số này đo lường số lượng ứng dụng lành tính được phát hiện thành công.
False positives: chỉ số này đo lường số lượng ứng dụng lành tính được phát hiện là độc hại.
Precision: là độ tin cậy của phép dự đoán Tức là tỷ lệ phần trăm ứng dụng độc hại được phát hiện thành công trong tổng số các mẫu mà mô hình phát
TP TP+FP hiện là ứng dụng độc hai Công thức: P =
- Recall: là khả năng khám phá các điểm Positive của mô hình Tức là tỷ lệ phần trăm ứng dụng độc hại được phát hiện thành công trong tổng số các mẫu ứng dụng độc hại Công thức: R = —
- Fl-Score: là thước đo độ chính xác của mô hình Công thức: Fl = 2 x —
- False positive rate: là tỷ lệ xác định nhằm Công thức: FPR = ——
- False negative rate: là tỷ lệ bỏ sót Công thức: FNR = Tu
Mô hình MalDozer đòi hỏi tập dữ liệu dùng dé huấn luyện phải cân bang, tức là số mẫu positives (các ứng dụng độc hại) và số mẫu negatives (các ứng dụng lành tính) phải bằng nhau.
Chúng tôi sử dụng bộ Dataset cua Canadian Institute for Cybersecurity tại
University of New Brunswick là CICMalDroid2020 [24] Day là bộ Dataset phong phú với 17,341 mẫu mới gần đây, được thu thập từ nhiều nguồn như VirusTotal service, Contagio security blog, AMD, MalDozer, gom 5 danh mục riêng biệt là:
- Mobile Adware: là mã độc chứa tài liệu quảng cáo ân bên trong các ứng dụng hợp pháp bị nhiễm phần mềm độc hại Các thư viện quảng cáo được phần mềm độc hại sử dụng sẽ lặp lại một loạt các bước dé giữ cho quảng cáo tiếp tục chạy, phần mềm quảng cáo sẽ liên tục bật lên quảng cáo ngay cả khi nạn nhân cố gắng đóng ứng dụng Phần mềm quảng cáo có thể lây nhiễm, buộc thiết bị phải tải xuống các loại phần mềm quảng cáo cụ thể và cho phép những kẻ tắn công lấy cắp thông tin cá nhân của nạn nhân.
- Mobile Banking Malware: là phần mềm độc hại chuyên biệt được thiết kế dé truy cập vào tài khoản ngân hàng trực tuyến của người dùng bằng cách giả mạo các ứng dụng ngân hàng hợp pháp hoặc giao diện web ngân hàng Hầu hết Mobile banking malware là Trojan, các mã độc này sẽ đánh cắp các thông tin nhạy cảm như thông tin đăng nhập, mật khâu ngân hang, đồng thời gửi thông tin bị đánh cắp đến máy chủ C&C (command and control).
SMS Malware: là phần mềm độc hại lợi dụng dịch vụ SMS làm phương tiện để tiến hành các cuộc tấn công Chúng sử dụng máy chủ C&C để kiểm soát các cuộc tấn công của chúng như gửi SMS độc hại, chặn SMS và đánh cắp dữ liệu,
Mobile Riskware: là phần mềm hợp pháp nhưng tén tại lỗ hồng có thé bị kẻ tấn công khai thác gây thiệt hại cho người dùng Do đó, nó có thê biến thành bất kỳ dạng phần mềm độc hại nào khác như Mobile Adware, Mobile
Banking Malware hay SMS Malware,
Benign: là các ứng dụng hop pháp (lành tính) Trong trường hợp nay, Benign là tập các ứng dụng khác không thuộc các tập trên và đã được tác giả kiểm tra bằng VirusTotal.
Trong đó chúng tôi sử dụng tập Riskware và Benign dé huấn luyện, đánh giá và kiểm tra kết quả mô hình Chúng tôi chia Dataset làm 2 phần:
So sánh với mô hình khác sử dụng cùng Dataset
Trong phần này, chúng tôi sẽ so sánh mô hình mà nhóm chúng tôi đề xuất với mô hình có sử dụng CICMalDroid2020 Dataset đạt kết quả tốt đã được công bố Mô hình phân loại mã độc Pseudo-Label Deep Neural Network (PLDNN) mà Samaneh
Mahdavifar và cộng sự đã đề xuất [25], trong đó có sử dụng CICMalDroid2020 Dataset để đánh giá kết quả trong bài báo của mình Đây là một mô hình phân loại mã độc Android dựa trên phương pháp Semi-Supervised Deep Learning.
Bang 4.5 Bảng so sánh kết các chi số đánh giá giữa hai mô hình
Kết quả cho thấy mô hình PLDNN mà Samaneh Mahdavifar và cộng sự đã dé xuất có Fl-Score = 97.84%, thap hơn chi số Fl-Score = 98.06% của mô hình ma chúng tôi đề xuất Nguyên nhân là vi PLDNN là mô hình phân loại mã độc áp dụng kỹ thuật học bán giám sát (Semi-Supervised) với khoảng 10% (khoảng 1000 mẫu) dữ liệu huấn luyện được gán nhãn Trong khi đó, mô hình của chúng tôi sử dụng kỹ thuật học giám sát (Supervised), tức là tất cả các mẫu dữ liệu huấn luyện đều có gán nhãn, do đó MalDozer đạt độ chính xác cao hơn trong quá trình phân tích So với
PLDNN, mô hình mà chúng tôi đề xuất có “độ tin cậy” của phép dự đoán thấp hơn (tức là chỉ số Precision), PLDNN sử dụng API system calls, binder calls và composite behaviors trích xuất được từ ứng dụng làm đặc trưng dé huấn luyện mô hình, trong khi đó chúng tôi chỉ đề xuất dùng API system calls và Permission làm đặc trưng dé phân tích dẫn đến độ tin cậy của phép dự đoán của mô hình chúng tôi
50 đề xuất thấp hơn với mô hình so sánh Tuy nhiên, về “khả năng khám” phá các mẫu độc hại của mô hình chúng tôi lại cao hơn so với mô hình PLDNN (tức là chỉ SỐ Recall), nguyên nhân cũng do sự ảnh hưởng từ kỹ thuật dùng để huấn luyện mô hình mà 2 nhóm áp dụng là kỹ thuật học giám sát và học bán giám sát Trong bài toán phát hiện mã độc, ta quan tâm “kha năng khám phá” nhiều hơn là “độ tin cậy” do các mã độc cần được ưu tiên phát hiện hơn là kết quả phát hiện có đáng tin tưởng hay không, ngoài ra Precision = 97.34% của mô hình chúng tôi là một chỉ số có thé chấp nhận tin tưởng Đây là cơ sở khăng định mô hình tìm năng trong lĩnh phát hiện mã độc Android trên thiết bị bằng phương pháp học sâu.
Bên cạnh đó, PLDNN sử dụng CopperDroid [26] ở quá trình tiền xử lý để trích xuất các tính năng, trong đó số mẫu dữ liệu trích xuất không thành công chiếm tới 25% (4264 mẫu trong tông số 17,341 mẫu) do các lỗi như hết thời gian chờ, tệp APK không hợp lệ, Trong khi đó với việc sử dụng Apktool ở quá trình tiền xử lý, mô hình của chúng tôi chi mat 11.95% (2073 mẫu trong tông số 17,341 mau) dữ liệu.
Nhu vậy trong khóa luận nay, chúng tôi đã trình bày hoàn chỉnh một hệ thong phát hiện mã độc Android trên thiết bi băng phương pháp học sâu Trong đó, chúng tôi đề xuất sử dụng MalDozer framework — một framework đơn giản nhưng hiệu quả trong việc phát hiện mã độc Android — cho việc phân tích, chúng tôi đã có một số chỉnh sửa để MalDozer phù hợp với bối cảnh Bên cạnh đó, chúng tôi đề xuất sử dụng thêm permission làm đặc trưng cho ứng dụng trong việc phân tích.
Chúng tôi sử dụng bộ Dataset của Canadian Institute for Cybersecurity (CIC) cung cấp là CICMalDroid2020 dé huấn luyện và đánh giá mô hình Kết quả mô hình đạt được cao với Fl-Score đạt 98.06%, ty lệ bỏ sót thấp với 1.2% cho thấy tính hiệu quả cao của mô hình đề xuất Sau đó, chúng tôi sử dụng các thư viện hỗ trợ để chuyên đổi mô hình sao cho phù hợp dé triển khai trên thiết bị Cũng trong giai đoạn này, một ứng dụng được chúng tôi xây dựng đề tích hợp mô hình đề xuất, quá trình tiền xử ly cũng được chúng tôi thay đồi lại dé phù hợp với bối cảnh triển khai trên thiết bi di động Sau cùng, chúng tôi tiến hành kiểm thử lại kết quả, cũng như là thống kê thời gian phân tích trên thiết bị Với các kết quả đạt được, chúng tôi hy vọng sẽ góp phan tăng cường sự bảo vệ đối với người dùng cuối trong bối cảnh mã độc ứng dụng Android đang ngày càng gia tăng.
Trong tương lai, chúng tôi sẽ mở rộng công việc hiện tại của mình từ 3 hướng: Cải thiện hiệu năng, triển khai trên thiết bị IoT và lập thêm các máy chủ lưu trữ các dữ liệu thu thập dé cải tiến mô hình Đầu tiên sẽ là cải thiện hiệu năng, trong toàn bộ quá trình phân tích ứng dụng trên thiết bị thì giai đoạn trích xuất đặc trưng chiếm nhiều thời gian nhất, mặc dù chúng tôi đã lưu trữ thông tin các ứng dụng đã phân tích và kết hợp với quá trình Scanning dé rút ngắn thời gian đối với các ứng dụng đã phân tích trước đó, tuy nhiên đây vẫn chưa phải là giải pháp tối ưu, các ứng dụng mới vẫn phải tốn khá nhiều thời gian cho quá trình trích xuất đặc trưng Thay vào đó, biện pháp hữu hiệu chính là tối ưu thuật toán trích xuất bằng các giải thuật, cũng như là tận dụng tốt sức mạnh phần cứng Hướng phát triển tiếp theo đó chính là triển khai mô hình trên thiết bị IoT, với sự phát triển của các thiết bị IoT va
52 được dự báo là sẽ còn tăng mạnh trong thời gian tới thì đây là thị trường thích hợp dé hướng đến Như đã dé cập, MalDozer framework rất thích hợp dé triển khai trên thiết bị IoT, thêm vào đó kỹ thuật lượng tử hóa sau quá trình huấn luyện giúp giảm kích thước mô hình đề triển khai trên các thiết bị hạn chế phần cứng được các thư viện hỗ trợ mạnh mẽ, nên việc phát triển mô hình đề xuất trên thiết bị IoT là phù hợp và khả thi trong tương lai gần Cuối cùng là lập thêm các máy chủ lưu trữ các dữ liệu thu thập dé cải tiến mô hình, các bộ Dataset được chia sẻ công khai có xu hướng lỗi thời, việc từ làm giàu Dataset từ hệ sinh thái gồm các thiết bị được cài đặt ứng dụng tích hợp mô hình đề xuất là hướng đi thú vị Ngoài việc làm giàu Dataset cho mô hình, các thiết bị cài đặt ứng dụng tích hợp mô hình có thể tham gia vào quá trình huấn luyện mô hình, việc lập thêm các máy chủ được dùng dé nhận và lưu trữ các dữ liệu hữu ích này.
[1] J Johnson "Development of new Android malware worldwide from June
2016 to March 2020." https://www.statista.com/statistics/680705/global-android-malware- volume/ (accessed.
[2] “Smartphone Market Share." https://www.idc.com/promo/smartphone-market-share/os (accessed.
[3] "McAfee Mobile Threat Report." https://www.mcafee.com/content/dam/consumer/en-us/docs/2020- Mobile-Threat-Report.pdf (accessed.
[4] E B Karbab, M Debbabi, A Derhab, and D Mouheb, "MalDozer:
Automatic framework for android malware detection using deep learning," Digital Investigation, vol 24, pp S48-S59, 2018.
[5] R Feng et al., "Mobidroid: A performance-sensitive malware detection system on mobile platform,” in 2019 24th International Conference on Engineering of Complex Computer Systems (ICECCS), 2019: IEEE, pp 61- 70.
[6] E Mariconti, L Onwuzurike, P Andriotis, E De Cristofaro, G Ross, and G.
Stringhini, "Mamadroid: Detecting android malware by building markov chains of behavioral models,” arXiv preprint arXiv:1612.04433, 2016.
[7] R Vallée-Rai, P Co, E Gagnon, L Hendren, P Lam, and V Sundaresan,
"Soot: A Java bytecode optimization framework," in CASCON First Decade High Impact Papers, 2010, pp 214-224.
[8] S Arzt et al, "Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps," Acm Sigplan Notices, vol.
[9] J FRANKENFIELD "Artificial Neural Network (ANN)." https://www.investopedia.com/terms/a/artificial-neural-networks- ann.asp (accessed.
[10] W Yang et al, "Appspear: Bytecode decrypting and dex reassembling for packed android malware," in International Symposium on Recent Advances in Intrusion Detection, 2015: Springer, pp 359-381.
[11] O.H Alliance https://tinyurl.com/2u76za (accessed.
[12] "Android Architecture." https://www.blog.neudeep.com/howto/android-architecture/210 (accessed.
[13] "Application Fundamentals." https://developer.android.com/guide/components/fundamentals (accessed.
[14] "Android Developer - "What is API Level?”." https://developer.android.com/guide/topics/manifest/uses-sdk- element#ApiLevels (accessed.
