Bagaimana cara menghindari rekayasa balik file APK?


764

Saya sedang mengembangkan aplikasi pemrosesan pembayaran untuk Android, dan saya ingin mencegah seorang hacker mengakses sumber daya, aset, atau kode sumber apa pun dari file APK .

Jika seseorang mengubah ekstensi .apk ke .zip maka mereka dapat membuka zipnya dan dengan mudah mengakses semua sumber daya dan aset aplikasi, dan menggunakan dex2jar dan dekompiler Java, mereka juga dapat mengakses kode sumber. Sangat mudah untuk merekayasa balik file Android APK - untuk lebih jelasnya lihat pertanyaan Stack Overflow Membalikkan rekayasa dari file APK ke proyek .

Saya telah menggunakan alat Proguard yang disediakan dengan Android SDK. Ketika saya merekayasa balik file APK yang dibuat menggunakan keystore dan Proguard yang ditandatangani, saya mendapatkan kode yang dikaburkan.

Namun, nama-nama komponen Android tetap tidak berubah dan beberapa kode, seperti nilai kunci yang digunakan dalam aplikasi, tetap tidak berubah. Sesuai dokumentasi Proguard, alat ini tidak dapat mengaburkan komponen yang disebutkan dalam file Manifest.

Sekarang pertanyaan saya adalah:

  1. Bagaimana saya bisa sepenuhnya mencegah rekayasa balik dari APK Android? Apakah ini mungkin?
  2. Bagaimana saya bisa melindungi semua sumber daya, aset, dan kode sumber aplikasi sehingga peretas tidak dapat meretas file APK dengan cara apa pun?
  3. Apakah ada cara untuk membuat peretasan lebih sulit atau bahkan tidak mungkin? Apa lagi yang bisa saya lakukan untuk melindungi kode sumber di file APK saya?

120
Sepertinya Anda mungkin menggunakan "keamanan karena ketidakjelasan" jika skema pemrosesan pembayaran Anda bergantung pada operasi rahasia yang tersisa dari klien.
PeterJ

43
Sudahkah Anda mempertimbangkan untuk menulis bagian-bagian penting dari kode dalam C / C ++ dan menambahkannya sebagai pustaka yang dikompilasi? Mereka dapat dibongkar menjadi kode assembly, tetapi rekayasa ulang perpustakaan besar dari assembly sangat memakan waktu.
Leo


60
Selamat datang di masalah mendasar pembuatan aset digital apa pun. Peretas dapat turun ke tingkat instruksi mesin, jadi jika komputer dapat membaca file maka dapat diretas terbuka / disalin, tidak ada jumlah kebingungan atau DRM yang dapat sepenuhnya menghentikan peretas yang ditentukan. Jika Anda memerlukan keamanan maka pastikan bahwa kunci pribadi tidak pernah dalam sumber, dan tahu pada tahap desain bahwa hanya isolasi (remote dan / atau perangkat keras khusus) yang dapat melindunginya.
Keith

16
Perhatikan bahwa tergantung pada apa yang dilakukan oleh aplikasi pemrosesan pembayaran Anda, mungkin ada kebijakan dan kebijakan hukum yang memengaruhi aplikasi Anda dan dapat berpotensi membuat Anda terkena hukuman berat: lihat kepatuhan PCI, dimulai dengan pcicomplianceguide.org/pcifaqs.php#11 .
bloopletech

Jawaban:


372

 1. Bagaimana saya bisa sepenuhnya menghindari rekayasa balik dari APK Android? Apakah ini mungkin?

AFAIK, tidak ada trik untuk sepenuhnya menghindari rekayasa terbalik.

Dan juga sangat baik dikatakan oleh @inazaruk: Apa pun yang Anda lakukan pada kode Anda, penyerang potensial dapat mengubahnya dengan cara apa pun yang menurutnya layak . Anda pada dasarnya tidak dapat melindungi aplikasi Anda dari modifikasi. Dan perlindungan apa pun yang Anda masukkan di sana dapat dinonaktifkan / dihapus.

 2. Bagaimana saya bisa melindungi semua sumber daya, aset, dan kode sumber aplikasi sehingga peretas tidak dapat meretas file APK dengan cara apa pun?

Anda dapat melakukan berbagai trik untuk membuat peretasan menjadi lebih sulit. Misalnya, gunakan kebingungan (jika itu kode Java). Ini biasanya memperlambat reverse engineering secara signifikan.

 3. Apakah ada cara untuk membuat peretasan lebih tangguh atau bahkan tidak mungkin? Apa lagi yang bisa saya lakukan untuk melindungi kode sumber di file APK saya?

Seperti yang dikatakan semua orang, dan seperti yang mungkin Anda ketahui, tidak ada keamanan 100%. Tetapi tempat untuk memulai untuk Android, yang telah dibangun Google, adalah ProGuard. Jika Anda memiliki opsi untuk menyertakan pustaka bersama , Anda dapat memasukkan kode yang diperlukan dalam C ++ untuk memverifikasi ukuran file, integrasi, dll. Jika Anda perlu menambahkan pustaka asli eksternal ke folder pustaka APK pada setiap bangunan, maka Anda dapat menggunakannya dengan saran di bawah ini.

Letakkan pustaka di jalur pustaka asli yang secara default adalah "libs" di folder proyek Anda. Jika Anda membuat kode asli untuk target 'armeabi', letakkan di bawah libs / armeabi . Jika dibangun dengan armeabi-v7a maka letakkan di bawah libs / armeabi-v7a.

<project>/libs/armeabi/libstuff.so

1
Untuk transaksi pembayaran, saya telah menggunakan standar ISO 8585, sekarang skema untuk standar ini adalah pasangan kunci-nilai menggunakan koleksi HashMap Java & ketika saya melakukan reverse engineering di apk saya akan mendapatkan semua skema. Apakah mungkin untuk menghindari skema dapatkan diekspos melalui rekayasa terbalik.? Bisakah saran terakhir Anda tentang perpustakaan Berbagi berguna dalam kasus ini? Doy Anda punya tautan apa pun sehingga saya bisa mendapatkan pustaka berbagi di android.
sachin003

4
bagaimana mengenkripsi string Anda dalam kode dan mendekripsi mereka saat runtime? Jika Anda melakukan dekripsi di server jauh, seperti yang disarankan orang lain, Anda tidak mendapatkan masalah bahwa kunci dekripsi ada di sumber.
kutschkem

ya, enkripsi itu cara, tetapi tidak pasti tidak di-Hacked. Jika saya mengenkripsi String untuk mendekripsi mereka, saya perlu satu id unik dalam kode. dan jika ada yang bisa mendekompilasi maka akan sangat mudah untuk mendapatkan id Unik.
Bhavesh Patadiya

mengapa Anda menambahkan hal-hal yang Diedit ? itu semua biasa.
Mohammed Azharuddin Shaikh

@ hotveryspicy: ya saya sekarang telah menghapus tanda "diedit" dari answer.i telah mengedit jawaban saya karena dia ingin tahu lebih banyak tentang bagaimana Share libraries berguna dalam kasus ini.
Bhavesh Patadiya

