Bir APK dosyasının tersine mühendislikten nasıl kaçınılır?


764

Android için bir ödeme işleme uygulaması geliştiriyorum ve bir bilgisayar korsanının APK dosyasından herhangi bir kaynağa, öğeye veya kaynak koduna erişmesini önlemek istiyorum .

Birisi .apk uzantısını .zip olarak değiştirirse, dosyayı açıp uygulamanın tüm kaynaklarına ve varlıklarına kolayca erişebilir ve dex2jar ve bir Java decompiler kullanarak kaynak koduna da erişebilirler. Bir Android APK dosyasını tersine çevirmek çok kolaydır - daha fazla bilgi için bkz. Yığın Taşması sorusu Bir APK dosyasından bir projeye tersine mühendislik .

Android SDK ile sağlanan Proguard aracını kullandım. İmzalı bir anahtar deposu ve Proguard kullanarak oluşturulan bir APK dosyasını tersine çevirdiğimde, gizli kod alıyorum.

Bununla birlikte, Android bileşenlerinin adları değişmeden kalır ve uygulamada kullanılan anahtar / değer çiftleri gibi bazı kodlar değişmeden kalır. Proguard belgelerine göre, araç Manifest dosyasında belirtilen bileşenleri gizleyemez.

Şimdi sorularım:

  1. Android APK'sının tersine mühendislik işlemini nasıl tamamen önleyebilirim ? Mümkün mü?
  2. Bilgisayar korsanlarının APK dosyasını hiçbir şekilde hackleyememesi için uygulamanın tüm kaynaklarını, varlıklarını ve kaynak kodunu nasıl koruyabilirim?
  3. Bilgisayar korsanlığını daha zor ve hatta imkansız hale getirmenin bir yolu var mı? APK dosyamdaki kaynak kodunu korumak için daha ne yapabilirim?

120
Ödeme işleme planınız gizli kalan müşterinin işlemine dayanıyorsa "belirsiz güvenlik" kullanıyor olabilirsiniz.
PeterJ

43
Kodun önemli kısımlarını C / C ++ 'da yazmayı ve bunları derlenmiş kitaplık olarak eklemeyi düşündünüz mü? Montaj koduna sökülebilirler, ancak büyük bir kütüphaneyi montajdan tersine mühendislik son derece zaman alıcıdır.
Leo


60
Herhangi bir dijital varlık yaratmanın temel konusuna hoş geldiniz. Bilgisayar korsanları makine talimatı seviyesine inebilir, bu nedenle bir bilgisayar dosyayı okuyabilirse açık / kopyalanabilir, hiçbir gizlilik veya DRM belirli bir bilgisayar korsanını tamamen durdurabilir. Güvenliğe ihtiyacınız varsa, özel anahtarların hiçbir zaman kaynakta olmadığından emin olun ve tasarım aşamasında yalnızca yalıtımın (uzak ve / veya özel donanım) bunları koruyabileceğini bilin.
Keith

16
Ödeme işleme uygulamanızın ne yaptığına bağlı olarak, uygulamanızı etkileyen ve sizi ciddi cezalara maruz bırakabilecek yasal ve yasal politikalar olabileceğini unutmayın: pcicomplianceguide.org/pcifaqs.php#11 ile başlayarak PCI uyumluluğuna bakın .
bloopletech

Yanıtlar:


372

 1. Nasıl bir Android APK ters mühendislik tamamen önleyebilirim? Mümkün mü?

AFAIK, tersine mühendislikten tamamen kaçınma hilesi yok.

Ayrıca @inazaruk tarafından çok iyi söylendi: Kodunuza ne yaparsanız yapın, potansiyel bir saldırgan onu mümkün olduğu her şekilde değiştirebilir . Temel olarak uygulamanızı değiştirilmekten koruyamazsınız. Ve oraya koyduğunuz her türlü koruma devre dışı bırakılabilir / kaldırılabilir.

 2. Bilgisayar korsanlarının APK dosyasını hiçbir şekilde hackleyememesi için uygulamanın tüm kaynaklarını, varlıklarını ve kaynak kodunu nasıl koruyabilirim?

Yine de hacklemeyi zorlaştırmak için farklı numaralar yapabilirsiniz. Örneğin, gizleme kullanın (Java kodu ise). Bu genellikle tersine mühendisliği önemli ölçüde yavaşlatır.

 3. Bilgisayar korsanlığını daha zor, hatta imkansız hale getirmenin bir yolu var mı? APK dosyamdaki kaynak kodunu korumak için daha ne yapabilirim?

Herkesin dediği ve muhtemelen bildiğiniz gibi% 100 güvenlik yoktur. Ancak Google'ın yerleşik olduğu Android için başlangıç ​​yeri ProGuard. Paylaşılan kitaplıkları dahil etme seçeneğiniz varsa, dosya boyutlarını, entegrasyonu vb. Doğrulamak için gerekli kodu C ++ 'a ekleyebilirsiniz. Her derlemede APK'nızın kitaplık klasörüne harici bir yerel kitaplık eklemeniz gerekiyorsa, o zaman kullanabilirsiniz Aşağıdaki öneriye göre.

Kütüphaneyi, proje klasörünüzde varsayılan olarak "libs" olan yerel kütüphane yoluna yerleştirin. Eğer 'armeabi' hedefi için yerel kodu oluşturduysanız, bunu libs / armeabi altına koyun . Armeabi-v7a ile yapılmışsa, libs / armeabi-v7a altına koyun.

<project>/libs/armeabi/libstuff.so

1
Ödeme işlemi için ISO 8585 standardını kullandım, şu anda bu standart için şema, Java HashMap koleksiyonunu kullanarak anahtar / değer çiftinde ve apk'de tersine mühendislik yaptığımda tüm şemayı alacağım. ters mühendislik yoluyla maruz kaldım. Bu durumda Paylaşım kitaplıklarıyla ilgili son öneriniz faydalı olabilir mi? Eğer android paylaşım kitaplıklarına maruz kalma böylece Doy herhangi bir bağlantı var.
sachin003

4
dizelerinizi kodda şifrelemeye ve çalışma zamanında bunları çözmeye ne dersiniz? Şifre çözmeyi uzaktaki bir sunucuda yaparsanız, diğer kişilerin önerdiği gibi, şifre çözme anahtarının kaynaklarda olduğu sorununu alamazsınız.
kutschkem

evet, şifreleme yoludur, ancak emin olunmaz. Dize onları şifresini çözmek için şifreleme, kodunda benzersiz bir kimliğe ihtiyacım var. ve herkes onu koda edebiliyorsa, Benzersiz kimliği almak çok kolay olacaktır.
Bhavesh Patadiya

neden Düzenlenmiş şeyler eklediniz ? hepsi düzenli.
Muhammed Azharuddin Shaikh

@hotveryspicy: evet şimdi "edited" işaretini answer.i 'den kaldırdım.
Bhavesh Patadiya

126

AFAIK, artık / res dizinindeki dosyaları şu anda korunduğundan daha fazla koruyamazsınız.

