Fakultas Ilmu Komputer
Universitas Brawijaya
707
Implementasi Perlindungan Peretasan Google In App Purchase dengan
Metode One Time Server Side Verfication, Verification Bypass Detection,
dan Obfuscator pada Aplikasi Informasi Cuaca Android
M Faizal Putra Pradana1, Agi Putra Kharisma2, Komang Candra Brata3 Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya
Email: 1faizal11011@gmail.com, 2agi@ub.ac.id, 3k.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
1. PENDAHULUAN
Sistem In-app Purchase adalah salah satu service dari Google Play yang memungkingkan pengembang aplikasi untuk menjual konten digital dalam aplikasi (Android Developer, 2014). Akan tetapi piracy atau pembajakan terhadap konten berbayar yang disediakan pengembang masih banyak terjadi. Menurut MobileSoftwareWorld Pada tahun 2010,
developer Android kehilangan sekitar 70%
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.
2. PERETASAN IN APP PURCHASE DENGAN VIRTUALSWINDLER
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
ads (iklan), backup dan restore aplikasi, serta melakukan bypass pada sistem In App Purchase
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. 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.
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. Implementasi dilakukan pada Android dengan
build kit SDK 22.
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.
Gambar 3. Alur Metodologi Penelitian
4. STRATEGI PENGAMANAN 4.1. Kriteria Pengamanan Sistem In App Purchase
VirtualSwindler melakukan emulasi pada proses signatureverification dari sistem Google
In App Purchase. Jadi hal kedua yang perlu 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.
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.
Berdasarkan penjelasan diatas, dapat disimpulkan beberapa kriteria dalam mengamankan In App Purchase. Kriteria tersebut menjadi kebutuhan fungsional yang perlu dipenuhi oleh sistem.
Tabel 1. Kebutuhan fungsional pengamanan Sistem
In App Purchase
No. Nama Fungsi Deskripsi
1
Mendeteksi apakah proses verifikasi otentik
atau tidak
Fungsi ini bertujuan untuk mendeteksi apakah proses verifikasi otentik atau tidak
2
Fungsi ini bertujuan untuk mendeteksi apakah hasil
Fungsi ini bertujuan untuk menyediakan item premium hanya kepada hasil pembelian yang otentik.
4.1. Metode Pengamanan
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.
Gambar 4. Class Diagram Library In App Purchase
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.
Base64 adalah class yang berfungsi untuk melakukan encoding dan decoding dengan algoritma Base64. Proses decoding dan encoding akan digunakan pada signature verification. Kemudian terdapat class Security yang befungsi untuk melakukan proses verfikasi dengan Base64. Proses verifikasi dilakukan dengan menggunakan public key dari aplikasi kita, data pembelian otentik, serta
signature.
Untuk menghambat serangan peretas terhadap In App Purchase perlu dilakukan deteksi terhadap manipulasi proses signature verification. Peretas menggunakan metode fake verify yang menggantikan proses verifikasi 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 key (Kim & Kim, 2016). Algoritma Fake Purchase Data verification digambarkan seperti pada Gambar 5.
Data proses pembelian dianggap sukses, maka di indikasi bahwa proses itu melalui fakeverify. 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
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
verifyPurchase 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
dijelaskan sebelumnya. IabSecureVerification adalah class yang merupukan turunan dari class
IabHelper dari library GoogleIn App Purchase. IabSecureVerification menambahkan unsur sekuritas yakni fake verification. Kemudian terdapat ServerVerify yang membantu koneksi ke dedicated server dalam proses server-side verification. Terdapat pula class
DataObfuscation yang berfungsi untuk melakukan obfuscate pada data SharedPreferences dengan bantuan dari library SecurePreferences.
Terdapat class–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
purchase yang berasosiasi dengan IabSecureVerification. MainActivity memiliki hubungan asosiasi dua arah terhadap IAPTask yang merupakan AsyncTask. IAPTask berfungsi untuk mengirim data pembelian untuk
server verification, serta menerima hasil verifikasi tersebut.
Gambar 9. Screen Flow WeatherKnight
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.
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.
6. TINGKAT KEBERHASILAN PENGAMANAN
Dalam mengetahui tingkat keberhasilan pengamanan Sistem In App Purchase akan dilakukan dengan 2 tahap. Yakni validasi dengan kebutuhan fungsional pengamanan In App Purchase dan pengujian tingkat keberhasilan.
Pengujian validasi pengamanan sistem In App Purchase menguji apakah sistem tersebut 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
In App Purchase telah memenuhi kriteria sistem
In App Purchase yang aman.
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.
Analisis dari hasil pengujian tingkat keberhasilan perlindungan sistem In App Purchase dilakukan dengan membandingkan hasil uji dari pembelian pada peretasan aplikasi tanpa perlindungan dan dengan perlindungan In App Purchase. Hal ini dilakukan untuk mengetahui tingkat keberhasilan perlindungan sistem In App Purchase dalam menghalau peretasan dengan LuckyPatcher.
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
Pembelian Sukses Pembelian Gagal
Peretasan Unauthenti c Saved Purchase
Pembelian Sukses Pembelian Gagal
Dalam penelitiannya Mulliner melakukan pengujian ketahanan pengaman In App Purchase pada 85 aplikasi Android. Prosedur pengujian yang dilakukan adalah, pertama melakukan patch menggunakan
VirtualSwindler, yang kedua adalah melakukan 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.
Proses pengujian dilakukan pada 2 jenis kasus. Yakni ketika sistem di retas dengan fitur
verification bypass dan ketika sistem menggunakan fitur save purchase dari
LuckyPatcher. Sistem tanpa perlindungan In App Purchase selalu berhasil diretas 2 jenis 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 Purchase. Ini membuktikan bahwa sistem In App Purchase terbukti berhasil melindungi peretasan sistem In App Purchase dari peretasan menggunakan LuckyPatcher.
DAFTAR PUSTAKA
Android Developer, G. (2014). In-app Billing. Dipetik September 12, 2016, dari https://developer.Android.com/Google /play/billing/index.html
AppIndex. (2015). Developers Reveal High Piracy Statistics Popular Android Apps. Dipetik September 12, 2016, dari
http://appindex.com/blog/developers- reveal-high-piracy-statistics-popular-Android-apps/
ChelpuS. (2014). Lucky Patcher. Diambil kembali dari
https://lucky-patcher.netbew.com/
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).
Kim, H., & Kim, S.-w. (2016). Securing Android In-app Billing Service against Automated Attacks. Suwon:
International Journal of Security and Its Applications.
Kovacheva, A. (2013). Efficient Code
Obfuscation for Android. Luxemburg: Université du Luxembourg.