126

AFAIK, Anda tidak dapat melindungi file di direktori / res lagi daripada yang dilindungi saat ini.

Namun, ada beberapa langkah yang dapat Anda ambil untuk melindungi kode sumber Anda, atau setidaknya apa yang dilakukannya jika tidak semuanya.

  1. Gunakan alat seperti ProGuard. Ini akan mengaburkan kode Anda, dan membuatnya lebih sulit untuk dibaca ketika didekompilasi, jika bukan tidak mungkin.
  2. Pindahkan bagian paling kritis dari layanan keluar dari aplikasi, dan ke layanan web, tersembunyi di balik bahasa sisi server seperti PHP. Misalnya, jika Anda memiliki algoritme yang membuat Anda jutaan dolar untuk menulis. Anda jelas tidak ingin orang lain mencurinya dari aplikasi Anda. Pindahkan algoritme dan minta proses data pada server jauh, dan gunakan aplikasi untuk hanya menyediakannya dengan data. Atau gunakan NDK untuk menuliskannya secara asli ke dalam file .so, yang jauh lebih kecil kemungkinannya untuk diuraikan daripada apks. Saya tidak berpikir decompiler untuk file .so bahkan ada seperti sekarang (dan bahkan jika itu, tidak akan sebagus decompiler Java). Selain itu, seperti yang disebutkan @nikolay dalam komentar, Anda harus menggunakan SSL saat berinteraksi antara server dan perangkat.
  3. Saat menyimpan nilai pada perangkat, jangan menyimpannya dalam format mentah. Misalnya, jika Anda memiliki game, dan Anda menyimpan jumlah dalam mata uang game yang dimiliki pengguna dalam SharedPreferences. Mari kita asumsikan itu 10000koin. Alih-alih menyimpan 10000secara langsung, simpan menggunakan algoritma seperti ((currency*2)+1)/13. Jadi, bukannya 10000Anda menabung1538.53846154 ke dalam SharedPreferences. Namun, contoh di atas tidak sempurna, dan Anda harus bekerja untuk menghasilkan persamaan yang tidak akan kehilangan mata uang karena kesalahan pembulatan, dll.
  4. Anda dapat melakukan hal serupa untuk tugas-tugas sisi server. Sekarang sebagai contoh, mari kita ambil aplikasi pemrosesan pembayaran Anda. Katakanlah pengguna harus melakukan pembayaran $200. Alih-alih mengirim $200nilai mentah ke server, kirim serangkaian nilai yang lebih kecil, yang telah ditentukan sebelumnya, yang ditambahkan $200. Misalnya, miliki file atau tabel di server Anda yang menyamakan kata dengan nilai. Jadi katakanlah itu Charliesesuai dengan $47, dan Johnuntuk $3. Jadi alih-alih mengirim $200, Anda dapat mengirim Charlieempat kali danJohnempat kali. Di server, tafsirkan apa yang mereka maksud dan tambahkan. Ini mencegah seorang peretas dari mengirimkan nilai-nilai sewenang-wenang ke server Anda, karena mereka tidak tahu kata apa yang sesuai dengan nilai apa. Sebagai ukuran keamanan tambahan, Anda dapat memiliki persamaan yang mirip dengan poin 3 untuk ini juga, dan mengubah kata kunci setiap nbeberapa hari.
  5. Akhirnya, Anda dapat memasukkan kode sumber acak yang tidak berguna ke dalam aplikasi Anda, sehingga peretas mencari jarum di tumpukan jerami. Masukkan kelas acak yang berisi cuplikan dari internet, atau hanya fungsi untuk menghitung hal-hal acak seperti urutan Fibonacci. Pastikan kelas ini dikompilasi, tetapi tidak digunakan oleh fungsionalitas sebenarnya dari aplikasi. Tambahkan cukup banyak kelas palsu ini, dan peretas akan kesulitan menemukan kode asli Anda.

Secara keseluruhan, tidak ada cara untuk melindungi aplikasi Anda 100%. Anda bisa membuatnya lebih sulit, tetapi bukan tidak mungkin. Server web Anda dapat dikompromikan, peretas dapat mengetahui kata kunci Anda dengan memantau beberapa jumlah transaksi dan kata kunci yang Anda kirim untuk itu, peretas dapat dengan susah payah menelusuri sumber dan mencari tahu kode mana yang merupakan tiruan.

Anda hanya bisa melawan, tetapi tidak pernah menang.


136
Alih-alih melakukan trik dengan nilai yang Anda kirim ke server Anda, gunakan SSL dan validasikan sertifikat server dengan benar. Keamanan oleh ketidakjelasan umumnya merupakan ide yang buruk.
Nikolay Elenkov

48
Anda dapat memasukkan kode sumber acak yang tidak berguna ke dalam aplikasi Anda . Ini juga tidak bisa membantu. Ini hanya akan menggembungkan aplikasi Anda, sekaligus mempersulit pemeliharaannya.
Anirudh Ramanathan

4
Anda juga bisa berpura-pura menggunakan kode tidak berguna dan mengirim data ke server yang akan membuangnya. Keamanan palsu mungkin, tetapi menyebalkan bagi peretas potensial, kan?
Benoit Duffez

19
Jika algoritme Anda bernilai satu juta dolar, maka hanya karena tidak ada dekompiler untuk .sofile tidak berarti saya tidak dapat membaca perakitan :) Sebagian besar jatuh ke dalam perangkap yang sama, hanya mengaburkan, bukannya melindungi diri sendiri dengan benar. Kebingungan hanya berfungsi jika itu tidak layak waktu penyerang untuk menindaklanjutinya, jadi jika Anda membangun sesuatu pada teknik ini Anda sebaiknya berharap mereka tidak menjadi populer, jika tidak Anda kacau karena basis kode Anda tiba-tiba tidak dapat dipertahankan dan itu membutuhkan perubahan besar.
Phoshi

23
Saya tidak mengerti mengapa jawaban ini memiliki skor tinggi. 3. dan 4. karena seseorang itu benar-benar konyol dan tidak ada jaminan sama sekali.
Matti Virkkunen

117

Tidak ada titik dalam sejarah komputasi yang memungkinkan untuk mencegah rekayasa ulang perangkat lunak ketika Anda memberikan salinannya kepada penyerang Anda. Juga, dalam banyak kemungkinan, itu tidak akan pernah mungkin terjadi .

Dengan mengerti, ada solusi yang jelas: jangan memberikan rahasia Anda kepada penyerang Anda. Meskipun Anda tidak dapat melindungi konten APK Anda, apa yang dapat Anda lindungi adalah apa pun yang tidak Anda distribusikan. Biasanya ini adalah perangkat lunak sisi server yang digunakan untuk hal-hal seperti aktivasi, pembayaran, penegakan aturan, dan bit kode berair lainnya. Anda dapat melindungi aset berharga dengan tidak membagikannya di APK Anda. Alih-alih, atur server yang menanggapi permintaan dari aplikasi Anda, "menggunakan" aset (apa pun artinya) dan kemudian mengirimkan hasilnya kembali ke aplikasi. Jika model ini tidak berfungsi untuk aset yang Anda pikirkan, maka Anda mungkin ingin memikirkan kembali strategi Anda.