Bununla birlikte, kaynak kodunuzu korumak için atabileceğiniz adımlar veya en azından her şey olmasa da ne yaptığı vardır.

  1. ProGuard gibi araçlar kullanın. Bunlar, kodunuzu gizler ve imkansız değilse de, kod çözüldüğünde okunmasını zorlaştırır.
  2. Hizmetin en kritik kısımlarını uygulamadan ve PHP gibi bir sunucu tarafı dilinin arkasına gizlenmiş bir web servisine taşıyın. Örneğin, yazmanız bir milyon dolar alan bir algoritmanız varsa. İnsanların uygulamanızdan çalmasını istemiyorsunuz. Algoritmayı taşıyın ve uzak bir sunucudaki verileri işlemesini sağlayın ve uygulamayı yalnızca verileri sağlamak için kullanın. Ya da NDK'yi yerel olarak .so dosyalarına yazmak için kullanın, bu dosyalar apks'ten daha az çözülür. .So dosyaları için bir decompiler bile şu an var olduğunu düşünmüyorum (ve yapsa bile, Java decompilers kadar iyi olmaz). Ayrıca, yorumlarda @nikolay'da belirtildiği gibi, sunucu ve aygıt arasında etkileşim kurarken SSL kullanmalısınız.
  3. Değerleri cihaza kaydederken, onları ham biçimde saklamayın. Örneğin, bir oyununuz varsa ve kullanıcının SharedPreferences'da oyundaki para birimini saklıyorsanız. Diyelim ki 10000paralar. 10000Doğrudan kaydetmek yerine, benzer bir algoritma kullanarak kaydedin ((currency*2)+1)/13. Bunun yerine , SharedPreferences'e 10000kaydedin 1538.53846154. Ancak, yukarıdaki örnek mükemmel değildir ve yuvarlama hatalarına para kaybetmeyecek bir denklem bulmak için çalışmanız gerekir.
  4. Sunucu tarafı görevleri için de benzer bir şey yapabilirsiniz. Şimdi bir örnek olarak, aslında ödeme işleme uygulamanızı ele alalım. Kullanıcının ödeme yapması gerektiğini varsayalım $200. $200Sunucuya ham değer göndermek yerine, toplanan daha küçük, önceden tanımlanmış bir dizi değer gönderin $200. Örneğin, sunucunuzda sözcükleri değerlerle eşitleyen bir dosya veya tablo bulundurun. Yani diyelim Charliekarşılık için $47, ve Johniçin $3. Yani göndermek yerine dört kez $200gönderebilir CharlieveJohndört kere. Sunucuda, ne anlama geldiğini yorumlayın ve ekleyin. Bu, bir bilgisayar korsanının hangi kelimenin hangi değere karşılık geldiğini bilmediğinden sunucunuza rasgele değerler göndermesini önler. Ek bir güvenlik önlemi olarak, bunun için 3. maddeye benzer bir denkleminiz olabilir ve anahtar kelimeleri her ngün değiştirebilirsiniz.
  5. Son olarak, uygulamanıza rastgele yararsız kaynak kodu ekleyebilirsiniz, böylece bilgisayar korsanı samanlıkta bir iğne arar. İnternetten parçacıklar içeren rastgele sınıflar veya sadece Fibonacci dizisi gibi rastgele şeyleri hesaplama işlevlerini ekleyin. Bu sınıfların derlendiğinden, ancak uygulamanın gerçek işlevselliği tarafından kullanılmadığından emin olun. Bu sahte sınıfları yeterince ekleyin ve bilgisayar korsanı gerçek kodunuzu bulmakta zorlanır.

Sonuç olarak, uygulamanızı% 100 korumanın bir yolu yoktur. Daha zor yapabilirsiniz, ama imkansız değil. Web sunucunuz tehlikeye girebilir, bilgisayar korsanı birden fazla işlem tutarını izleyerek anahtar kelimelerinizi çözebilir ve bunun için gönderdiğiniz anahtar kelimeler, bilgisayar korsanı titizlikle kaynağa gidebilir ve hangi kodun bir kukla olduğunu anlayabilir.

Sadece savaşabilirsin, ama asla kazanamazsın.


136
Sunucunuza gönderdiğiniz değerlerle hile yapmak yerine SSL kullanın ve sunucu sertifikasını doğru bir şekilde doğrulayın. Belirsizlik nedeniyle güvenlik genellikle kötü bir fikirdir.
Nikolay Elenkov

48
uygulamanıza rastgele yararsız kaynak kodu ekleyebilirsiniz . Bu da gerçekten yardımcı olamaz. Bu sadece uygulamanızı şişirir, aynı zamanda bakımını da zorlaştırır.
Anirudh Ramanathan

4
Ayrıca, işe yaramaz kodu kullanarak sahte verileri atabilir ve bu verileri atacak olan sunucuya gönderebilirsiniz. Yanlış güvenlik belki, ama potansiyel hacker için kıçından bir acı, değil mi?
Benoit Duffez

19
Algoritmanız bir milyon dolar değerinde ise, .sodosyalar için bir decompiler olmadığı için montajı okuyamayacağım anlamına gelmez :) Bunların çoğu aynı tuzağa düşer, kendinizi düzgün bir şekilde korumak yerine gizler. Vurgulama sadece bir saldırganın izlemeye değer olmadığı zaman işe yarar, bu nedenle bu teknikler üzerine bir şeyler yaparsanız popüler olmadıklarını ummanız daha iyi olur, aksi takdirde mahvolursunuz çünkü aniden kod tabanınız sürdürülemez ve büyük değişikliklere ihtiyacı var.
Phoshi

23
Bu cevabın neden bu kadar yüksek bir puan aldığını anlamıyorum. 3. ve 4. biri için sadece aptalca ve hiçbir güvenlik anlamına gelmez.
Matti Virkkunen

117

Bilgisayar tarihinin hiçbir noktasında, saldırganınıza çalışan bir kopyasını verirken yazılımın tersine mühendislik yapmasını önlemek mümkün olmamıştır. Ayrıca, büyük olasılıkla, asla mümkün olmayacaktır .

Bu anlaşıldığında, bariz bir çözüm var: sırlarınızı saldırganınıza vermeyin. APK'nızın içeriğini koruyamasanız da , koruyabileceğiniz şey dağıtmadığınız bir şeydir. Genellikle bu, etkinleştirme, ödemeler, kural uygulama ve diğer sulu kod parçaları gibi şeyler için kullanılan sunucu tarafı yazılımdır. Sen değerli varlıklarını koruyabilir değil APK'nızdaki dağıtmaya. Bunun yerine, uygulamanızdan gelen isteklere yanıt veren, varlıkları "kullanır" (ne anlama gelirse gelsin) ve ardından sonucu tekrar uygulamaya gönderen bir sunucu oluşturun. Bu model, aklınızdaki varlıklar için işe yaramazsa, stratejinizi yeniden düşünmek isteyebilirsiniz.

