Implementasi Perlindungan Peretasan Google In App Purchase dengan Metode One Time Server Side Verfication, Verification Bypass Detection, dan Obfuscator pada Aplikasi Informasi Cuaca Android
Vol. 1, No. 8, Juni 2017, hlm. 707-714 http://j-ptiik.ub.ac.id
Implementasi Perlindungan Peretasan Google In App Purchase dengan
Metode One Time Server Side Verfication, Verification Bypass Detection,
dan Obfuscator pada Aplikasi Informasi Cuaca Android
1 2 3 M Faizal Putra Pradana , Agi Putra Kharisma , Komang Candra BrataProgram Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya 1 2 3 Email: faizal11011@gmail.com, agi@ub.ac.id, k.candrabrata@ub.ac.id
Abstrak
Sistem In App Purchase merupakan salah satu fitur dari Google Play dimana pengembang dapat menjual beberapa konten tambahan dari aplikasi yang telah dibangun dan dipasarkan melalui Google Play. Akan tetapi sistem In App Purchase dapat diretas menggunakan sistem peretas VirtualSwindler. LuckyPatcher merupakan salah satu contoh dari sistem VirtualSwindler yang dapat memanipulasi proses verifikasi dan menyimpan data pembelian yang tidak otentik pada perangkat pengguna. Sistem pengamanan kombinasi 3 metode, Server Side Verification, Verification Bypass Detection, dan Obfuscator, dapat melindungi sistem In App Purchase pada studi kasus aplikasi informasi cuaca dari peretasan LuckyPatcher dengan tingkat akurasi 100%. Verification Bypass Detection dapat mendeteksi apakah proses verifikasi otentik atau tidak. Server Side Verification dapat melakukan tes keotentikan data pembelian yang tersimpan pada perangkat tanpa manipulasi sistem In App Purchase yang ada didalam perangkat pengguna. Obsfucator dapat mengamankan data aplikasi, terutama data hasil verifikasi data pembelian.
Kata Kunci: android, In App Purchase, perlindungan peretasan, Virtualswindler, Luckypatcher
Abstract
In App Purchase System is one of Google Play’s features that allows developers to sell additional
contents on applications that available on Google Play. But the In App Purchase System has its
shortcomings, it can be hacked by VirtualSwindler system. LuckyPatcher is an example of
VirtualSwindler system that able to manipulate signature verification process and save unauthentic
purchase data into the local device system. The combination of 3 security methods, Server Side
Verification, Verification Bypass Detection, dan Obfuscator, successfuly secure the In App Purchase
system of a Weather Information App from the attacks of LuckyPatcher with 100% of accuracies .
Verification Bypass Detection will determine wether the verification process is authentic or not. Server
Side Verification will check the authenticity of saved purchase data without the worries of being
manipulated by the compromised In App Purchase system. Obsfucator can keep the saved data secure
from unauthentic modifications.Keywords: android, In App Purchase, system defense, Virtualswindler, Luckypatcher
potensi keuntungannya akibat pembajakan 1. konten berbayar. Developer aplikasi Monument
PENDAHULUAN
Valley menyatakan hanya 5% dari pengguna Sistem In-app Purchase adalah salah satu aplikasi berbayarnya yang tidak menggunakan service dari Google Play yang memungkingkan aplikasi bajakan (AppIndex, 2015). Dalam pengembang aplikasi untuk menjual konten penelitiannya, Muller mendapatkan 60% digital dalam aplikasi (Android Developer, aplikasi dengan InAppPurchase dapat di retas 2014). Akan tetapi piracy atau pembajakan secara automatis dengan menggunakan terhadap konten berbayar yang disediakan
VirtualSwindler. VirtualSwindler merupakan pengembang masih banyak terjadi. Menurut salah satu teknik peretasan InAppPurchase
MobileSoftwareWorld Pada tahun 2010, popular di kalangan pengguna Android yang
developer Android kehilangan sekitar 70% Fakultas Ilmu Komputer Universitas Brawijaya
707 ingin memperoleh konten berbayar secara gratis. VirtualSwindler memanfaatkan kelemahan proses bisnis Google InAppPurchase pada Android dengan melakukan emulasi dan manipulasi pada Market Billing Service (Mulliner et al., 2014).
Terdapat metode yang dapat dilakukan
developer untuk mengatasi peretasan In App Purchase . Metode tersebut antara lain adalah server signature verification. Sebagian besar
aplikasi menggunakan sistem verifikasi lokal pada Android seperti Angry Bird, Temple Run, Dead Trigger, dan lain-lain (Mulliner et al., 2014). Padahal teknik VirtualSwindler mampu memanipulasi proses tersebut. Kemudian terdapat metode verfikasi server yang biasanya digunakan pada aplikasi dengan fitur utama yang harus di akses secara online contoh nya aplikasi chatting seperti Line dan game online seperti Clash of Clan. Metode ini menyimpan data pembelian user pada dedicated server (bukan server market Google) dan untuk mengakses data pembelian itu, user diharuskan senantiasa terkoneksi dengan internet. Terdapat pula metode bypass detection. Akan tetapi metode tersebut hanya dapat melakukan deteksi proses verifikasi saja tanpa memperhatikan keotentikan data hasil pembelian (Kim & Kim, 2016).
Metode pengamanan yang ditawarkan penulis adalah kombinasi dari one time server side verification, verification bypass detection, dan obfuscator untuk mengatasi serangan dari VirtualSwindler. Penulis menggunakan contoh aplikasi informasi cuaca yang dilengkapi dengan fitur In App Purchase sebagai studi kasus. VirtualSwindler yang digunakan adalah aplikasi LuckyPatcher.
In-app Purchase adalah salah satu service dari Google Play yang memungkingkan pengembang aplikasi untuk menjual konten digital dalam aplikasi. Proses bisnis Google In- app Purchase terdiri dari 3 komponen. Google Play server yang menangani transaksi finansial. Lalu aplikasi Google Play yang terinstall pada perangkat Android pengguna yang melakukan request penagihan dari pembelian konten pada suatu aplikasi oleh akun pengguna. Request nantinya akan disampaikan pada server. Alur proses In App Purchase secara global digambarkan pada Gambar 1.
Pengembang harus terlebih dahulu mendaftarkan diri dan aplikasinya ke Google Play dan in-app purchase service. Public key dari aplikasi akan di-generate untuk proses pembelian. Pengembang kemudian menyisipkan kode sesuai dengan API Google
In-app-purchase service . Setiap konten yang
ingin dijual harus terdaftar pada Google Developer Console. Dalam proses transaksi, di-
generate data pembelian dari item yang terdaftar pada Google In-app purchase service.
Diperlukan public key dari aplikasi dan data pembelian untuk verifikasi transaksi.
Gambar 1. Alur Proses In App Purchase Sumber: (Kim & Kim, 2016)
VirtualSwindler adalah salah satu jenis penyerangan terhadap sistem in-app purchase Google. Kim menemukan bahwa kunci utama dari peretasan In App Purchase adalah tentang bagaimana peretas dapat melakukan bypass pada signature verification. VirtualSwindler mampu memberikan konten yang diinginkan pengguna secara cuma-cuma dengan mengacaukan proses signature verification. VirtualSwindle dapat melakukan emulasi proses bisnis In App Purchase dan memanipulasi proses signature verification. VirtualSwindle mengubah method verification menjadi fake verification, lalu melakukan generate Intent yang membuat seolah-olah proses transaksi berhasil.
Lucky Patcher adalah sebuah aplikasi Android yang berisi alat-alat untuk memodifikasi file aplikasi Android. Beberapa fitur dari Lucky Patcher adalah menghilangkan
2. PERETASAN IN APP PURCHASE DENGAN VIRTUALSWINDLER
ads (iklan), backup dan restore aplikasi, serta
melakukan bypass pada sistem In App Purchase pada suatu aplikasi. Untuk menggunakan fitur- fitur dari Lucky Patcher, perangkat Android pengguna harus sudah memiliki akses Root. Dalam melakukan bypass sendiri Lucky Patcher memiliki 2 opsi. Pertama adalah hanya melakukan bypass pada proses verifikasi. Kedua adalah melakukan bypass pada proses verifikasi serta menyimpan data pembelian palsu statis secara permanen (ChelpuS, 2014).
Gambar 2. Alur Proses Virtual Swindler dalam meretas In App Purchase Sumber: (Kim & Kim, 2016)
3. METODOLOGI PENELITIAN
Metodologi dari penelitian ini terdiri dari studi literatur, rekayasa kebutuhan sistem In
App Purchase , rekayasa kebutuhan aplikasi
informasi cuaca, perancangan sistem In App
Purchase , perancangan aplikasi informasi
cuaca, implementasi, pengujian dan analisis, serta pengambilan kesimpulan dan saran. Alur dari metodologi penelitian digambarkan pada Gambar 3.
Tahap studi literatur pada penelitian ini adalah mempelajari beberapa sumber pustaka yang berkaitan dengan perlindungan In App
Purchase pada aplikasi Android. Sumber pustaka berasal dari buku, jurnal, dan website.
Gambar 3. Alur Metodologi Penelitian 4.
STRATEGI PENGAMANAN
Setelah dilakukan implementasi, akan dilakukan pengujian. Pengujian yang dilakukan adalah validasi sistem pengamanan dan sistem aplikasi informasi cuaca. Selain itu akan dilakukan pula pengujian tingkat keberhasilan sistem pengamanan. Tahap terakhir adalah pengambilan kesimpulan dan saran. Kesimpulan diambil dari hasil pengujian dan analisis. Sehingga kesimpulan pada penelitian ini mengacu pada uji vailidasi dan pengujian tingkat keberhasilan. Lalu dijelaskan pula saran untuk menyempurnakan pengmbangan aplikasi sebagai acuan penelitian selanjutnya.
Tahap selanjutnya ada perancangan. Tahapan perancangan dilakukan dengan berbasis Object Oriented. Perancangan dilakukan pada perancangan strategi pengamanan in-app purchase serta penerapannya pada aplikasi informasi cuaca. Tahap selanjutnya implementasi kode berdasarkan perancangan yang telah dilakukan.
4.1. Kriteria Pengamanan Sistem In App Purchase
Penelitian ini berfokus tentang bagaimana melindungi sistem In App Purchase pada aplikasi informasi cuaca dari peretasan yang dilakukan dengan VirtualSwindler. Berdasarkan teori tentang sistem Google In App
Purchase pada pembahasan nomor 2, dapat
diambil beberapa poin penting pada proses In
App Purchase yang perlu capai dalam
pengamanan. Pertama adalah perencanaan penyimpanan data pembelian pengguna agar tidak tersentuh oleh pihak luar. Selain aman, lokasi penyimpanan tersebut harus dapat dengan mudah dijangkau oleh aplikasi tanpa perlu koneksi internet. Disini penulis menggunakan salah satu fitur Google Play Service dalam penyimpanan data pembelian secara lokal. Data yang tersimpan akan masuk ke dalam cache Google Play Service yang sulit diakses pihak luar.
Tahap rekayasa kebutuhan dibagi menjadi 2 jenis, rekayasa kebutuhan aplikasi cuaca dan rekayasa kebutuhan in-app purchase. Rekayasa kebutuhan aplikasi cuaca dilakukan dengan observasi. Sedangkan pada in-app purchase dilakukan dengan melakukan sepsifikasi berdasarkan riset dan jurnal penelitian. Hal tersebut dilakukan untuk menentukan kebutuhan pengamanan in-app purchase.
Implementasi dilakukan pada Android dengan build kit SDK 22.
VirtualSwindler melakukan emulasi pada proses signature verification dari sistem Google
Terdapat class SkuDetails yang merupakan objek representasi dari detail produk yang ditawarkan aplikasi dan tersedia pada store. Class Purchase yang merupakan representasi dari data pembelian yang dilakukan oleh pengguna terhadap aplikasi. Purchase merepresentasikan beberapa elemen purchase seperti tipe item, SKU, waktu purchase, token pembelian, dan signature yang digunakan saat pembelian. Signature ini yang nantinya akan digunakan untuk verfikasi.
Jika dengan menggunakan Fake Purchase
Purchase Data verification digambarkan seperti pada Gambar 5.
key (Kim & Kim, 2016). Algoritma Fake
original. Fake verify mampu melakukan generate intent pembelian sukses tanpa perlu melalui proses pembayaran. Salah satu cara untuk mengetahui apakah intent tersebut ter generate melaui fake verify adalah dengan memancing peretas menggunakan fake public
verification . Peretas menggunakan metode fake verify yang menggantikan proses verifikasi
Untuk menghambat serangan peretas terhadap In App Purchase perlu dilakukan deteksi terhadap manipulasi proses signature
signature .
yang befungsi untuk melakukan proses verfikasi dengan Base64. Proses verifikasi dilakukan dengan menggunakan public key dari aplikasi kita, data pembelian otentik, serta
verification . Kemudian terdapat class Security
Base64 adalah class yang berfungsi untuk melakukan encoding dan decoding dengan algoritma Base64. Proses decoding dan encoding akan digunakan pada signature
Gambar 4. Class Diagram Library In App Purchase
In App Purchase . Jadi hal kedua yang perlu
Sistem In App Purchase pada aplikasi ini dirancang sesuai dengan Google Developer guidelines dengan memanfaatkan implementasi library In App Purchase utility dari Google. Pada library tersebut terdapat beberapa class seperti yang ditunjukkan oleh Gambar 4. Class IabHelper adalah class utama dari library tersebut. Class tersebut memfasilitasi pemanggilan segala jenis proses yang berhubungan dengan In App Purchase. Pada activity IabHelper tempat instansiasi di panggil dalam beberapa fase. Pertama adalah saat melakukan persiapan sitem In App Purchase. Kemudian di fase pembelian In App Purchase. Selanjutnya di fase ketika pembelian telah selesai. Yang terakhir adalah di fase pemeriksaan apakah pengguna mendapatkan item yang diinginkan atau tidak.
Fungsi ini bertujuan untuk menyediakan item premium hanya kepada hasil pembelian yang otentik.
3 Menyediakan item premium hanya kepada hasil pembelian yang otentik.
2 Mendeteksi apakah hasil pembelian yang tersimpan otentik atau tidak Fungsi ini bertujuan untuk mendeteksi apakah hasil pembelian yang tersimpan otentik atau tidak
Fungsi ini bertujuan untuk mendeteksi apakah proses verifikasi otentik atau tidak
1 Mendeteksi apakah proses verifikasi otentik atau tidak
No. Nama Fungsi Deskripsi
Tabel 1. Kebutuhan fungsional pengamanan Sistem In App Purchase
Berdasarkan penjelasan diatas, dapat disimpulkan beberapa kriteria dalam mengamankan In App Purchase. Kriteria tersebut menjadi kebutuhan fungsional yang perlu dipenuhi oleh sistem.
Selain signature verification pada proses pembelian, VirtualSwindler Lucky Patcher sendiri memiliki satu fitur lain. Fitur tersebut adalah menyimpan data pembelian yang palsu secara permanen. Hal ini dapat menipu aplikasi bahwa data tersebut berasal dari Google Play Server dan otentik. Diperlukan mekanisme yang mampu melakukan pengecekan data tersebut tanpa pengaruh emulasi dari dalam perangkat pengguna.
diamankan adalah proses verifikasi yang terjadi di dalam perangkat user. Kita mungkin tidak dapat mengamankan secara penuh proses verifikasi, akan tetapi sistem harus dapat mendeteksi apakah proses verifikasi yang sedang berjalan otentik atau tidak.
4.1. Metode Pengamanan
Data proses pembelian dianggap sukses, maka di indikasi bahwa proses itu melalui fake verify. Jika tidak sukses, kita dapat memberikan data asli untuk melakukan proses verifikasi original. Ketika proses verifikasi sukses dengan menggunakan public key asli, maka pembelian sukses. Jika tidak maka pembelian gagal. Mekanisme fake verfication dapat diterapkan pada IabHelper.
Gambar 5. Algoritma Fake Purchase Data Verification
Server side Signature verification adalah salah satu cara melakukan verifikasi signature pada saat pembelian konten melalui In App
Purchase . Signature Verification sendiri adalah
proses verifikasi apakah data yang ingin didapatkan sudah sesuai dengan public key yang diberikan. Pada metode ini proses verifikasi utama dilakukan pada remote server, sehingga virtual swindler akan kesushan dalam memanipulasi proses verifikasi hanya dengan menganalisa kode program.
Pada penelitian ini server side verification dimanfaatkan sebagai sarana pengecekan data pembelian yang tersimpan. Seperti yang dijelaskan pada Gambar 6, program terlebih dahulu melakukan verfikasi secara lokal dengan memanfaatkan library In App Purchase dari Google. Kemudian ketika sukses, program akan mengirimkan data Response Code, data pembelian, serta signature ke server. Kemudian server akan memasukkan data tersebut ke database sebagai log. Lalu akan dilakukan proses verifikasi server dengan memanfaatkan data Response code dan signature. Hasil verifikasi kemudian akan dikirimkan ke program kembali.
Pengamanan obsfucator disini akan dilakukan pada 2 level, yakni pada kode program dan pada data penyimpanan. Obsfucation pada kode program berfungsi untuk melindungi kode program agar tidak mudah dilakukan reverse engineer (Kovacheva, 2013). Untuk proses obfuscation akan diletakkan pada akhir pengembangan aplikasi dimana program akan di obsfucate menggunakan library.
Sedangkan obsfucate pada penyimpanan data dilakukan dengan cara melakukan perlindungan terhadap Shared Preferences. Shared preferences disini tidak akan menyimpan data pembelian, tetapi akan menyimpan data keotentikan data pembelian. Data keontetikan pembelian sendiri didapatkan dari proses server verification.
Gambar 6. Alur Pengamanan Sistem In App Purchase dengan Metode Server Side Signature
Verification 5.
PENERAPAN STRATEGI PENGAMANAN
Setelah merancang strategi pengamanan, peniliti merancang penerapannya pada sistem yang akan dibangun. Gambar 7 merupakan
sequence diagram utama dari sistem
pengamanan. Proses pengamanan dibagi menjadi 3 tahapan. Pertama adalah tahapan dalam mendeteksi apakah proses verifikasi otentik atau tidak. WeatherKnight akan memulai aplikasi dengan memanggil OnCreate(). MainActivity lalu akan memanggil fungsi launchPurchaseFlow() dari IabSecureVerification untuk menginisiasi pembelian. IabSecreVerification akan memanggil getBuyIntent() dari
IInAppBillingService yang akan memulai layanan pembelian dari Google Play Service.
Gambar 7. Sequence diagram sistem pembelian In App Purchase
MainActivity lalu akan memanggil fungsi handleActivityResult dari IabSecureVerification ketika item pembelian telah disetujui oleh user dan Google Play Service. IabSecureVerification kemudian akan menginisiasi objek Purchase berdasarkan receipt dari Google Play untuk di verifikasi. Pada objek IiabSecure verification ini pula akan dilakukan proses fake verification seperti yang dijelaskan pada Activity Diagram. Proses verifikasi akan dilakukan menggunakan fungsi
verify Purchase pada objek Security. Setelah
proses verifikasi selesai maka hasil verifikasi akan di kembalikan ke MainActivity.
Lalu masuk ke tahapan kedua dalam mendeteksi apakah hasil pembelian yang tersimpan otentik atau tidak. MainActivity akan dimuat ulang melalui fungsi startActivity. MainActivity lalu akan menjalankan fungsi execute dari iapTask yang merupakan asynctask. Asynctask tersebut akan melakukan request server verification dari data pembelian yang tersimpan melalui fungsi makeHttpRequest() dari JSONParser.
JSONParser akan mengembalikan hasil server verification ke MainActivity. Kemudian masuk tahapan ketiga dalam menyediakan In
App Purchase
hanya kepada hasil pembelian otentik. Hasil verifikasi server akan diperiksa oleh MainActivity. Jika terbukti menggunakan data pembelian palsu, maka MainActivity tidak akan melakukan unlock versi premium. Jika tidak maka fitur premium akan di unlock. Setelah itu MainActivity akan melakukan inisialisasi objek SecuredPreferences pada objek DataObfuscation penyimpanan data verifikasi. Kemudian melakukan penyimpanan data verifikasi dengan memanggil fungsi edit() dari SecuredPreferences.
Perancangan class diagram adalah salah satu kegiatan yang dilakukan dalam menggambarkan class-class yang terlibat pada sistem dan relasinya. Gambar 8 merupakan
class diagram dari sistem Pengamanan Aplikasi
Informasi Cuaca dengan Sistem In App Purchase .
Gambar 8. Class diagram Pengamanan Aplikasi Informasi Cuaca dengan Sistem In App Purchase
Class pada package Util adalah class-class
yang menyediakan fungsi utilitas yang menunjang berjalannya aplikasi. Package Util disini merupakan library In App Purchase yang digambarkan pada Gambar 4 dan telah
- –class yang berhubungan dengan berjalannya aktivitas utama suatu aplikasi. MainActivity adalah anak class dari FragmentActivity yang menyediakan fungsi layout tampilan dan proses logik. MainActivity memiliki atribut yang berhubungan dengan
App Purchase dan pengujian tingkat keberhasilan.
mengetahui tingkat keberhasilan perlindungan sistem In App Purchase dalam menghalau peretasan dengan LuckyPatcher.
App Purchase . Hal ini dilakukan untuk
hasil uji dari pembelian pada peretasan aplikasi tanpa perlindungan dan dengan perlindungan In
Purchase dilakukan dengan membandingkan
Analisis dari hasil pengujian tingkat keberhasilan perlindungan sistem In App
Pengujian validasi pengamanan aplikasi informasi cuaca dengan sistem In App Purchase menguji apakah sistem tersebut mampu memenuhi kebutuhan fungsional dari sistem tersebut. Sistem mampu mendapatkan hasil ideal dari setiap kasus yang ada. Ini membuktikan bahwa sistem mampu memenuhi kebutuhan fungsional baik sebagai aplikasi informasi cuaca serta pada sisi pengamanan In App Purchase .
In App Purchase telah memenuhi kriteria sistem In App Purchase yang aman.
memenuhi kriteria sistem In App Purchase yang aman. Terdapat 3 tipe kasus pengujian yakni ketika tidak diretas, lalu di patch pada proses verifikasi, dan penyimpanan data pembelian yang tidak valid. Sistem In App Purchase mampu mendapatkan hasil ideal dari setiap kasus yang ada. Ini membuktikan bahwa sistem
App Purchase menguji apakah sistem tersebut
Pengujian validasi pengamanan sistem In
Dalam mengetahui tingkat keberhasilan pengamanan Sistem In App Purchase akan dilakukan dengan 2 tahap. Yakni validasi dengan kebutuhan fungsional pengamanan In
dijelaskan sebelumnya. IabSecureVerification adalah class yang merupukan turunan dari class IabHelper dari library Google In App Purchase. IabSecureVerification menambahkan unsur sekuritas yakni fake verification. Kemudian terdapat ServerVerify yang membantu koneksi ke dedicated server dalam proses server-side
6. TINGKAT KEBERHASILAN PENGAMANAN
Perancangan navigasi atau screen flow adalah proses merancang alur tampilan yang ditampilkan kepada user. WeatherKnight memiliki 2 tampilan, yakni tampilan utama dan tampilan pembelian. Tampilan utama terhubung dengan tampilan pembelian. Untuk menuju ke tampilan pembelian, pengguna terlebih dahulu menekan tombol Buy Premium. Screen Flow dari WeatherKnight digambarkan pada Gambar 9.
Dalam melakukan implementasi, peneliti menggunakan aplikasi informasi cuaca WeatherKnight sebagai studi kasus. WeatherKnight adalah aplikasi informasi cuaca dimana pengguna dapat melihat kondisi cuaca saat ini. Dengan fitur premium, pengguna juga dapat melihat prakiraan cuaca untuk 14 hari ke depan. WeatherKnight merupakan aplikasi Android, sehingga user dapat berinteraksi dengan sistem melaui tampilan dari WeatherKnight.
Gambar 9. Screen Flow WeatherKnight
server verification , serta menerima hasil verifikasi tersebut.
IAPTask berfungsi untuk mengirim data pembelian untuk
IabSecureVerification. MainActivity memiliki hubungan asosiasi dua arah terhadap IAPTask yang merupakan AsyncTask.
purchase yang berasosiasi dengan
Terdapat class
DataObfuscation yang berfungsi untuk melakukan obfuscate pada data SharedPreferences dengan bantuan dari library SecurePreferences .
verification . Terdapat pula class
Proses peretasan akan dilakukan pada 2 jenis aplikasi. Aplikasi tanpa perlindungan yang merupakan aplikasi informasi cuaca dengan In App Purchase tanpa perlindungan pada proses verifikasi dan penyimpanan data pembelian. Prosedur pengujian dilakukan 1 kali pada tiap tipe aplikasi sesuai dengan penelitian Mulliner (Mulliner et al., 2014). Dalam proses penelitiannya Mulliner mengambil referensi dari Davis dalam penelitiannya tentang keamanan aplikasi dan DEX Android (Davis B, 2012). Dapat diambil kesimpulan bahwa metode penyerangan VirtualSwindler akan tetap sama pada 1 tipe aplikasi yang sama karena VirtualSwindler hanya akan memperhatikan susunan DEX aplikasi dalam menentukan metode serangannya. Jadi hanya diperlukan 1 kali pengujian pada kasus-kasus tertentu untuk mengetahui tingkat keberhasilan dari metode pengamanan dalam aplikasi tertentu.
Tabel 2. Hasil pengujian tingkat keberhasilan pengamanan Sistem In App Purchase jenis peretasan hasil pembelian pada peretasan aplikasi tanpa perlindungan hasil pembelian pada peretasan aplikasi dengan perlindungan
DAFTAR PUSTAKA Android Developer, G. (2014). In-app Billing.
(2014). VirtualSwindle: An Automated
Obfuscation for Android. Luxemburg: Université du Luxembourg. Mulliner, C., Robertson, W., & Kirda, E.
International Journal of Security and Its Applications. Kovacheva, A. (2013). Efficient Code
Android In-app Billing Service against Automated Attacks. Suwon:
Kim, H., & Kim, S.-w. (2016). Securing
Davis B, S. B. (2012). I-ARM-Droid:A Rewriting Framework for In-App Reference Monitors for Android Applications. Workshop on Mobile Security Technologies (MoST).
ChelpuS. (2014). Lucky Patcher. Diambil kembali dari https://lucky- patcher.netbew.com/
dari http://appindex.com/blog/developers- reveal-high-piracy-statistics-popular- Android-apps/
Piracy Statistics Popular Android Apps . Dipetik September 12, 2016,
AppIndex. (2015). Developers Reveal High
Dipetik September 12, 2016, dari https://developer.Android.com/Google /play/billing/index.html
peretasan sistem In App Purchase dari peretasan menggunakan LuckyPatcher.
Peretasan Verificatio n Bypass Pembelian Sukses Pembelian Gagal Peretasan Unauthenti c Saved Purchase
Purchase . Ini membuktikan bahwa sistem In App Purchase terbukti berhasil melindungi
kasus peretasan. Hasil pengujian ditunjukkan pada Tabel 2. Tingkat keberhasilan dari sistem perlindungan adalah 0% dalam melindungi sistem In App Purchase dari serangan lucky patcher. Sedangkan pada sistem dengan perlindungan sistem In App Purchase , peretasan tidak pernah membuahkan hasil dalam mendapatkan fitur premium dari aplikasi meskipun diretas dengan 2 kasus yang berbeda. Sistem perlindungan dengan kombinasi 3 metode tersebut memiliki tingkat keberhasilan 100% dalam melindungi sistem In App
LuckyPatcher . Sistem tanpa perlindungan In App Purchase selalu berhasil diretas 2 jenis
dan ketika sistem menggunakan fitur save purchase dari
verification bypass
Proses pengujian dilakukan pada 2 jenis kasus. Yakni ketika sistem di retas dengan fitur
pembelian item berbayar, ketiga adalah melakukan pengamatan pada aplikasi setelah terjadi pembelian. Pengamatan dilakukan pada 2 bagian, yakni hasil pembelian melalui tampilan aplikasi dan log hasil pembelian. Hal ini dilakukan 1 kali pada tiap aplikasi.
VirtualSwindler , yang kedua adalah melakukan
pengujian yang dilakukan adalah, pertama melakukan patch menggunakan
Purchase pada 85 aplikasi Android. Prosedur
Dalam penelitiannya Mulliner melakukan pengujian ketahanan pengaman In App
Pembelian Sukses Pembelian Gagal
Attack Against In-App. Boston: Northeastern University.