Juga, jika tujuan utama Anda adalah untuk mencegah pembajakan aplikasi : jangan repot-repot. Anda telah menghabiskan lebih banyak waktu dan uang untuk masalah ini daripada tindakan anti-pembajakan yang mungkin bisa menyelamatkan Anda. Pengembalian investasi untuk menyelesaikan masalah ini sangat rendah sehingga tidak masuk akal untuk memikirkannya.


21
Paragraf pertama adalah jawaban terbaik. Jika penyerang Anda mengontrol perangkat keras, mereka akan selalu dapat mengalahkan perangkat lunak Anda. Apa pun yang benar-benar perlu dilindungi harus tetap pada perangkat keras yang Anda kontrol, sesederhana itu. Dan paragraf terakhir, tentang ROI, juga tepat.
Daniel Pryden

88

Aturan pertama keamanan aplikasi: Mesin apa pun yang digunakan penyerang untuk mendapatkan akses fisik atau elektronik tanpa batas kini menjadi milik penyerang Anda, terlepas dari di mana sebenarnya itu atau apa yang Anda bayar untuk itu.

Aturan kedua keamanan aplikasi: Perangkat lunak apa pun yang meninggalkan batas fisik yang tidak dapat ditembus penyerang kini menjadi milik penyerang Anda, terlepas dari berapa lama waktu yang Anda habiskan untuk mengkodekannya.

Aturan ketiga: Setiap informasi yang meninggalkan batas fisik yang sama yang tidak dapat ditembus oleh penyerang sekarang menjadi milik penyerang Anda, tidak peduli betapa berharganya itu bagi Anda.

Fondasi keamanan teknologi informasi didasarkan pada tiga prinsip dasar ini; satu-satunya komputer yang benar-benar aman adalah yang terkunci di dalam brankas, di dalam sangkar Farraday, di dalam sangkar baja. Ada komputer yang menghabiskan sebagian besar umur layanan mereka hanya dalam keadaan ini; setahun sekali (atau kurang), mereka menghasilkan kunci pribadi untuk otoritas sertifikasi akar tepercaya (di depan sejumlah saksi dengan kamera merekam setiap inci ruangan tempat mereka berada).

Sekarang, sebagian besar komputer tidak digunakan dalam lingkungan seperti ini; mereka secara fisik di tempat terbuka, terhubung ke Internet melalui saluran radio nirkabel. Singkatnya, mereka rentan, seperti perangkat lunak mereka. Karena itu mereka tidak dapat dipercaya. Ada hal-hal tertentu yang harus diketahui atau dilakukan oleh komputer dan perangkat lunaknya agar bermanfaat, tetapi kehati-hatian harus dilakukan untuk memastikan bahwa mereka tidak pernah tahu atau berbuat cukup untuk menyebabkan kerusakan (setidaknya bukan kerusakan permanen di luar batas-batas mesin tunggal itu) ).

Anda sudah tahu semua ini; itu sebabnya Anda mencoba melindungi kode aplikasi Anda. Tapi, di situlah letak masalah pertama; alat kebingungan dapat membuat kode berantakan bagi manusia untuk mencoba menggali, tetapi program masih harus dijalankan; itu berarti aliran logika aktual dari aplikasi dan data yang digunakannya tidak terpengaruh oleh kebingungan. Dengan sedikit kegigihan, seorang penyerang bisa dengan mudah menghapus kode, dan itu bahkan tidak perlu dalam kasus-kasus tertentu di mana apa yang dia lihat tidak bisa apa-apa selain apa yang dia cari.

Sebaliknya, Anda harus mencoba memastikan bahwa penyerang tidak dapat melakukan apa pun dengan kode Anda, tidak peduli betapa mudahnya baginya untuk mendapatkan salinan yang jelas. Itu berarti, tidak ada rahasia yang disandikan, karena rahasia itu bukan rahasia begitu kode meninggalkan gedung tempat Anda mengembangkannya.

Nilai kunci ini yang Anda miliki dengan kode-keras harus dihapus dari kode sumber aplikasi sepenuhnya. Sebaliknya, mereka harus berada di salah satu dari tiga tempat; memori volatile pada perangkat, yang lebih sulit (tetapi masih tidak mustahil) bagi penyerang untuk mendapatkan salinan offline; secara permanen di server cluster, di mana Anda mengontrol akses dengan tangan besi; atau di penyimpanan data kedua yang tidak terkait dengan perangkat atau server Anda, seperti kartu fisik atau dalam memori pengguna Anda (artinya itu pada akhirnya akan berada dalam memori yang tidak stabil, tetapi tidak harus lama).

Pertimbangkan skema berikut. Pengguna memasukkan kredensial mereka untuk aplikasi dari memori ke dalam perangkat. Sayangnya, Anda harus percaya bahwa perangkat pengguna belum dikompromikan oleh keylogger atau Trojan; yang terbaik yang dapat Anda lakukan dalam hal ini adalah menerapkan keamanan multi-faktor, dengan mengingat informasi pengidentifikasian yang sulit-palsu tentang perangkat yang telah digunakan pengguna (MAC / IP, IMEI, dll), dan menyediakan setidaknya satu saluran tambahan dengan dimana upaya login pada perangkat yang tidak dikenal dapat diverifikasi.

Kredensial, setelah dimasukkan, dikaburkan oleh perangkat lunak klien (menggunakan hash aman), dan kredensial teks biasa dibuang; mereka telah melayani tujuan mereka. Kredensial yang dikaburkan dikirim melalui saluran aman ke server terautentikasi-sertifikat, yang mem-hashnya lagi untuk menghasilkan data yang digunakan untuk memverifikasi validitas login. Dengan cara ini, klien tidak pernah tahu apa yang sebenarnya dibandingkan dengan nilai database, server aplikasi tidak pernah tahu kredensial plainteks di balik apa yang diterimanya untuk validasi, server data tidak pernah tahu bagaimana data yang disimpan untuk validasi diproduksi, dan seorang pria di tengah hanya melihat omong kosong meskipun saluran aman dikompromikan.

Setelah diverifikasi, server mengirimkan kembali token melalui saluran. Token hanya berguna dalam sesi aman, terdiri dari derau acak atau salinan terenkripsi (dan dengan demikian dapat diverifikasi) dari pengidentifikasi sesi, dan aplikasi klien harus mengirim token ini pada saluran yang sama ke server sebagai bagian dari permintaan apa pun melakukan sesuatu. Aplikasi klien akan melakukan ini berkali-kali, karena tidak dapat melakukan apa pun yang melibatkan uang, data sensitif, atau apa pun yang dapat merusak dengan sendirinya; melainkan harus meminta server untuk melakukan tugas ini. Aplikasi klien tidak akan pernah menulis informasi sensitif ke memori persisten pada perangkat itu sendiri, setidaknya tidak dalam teks biasa; klien dapat meminta server melalui saluran aman untuk kunci simetris untuk mengenkripsi data lokal, yang akan diingat server; dalam sesi berikutnya klien dapat meminta server untuk kunci yang sama untuk mendekripsi data untuk digunakan dalam memori yang mudah menguap. Data itu tidak akan menjadi satu-satunya salinan, baik; apa pun yang disimpan oleh klien juga harus dikirimkan dalam beberapa bentuk ke server.