Ayrıca, birincil hedefiniz uygulama korsanlığını önlemekse : rahatsız bile etmeyin. Bu soruna korsanlıkla mücadele tedbirlerinin sizi kurtarmayı umabileceğinden daha fazla zaman ve para harcadınız. Bu sorunu çözmek için yatırım getirisi o kadar düşüktür ki, bunu düşünmek bile mantıklı değildir.


21
İlk paragraf en iyi cevaptır. Saldırganınız donanımı kontrol ederse, yazılımınızı her nasılsa bir şekilde yenebilir. Gerçekten korunması gereken her şey kontrol ettiğiniz donanımda kalmalıdır, bu kadar basit. YG ile ilgili son paragraf da dikkat çekiyor.
Daniel Pryden

88

Uygulama güvenliğinin ilk kuralı: Bir saldırganın sınırsız fiziksel veya elektronik erişim elde ettiği herhangi bir makine, gerçekte nerede olduğuna veya ne için ödeme yaptığınıza bakılmaksızın saldırganınıza aittir.

Uygulama güvenliğinin ikinci kuralı: Bir saldırganın içine giremeyeceği fiziksel sınırları geride bırakan herhangi bir yazılım, kodlamak için ne kadar zaman harcadığınıza bakılmaksızın saldırganınıza aittir.

Üçüncü kural: Bir saldırganın nüfuz edemeyeceği aynı fiziksel sınırları bırakan herhangi bir bilgi, sizin için ne kadar değerli olursa olsun, saldırganınıza aittir.

Bilgi teknolojisi güvenliğinin temelleri şu üç temel ilkeye dayanmaktadır; Gerçekten güvenli olan tek bilgisayar, bir Farraday kafesinin içinde, çelik bir kafesin içinde güvenli bir kasada kilitlenmiş olan bilgisayardır. Hizmet hayatlarının çoğunu sadece bu durumda geçiren bilgisayarlar var; yılda bir kez (veya daha az), güvenilir kök sertifika yetkilileri için özel anahtarlar oluştururlar (içinde bulundukları odanın her santimini kaydeden kameralarla bir dizi tanığın önünde).

Artık çoğu bilgisayar bu tür ortamlarda kullanılmamaktadır; fiziksel olarak açıkta, kablosuz bir radyo kanalı üzerinden İnternet'e bağlı. Kısacası, yazılımları gibi hassastırlar. Bu nedenle onlara güvenilmemelidir. Bilgisayarların ve yazılımlarının yararlı olması için bilmesi ya da yapması gereken bazı şeyler vardır, ancak hiçbir zaman zarar veremeyecek kadar bilmeyecek ya da yeterince yapamayacaklarından emin olmak için özen gösterilmelidir (en azından o makinenin sınırları dışında kalıcı hasar değil) ).

Bunların hepsini zaten biliyordunuz; bu yüzden uygulamanızın kodunu korumaya çalışıyorsunuz. Ama burada ilk sorun yatıyor; gizleme araçları, kodun bir insanın kazmaya çalışması için bir karmaşaya neden olabilir, ancak programın hala çalışması gerekir; bu, uygulamanın gerçek mantık akışı ve kullandığı verilerin gizlenmeden etkilenmediği anlamına gelir. Biraz azim göz önüne alındığında, bir saldırgan kodu gizlemeden kaldırabilir ve baktığı şeyin aradığı şeyden başka bir şey olamayacağı belirli durumlarda bile gerekli değildir.

Bunun yerine, saldırganın açık bir kopyasını alması ne kadar kolay olursa olsun, bir saldırganın kodunuzla hiçbir şey yapamayacağından emin olmalısınız. Bu, sabit kodlanmış sırlar olmadığı anlamına gelir, çünkü kod, onu geliştirdiğiniz binadan çıkar çıkmaz bu sırlar gizli değildir.

Sabit kodladığınız bu anahtar / değer çiftleri uygulamanın kaynak kodundan tamamen kaldırılmalıdır. Bunun yerine, üç yerden birinde olmalılar; aygıtta geçici bir bellek var, bu da saldırganın çevrimdışı bir kopyasını alması daha zor (ama yine de imkansız değil); bir demir yumrukla erişimi denetlediğiniz sunucu kümesinde kalıcı olarak; veya fiziksel bir kart veya kullanıcı anılarınız gibi cihazınızla veya sunucularınızla ilgili olmayan ikinci bir veri deposunda (yani sonunda kalıcı bellekte olacaktır, ancak uzun süre olması gerekmez).

Aşağıdaki şemayı düşünün. Kullanıcı, uygulamanın kimlik bilgilerini bellekten cihaza girer. Ne yazık ki, kullanıcının cihazının zaten bir keylogger veya Trojan tarafından ele geçirilmediğine güvenmelisiniz; bu konuda yapabileceğiniz en iyi şey, kullanıcının kullandığı cihazlar (MAC / IP, IMEI, vb.) hakkında sahte ve zor tanımlayıcı bilgileri hatırlayarak ve tarafından en az bir ek kanal sağlayarak çok faktörlü güvenlik uygulamaktır. bilmediğiniz bir cihazda oturum açma girişimi doğrulanabilir.

Girilen kimlik bilgileri, istemci yazılımı (güvenli bir karma kullanarak) tarafından gizlenir ve düz metin kimlik bilgileri atılır; amaçlarına hizmet ettiler. Gizlenen kimlik bilgileri, güvenli bir kanal üzerinden sertifika kimlik doğrulamalı sunucuya gönderilir ve bu da onları yeniden oluşturur da oturum açma işleminin geçerliliğini doğrulamak için kullanılan verileri üretmek üzere . Bu şekilde, istemci veritabanı değeriyle gerçekte neyin karşılaştırıldığını asla bilemez, uygulama sunucusu doğrulama için aldıkları şeyin arkasındaki düz metin kimlik bilgilerini asla bilemez, veri sunucusu doğrulama için depoladığı verilerin nasıl üretildiğini ve ortada güvenli kanal tehlikeye atılmış olsa bile sadece anlamsız görünüyor.

Doğrulandıktan sonra, sunucu kanal üzerinden bir jeton iletir. Belirteç yalnızca güvenli oturumda kullanışlıdır, rasgele gürültü veya oturum tanımlayıcılarının şifreli (ve dolayısıyla doğrulanabilir) bir kopyasından oluşur ve istemci uygulaması bu belirteci herhangi bir isteğin bir parçası olarak sunucuya aynı kanalda göndermelidir. bir şey yapmak. İstemci uygulaması bunu birçok kez yapacaktır, çünkü para, hassas veriler veya kendi başına zarar verebilecek başka herhangi bir şey yapamaz; bunun yerine sunucudan bu görevi yapmasını istemelidir. İstemci uygulaması, en azından düz metin olarak değil, cihazın üzerindeki kalıcı belleğe hiçbir zaman hassas bilgiler yazmaz; istemci sunucudan hatırlayacağı herhangi bir yerel veriyi şifrelemek için sunucudan güvenli kanal üzerinden simetrik bir anahtar isteyebilir; daha sonraki bir oturumda istemci, kalıcı bellekte kullanılmak üzere verilerin şifresini çözmek için sunucudan aynı anahtarı isteyebilir. Bu veriler de tek kopya olmayacak; istemcinin depoladığı her şey bir şekilde sunucuya iletilmelidir.

