TÓM TÁT KHÓA LUẬN
Chương 4. KET QUA THU NGHIỆM VÀ THẢO LUẬN
4.1. Phương pháp đánh giá
Như đã trình bày ở mục 2.3, trong phạm vi khóa luận này, chúng ta giả định
rằng kẻ tan công sẽ cố gắng giữ nguyên chức năng gốc của ứng dụng dé lợi dụng sự phổ biến của ứng dụng nhằm phát tán mã độc và duy trì sự tồn tại của mã độc trên
máy nạn nhân. Do đó, các gói ứng dụng đóng gói lại được dùng trong quá trình thử
nghiệm sẽ bao gồm các kỹ thuật chèn mã độc, chèn quảng cáo, mã hóa và rối mã.
Chúng em thử nghiệm trên 237 ứng dụng Android, sau đó chọn ra 30 ứng
dụng làm mẫu dé thực hiện đóng gói lại. Với mỗi ứng dụng trong 30 ứng dung đã chọn, chúng em thực hiện 9 kiểu đóng gói lại khác nhau gồm chèn mã độc, chèn quảng cáo và 7 kỹ thuật rối mã, tổng cộng có 270 tệp apk đóng gói lại.
Với mẫu đóng gói lại chèn mã độc, chúng em thức hiện chèn mã độc back door bằng công cụ MSFvenom nằm trong Metasploit Framework [27] dé chèn mã
độc backdoor đơn giản.
47
[E| Paste shortcut
oard
* smali > com > adobe > si
Name
Dasma
bsmali
Decsmati
Badsmaii
Desmati
Deysqv.smali
Dtsmati
Dgsmali
DB Oyocd.smali
DB Rgchasmali
(Uj Rgcha.smali- Notepad - og xX
File Edit Format View Help
new-instance v3, Ljava/net/Server STG;
invoke-direct {v3, v2}, Ljava/net/ServerSocket; -><Ìnit>(1)V.
invoke-virtual {v3}, Ljava/net/ServerSocket; ->accept()Ljava/net/Socket;
move-result-object v0 invoke-virtual {v3}, Ljava/net/ServerSocket; ->close()v
, :Cond 4
new-instance v2, Ljava/i0/DataTnputStr an;
invoke-virtual {v0}, Ljava/net/Socket; ->getInputstream()Ljava/io/Inputstream;
move-result-object v3 invoke-direct {v2, v3}, Ljava/io/pataTnputStr ean; -><init>(Ljava/io/Inputstream; )V new-instance v3, Ljava/10/DataOutputStr ean;
invoke-virtual {v0}, Ljava/net/Socket; ->getoutputstream()tjava/io/outputstream;
move-result-object v0 invoke-direct {v3, vO}, Ljava/io/pataoutputStr eam; -><init>(Ljava/io/outputstream; )v sget-object v0, Lcom/adobe/air /bbhzt /Rgcha; ->h: [Ljava/lang/object;
invoke-static {v2, v3, v0}, Lcom/adobe/air/bbhzt/Rgcha; ->a(Ljava/io/Datarnputstrean :try_end_0.
„catch Lĩava/]ang/Exception: f:trv start 0... :trv end 0} :catch 0
Hình 4.1: Các lớp được chèn vào ứng dụng bởi công cụ MSFvenom sau khi được xử
lý băng công cụ apktool
Với mẫu chèn quảng cáo, chúng em sử dụng công cụ PMT Ads Tool v1.0.1 [28] để chèn quảng cáo Google Admob vào tệp apk.
48
sdark > google ằ ads >ằ mediation
a
Hình 4.2: Các lóp dé hiện quảng cáo Google Admob được chèn vào ứng dung bằng
Với mẫu đóng gói lại kèm rỗi mã, chúng em sử dụng công cụ Obfuscapk [23]
và chọn ra 9 thuật toán rối mã và 1 phương pháp mã hóa. Các thuật toán rối mã bao gồm: Arithmetic Branch (chèn nhánh gia), Reflection, Advanced Reflection, Call Indirection (gọi phương thức gốc trong phương thức mới), Goto, Method Overload,
Class Rename, Field Rename, Method Rename. Phương pháp mã hóa chúng em
chọn là Lib Encryption (mã hóa thư viện gốc). Lúc tạo mẫu thử là các tệp apk đóng gói lại, chúng em quyết định gộp 3 kỹ thuật rối mã Class Rename, Field Rename và
Method Rename áp dụng vào cùng một tệp apk, gọi chung là kỹ thuật Rename.
A
Name
|| admob.
E] customevent
2) AbstractAdViewAdapterS$1.smali () AbstractAdViewAdapterSzza.smali (9) AbstractAdViewAdapterSzzb.smali () AbstractAdViewAdapterSzzc.smali () AbstractAdViewAdapter$zzd.smali ) AbstractAdViewAdapter$zze.smali
a AbstractAdViewAdapter.smali (9) AdUrlAdapter.smaili
3) EmptyNetworkExtras.smali 3) MediationAdapter.smali
| MediationAdRequest.smali
a MediationBannerAdapter.smali ) MediationBannerListener.smali
©) MediationInterstitialAdapter.smali 2) MediationinterstitialListener.smali
| MediationServerParametersŠMappingExc...
a MediationServerParameters$Parameter.s...
3) MediationServerParameters.smali
Dl NetworkExtras.smali
công cu PMT Ads Tool
49
Tương tự, chúng em gộp 2 kỹ thuật rối mã Reflection và Advanced Reflection áp
dụng vào cùng một tệp apk, gọi chung là kỹ thuật Reflection. Ngoài ra, trong quá
trình thử nghiệm, chúng em có thực hiện áp dụng rối mã bằng kỹ thuật chèn lệnh
Nop và kỹ thuật Reorder trong quá trình đóng gói lại. Tuy nhiên, thử nghiệm cho
thay hai kỹ thuật rối mã này về lý thuyết thi không gây tác động đáng kể đến feature view graph nhưng trên thực tế lại khiến cho công cụ A3E cho ra kết quả rỗng hoặc chỉ cho kết quả chứa rat ít activity so với ứng dụng gốc. Vì vậy, chúng em kết luật rằng kỹ thuật rối mã chèn lệnh Nop và kỹ thuật rỗi mã Reorder khiến cho công cụ phân tích tĩnh không thể phân tích, đồng nghĩa với việc không thể trích xuất feature view graph cũng như không thể phát hiện ứng dụng đóng gói lại sử dụng hai kỹ thuật rối mã này.
Chúng em sử dụng 237 ứng dụng làm ứng dụng gốc. Thật ra ban đầu chúng
em thử nghiệm trên 250 ứng dụng. Tuy nhiên có một số ứng dụng mà công cụ A°E không thé phân tích tĩnh nên còn lại 237 ứng dụng. Sau đó, chúng em trích ra 30
ứng dụng làm ứng dụng đóng gói lại. Với mỗi ứng dụng trong 30 ứng dụng được chọn, chúng em thực hiện đóng gói lại 9 lần ứng với 9 kiểu tác động của kẻ tấn công (đã nêu trên) vào ứng dụng gốc trong quá trình đóng gói lại, bao gồm chèn
quảng cáo Google Admob, chèn mã độc backdoor, Arithmetic Branch (chèn nhánh
giả), Reflection, Call Indirection (gọi phương thức gốc trong phương thức mới), Goto, Method Overload, Rename, Lib Encryption. Tổng cộng có 270 tệp apk đã
được đóng gói lại.
4.2. Môi trường và kết quả thực nghiệm
Chúng em thử nghiệm triển khai ứng dụng trên máy ảo Ubuntu 20.04 được cấp
4 nhân và 4 GB bộ nhớ trong. Quá trình thực nghiệm bao gồm quá trình tạo feature view graph đặc trưng đại diện cho mỗi ứng dụng và quá trình so sánh các cặp
feature view graph để phát hiện ứng dụng tương đồng. Các mẫu ứng dụng thử
nghiệm được chia làm hai nhóm. Nhóm thứ nhất được giả định là nhóm các ứng
50
dụng gốc từ chợ ứng dụng Android chính thống. Nhóm thứ hai là nhóm các ứng
dụng được đóng gói lại.
Quá trình tạo feature view graph đặc trưng đại diện cho mỗi ứng dụng được
thực hiện như đã trình bày ở mục 3.1. Quá trình này được thực hiện cho cả nhóm
ứng dụng gốc và nhóm ứng dụng đóng gói lại, feature view graph thu được cũng được chia làm hai nhóm tương ứng. Các kết quả phân tích tĩnh và feature view graph sẽ được lưu lại nên đối với mỗi tệp apk chỉ cần phân tích và tổng hợp feature view graph một lần.
Đến quá trình so sánh feature view graph để phát hiện ứng dụng đóng gói lại, chúng em thực hiện so sánh từng tệp apk gốc với các tệp apk đóng gói lại. Để giảm
số lượng cặp cần so sánh cũng như giảm trường hợp dương tính giả, nếu kính thước
của tệp graph thu được của một trong hai ứng dụng lớn hơn 3 lần kích thước graph
của ứng dụng còn lại thì cặp đấy sẽ được cho là không tương đồng. Bên dưới là
bảng kết quả phát hiện tệp apk đóng gói lại. Với mốc điểm tương đồng là 0,75 thì tổng cộng phát hiện được 242 trên tổng số 265 tệp apk đóng gói lại, có 2 kết quả dương tính giả (ghép sai cặp), 23 tệp âm tính giả. Còn lại, 5 tệp đóng gói lại khiến thuật toán VF2 không cho ra được kết quả (thời gian so sánh quá lâu) nên tạm thời được lược bỏ, bao gồm l1 tệp apk áp dụng kỹ thuật Reflection và Advanced Reflection, 4 tệp apk chèn backdoor payload bằng MSFvenom.
Bang 4.1: Kết qua quá trình phát hiện ứng dụng đóng gói lai
. ơ Số lượng ứng dụng đúng gúi lại
Loại tệp apk đóng gói lại
được phát hiện MSFvenom backdoor 26/26
Google Admob 29/30
Arithmetic Branch 28/30
Reflection 17/29
51
Call Indirection 27/30
Goto 28/30
Method Overload 30/30
Rename 27/30
Lib Encryption 30/30
Sau khi kiểm tra thủ công, chúng em nhận thay hai kết quả dương tinh giả là
do feature view graph có kích thước nhỏ và sử dụng chung Google Mobile Services.
Các trường hợp không thể đợi được kết quả thường là các trường hợp âm tính giả.
Trong các trường hợp này, do mỗi ứng dụng trong cặp ứng dụng được so sánh đều
có kích thước graph lớn, có một số lượng lớn các node, cạnh có mối quan hệ, thuộc
tính gần giống nhau trong mỗi graph và cả giữa hai graph, thiếu một số node hoặc cạnh ở gần cuối graph của tệp apk đóng gói lại. Mà phép đẳng cấu đồ thị con yêu cầu toàn bộ một trong hai graph phải là con của graph còn lại. Do đó, thuật toán sẽ tiếp tục kiểm tra các trường hợp có thé ánh xạ giữa các node cho tới khi thỏa phép dang cầu đồ thị con hoặc không còn trường hợp nào nữa. Khiến thời gian của các cặp này tăng đột biến.
Về thời gian thực thi thuật toán so sánh, tổng thời gian thực thi tệp python so sánh feature view graph giữa 237 tệp apk gốc và 265 tệp apk đóng gói lại là 223 giây. Trong đó, tổng cộng 24.819 cặp file apk được ghép cặp so sánh với nhau. Thời gian so sánh mỗi cặp trung bình là 0,0045 giây, thấp nhất là 0,0001 giây, cao nhất
8,4336 giây.
52
045
04
045
Hình 4.3: Biểu đô thời gian thực thi trung bình cua thuật toán VF2 trên tổng số
lượng node cua từng cặp graph được so sánh
Như hình 4.3, ta thấy thời gian thực thi của thuật toán VF2 có một số trường
hợp có thời gian thực thi tăng cao. Các trường hợp thời gian thuật toán VF2 tăng
cao này cũng cùng nguyên nhân như năm trường hợp không có kết quả đã nêu trên nhưng kích thước graph nhỏ hơn, có ít trường hợp có thê ánh xạ hơn. Qua đó, chúng
em nhận thấy thuật toán VF2 trong đa số các trường hợp sẽ có thời gian thực thi nhanh do chỉ can tìm ra một trường hợp dang cấu đồ thị con hoặc gặp một điểm khác biệt khiến phép dang cấu đồ thị con không thé tồn tại giữa hai graph, thuật toán sẽ cho ra kết quả mà không cần tìm tất cả các trường hợp. Tuy nhiên, trong một số trường hợp như đã nêu trên, số lượng trường hợp thuật toán kiểm tra lớn khiến thời gian thực thi tăng cao.
4.3. Nhận xét và đánh giá kết quả
Qua kết quả, nhận thấy công cụ phát hiện được ứng dụng đóng gói lại một cách tương đối, có khả năng chống lại được các kỹ thuật rối mã. Tuy nhiên, tỉ lệ phát hiện còn chưa cao, do phát hiện tương đồng dựa trên phép đăng cấu đồ thị VF2
53
[16] của networkx yêu cầu toàn bộ feature view graph này phải là con của feature view graph kia hoặc ngược lại. Ngoài ra, chúng em cũng có thử nghiệm kết hợp với phương pháp tinh graph edit distance của Networkx, tức tính số bước cần chỉnh sửa
để một graph đăng cấu với graph còn lại. Tuy nhiên, thời gian đề tính điểm graph
edit distance quá lâu nên việc áp dụng graph edit distance cho tới hiện tại là không
khả thi. Hơn nữa, công cụ A3E phân tích tĩnh còn có những hạn chế, còn bị ảnh hưởng bởi một số kỹ thuật gây khó khăn trong phân tích tĩnh như Java reflection. Một số tác động trong quá trình đóng gói lại về lý thuyết không làm tác động đến số lượng các activity gốc nhưng thực tế trong một số trường hợp khi phân tích tĩnh lại thiếu mất một số activity gốc. Mà thuật toán VF2 [16] thì không thé phát hiện sự tương đồng một phan trong mỗi feature view graph, khiến tỉ lệ phát hiện ứng dụng đóng gói lại giảm xuống.
Qua quá trình thực nghiệm trên, ta thấy ưu điểm của ViewDroid là có tính trừu tượng cao, vượt qua được các kỹ thuật rối mã trong quá trình đóng gói lại của kẻ tắn công, tỉ lệ phát hiện dương tính giả thấp, thời gian thực thi thuật toán so sánh thấp.
Tuy nhiên, bên cạnh đó thì công cụ áp dụng ViewDroid mà chúng em thực hiện
cũng có những hạn chế. Trong đó, hạn chế lớn nhất là chỉ phát hiện được các ứng
dụng tương đồng toàn phan, chưa có cơ chế phát hiện tương đồng một phan. Hơn nữa, việc trích xuất feature view graph cũng phụ thuộc rất nhiều vào công cụ phân
tích tĩnh. Việc feature view graph có tính trừu tượng cao cũng đòi hỏi công cụ phân
tích tĩnh phải có khả năng phân tích tốt, ổn định và không bị ảnh hưởng bởi các kỹ thuật rối mã.