Jelas, ini membuat aplikasi Anda sangat bergantung pada akses Internet; perangkat klien tidak dapat melakukan fungsi dasar apa pun tanpa koneksi dan otentikasi yang benar oleh server. Tidak berbeda dengan Facebook, sungguh.

Sekarang, komputer yang diinginkan penyerang adalah server Anda, karena itu dan bukan aplikasi / perangkat klien adalah hal yang dapat membuatnya uang atau menyebabkan orang lain kesakitan untuk kesenangannya. Tidak apa-apa; Anda mendapatkan jauh lebih banyak uang untuk pengeluaran uang Anda dan upaya untuk mengamankan server daripada mencoba mengamankan semua klien. Server dapat berada di belakang semua jenis firewall dan keamanan elektronik lainnya, dan juga dapat diamankan secara fisik di balik baja, beton, akses kartu kunci / pin, dan pengawasan video 24 jam. Penyerang Anda harus sangat canggih memang untuk mendapatkan segala jenis akses ke server secara langsung, dan Anda akan (harus) segera mengetahuinya.

Yang terbaik yang bisa dilakukan penyerang adalah mencuri ponsel dan kredensial pengguna dan masuk ke server dengan hak terbatas klien. Jika ini terjadi, seperti halnya kehilangan kartu kredit, pengguna yang sah harus diinstruksikan untuk menelepon nomor 800 (lebih mudah diingat, dan bukan di belakang kartu yang mereka bawa di dompet, dompet atau tas kerja yang bisa jadi dicuri di samping perangkat seluler) dari telepon apa pun yang dapat mereka akses yang menghubungkannya langsung ke layanan pelanggan Anda. Mereka menyatakan ponsel mereka dicuri, memberikan beberapa pengenal unik dasar, dan akun dikunci, setiap transaksi yang mungkin dapat diproses oleh penyerang dibatalkan, dan penyerang kembali ke titik awal.


1
jawaban sempurna !! Saya hanya menyukai cara Anda untuk mendapatkan data dari server dengan beberapa token terenkripsi, saya pikir ini hampir mustahil untuk memecahkan kode setelah itu.
Dharam

Saya tahu ini agak terlambat, tetapi bagaimana dengan mengakses bagian server. Layanan seperti Microsoft azure memberi Anda sesuatu seperti ini untuk mengakses server mereka: MobileServiceClient mClient = new MobileServiceClient ("MobileServiceUrl", // Ganti dengan URL Situs "AppKey" di atas, // ganti dengan Kunci Aplikasi ini) dan hampir semua orang yang memiliki akses ke yang dapat mengakses server mereka dan mengeditnya
edwinj

@edwinj - Tidak ada masalah dalam ilmu komputer yang tidak dapat diselesaikan dengan lapisan tipuan lainnya. Cuplikan Anda memberikan ide dasar untuk mengakses layanan klien seluler Azure; itu memberikan tingkat keamanan dasar terhadap "drive-bys" dari pintu depan Microsoft. Anda pada gilirannya dapat menambahkan lapisan tambahan, seperti membutuhkan kunci sesi (pada dasarnya apa itu token terenkripsi) pada panggilan layanan apa pun, dan untuk mendapatkan kunci itu, mereka harus terlebih dahulu mengotentikasi dengan kombinasi pengetahuan kredensial dan skema enkripsi.
KeithS

1
Salah satu jawaban terbaik.
debo.stackoverflow

64

 1. Bagaimana saya bisa sepenuhnya menghindari rekayasa balik dari APK Android? Apakah ini mungkin?

Ini tidak mungkin

 2. Bagaimana saya bisa melindungi semua sumber daya, aset, dan kode sumber aplikasi sehingga peretas tidak dapat meretas file APK dengan cara apa pun?

Ketika seseorang mengubah ekstensi .apk ke .zip, lalu setelah unzipping, seseorang dapat dengan mudah mendapatkan semua sumber daya (kecuali Manifest.xml ), tetapi dengan APKtool, seseorang dapat memperoleh konten sebenarnya dari file manifes juga. Sekali lagi, tidak.

 3. Apakah ada cara untuk membuat peretasan lebih tangguh atau bahkan tidak mungkin? Apa lagi yang bisa saya lakukan untuk melindungi kode sumber di file APK saya?

Sekali lagi, tidak, tetapi Anda dapat mencegah hingga tingkat tertentu, yaitu,

  • Unduh sumber daya dari Web dan lakukan beberapa proses enkripsi
  • Gunakan perpustakaan asli yang telah dikompilasi sebelumnya (C, C ++, JNI, NDK)
  • Selalu melakukan hashing ( MD5 / SHA kunci atau logika lainnya)

Bahkan dengan Smali, orang dapat bermain dengan kode Anda. Semua dalam semua, itu tidak MUNGKIN.


7
@TrevorBoydSmith: Enkripsi tidak banyak membantu ketika OS open source dan dapat di-root. Sistem membutuhkan kunci untuk mendekripsi APK dan menjalankan hal-hal. Dan jika sistem memiliki kunci, dan saya memiliki akses tidak terkekang ke sistem, maka saya tahu di mana menemukan kunci dan bisa sampai ke sana. Berarti saya punya kuncinya sekarang juga .
cHao

4
@TrevorBoydSmith: Ini bagian "bagaimana melakukan", yang membunuh seluruh gagasan. Tidak ada cara untuk mengeksekusi kode terenkripsi secara langsung; pada beberapa titik, kode yang didekripsi harus tersedia. Yang berarti (1) harus ada kunci (bahwa saya, sebagai root, mungkin memiliki akses ke), dan (2) saya bahkan mungkin dapat menemukan salinan yang jelas dalam RAM dan hanya tidak khawatir tentang enkripsi pula.
cao

3
@TrevorBoydSmith: Masalahnya adalah, dalam hal ini Anda tidak dapat menaikkan biaya yang cukup untuk membuatnya tidak berharga. Kita tidak berbicara tentang kunci pemaksaan kasar di sini; kita berbicara tentang sudah memilikinya - OS harus memiliki kunci, dan kita memiliki OS. Satu-satunya cara untuk memperbaikinya adalah dengan membuat OS tidak dapat dicopot. Semoga beruntung dengan itu; bahkan Apple tidak dapat mengelolanya. :)
cHao

3
@ TrevorBoydSmith: Saya tidak berpikir menaikkan biaya secara umum tidak mungkin. Saya pikir (dan katakan), khususnya , bahwa saran Anda tidak mungkin - karena memang demikian . MATLAB bukan Android, dan memiliki kebebasan tertentu yang tidak dimiliki Android. Secara khusus, ia memiliki kebingungan di sisinya; jauh lebih sulit untuk menyembunyikan kunci enkripsi. Android tidak bisa melakukan itu. Siapa pun yang memiliki kode sumber akan tahu di mana kunci disembunyikan, dan akan memiliki alat untuk mengambilnya dalam waktu 10 menit dari fitur yang diumumkan. Bukan hanya mungkin untuk melakukan itu; itu benar-benar sepele .
cHao