Açıkçası, bu, uygulamanızı büyük ölçüde İnternet erişimine bağımlı kılar; istemci aygıt, sunucu ile düzgün bağlantı ve kimlik doğrulama yapmadan temel işlevlerinden hiçbirini gerçekleştiremez. Facebook'tan farklı değil, gerçekten.

Şimdi, saldırganın istediği bilgisayar sunucunuzdur, çünkü istemci uygulaması / cihazı değil, ona para kazandırabilecek veya diğer insanların keyfi için acı çekmesine neden olabilecek şeydir. Bu iyi; paranızın karşılığını tüm sunucuları güvenceye almaktan çok daha fazla para alıyorsunuz. Sunucu her türlü güvenlik duvarının ve diğer elektronik güvenliğin arkasında olabilir ve ayrıca çelik, beton, anahtar kart / pim erişimi ve 24 saat video gözetiminin arkasında fiziksel olarak güvence altına alınabilir. Saldırıcınızın sunucuya doğrudan her türlü erişimi elde etmek için gerçekten çok sofistike olması gerekir ve hemen bunu bilmelisiniz.

Bir saldırganın yapabileceği en iyi şey kullanıcının telefonunu ve kimlik bilgilerini çalmak ve istemcinin sınırlı haklarıyla sunucuya giriş yapmaktır. Böyle bir durumda, tıpkı bir kredi kartını kaybetmek gibi, meşru kullanıcıdan 800'lü numarayı (tercihen hatırlaması kolay ve cüzdanında, cüzdanında veya evrak çantasında taşıyabilecekleri bir kart değil) araması istenmelidir. mobil cihazla birlikte çalındıysa), doğrudan müşteri hizmetinize bağlayan erişebilecekleri herhangi bir telefondan. Telefonlarının çalındığını, bazı temel benzersiz tanımlayıcıların sağlandığını ve hesabın kilitlendiğini, saldırganın işleyebileceği tüm işlemler geri alındığını ve saldırganın kareye geri döndüğünü belirtirler.


1
mükemmel cevap !! Ben sadece bazı şifreli jeton ile sunucudan veri almak için yolunuzu sevdi, bu bundan sonra kodunu çözmek imkansız olduğunu düşünüyorum.
dharam

Bu biraz geç ama sunucu bölümüne erişme hakkında ne biliyorum. Microsoft azure gibi hizmetler, sunucularına erişmeniz için size böyle bir şey sağlar: MobileServiceClient mClient = new MobileServiceClient ("MobileServiceUrl", // Yukarıdaki Site URL'si "AppKey" ile değiştirin, // bu Uygulama Anahtarı ile değiştirin) ve hemen hemen herkes kendi sunucu sonuna erişebilirsiniz erişimi var
edwinj

@edwinj - Bilgisayar bilimlerinde başka bir dolaylı katman ile çözülemeyen bir sorun yok. Snippet'iniz bir Azure mobil istemci hizmetine erişmek için temel fikri verir; Microsoft'un ön kapısının "arabayla" sürülmesine karşı temel düzeyde güvenlik sağlar. Buna karşılık, herhangi bir hizmet çağrısında bir oturum anahtarı (temel olarak şifreli belirtecin ne olduğu) gibi ek katmanlar ekleyebilir ve bu anahtarı elde etmek için, önce kimlik bilgileri ve şifreleme şeması bilgilerinin bir birleşimi ile kimlik doğrulaması yapmaları gerekir.
Keiths

1
En iyi cevaplardan biri.
debo.stackoverflow

64

 1. Nasıl bir Android APK ters mühendislik tamamen önleyebilirim? Mümkün mü?

Bu mümkün değil

 2. Bilgisayar korsanlarının APK dosyasını hiçbir şekilde hackleyememesi için uygulamanın tüm kaynaklarını, varlıklarını ve kaynak kodunu nasıl koruyabilirim?

Birisi bir .apk uzantısını .zip olarak değiştirdiğinde, sıkıştırdıktan sonra, birisi kolayca tüm kaynakları ( Manifest.xml hariç ) alabilir, ancak APKtool ile manifest dosyasının gerçek içeriğini de alabilirsiniz. Yine, hayır.

 3. Bilgisayar korsanlığını daha zor, hatta imkansız hale getirmenin bir yolu var mı? APK dosyamdaki kaynak kodunu korumak için daha ne yapabilirim?

Yine, hayır, ama bir seviyeye kadar önleyebilirsiniz, yani,

  • Web'den bir kaynak indirin ve bazı şifreleme işlemleri yapın
  • Önceden derlenmiş yerel kitaplık kullanma (C, C ++, JNI, NDK)
  • Her zaman biraz karma gerçekleştirme ( MD5 / SHA tuşları veya başka bir mantık)

İle bile Smali, insanlar kodunuzla oynayabilir. Sonuçta, OLASI değil.


7
@TrevorBoydSmith: İşletim sistemi açık kaynak ve rootable olduğunda şifreleme pek yardımcı olmaz. Sistemin APK şifresini çözmek ve bir şeyler çalıştırmak için bir anahtara ihtiyacı vardır. Sistemin bir anahtarı varsa ve sisteme serbest bir şekilde erişebiliyorum, o zaman anahtarı nerede bulacağımı biliyorum ve ona ulaşabilirim. Yani artık anahtarım var .
cHao

4
@TrevorBoydSmith: Yine de, tüm fikri öldüren "nasıl yapılır" kısmı. Doğrudan şifrelenmiş kodu yürütmenin bir yolu yoktur; bir noktada, şifresi çözülmüş kodun kullanılabilir olması gerekir. Bu, (1) bir anahtar olması gerektiği anlamına gelir (i, root olarak, muhtemelen erişime sahip olabilir) ve (2) Hatta RAM'deki net kopyayı bulabilir ve yine de şifreleme konusunda endişelenmeyebilirim.
cHao

3
@TrevorBoydSmith: Sorun şu ki, bu durumda sadece değmez hale getirmek için yeterli maliyeti artıramazsınız. Burada kaba kuvvet anahtarlarından bahsetmiyoruz; zaten bunlara sahip olmaktan bahsediyoruz - işletim sisteminin anahtarları olmalı ve işletim sistemimiz var. Bunu düzeltmenin tek yolu işletim sistemini rorotable yapmaktır. Bunda iyi şanslar; Apple bile yönetemiyor. :)
cHao

3
@TrevorBoydSmith: Genel olarak maliyeti yükseltmenin imkansız olduğunu düşünmüyorum . Özellikle , önerinin imkansız olduğunu düşünüyorum (ve söylüyorum) - çünkü öyle . MATLAB Android değildir ve Android'in sahip olmadığı belirli özgürlüklere sahiptir. Özellikle yan tarafında bir şaşkınlık vardır; bir şifreleme anahtarını gizlemek çok daha zor. Android bunu yapamaz. Kaynak koduna sahip olan herkes, anahtarların nerede saklandığını bilecek ve özellik açıklandıktan sonraki 10 dakika içinde bunları almak için bir araca sahip olacaktır. Bunu yapmak mümkün değil; düpedüz önemsiz .
cHao