6
@ TrevorBoydSmith: Saya tidak pernah bersikeras hal semacam itu. Yang saya tekankan adalah bahwa statis, berubah, bergerak, dll tidak masalah . Dalam OS open source, enkripsi saja tidak dapat melindungi kode dari siapa pun yang bisa merekayasa baliknya. Karena saya dapat membaca kode yang akan melakukan dekripsi, terlepas dari bagaimana kunci diperoleh, digunakan, dan / atau disimpan, saya dapat melihat bagaimana Anda melakukannya dan menggandakannya - bahkan lebih mudah daripada saya dapat membalikkan beberapa rahasia super kode aplikasi.
cao

37

Menghindari 100% rekayasa balik APK Android tidak mungkin dilakukan, tetapi Anda dapat menggunakan cara ini untuk menghindari ekstraksi lebih banyak data, seperti kode sumber, aset membentuk APK Anda, dan sumber daya:

  1. Gunakan ProGuard untuk mengaburkan kode aplikasi

  2. Gunakan NDK menggunakan C dan C ++ untuk meletakkan inti aplikasi Anda dan mengamankan bagian kode dalam .sofile

  3. Untuk mengamankan sumber daya, jangan sertakan semua sumber daya penting dalam folder aset dengan APK. Unduh sumber daya ini pada saat aplikasi pertama kali dinyalakan.


7
Yang ketiga benar-benar memudahkan pekerjaan para penyerang. Mengendus komunikasi jaringan lebih mudah daripada rekayasa terbalik.
jatuh

Untuk mengatasi masalah yang ketiga, orang dapat mengenkripsi konten yang diunduh dan / atau menggunakan koneksi terenkripsi (mis. SSL / TLS)
Stradivari

1
Mengenkripsi koneksi melindungi terhadap orang yang mengendus atau memodifikasi lalu lintas. Dalam kasus di mana pengguna itu sendiri jahat (yaitu ia memiliki apk Anda dan ia telah mencoba untuk meretasnya), ia masih akan mendapatkan konten dengan menggunakan aplikasi Anda, mengekstraksi sumber daya sebagai pengguna root; tapi ya itu membantu melawan serangan mengendus sederhana.
Kevin Lee

Menambahkannya: 4) menggunakan dexguard untuk kebingungan yang lebih tinggi tetapi dibayar 5) menggunakan file OBB untuk mengunduh aset pada saat mengunduh aplikasi, ini juga akan membantu mengurangi ukuran aplikasi juga
Ashok Kumar

35

Pengembang dapat mengambil langkah-langkah berikut untuk mencegah APK dari pencurian,

  • cara yang paling mendasar adalah dengan menggunakan alat-alat seperti ProGuardmengaburkan kode mereka, tetapi sampai sekarang, sangat sulit untuk sepenuhnya mencegah seseorang mendekompilasi aplikasi.

  • Saya juga pernah mendengar tentang alat HoseDex2Jar . Itu berhenti Dex2Jardengan memasukkan kode tidak berbahaya di Android APK yang membingungkan dan menonaktifkan Dex2Jardan melindungi kode dari dekompilasi. Entah bagaimana itu bisa mencegah hacker dari mendekompilasi APK menjadi kode java yang dapat dibaca.

  • Gunakan beberapa aplikasi sisi server untuk berkomunikasi dengan aplikasi hanya jika diperlukan. Ini bisa membantu mencegah data penting.

Sama sekali, Anda tidak dapat sepenuhnya melindungi kode Anda dari peretas potensial. Entah bagaimana, Anda bisa membuatnya menjadi tugas yang sulit dan membuat frustasi bagi mereka untuk mendekompilasi kode Anda. Salah satu cara yang paling efisien adalah menulis dalam kode asli (C / C ++) dan menyimpannya sebagai pustaka yang dikompilasi.


3
HoseDex2Jar hampir tidak berguna. Ini hanya 'membingungkan' dex2jar dan dapat dengan mudah diblokir. smali / apktool, dll berfungsi dengan baik dengan APK 'hosed'.
Nikolay Elenkov

@NikolayElenkov Apakah Anda tahu cara kerja HoseDex2Jar? Apa yang mereka gunakan untuk menghindari atau membingungkan dex2jar. Karena saya tidak bisa mengunggah file apk saya ke web untuk menggunakan HoseDex2Jar. Jika saya dapat melakukan sesuatu seperti HoseDex2Jar untuk membingungkan dex2jar maka akan sulit untuk meretas menggunakan alat dex2jar.
sachin003

1
Mungkin Anda salah paham maksud saya: apa yang HoseDex2Jar lakukan adalah mengemas ulang APK Anda sehingga alat dex2jar yang populer tidak dapat (di luar kotak) membalikkannya. Namun alat lain bisa, dan sangat mudah untuk mengalahkannya secara umum. Tidak ada gunanya menggunakannya. Tidak ada yang menyebutkan hal Dexguard I (oleh penulis ProGuard; tidak gratis), tetapi itu adalah pekerjaan. Itu melakukan beberapa hal lebih daripada kebingungan 'biasa'.
Nikolay Elenkov

C ++ tidak pernah bisa dibalik? itu sulit tetapi mungkin. dan ada alat untuk membantu Anda dengan itu seperti hex-rays.com/products/decompiler/index.shtml (ya, mereka memiliki versi ARM. bukan itu TIDAK mudah untuk mendapatkannya).
dkzm

ya, @VikartiAnatra: Saya juga menyebutkan , Anda bisa membuatnya sulit
Sahil Mahajan Mj

24

Berikut adalah beberapa metode yang dapat Anda coba:

  1. Gunakan kebingungan dan alat-alat seperti ProGuard .
  2. Enkripsi beberapa bagian sumber dan data.
  3. Gunakan checksum bawaan bawaan di aplikasi untuk mendeteksi gangguan.
  4. Perkenalkan kode untuk menghindari pemuatan di debugger, yaitu, biarkan aplikasi memiliki kemampuan untuk mendeteksi debugger dan keluar / bunuh debugger.
  5. Pisahkan otentikasi sebagai layanan online.
  6. Gunakan keragaman aplikasi
  7. Gunakan teknik pencetakan jari untuk misalnya, tanda tangan perangkat keras dari subsistem yang berbeda sebelum mengautentikasi perangkat.

23

 1. Bagaimana saya bisa sepenuhnya menghindari rekayasa balik dari APK Android? Apakah ini mungkin?

Mustahil

 2. Bagaimana saya bisa melindungi semua sumber daya, aset, dan kode sumber aplikasi sehingga peretas tidak dapat meretas file APK dengan cara apa pun?

Mustahil

 3. Apakah ada cara untuk membuat peretasan lebih tangguh atau bahkan tidak mungkin? Apa lagi yang bisa saya lakukan untuk melindungi kode sumber di file APK saya?

Lebih sulit - mungkin, tetapi pada kenyataannya itu akan lebih sulit sebagian besar untuk pengguna rata-rata, yang hanya googling untuk panduan peretasan. Jika seseorang benar-benar ingin meretas aplikasi Anda - itu akan diretas, cepat atau lambat.


22

 1. Bagaimana saya bisa sepenuhnya menghindari rekayasa balik dari APK Android? Apakah ini mungkin?

Itu tidak mungkin

 2. Bagaimana saya bisa melindungi semua sumber daya, aset, dan kode sumber aplikasi sehingga peretas tidak dapat meretas file APK dengan cara apa pun?

Pengembang dapat mengambil langkah-langkah seperti menggunakan alat seperti ProGuard untuk mengaburkan kode mereka, tetapi sampai sekarang, sangat sulit untuk sepenuhnya mencegah seseorang mendekompilasi aplikasi.

Ini adalah alat yang sangat hebat dan dapat meningkatkan kesulitan 'membalikkan' kode Anda sambil mengecilkan jejak kode Anda.

Dukungan ProGuard terintegrasi: ProGuard sekarang dipaket dengan Alat SDK. Pengembang sekarang dapat mengaburkan kode mereka sebagai bagian terintegrasi dari rilis rilis.

 3. Apakah ada cara untuk membuat peretasan lebih tangguh atau bahkan tidak mungkin? Apa lagi yang bisa saya lakukan untuk melindungi kode sumber di file APK saya?

Saat meneliti, saya jadi tahu tentang HoseDex2Jar . Alat ini akan melindungi kode Anda dari penguraian, tetapi sepertinya tidak mungkin untuk melindungi kode Anda sepenuhnya.

Beberapa tautan bermanfaat, Anda dapat merujuknya.


21

Pertanyaan utama di sini adalah apakah file dex dapat didekompilasi dan jawabannya adalah "semacam". Ada disassembler seperti dedexer dan smali .

ProGuard, yang dikonfigurasi dengan benar, akan mengaburkan kode Anda. DexGuard yang merupakan versi komersial diperluas dari ProGuard, dapat membantu sedikit lebih banyak. Namun, kode Anda masih dapat dikonversi menjadi smali dan pengembang dengan pengalaman rekayasa balik akan dapat mengetahui apa yang Anda lakukan dari smali.

Mungkin memilih lisensi yang baik dan menegakkannya dengan hukum sebaik mungkin.


4
Sebagai catatan tambahan (penafian: IANAL) - lisensi tidak akan melindungi aplikasi di bawah semua yurisdiksi dalam semua keadaan (misalnya di beberapa negara di Eropa, lisensi diizinkan untuk dibongkar untuk meningkatkan kompatibilitas).
Maciej Piechotka

12

Klien Anda harus mempekerjakan seseorang yang tahu apa yang mereka lakukan, yang dapat membuat keputusan yang tepat dan dapat membimbing Anda.

Bicara di atas tentang Anda memiliki beberapa kemampuan untuk mengubah sistem pemrosesan transaksi di backend adalah tidak masuk akal - Anda tidak seharusnya diizinkan untuk membuat perubahan arsitektur seperti itu, jadi jangan berharap untuk dapat melakukannya.

Alasan saya tentang ini:

Karena domain Anda sedang memproses pembayaran, aman untuk berasumsi bahwa PCI DSS dan / atau PA DSS (dan hukum negara bagian / federal potensial) akan signifikan bagi bisnis Anda - untuk memenuhi persyaratan Anda harus menunjukkan bahwa Anda aman. Menjadi tidak aman kemudian mencari tahu (melalui pengujian) bahwa Anda tidak aman, kemudian memperbaiki, menguji ulang, dan sebagainya sampai keamanan dapat diverifikasi pada tingkat yang sesuai = mahal, lambat, cara berisiko tinggi untuk sukses. Untuk melakukan hal yang benar, berpikir keras di depan, berkomitmen bakat berpengalaman untuk pekerjaan itu, mengembangkan dengan cara yang aman, kemudian menguji, memperbaiki (kurang), dan sebagainya (kurang) sampai keamanan dapat diverifikasi pada tingkat yang sesuai = murah, cepat, cara berisiko rendah untuk sukses.


8

Sebagai seseorang yang bekerja secara luas pada platform pembayaran, termasuk satu aplikasi pembayaran seluler (MyCheck), saya akan mengatakan bahwa Anda perlu mendelegasikan perilaku ini ke server, tidak ada nama pengguna atau kata sandi untuk prosesor pembayaran (mana pun itu) yang harus disimpan atau Hardcoded dalam aplikasi mobile, itu hal terakhir yang Anda inginkan, karena sumbernya dapat dipahami bahkan ketika Anda mengaburkan kodenya.

Selain itu, Anda tidak boleh menyimpan kartu kredit atau token pembayaran pada aplikasi, semuanya harus, sekali lagi, didelegasikan ke layanan yang Anda buat, itu juga akan memungkinkan Anda nanti, menjadi PCI-compliant lebih mudah, dan perusahaan Kartu Kredit memenangkan tarik nafasmu (seperti yang mereka lakukan untuk kita).


7

Jawaban tervvotifikasi lainnya di sini benar. Saya hanya ingin memberikan opsi lain.

Untuk fungsionalitas tertentu yang Anda anggap penting, Anda dapat meng-host kontrol WebView di aplikasi Anda. Fungsionalitas kemudian akan diterapkan di server web Anda. Ini akan terlihat seperti sedang berjalan di aplikasi Anda.


@Sarel Botha ya untuk layar IMP Saya sudah menggunakan tampilan web & ya ini juga salah satu cara untuk menjaga keamanan, saya menerima jawaban Anda.
sachin003

7

Jika kita ingin membuat reverse engineering (hampir) tidak mungkin, kita dapat menempatkan aplikasi pada chip yang sangat tahan-rusak, yang mengeksekusi semua hal sensitif secara internal, dan berkomunikasi dengan beberapa protokol untuk membuat mengendalikan GUI mungkin di host. Bahkan chip yang tahan terhadap kerusakan tidak 100% anti retak; mereka hanya mengatur bilah jauh lebih tinggi daripada metode perangkat lunak. Tentu saja, ini merepotkan: aplikasi memerlukan sedikit kutil USB yang menahan chip untuk dimasukkan ke dalam perangkat.

Pertanyaannya tidak mengungkapkan motivasi karena ingin melindungi aplikasi ini dengan cemburu.