6
@TrevorBoydSmith: Bu tür hiçbir şeyde ısrar etmedim. Ne ısrar ediyorum statik, değişen, hareketli, vb önemli değil . Açık kaynaklı bir işletim sisteminde, tek başına şifreleme, kodu tersine mühendislik yapabilenlerden koruyamaz. Anahtarın nasıl edinildiğine, kullanıldığına ve / veya saklandığına bakılmaksızın, şifre çözme işlemini yapacak olan kodu okuyabildiğim için, nasıl yaptığınızı görebilir ve çoğaltabilirim - bazı süper sırları tersine çevirebileceğimden bile daha kolay uygulama kodu.
cHao

37

Android APK'sının tersine mühendislikten% 100 kaçınma mümkün değildir, ancak kaynak kodu, APK'nızdaki varlıklar ve kaynaklar gibi daha fazla veri elde etmekten kaçınmak için bu yolları kullanabilirsiniz:

  1. Uygulama kodunu gizlemek için ProGuard kullanın

  2. Uygulama çekirdeğinizi ve kodun güvenli kısmını dosyalara koymak için C ve C ++ kullanarak NDK kullanın.so

  3. Kaynakları güvence altına almak için APK içeren varlıklar klasörüne tüm önemli kaynakları dahil etmeyin. Uygulama ilk başlatıldığında bu kaynakları indirin.


7
Üçüncüsü, saldırganların çalışmalarını gerçekten kolaylaştırıyor. Ağ iletişimini koklamak tersine mühendislikten daha kolaydır.
15'te totten

Üçüncüsünün problemini çözmek için, indirilen içeriği şifreleyebilir ve / veya şifreli bir bağlantı kullanabilirsiniz (örn. SSL / TLS)
Stradivari

1
Bağlantıyı şifrelemek, trafiği koklayan veya değiştiren kişilere karşı koruma sağlar. Kullanıcının kendisinin kötü amaçlı olduğu durumda (yani, apk'niz var ve onu hacklemeye çalışıyor), yine de, uygulamanızı kullanarak kaynakları kök kullanıcı olarak çıkararak içeriği alacaktır; ama evet basit koklama saldırılarına karşı yardımcı olur.
Kevin Lee

Buna ek olarak: 4) daha yüksek gizleme için dexguard kullanın ancak ödenir 5) uygulamayı indirirken varlıklar indirmek için OBB dosyasını kullanın, uygulama boyutunu da azaltmaya yardımcı olacaktır
Ashok Kumar

35

Geliştiriciler, bir APK'nın bir şekilde çalınmasını önlemek için aşağıdaki adımları atabilir,

  • En temel yol, ProGuardkodlarını gizlemek gibi araçlar kullanmaktır , ancak şimdiye kadar, bir kişinin bir uygulamanın kodunu çözmesini tamamen önlemek oldukça zordu.

  • Ayrıca bir araç HoseDex2Jar duydum . Dex2JarKodu karıştıran ve devre dışı bırakan bir Android APK'sına zararsız kod ekleyerek durur Dex2Jar. Bilgisayar korsanlarının bir APK'yi okunabilir java koduna dönüştürmesini bir şekilde engelleyebilir.

  • Bazı sunucu tarafı uygulamalarını, yalnızca gerektiğinde uygulama ile iletişim kurmak için kullanın. Önemli verilerin önlenmesine yardımcı olabilir.

Kodunuzu potansiyel bilgisayar korsanlarından tamamen koruyamazsınız. Her nasılsa, kodunuzu koda etmelerini zorlaştırabilir ve biraz sinir bozucu bir görev yapabilirsiniz. En etkili yollardan biri yerel kod (C / C ++) yazmak ve derlenmiş kitaplık olarak saklamaktır.


3
HoseDex2Jar işe yaramaz. Sadece dex2jar 'karıştırır' ve kolayca engellenebilir. smali / apktool, vb 'hosed' APK'ları ile gayet iyi çalışıyor.
Nikolay Elenkov

@NikolayElenkov HoseDex2Jar'ın nasıl çalıştığını biliyor musunuz? Nex2jar önlemek ya da karıştırmak için kullandıkları. HoseDex2Jar kullanmak için apk dosyamı web'e yükleyemiyorum çünkü. Ben dex2jar karıştırmak için HoseDex2Jar gibi bir şey yapabilirseniz dex2jar aracını kullanarak kesmek zor olacaktır.
sachin003