Jika tujuannya adalah untuk meningkatkan keamanan metode pembayaran dengan menyembunyikan kelemahan keamanan apa pun yang mungkin dimiliki aplikasi (diketahui atau tidak), itu sepenuhnya salah arah. Bit yang peka terhadap keamanan sebenarnya harus bersumber terbuka, jika itu layak. Anda harus membuatnya semudah mungkin bagi setiap peneliti keamanan yang meninjau aplikasi Anda untuk menemukan bit-bit itu dan memeriksa operasi mereka, dan untuk menghubungi Anda. Aplikasi pembayaran tidak boleh mengandung sertifikat tertanam. Dengan kata lain, seharusnya tidak ada appliaction server yang mempercayai suatu perangkat hanya karena ia memiliki sertifikat tetap dari pabrik. Transaksi pembayaran harus dilakukan atas kredensial pengguna sendiri, menggunakan protokol otentikasi end-to-end yang dirancang dengan benar yang menghalangi mempercayai aplikasi, atau platform, atau jaringan, dll.

Jika tujuannya adalah untuk mencegah kloning, singkat dari chip anti-perusakan itu, tidak ada yang dapat Anda lakukan untuk melindungi program dari rekayasa balik dan disalin, sehingga seseorang memasukkan metode pembayaran yang kompatibel ke dalam aplikasi mereka sendiri, memberikan naik menjadi "klien tidak sah". Ada beberapa cara untuk mempersulit pengembangan klien yang tidak sah. Salah satunya adalah dengan membuat checksum berdasarkan snapshot dari status lengkap program: semua variabel status, untuk semuanya. GUI, logika, apa pun. Program klon tidak akan memiliki keadaan internal yang persis sama. Tentu, ini adalah mesin keadaan yang memiliki transisi keadaan yang terlihat secara eksternal serupa (seperti yang dapat diamati oleh input dan output), tetapi hampir tidak keadaan internal yang sama. Aplikasi server dapat menginterogasi program: apa kondisi terperinci Anda? (yaitu beri saya checksum atas semua variabel status internal Anda). Ini dapat dibandingkan dengan kode dummy client yang dijalankan pada server secara paralel, melalui transisi state asli. Klon pihak ketiga harus meniru semua perubahan status yang relevan dari program asli untuk memberikan tanggapan yang benar, yang akan menghambat pengembangannya.


7

Setuju dengan @Muhammad Saqib di sini: https://stackoverflow.com/a/46183706/2496464

Dan @Mumair memberikan langkah awal yang baik: https://stackoverflow.com/a/35411378/474330

Itu selalu aman untuk mengasumsikan bahwa semua yang Anda distribusikan ke perangkat pengguna Anda, milik pengguna. Polos dan sederhana. Anda mungkin dapat menggunakan alat dan prosedur terbaru untuk mengenkripsi properti intelektual Anda, tetapi tidak ada cara untuk mencegah orang yang ditentukan dari 'mempelajari' sistem Anda. Dan bahkan jika teknologi saat ini mungkin mempersulit mereka untuk mendapatkan akses yang tidak diinginkan, mungkin ada beberapa cara mudah besok, atau bahkan hanya satu jam berikutnya!

Jadi, inilah persamaan:

When it comes to money, we always assume that client is untrusted.

Bahkan sesederhana ekonomi dalam game. (Terutama di game! Ada lebih banyak pengguna 'canggih' di sana dan celah menyebar dalam hitungan detik!)

Bagaimana kita tetap aman?

Sebagian besar, jika tidak semua, sistem pemrosesan utama kami (dan database tentu saja) terletak di sisi server. Dan antara klien dan server, terletak komunikasi terenkripsi, validasi, dll. Itu adalah gagasan thin client.



4

Skema tanda tangan APK v2 di Android N

Kelas PackageManager sekarang mendukung verifikasi aplikasi menggunakan skema tanda tangan APK v2. Skema tanda tangan APK v2 adalah skema tanda tangan seluruh file yang secara signifikan meningkatkan kecepatan verifikasi dan memperkuat jaminan integritas dengan mendeteksi segala perubahan tidak sah pada file APK.

Untuk mempertahankan kompatibilitas ke belakang, APK harus ditandatangani dengan skema tanda tangan v1 (skema tanda tangan JAR) sebelum ditandatangani dengan skema tanda tangan v2. Dengan skema tanda tangan v2, verifikasi gagal jika Anda menandatangani APK dengan sertifikat tambahan setelah masuk dengan skema v2.

Dukungan skema tanda tangan APK v2 akan tersedia nanti di Pratinjau Pengembang N.

http://developer.android.com/preview/api-overview.html#apk_signature_v2


2
Apk signature v2 hanya mencegah sumber daya dirusak, tetapi tidak membuat rekayasa balik menjadi lebih sulit ...
Louis CAD

1
Selanjutnya Anda bisa menghapus tanda tangan dan menandatanganinya kembali. Tanda tangan v2 hanyalah blok data dalam file APK.
Robert

4

Tidak ada cara untuk sepenuhnya menghindari rekayasa balik APK. Untuk melindungi aset aplikasi, sumber daya, Anda dapat menggunakan enkripsi.

  • Enkripsi akan membuat lebih sulit untuk menggunakannya tanpa dekripsi. Memilih beberapa algoritma enkripsi yang kuat akan membuat cracking lebih sulit.
  • Menambahkan beberapa kode spoof ke dalam logika utama Anda untuk membuat lebih sulit untuk cracking.
  • Jika Anda dapat menulis logika kritis Anda dalam bahasa asli apa pun dan itu pasti membuat sulit untuk diurai.
  • Menggunakan kerangka kerja keamanan pihak ketiga seperti Quixxi

3

Pada dasarnya itu tidak mungkin. Itu tidak akan pernah mungkin terjadi. Namun, ada harapan. Anda dapat menggunakan obfuscator untuk membuatnya sehingga beberapa serangan umum jauh lebih sulit dilakukan termasuk hal-hal seperti:

  1. Mengganti nama metode / kelas (jadi di dekompiler Anda mendapatkan tipe seperti a.a)
  2. Mengaburkan alur kontrol (sehingga dalam dekompiler kodenya sangat sulit dibaca)
  3. Mengenkripsi string dan mungkin sumber daya

Saya yakin ada yang lain, tapi itu yang utama. Saya bekerja untuk sebuah perusahaan bernama PreEmptive Solutions di .NET obfuscator. Mereka juga memiliki obfuscator Java yang berfungsi untuk Android dan juga disebut DashO .

Kebingungan selalu datang dengan harga. Khususnya, kinerja biasanya lebih buruk, dan itu membutuhkan waktu ekstra sekitar rilis biasanya. Namun, jika kekayaan intelektual Anda sangat penting bagi Anda, maka itu biasanya sepadan.

Jika tidak, satu-satunya pilihan Anda adalah membuatnya agar aplikasi Android Anda hanya melewati ke server yang menampung semua logika nyata dari aplikasi Anda. Ini memiliki masalah sendiri, karena itu berarti pengguna harus terhubung ke Internet untuk menggunakan aplikasi Anda.

Juga, bukan hanya Android yang memiliki masalah ini. Ini masalah di setiap toko aplikasi. Hanya masalah betapa sulitnya untuk mendapatkan file paket (misalnya, saya tidak percaya itu sangat mudah di iPhone, tetapi masih mungkin).


Sayangnya jika satu meretas klien (aplikasi) mereka akan dapat melihat format komunikasi dan membuat server sendiri :(
Jocky Doe

3

Ini tidak mungkin untuk sepenuhnya menghindari RE tetapi dengan membuatnya lebih kompleks secara internal, Anda membuatnya semakin sulit bagi penyerang untuk melihat operasi yang jelas dari aplikasi, yang dapat mengurangi jumlah vektor serangan.

Jika aplikasi menangani data yang sangat sensitif, ada berbagai teknik yang dapat meningkatkan kompleksitas rekayasa balik kode Anda. Salah satu teknik adalah menggunakan C / C ++ untuk membatasi manipulasi runtime yang mudah oleh penyerang. Ada banyak perpustakaan C dan C ++ yang sangat matang dan mudah diintegrasikan dengan penawaran Android JNI. Seorang penyerang harus terlebih dahulu menghindari pembatasan debugging untuk menyerang aplikasi pada level rendah. Ini menambah kompleksitas serangan. Aplikasi Android harus memiliki android: debuggable = ”false” diatur dalam manifes aplikasi untuk mencegah manipulasi waktu yang mudah dijalankan oleh penyerang atau malware.

Memeriksa Jejak - Aplikasi dapat menentukan apakah saat ini sedang dilacak oleh debugger atau alat debugging lainnya. Jika dilacak, aplikasi dapat melakukan sejumlah tindakan respons serangan yang mungkin dilakukan, seperti membuang kunci enkripsi untuk melindungi data pengguna, memberi tahu administrator server, atau respons jenis lain semacam itu dalam upaya untuk mempertahankan diri. Ini dapat ditentukan dengan memeriksa tanda status proses atau menggunakan teknik lain seperti membandingkan nilai balik ptrace attach, memeriksa proses induk, daftar hitam debugger dalam daftar proses atau membandingkan cap waktu di berbagai tempat program.

Optimalisasi - Untuk menyembunyikan perhitungan matematis tingkat lanjut dan jenis logika kompleks lainnya, memanfaatkan optimisasi kompiler dapat membantu mengaburkan kode objek sehingga tidak dapat dengan mudah dibongkar oleh penyerang, sehingga penyerang lebih sulit mendapatkan pemahaman tentang kode tertentu. Dalam Android ini dapat lebih mudah dicapai dengan menggunakan pustaka yang dikompilasi secara asli dengan NDK. Selain itu, menggunakan LLVM Obfuscator atau SDK pelindung apa pun akan memberikan kebingungan kode mesin yang lebih baik.

Stripping binary - Stripping binary asli adalah cara yang efektif untuk meningkatkan jumlah waktu dan level skill yang dibutuhkan penyerang untuk melihat susunan fungsi level rendah aplikasi Anda. Dengan menghapus biner, tabel simbol biner dilucuti, sehingga penyerang tidak dapat dengan mudah men-debug atau merekayasa balik aplikasi. Anda dapat merujuk teknik yang digunakan pada sistem GNU / Linux seperti sstriping atau menggunakan UPX.

Dan akhirnya Anda harus sadar tentang kebingungan dan alat-alat seperti ProGuard.


3

Jika aplikasi Anda sensitif ini maka Anda harus mempertimbangkan bagian pemrosesan pembayaran di sisi server. Cobalah untuk mengubah algoritma pemrosesan pembayaran Anda. Gunakan aplikasi android hanya untuk mengumpulkan dan menampilkan informasi pengguna (yaitu saldo akun) dan daripada memproses pembayaran dalam kode java, kirim tugas ini ke server Anda menggunakan protokol SSL aman dengan parameter terenkripsi. Buat API terenkripsi dan aman sepenuhnya untuk berkomunikasi dengan server Anda.

Tentu saja, ini juga bisa diretas dan tidak ada hubungannya dengan perlindungan kode sumber, tetapi menganggapnya sebagai lapisan keamanan lain yang mempersulit peretas untuk mengelabui aplikasi Anda.


2

Bukankah chip TPM (Trusted Platform Module) seharusnya mengelola kode yang dilindungi untuk Anda? Mereka menjadi umum pada PC (terutama yang Apple) dan mereka mungkin sudah ada di chip smartphone saat ini. Sayangnya belum ada OS API untuk menggunakannya. Semoga Android akan menambah dukungan untuk hari ini. Itu juga kunci untuk membersihkan konten DRM (yang sedang dikerjakan Google untuk WebM).


2

Tidak ada yang aman ketika Anda meletakkannya di tangan pengguna akhir, tetapi beberapa praktik umum mungkin membuat ini lebih sulit bagi penyerang untuk mencuri data.

  • Masukkan logika utama Anda (algoritma) ke sisi server.
  • Berkomunikasi dengan server dan klien; pastikan komunikasi dengan server dan klien diamankan melalui SSL atau HTTPS; atau gunakan teknik-teknik lain algoritma pasangan kunci pasangan (ECC, RSA). Pastikan informasi sensitif tetap terenkripsi dari ujung ke ujung.
  • Gunakan sesi dan berakhir setelah interval waktu tertentu.
  • Enkripsi sumber daya dan ambil dari server sesuai permintaan.
  • Atau Anda dapat membuat aplikasi Hybrid yang mengakses sistem melalui webviewkode + sumber daya terlindungi di server

Berbagai pendekatan; ini jelas Anda harus berkorban di antara kinerja dan keamanan


2

Saya bisa melihat jawaban yang bagus di utas ini. Selain itu Anda dapat menggunakan facebook redexuntuk mengoptimalkan kode. Redex bekerja pada .dexlevel di mana proguard bekerja sebagai .classlevel.



1

Bagaimana saya bisa melindungi semua sumber daya, aset, dan kode sumber aplikasi sehingga peretas tidak dapat meretas file APK dengan cara apa pun?

File APK dilindungi dengan algoritma SHA-1 . Anda dapat melihat beberapa file di folder META-INF APK. Jika Anda mengekstrak file APK apa pun dan mengubah kontennya dan meng zipnya lagi dan saat Anda menjalankan file APK baru itu di mesin Android, itu tidak akan berfungsi, karena hash SHA-1 tidak akan pernah cocok.


Ini benar; tapi sepele untuk mengundurkan diri APK (dengan sertifikat berbeda) dan semuanya akan berfungsi lagi. Mungkin untuk memeriksa tanda tangan mana yang telah digunakan untuk menandatangani APK dari dalam aplikasi itu sendiri, dan kesalahan keluar jika sertifikat berubah, tetapi hanya sedikit kurang sepele untuk mengedit kode ini dari aplikasi.
David Diberi

Ini dapat mencegah perangkat android dari menjalankan kode yang dimodifikasi, tetapi Anda masih dapat dengan mudah mengekstrak kode yang relevan dan menulis kode baru pada PC yang melakukan apa yang Anda inginkan.
Sarel Botha

1

Meskipun saya setuju tidak ada solusi 100% yang akan melindungi kode Anda, v3 dari HoseDex2Jar sekarang aktif jika Anda ingin mencobanya.


1

Alat: Menggunakan Proguard di aplikasi Anda, dapat dibatasi untuk merekayasa balik aplikasi Anda


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.