1
Belki benim açımdan yanlış anladınız: HoseDex2Jar'ın yaptığı şey, popüler dex2jar aracının (kutunun dışında) tersine çevirememesi için APK'nızı yeniden paketlemektir. Ancak diğer araçlar bunu yapabilir ve genellikle onu yenmek çok kolaydır. Kullanmanın anlamı yok. Hiç kimse Dexguard I şeyden bahsetmedi (ProGuard'ın yazarı tarafından; ücretsiz değil), ama bakmak iş. 'Düzenli' şaşkınlıktan birkaç şey daha yapar.
Nikolay Elenkov

C ++ asla tersine çevrilemez mi? zor ama mümkün. ve size yardımcı olmak için hex-rays.com/products/decompiler/index.shtml gibi araçlar vardır (evet, ARM sürümleri var. bu kolay değil).
dkzm

Evet, @VikartiAnatra: Ben de bir şekilde bahsetmiştim , bunu zorlaştırabilirsin
Sahil Mahajan Mj

24

İşte deneyebileceğiniz birkaç yöntem:

  1. ProGuard gibi gizleme ve araçları kullanın .
  2. Kaynak ve verilerin bir kısmını şifreleyin.
  3. Kurcalamayı tespit etmek için uygulamada tescilli dahili bir sağlama toplamı kullanın.
  4. Bir hata ayıklayıcıya yüklenmesini önlemek için kod tanıtın, yani uygulamanın hata ayıklayıcıyı algılama ve hata ayıklayıcıdan çıkma / öldürme yeteneğine sahip olmasına izin verin.
  5. Çevrimiçi hizmet olarak kimlik doğrulamasını ayırın.
  6. Kullanım uygulama çeşitliliği
  7. Aygıtın kimliğini doğrulamadan önce, örneğin farklı alt sistemdeki aygıtların donanım imzaları için parmak yazdırma tekniğini kullanın.

23

 1. Nasıl bir Android APK ters mühendislik tamamen önleyebilirim? Mümkün mü?

imkansız

 2. Bilgisayar korsanlarının APK dosyasını hiçbir şekilde hackleyememesi için uygulamanın tüm kaynaklarını, varlıklarını ve kaynak kodunu nasıl koruyabilirim?

imkansız

 3. Bilgisayar korsanlığını daha zor, hatta imkansız hale getirmenin bir yolu var mı? APK dosyamdaki kaynak kodunu korumak için daha ne yapabilirim?

Daha zor - mümkün, ama aslında sadece hack rehberleri için googling ortalama bir kullanıcı için daha zor olacak. Birisi uygulamanızı gerçekten kesmek istiyorsa - er ya da geç saldırıya uğrayacaktır.


22

 1. Nasıl bir Android APK ters mühendislik tamamen önleyebilirim? Mümkün mü?

İmkansız

 2. Bilgisayar korsanlarının APK dosyasını hiçbir şekilde hackleyememesi için uygulamanın tüm kaynaklarını, varlıklarını ve kaynak kodunu nasıl koruyabilirim?

Geliştiriciler, kodlarını gizlemek için ProGuard gibi araçları kullanmak gibi adımlar atabilirler, ancak şimdiye kadar birisinin bir uygulamanın kodunu çözmesini tamamen önlemek oldukça zordu.

Gerçekten harika bir araçtır ve kodunuzun kapladığı alanı daraltırken kodunuzu 'tersine çevirme' zorluğunu artırabilir.

Entegre ProGuard desteği: ProGuard artık SDK Araçları ile birlikte paketlenmiştir. Geliştiriciler artık kodlarını bir sürüm derlemesinin entegre bir parçası olarak gizleyebilirler.

 3. Bilgisayar korsanlığını daha zor, hatta imkansız hale getirmenin bir yolu var mı? APK dosyamdaki kaynak kodunu korumak için daha ne yapabilirim?

Araştırma yaparken HoseDex2Jar'ı tanımaya başladım . Bu araç kodunuzu ayrışmaya karşı koruyacaktır, ancak kodunuzu tamamen korumak mümkün görünmemektedir.

Bazı yararlı linkler, bunlara başvurabilirsiniz.


21

Burada asıl soru, dex dosyalarının çözülüp çözülemeyeceğidir ve cevap "bir çeşit" olabilir. Dedexer ve smali gibi sökücüler var .

ProGuard, doğru yapılandırılmış, kodunuzu gizleyecektir. ProGuard'ın ticari bir genişletilmiş versiyonu olan DexGuard, biraz daha yardımcı olabilir. Bununla birlikte, kodunuz hala smali'ye dönüştürülebilir ve tersine mühendislik deneyimine sahip geliştiriciler smali'den ne yaptığınızı anlayabilecektir.

Belki iyi bir lisans seçin ve yasa tarafından mümkün olan en iyi şekilde uygulayın.


4
Bir yan not olarak (sorumluluk reddi: IANAL) - lisans, her koşulda tüm yetki alanları altında uygulamayı korumaz (örneğin, Avrupa'daki bazı ülkelerde uyumluluğu artırmak için sökmeye izin verilir).
Maciej Piechotka

12

Müşteriniz ne yaptığını bilen, doğru kararları verebilecek ve size rehberlik edebilecek birini işe almalıdır.

Yukarıda, arka uçtaki işlem işleme sistemini değiştirme yeteneğine sahip olduğunuz hakkında konuşun saçma - bu tür mimari değişiklikler yapmanıza izin verilmemelidir, bu yüzden yapmayı beklemeyin.

Benim mantığım:

Alan adınız ödeme işleme tabi olduğundan, PCI DSS ve / veya PA DSS'nin (ve potansiyel eyalet / federal yasaların) işletmeniz için önemli olacağını varsaymak güvenlidir - uyumlu olabilmek için güvenli olduğunuzu göstermeniz gerekir. Güvensiz olmak için, güvenli olmadığınızı (test ederek), sonra güvenlik uygun bir seviyede doğrulanana kadar sabitleme, tekrar test etme, vb. Öğrenin (pahalı, yavaş, yüksek riskli başarı yolu). Doğru olanı yapmak için, sıkı düşünün, iş için deneyimli yetenekler uygulayın, güvenli bir şekilde gelişin, daha sonra güvenlik uygun bir seviyede doğrulanana kadar test edin, düzeltin (daha az), vb. (Daha az) = ucuz, hızlı, başarının düşük riskli yolu.


8

Bir mobil ödeme uygulaması (MyCheck) dahil olmak üzere ödeme platformlarında yoğun bir şekilde çalışan biri olarak, bu davranışı sunucuya devretmeniz gerektiğini, ödeme işlemcisi için herhangi bir kullanıcı adı veya şifre (hangisi olursa olsun) saklanacağını veya mobil uygulamada sabit kodlanmış, bu istediğiniz son şeydir, çünkü kaynak kodu gizlemiş olsanız bile anlaşılabilir.

Ayrıca, kredi kartlarını veya ödeme jetonlarını uygulamada saklamamalısınız, her şey tekrar, oluşturduğunuz bir hizmete devredilmeli, daha sonra size daha kolay, PCI uyumlu olmanıza ve Kredi Kartı şirketlerinin kazanmasına izin vermelidir. boynunu solumayın (bizim için yaptıkları gibi).


7

Burada yukarıda verilen diğer cevaplar doğrudur. Sadece başka bir seçenek sunmak istiyorum.

Önemli olduğunu düşündüğünüz bazı işlevler için uygulamanızda WebView denetimini barındırabilirsiniz . Bu durumda işlevsellik web sunucunuza uygulanır. Uygulamanızda çalışıyor gibi görünecek.


@ Giyim Botha evet IMP ekranlar için zaten webview kullandım ve evet bu da güvenliği korumanın bir yoludur, cevabınızı kabul ediyorum.
sachin003

7

Tersine mühendislik (neredeyse) imkansız hale getirmek istiyorsak, uygulamayı tüm hassas şeyleri dahili olarak yürüten ve ana bilgisayar üzerinde GUI'yi kontrol etmek için bazı protokollerle iletişim kuran kurcalamaya karşı oldukça dayanıklı bir çip üzerine koyabiliriz. Kurcalamaya karşı korumalı yongalar bile% 100 çatlamaya dayanıklı değildir; çıtayı yazılım yöntemlerinden çok daha yükseğe yerleştirdiler. Tabii ki, bu rahatsız edici: uygulama, çipin cihaza takılmasını tutan küçük bir USB siğil gerektirir.

Soru, bu uygulamayı kıskançlıkla koruma isteğini ortaya koymuyor.

Amaç, uygulamanın sahip olabileceği (veya bilinen) güvenlik kusurlarını gizleyerek ödeme yönteminin güvenliğini artırmaksa, tamamen yanlıştır. Güvenliğe duyarlı bitler aslında mümkünse açık kaynaklı olmalıdır. Başvurunuzu inceleyen herhangi bir güvenlik araştırmacısının bu bitleri bulmasını ve işlemlerini incelemesini ve sizinle iletişim kurmasını mümkün olduğunca kolaylaştırmalısınız. Ödeme uygulamaları gömülü sertifika içermemelidir. Yani, bir cihaza fabrikadan sabit bir sertifikaya sahip olduğu için bir cihaza güvenen hiçbir sunucu uygulaması olmamalıdır. Uygulamaya, platforma veya ağa vb. Güvenmeyi önleyen doğru tasarlanmış bir uçtan uca kimlik doğrulama protokolü kullanılarak yalnızca kullanıcının kimlik bilgileri üzerinde bir ödeme işlemi yapılmalıdır.

Amaç, kurcalamaya karşı korumalı çipten kısa olan klonlamayı önlemekse, programın tersine mühendislikten ve kopyalanmasından korunmak için yapabileceğiniz hiçbir şey yoktur, böylece biri kendi uygulamasına uyumlu bir ödeme yöntemi ekler. "yetkisiz müşteriler" e yükselme. Yetkisiz müşteriler geliştirmeyi zorlaştırmanın yolları vardır. Bunlardan biri, programın tam durumunun anlık görüntülerine dayalı sağlama toplamları oluşturmak olacaktır: her şey için tüm durum değişkenleri. GUI, mantık, her neyse. Bir klon programı tam olarak aynı iç duruma sahip olmayacaktır. Elbette, benzer şekilde harici olarak görülebilir durum geçişlerine (girişler ve çıkışlar tarafından gözlemlenebileceği gibi), ancak neredeyse aynı dahili duruma sahip bir durum makinesidir. Bir sunucu uygulaması programı sorgulayabilir: ayrıntılı durumunuz nedir? (yani tüm dahili durum değişkenleriniz üzerinde bir sağlama toplamı verin). Bu, gerçek durum geçişlerinden geçerek sunucuda paralel olarak çalışan kukla istemci koduyla karşılaştırılabilir. Bir üçüncü taraf klonu, gelişimini engelleyecek doğru yanıtları vermek için orijinal programın tüm ilgili durum değişikliklerini çoğaltmak zorunda kalacaktır.


7

@Muhammad Saqib ile aynı fikirde: https://stackoverflow.com/a/46183706/2496464

Ve @Mumair iyi bir başlangıç ​​adımları verir: https://stackoverflow.com/a/35411378/474330

Kullanıcının cihazına dağıttığınız her şeyin kullanıcıya ait olduğunu varsaymak her zaman güvenlidir. Sade ve basit. Entelektüel mülklerinizi şifrelemek için en son araçları ve prosedürü kullanabilirsiniz, ancak kararlı bir kişinin sisteminizi 'çalışmasını' önlemenin bir yolu yoktur. Ve mevcut teknoloji, istenmeyen erişim elde etmelerini zorlaştırabilse bile, yarın ya da sadece bir sonraki saat için kolay bir yol olabilir!

Böylece, denklem geliyor:

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

Oyun içi ekonomi kadar basit. (Özellikle oyunlarda! Orada daha 'sofistike' kullanıcılar var ve saniyeler içinde boşluklar var!)

Nasıl güvende oluruz?

Hepsi olmasa da, sunucu tarafında bulunan anahtar işleme sistemlerimizin (ve elbette veritabanının) çoğu. İstemci ve sunucu arasında, şifreli iletişim, doğrulama vb. Yer alır. Bu ince istemci fikridir.



4

Android'de APK imza şeması v2

PackageManager sınıfı artık APK imza şeması v2'yi kullanarak uygulamaların doğrulanmasını destekliyor. APK imza şeması v2, APK dosyalarında yetkisiz değişiklikleri tespit ederek doğrulama hızını önemli ölçüde artıran ve bütünlük garantilerini güçlendiren bir tam dosya imza şemasıdır.

Geri uyumluluğu sağlamak için, v2 imza şemasıyla imzalanmadan önce bir APK v1 imza şemasıyla (JAR imza şeması) imzalanmalıdır. V2 imza şemasında, APK'yı v2 şemasında imzaladıktan sonra ek bir sertifika ile imzalarsanız doğrulama başarısız olur.

APK imza şeması v2 desteği daha sonra N Geliştirici Önizlemesi'nde sunulacaktır.

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


2
Apk imza v2 sadece kaynakların tahrif edilmesini önler, ancak tersine mühendislik daha zor hale getirmez…
Louis CAD

1
Ayrıca imzayı kaldırabilir ve yeniden imzalayabilirsiniz. V2 imzası sadece APK dosyasındaki bir veri bloğudur.
Robert

4

Bir APK'nın tersine mühendislikten tamamen kaçınmanın bir yolu yoktur. Uygulama varlıklarını, kaynakları korumak için şifreleme kullanabilirsiniz.

  • Şifreleme, şifre çözme olmadan kullanılmasını zorlaştıracaktır. Güçlü bir şifreleme algoritması seçmek çatlamayı zorlaştıracaktır.
  • Çatlamayı daha da zorlaştırmak için ana mantığınıza bir parodi kodu ekleme.
  • Kritik mantığınızı herhangi bir ana dilde yazabiliyorsanız ve bu da derhal çözülmesini zorlaştırırsa.
  • Quixxi gibi üçüncü taraf güvenlik çerçevelerini kullanma

3

Temel olarak mümkün değil. Asla mümkün olmayacak. Ancak umut var. Bunu yapmak için bir obfuscator kullanabilirsiniz, böylece bazı yaygın saldırıların yapılması çok daha zor olur:

  1. Yöntemleri / sınıfları yeniden adlandırma (böylece kod çözücüde türler alırsınız a.a)
  2. Şaşırtıcı kontrol akışı (bu nedenle dekompresörde kodun okunması çok zordur)
  3. Dizeleri ve olası kaynakları şifreleme

Eminim başkaları da vardır, ama ana olanlar budur. .NET obfuscator'da PreEmptive Solutions adlı bir şirkette çalışıyorum . Ayrıca Android için çalışan ve DashO adlı bir Java obfuscator var .

Ne var ki, her zaman bir bedeli vardır. Özellikle, performans genellikle daha kötüdür ve genellikle sürümlerde daha fazla zaman gerektirir. Ancak, fikri mülkiyetiniz sizin için son derece önemliyse, genellikle buna değer.

Aksi takdirde, tek seçeneğiniz Android uygulamanızın uygulamanızın tüm gerçek mantığını barındıran bir sunucuya geçmesini sağlamaktır. Bunun kendi sorun payı vardır, çünkü kullanıcıların uygulamanızı kullanmak için İnternet'e bağlı olması gerekir.

Ayrıca, bu sorunu sadece Android değil. Her uygulama mağazasında bir sorun var. Sadece paket dosyasına ulaşmanın ne kadar zor olduğu meselesi (örneğin, iPhone'larda çok kolay olduğuna inanmıyorum, ancak yine de mümkün).


Ne yazık ki bir istemci (uygulama) kesmek, onlar iletişim biçimini görmek ve kendi sunucu oluşturmak mümkün olacaktır :(
Jocky Doe

3

RE'den tamamen kaçınmak mümkün değildir, ancak onları dahili olarak daha karmaşık hale getirerek, saldırganların uygulamanın net çalışmasını görmesini zorlaştırırsınız, bu da saldırı vektörlerinin sayısını azaltabilir.

Uygulama son derece hassas verileri işliyorsa, kodunuzu tersine mühendislik karmaşıklığını artırabilecek çeşitli teknikler mevcuttur. Bir teknik, saldırgan tarafından kolay çalışma zamanı yönetimini sınırlamak için C / C ++ kullanmaktır. Çok olgun ve Android ile entegre edilmesi kolay geniş C ve C ++ kütüphaneleri var JNI sunuyor. Saldırganın, uygulamaya düşük düzeyde saldırmak için hata ayıklama kısıtlamalarını atlaması gerekir. Bu, bir saldırıya daha fazla karmaşıklık katar. Android uygulamalarında, bir saldırgan veya kötü amaçlı yazılım tarafından kolay çalışma süresi manipülasyonunu önlemek için uygulama bildiriminde android: debuggable = ”false” ayarlanmalıdır.

İzleme Denetimi - Bir uygulama şu anda bir hata ayıklayıcı veya başka bir hata ayıklama aracı tarafından izlenip izlenmediğini belirleyebilir. İzlenirse, uygulama, kullanıcı verilerini korumak için şifreleme anahtarlarını atmak, sunucu yöneticisine bildirimde bulunmak veya kendini savunmak için bu tür diğer yanıtlar gibi herhangi bir sayıda olası saldırı yanıtı eylemi gerçekleştirebilir. Bu, işlem durum bayraklarını kontrol ederek veya ptrace ekinin dönüş değerini karşılaştırmak, üst işlemi kontrol etmek, işlem listesindeki kara liste hata ayıklayıcılarını veya programın farklı yerlerindeki zaman damgalarını karşılaştırmak gibi diğer teknikler kullanılarak belirlenebilir.

Optimizasyonları - gizlemek yardımcı olabilir derleyici optimizasyonlar kullanan matematiksel hesaplamalar ve karmaşık mantık diğer tür, gelişmiş için bullak kolayca daha zor bir saldırganın belirli kodun bir anlayış kazanmak için yapım, bir saldırgan tarafından sökülemez şekilde nesne kodu. Android'de bu, NDK ile yerel olarak derlenmiş kütüphaneler kullanılarak daha kolay elde edilebilir. Ek olarak, bir LLVM Obfuscator veya herhangi bir koruyucu SDK kullanılması, daha iyi makine kodu gizlemesi sağlayacaktır.

İkili sıyırma - Yerel ikili sıyırma, uygulamanızın düşük düzeyli işlevlerinin yapısını görüntülemek için saldırganın ihtiyaç duyduğu zaman ve beceri düzeyini artırmanın etkili bir yoludur. İkili sıyırma yoluyla, ikilinin sembol tablosu çıkarılır, böylece bir saldırgan bir uygulamada kolayca hata ayıklayabilir veya tersine mühendislik uygulayamaz.

Ve sonunda, gizleme ve ProGuard gibi araçların farkında olmalısınız.


3

Uygulamanız bu kadar hassassa, sunucu tarafında ödeme işleme bölümünü dikkate almalısınız. Ödeme işleme algoritmalarınızı değiştirmeyi deneyin. Android uygulamasını yalnızca kullanıcı bilgilerini (örn. Hesap bakiyesi) toplamak ve görüntülemek için kullanın ve java kodları içinde ödemeleri işlemek yerine şifrelenmiş parametrelerle güvenli bir SSL protokolü kullanarak sunucunuza gönderin. Sunucunuzla iletişim kurmak için tamamen şifreli ve güvenli bir API oluşturun.

Tabii ki, o da hacklenebilir ve kaynak kodları koruması ile ilgisi yoktur, ancak korsanların uygulamanızı kandırmasını zorlaştırmak için başka bir güvenlik katmanı olduğunu düşünün.


2

TPM yongalarının (Güvenilir Platform Modülü) korumalı kodu sizin için yönetmesi gerekmez mi? PC'lerde (özellikle Apple'da) yaygınlaşıyorlar ve bugünün akıllı telefon yongalarında zaten mevcut olabilirler. Ne yazık ki, henüz onu kullanacak bir OS API'sı yok. Umarım Android bu bir gün için destek ekleyecektir. Bu aynı zamanda Google'ın WebM için üzerinde çalıştığı içerik DRM'sini temizlemenin anahtarıdır.


2

Son kullanıcıların eline geçtiğinizde hiçbir şey güvenli değildir, ancak bazı yaygın uygulamalar saldırganın verileri çalmasını zorlaştırabilir.

  • Ana mantığınızı (algoritmaları) sunucu tarafına koyun.
  • Sunucu ve istemci ile iletişim kurun; s / b sunucusu ve istemcinin SSL veya HTTPS ile güvenli olduğundan emin olun; veya diğer teknikler anahtar çifti oluşturma algoritmalarını (ECC, RSA) kullanabilir. Hassas bilgilerin Uçtan Uca şifreli kaldığından emin olun.
  • Oturumları kullanın ve belirli bir zaman aralığından sonra süreleri dolar.
  • Kaynakları şifreleyin ve istek üzerine sunucudan alın.
  • Veya webviewsunucudaki kaynak + kodu koruyarak sisteme erişen Hibrit uygulamasını yapabilirsiniz

Çoklu yaklaşımlar; performans ve güvenlik arasında feda etmeniz gerektiği açıktır


2

Bu konuda bu iyi cevabı görebiliyorum. Ayrıca redexkodu optimize etmek için facebook kullanabilirsiniz . Redex, korumanın .dexseviye olarak çalıştığı düzeyde çalışır .class.



1

Bilgisayar korsanlarının APK dosyasını hiçbir şekilde hackleyememesi için uygulamanın tüm kaynaklarını, varlıklarını ve kaynak kodunu nasıl koruyabilirim?

Bir APK dosyası SHA-1 algoritması ile korunur . APK'nın META-INF klasöründe bazı dosyalar görebilirsiniz . Herhangi bir APK dosyasını çıkarır ve içeriğinden herhangi birini değiştirir ve tekrar sıkıştırırsanız ve bu yeni APK dosyasını bir Android makinesinde çalıştırdığınızda, çalışmaz, çünkü SHA-1 karmaları asla eşleşmez.


Bu doğru; ancak APK'yı (farklı bir sertifika ile) istifa etmek önemsizdir ve her şey tekrar çalışacaktır. APK'yı uygulamanın içinden imzalamak için hangi imzanın kullanıldığını kontrol etmek ve sertifika değişirse hata yapmak mümkündür, ancak bu kodu uygulamadan düzenlemek sadece biraz daha az önemsizdir.
David Verilen

Bu, android cihazın değiştirilmiş kodu çalıştırmasını engelleyebilir, ancak yine de kolayca ilgili kodu çıkarabilir ve bir PC'ye istediğinizi yapan yeni bir kod yazabilirsiniz.
Sarel Botha


1

Araç: Proguard'ı uygulamanızda kullanmak uygulamanızın tersine mühendislik yapmakla sınırlandırılabilir


Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.