Jak uniknąć inżynierii odwrotnej pliku APK?

AFAIK, nie możesz już chronić plików w katalogu / res, niż są one teraz chronione.

Są jednak kroki, które możesz podjąć, aby chronić swój kod źródłowy, a przynajmniej to, co robi, jeśli nie wszystko.

1. Użyj narzędzi takich jak ProGuard. Spowoduje to zaciemnienie kodu i utrudni jego odczytanie podczas dekompilacji, jeśli nie niemożliwe.
2. Przenieś najbardziej krytyczne części usługi z aplikacji i do serwisu internetowego, ukrytego za serwerem język jak PHP. Na przykład, jeśli masz algorytm, który zabrał ci milion dolarów, aby napisać. Najwyraźniej nie chcesz, żeby ludzie kradli to z Twojej aplikacji. Przenieś algorytm i poproś, aby przetwarzał dane na zdalnym serwerze, a następnie użyj aplikacji, aby po prostu dostarczyć mu dane. Lub użyj NDK, aby zapisać je natywnie do plików. so, które są znacznie mniej podatne na dekompilację niż pliki APK. Nie wydaje mi się, żeby dekompilator był. więc pliki już istnieją (a nawet gdyby tak było, to nie byłoby tak dobrze jako Dekompilatory Javy). Dodatkowo, jak wspomniał @nikolay w komentarzach, powinieneś używać SSL podczas interakcji między serwerem a urządzeniem.
3. podczas przechowywania wartości na urządzeniu nie przechowuj ich w formacie raw. Na przykład, jeśli masz grę i przechowujesz kwotę w walucie gry, którą użytkownik ma w SharedPreferences. Załóżmy, że to 10000 monety. Zamiast zapisywać 10000 bezpośrednio, zapisz go za pomocą algorytmu, takiego jak ((currency*2)+1)/13. Więc zamiast 10000 zapisujesz 1538.53846154 do SharedPreferences. Jednak powyższy przykład nie jest doskonały i będziesz musiał pracować, aby wymyślić równanie, które nie straci waluty na błędy zaokrąglania itp.
4. możesz zrobić podobną rzecz dla zadań po stronie serwera. Teraz dla przykładu, weźmy aplikację do przetwarzania płatności. Załóżmy, że użytkownik musi dokonać płatności $200. Zamiast wysyłać surową wartość $200 do serwera, wyślij serię mniejszych, predefiniowanych wartości, które sumują się do $200. Na przykład, mieć plik lub tabelę na twoim serwerze, który zrównuje słowa z wartościami. Powiedzmy więc, że Charlie odpowiada $47, a John $3. Więc zamiast wysyłać $200, możesz wysłać Charlie cztery razy i John cztery razy. Na serwerze, zinterpretować co oznaczają i dodać to. Uniemożliwia to hakerowi wysyłanie dowolnych wartości na serwer, ponieważ nie wie, które słowo odpowiada jakiej wartości. Jako dodatkowy środek bezpieczeństwa, można mieć równanie podobne do punktu 3 dla tego, jak również, i zmienić słowa kluczowe co n liczba dni.
5. wreszcie, możesz wstawić losowy bezużyteczny kod źródłowy do swojej aplikacji, tak aby haker szukał igły w stogu siana. Wstaw losowe klasy zawierające fragmenty z Internetu lub po prostu funkcje do obliczania losowych rzeczy, takich jak ciąg Fibonacciego. Upewnij się, że te klasy są kompilowane, ale nie są używane przez rzeczywistą funkcjonalność aplikacji. Dodaj wystarczająco dużo tych fałszywych klas, a haker będzie miał trudności ze znalezieniem prawdziwego kod.

W sumie, nie ma sposobu, aby chronić swoją aplikację w 100%. Możesz to utrudnić, ale nie niemożliwe. Twój serwer WWW może zostać naruszony, haker może dowiedzieć się słów kluczowych, monitorując wiele kwot transakcji i słów kluczowych, które wysyłasz, haker może pieczołowicie przejść przez źródło i dowiedzieć się, który kod jest atrapą.

W żadnym momencie w historii komputerów nie było możliwe, aby zapobiec inżynierii odwrotnej oprogramowania, gdy podajesz jego roboczą kopię atakującemu. Ponadto, najprawdopodobniej, nigdy nie będzie to możliwe .

Z tym zrozumiałym, jest oczywiste rozwiązanie: nie zdradzaj swoich sekretów napastnikowi. chociaż nie możesz chronić zawartości swojego APK, to to, co możesz chronić, to wszystko, czego nie rozpowszechniasz. Zazwyczaj jest to po stronie serwera oprogramowanie używane do aktywacji, płatności, egzekwowania reguł i innych soczystych bitów kodu. Możesz chronić cenne aktywa przez Nie dystrybuując je w swoim APK. Zamiast tego skonfiguruj serwer, który odpowiada na żądania z Twojej aplikacji, "używa" zasobów (cokolwiek to może oznaczać), a następnie wysyła wynik z powrotem do aplikacji. Jeśli ten model nie działa dla aktywów, które masz na myśli, możesz ponownie przemyśleć swoją strategię.

Również, jeśli twoim głównym celem jest zapobieganie piractwo aplikacji : nawet się nie trudź. Spaliłeś już więcej czasu i pieniędzy na ten problem, niż jakikolwiek środek antypiracki mógłby kiedykolwiek mieć nadzieję, że cię uratuje. Zwrot z inwestycji za rozwiązanie tego problemu jest tak niski, że nie ma sensu nawet o tym myśleć.

Pierwsza zasada bezpieczeństwa aplikacji: każda maszyna, do której atakujący uzyskuje nieograniczony dostęp fizyczny lub elektroniczny, należy teraz do atakującego, niezależnie od tego, gdzie faktycznie się znajduje i ile za nią zapłaciłeś.

Druga zasada bezpieczeństwa aplikacji: każde oprogramowanie, które pozostawia fizyczne granice, do których atakujący nie może przeniknąć, należy teraz do atakującego, niezależnie od tego, ile czasu spędziłeś na kodowaniu.

Trzecia zasada: Dowolna informacje, które pozostawiają te same fizyczne granice, których atakujący nie może teraz przekroczyć, należą do atakującego, bez względu na to, jak cenne są dla Ciebie.

Już to wszystko wiedziałeś, dlatego starasz się chronić kod swojej aplikacji. Ale na tym polega pierwszy problem; narzędzia maskujące mogą sprawić, że kod będzie bałaganem dla człowieka, który spróbuje się przekopać, ale program nadal musi działać; oznacza to rzeczywisty przepływ logiczny aplikacji i danych jego użycie nie ma wpływu na zaciemnienie. Biorąc pod uwagę małą wytrwałość, atakujący może po prostu odkamieniać kod, a to nie jest nawet konieczne w niektórych przypadkach, gdy to, na co patrzy, nie może być niczym innym, niż tym, czego szuka.

Zamiast tego powinieneś starać się upewnić, że atakujący nie może nic zrobić z Twoim kodem, bez względu na to, jak łatwo jest mu uzyskać jego wyraźną kopię. Oznacza to, że nie ma zakodowanych sekretów, ponieważ te sekrety nie są tajne, gdy tylko kod odejdzie budynek, w którym go rozwinąłeś.

Te wartości klucza, które zakodowałeś na twardo, powinny zostać całkowicie usunięte z kodu źródłowego aplikacji. Zamiast tego, powinny one znajdować się w jednym z trzech miejsc; niestabilna pamięć na urządzeniu, która jest trudniejsza (ale nadal nie jest niemożliwa) dla atakującego do uzyskania kopii offline; na stałe w klastrze serwerów, do którego kontrolujesz dostęp żelazną pięścią; lub w drugim magazynie danych niezwiązanym z urządzeniem lub serwerami, takim jak karta fizyczna lub w Twoim komputerze. pamięci użytkownika (co oznacza, że w końcu będzie w pamięci, ale nie musi być na długo).

Rozważ następujący schemat. Użytkownik wprowadza swoje poświadczenia dla aplikacji z pamięci do urządzenia. Musisz niestety zaufać, że urządzenie użytkownika nie jest już zagrożone przez keylogger lub trojana; najlepsze, co możesz zrobić w tym zakresie, to zaimplementować zabezpieczenia wieloskładnikowe, zapamiętywając trudne do sfałszowania informacje identyfikacyjne o urządzeniach, z których korzystał użytkownik (MAC / IP, IMEI, itp.), oraz dostarczenie co najmniej jednego dodatkowego kanału, za pomocą którego można zweryfikować próbę logowania na nieznanym urządzeniu.

Dane uwierzytelniające, raz wprowadzone, są zaciemniane przez oprogramowanie Klienta( przy użyciu bezpiecznego skrótu), a dane uwierzytelniające w postaci zwykłego tekstu odrzucane; spełniły swoje zadanie. Dane uwierzytelnione są przesyłane bezpiecznym kanałem do serwera uwierzytelnionego certyfikatem, który ponownie je zahaszowuje , aby uzyskać dane używane do weryfikacji poprawności logowania. W ten sposób klient nigdy nie wie, co jest w rzeczywistości w porównaniu do wartości bazy danych, serwer aplikacji nigdy nie zna poświadczeń tekstowych za tym, co otrzymuje do walidacji, serwer danych nigdy nie wie, w jaki sposób dane przechowywane do walidacji są produkowane, a człowiek w środku widzi tylko bełkot, nawet jeśli bezpieczny kanał został naruszony.

Po zweryfikowaniu, serwer przesyła z powrotem token przez kanał. Token jest przydatny tylko w ramach bezpiecznej sesji, składa się z losowy szum lub zaszyfrowana (a więc weryfikowalna) Kopia identyfikatorów sesji, a aplikacja kliencka musi wysłać ten token na tym samym kanale do serwera w ramach każdego żądania, aby coś zrobić. Aplikacja kliencka zrobi to wiele razy, ponieważ nie może zrobić niczego związanego z pieniędzmi, poufnymi danymi lub czegokolwiek innego, co samo w sobie mogłoby być szkodliwe; musi zamiast tego poprosić serwer o wykonanie tego zadania. Aplikacja kliencka nigdy nie zapisze żadnych poufnych informacji do persistent pamięć na samym urządzeniu, przynajmniej nie w postaci zwykłego tekstu; klient może poprosić serwer przez bezpieczny kanał o symetryczny klucz do zaszyfrowania wszelkich lokalnych danych, które serwer będzie pamiętał; w późniejszej sesji klient może poprosić serwer o ten sam klucz do odszyfrowania danych do użycia w pamięci lotnej. Te dane nie będą również jedyną kopią; wszystko, co przechowuje klient, powinno być również przesłane w jakiejś formie do serwera.

Oczywiście, to sprawia, że aplikacja w dużym stopniu zależy od Dostęp do Internetu; urządzenie klienckie nie może wykonywać żadnej ze swoich podstawowych funkcji bez prawidłowego połączenia i uwierzytelnienia przez serwer. Nie inaczej niż Facebook, naprawdę.

Teraz, komputer, który atakujący chce jest Twój serwer, ponieważ to, a nie aplikacja / urządzenie klienta jest rzeczą, która może zrobić mu pieniądze lub spowodować ból innych ludzi dla jego przyjemności. To jest OK; dostajesz znacznie więcej huku za swoje pieniądze i wysiłek, aby zabezpieczyć serwer niż próbując zabezpieczyć wszystkie klientów. Serwer może znajdować się za wszelkiego rodzaju zaporami ogniowymi i innymi zabezpieczeniami elektronicznymi, a dodatkowo może być fizycznie zabezpieczony za stalą, betonem, dostępem do Karty/pin i całodobowym nadzorem wideo. Atakujący musiałby być bardzo wyrafinowany, aby uzyskać bezpośredni dostęp do serwera, a Ty (powinieneś) natychmiast o tym wiedzieć.

Najlepsze, co może zrobić atakujący, to ukraść telefon i dane uwierzytelniające użytkownika i zalogować się na serwer z ograniczonymi prawami klient. Jeśli tak się stanie, podobnie jak utrata karty kredytowej, uprawniony użytkownik powinien zostać poinstruowany, aby zadzwonić na numer 800 (najlepiej łatwy do zapamiętania, a nie na odwrocie karty, którą nosiłby w torebce, portfelu lub teczce, która mogłaby zostać skradziona wraz z urządzeniem mobilnym) z dowolnego telefonu, do którego ma dostęp, który łączy go bezpośrednio z Działem obsługi klienta. Twierdzą, że ich telefon został skradziony, podają jakiś podstawowy unikalny identyfikator, a konto jest zablokowane, wszelkie transakcje atakujący może być w stanie przetworzyć są wycofane, a atakujący jest z powrotem do punktu wyjścia.

1. Jak mogę całkowicie uniknąć inżynierii odwrotnej APK Androida? Czy to możliwe?

To niemożliwe

2. Jak mogę chronić wszystkie zasoby, zasoby i Kod źródłowy aplikacji, aby hakerzy nie mogli zhakować pliku APK w żaden sposób?

Gdy ktoś zmieni a .rozszerzenie apk do .zip, potem po rozpakowaniu ktoś może łatwo zdobyć wszystkie zasoby (poza Manifest.xml ), ale z APKtool można dostać prawdziwa zawartość pliku manifestu też. Znowu nie.

3. Czy istnieje sposób, aby hakowanie było trudniejsze, a nawet niemożliwe? Co jeszcze mogę zrobić, aby chronić kod źródłowy w moim pliku APK?

Ponownie, nie, ale można zapobiec do pewnego poziomu, czyli

[28]} Pobierz zasób z sieci i wykonaj jakiś proces szyfrowania
• użyj wstępnie skompilowanej biblioteki natywnej (C, C++, JNI, NDK)
• Zawsze wykonuj jakieś hashowanie ( MD5/SHA keys or any other logic)

Nawet z Smali, ludzie mogą bawić się Twoim kodem. Podsumowując, to niemożliwe.

100% unikanie inżynierii odwrotnej APK Androida nie jest możliwe, ale możesz użyć tych sposobów, aby uniknąć wyodrębniania większej ilości danych, takich jak kod źródłowy, zasoby z APK i zasoby:

1. Użyj ProGuard do zaciemnienia kodu aplikacji

2. Użyj NDK używając C i C++ aby umieścić rdzeń aplikacji i zabezpieczyć część kodu w plikach .so

3. Aby zabezpieczyć zasoby, nie umieszczaj wszystkich ważnych zasobów w folderze zasoby z APK. Pobierz te zasoby w momencie pierwszego uruchomienia aplikacji.

Programiści mogą podjąć następujące kroki, aby zapobiec kradzieży APK w jakiś sposób,

• Najbardziej podstawowym sposobem jest użycie narzędzi takich jak ProGuard do zaciemniania kodu, ale do tej pory dość trudno było całkowicie uniemożliwić komuś dekompilację aplikacji.

• Słyszałem też o narzędziu HoseDex2Jar. Zatrzymuje Dex2Jar wstawiając nieszkodliwy kod w APK Androida, który myli i wyłącza {[1] } i chroni kod przed dekompilacją. Może w jakiś sposób uniemożliwić hakerom dekompilację APK do czytelnego kodu java.

• Użyj jakiejś aplikacji po stronie serwera, aby komunikować się z aplikacją tylko wtedy, gdy jest to potrzebne. Może to pomóc zapobiec ważnych danych.

W ogóle nie można całkowicie chronić kodu przed potencjalnymi hakerami. W jakiś sposób możesz utrudnić im dekompilację kodu i być nieco frustrującym zadaniem. Jednym z najskuteczniejszych sposobów jest pisanie w kodzie natywnym (C / C++) i przechowywanie to jako skompilowane biblioteki.

1. Jak mogę całkowicie uniknąć inżynierii odwrotnej APK Androida? Czy to możliwe?

To niemożliwe

2. Jak mogę chronić wszystkie zasoby, zasoby i Kod źródłowy aplikacji, aby hakerzy nie mogli zhakować pliku APK w żaden sposób?

Programiści mogą podjąć takie kroki, jak używanie narzędzi takich jak ProGuard, aby zaciemnić swój kod, ale do tej pory było dość trudno całkowicie zapobiec dekompilacji kodu app.

Jest to naprawdę świetne narzędzie i może zwiększyć trudność "odwrócenia" kodu, zmniejszając jego ślad.

Zintegrowana obsługa programu ProGuard: program ProGuard jest teraz pakowany z narzędziami SDK. Deweloperzy mogą teraz zaciemniać swój kod jako zintegrowaną część kompilacji wydania.

3. Czy istnieje sposób, aby hakowanie było trudniejsze, a nawet niemożliwe? Co jeszcze mogę zrobić, aby chronić kod źródłowy w moim pliku APK?

Podczas badania, przyszedłem aby dowiedzieć się o HoseDex2Jar. To narzędzie ochroni Twój kod przed dekompilacją, ale wydaje się, że nie jest możliwe całkowite zabezpieczenie Twojego kodu.

Niektóre z pomocnych linków, można odnieść się do nich.

• Proguard, Android i serwer licencjonowania
• zabezpieczanie aplikacji Android LVL
• pytanie o przepełnienie stosu czy naprawdę nie można chronić aplikacji na Androida przed inżynierią odwrotną?
• stos Pytanie o przepełnienie Jak zapobiec inżynierii odwrotnej pliku APK Androida w celu zabezpieczenia kodu?

1. Jak mogę całkowicie uniknąć inżynierii odwrotnej APK Androida? Czy to możliwe?

Impossible

2. Jak mogę chronić wszystkie zasoby, zasoby i Kod źródłowy aplikacji, aby hakerzy nie mogli zhakować pliku APK w żaden sposób?

Impossible

3. Czy istnieje sposób, aby hakowanie było trudniejsze, a nawet niemożliwe? Co jeszcze mogę zrobić, aby chronić kod źródłowy w moim pliku APK?

Oto kilka metod, które możesz wypróbować:

1. Użyjzaciemniania i narzędzi takich jakProGuard .
2. Szyfruj część źródła i danych.
3. Użyj zastrzeżonej sumy kontrolnej wbudowanej w aplikacji do wykrywania manipulacji.
4. wprowadzenie kodu, aby uniknąć ładowania w debugerze, to znaczy, niech aplikacja ma możliwość wykrycia debuggera i zakończyć / zabić debuggera.
5. oddziel uwierzytelnianie jako usługę online.
6. Użyj różnorodność Aplikacji
7. Użyj techniki drukowania palcem np. sygnatur sprzętowych urządzeń z różnych podsystemów przed uwierzytelnieniem urządzenia.

Głównym pytaniem jest to, czy pliki dex mogą być dekompilowane, a odpowiedź jest taka, że mogą być "jakby". Istnieją disassemblery takie jak dedexer i smali.

ProGuard, poprawnie skonfigurowany, zaciemni Twój kod. DexGuard, który jest komercyjną rozszerzoną wersją ProGuard, może pomóc trochę więcej. Jednak Twój kod nadal może zostać przekonwertowany na smali, a programiści z doświadczeniem w inżynierii odwrotnej będą mogli dowiedzieć się, co robisz z smali.

Może wybrać dobrą licencję i egzekwować ją przez prawo w najlepszy możliwy sposób.

Twój Klient powinien zatrudnić kogoś, kto wie, co robi, kto może podejmować właściwe decyzje i może cię mentorować.

Mówienie powyżej o tym, że masz jakąś zdolność do zmiany systemu przetwarzania transakcji na backendzie jest absurdalne - nie powinieneś mieć pozwolenia na wprowadzanie takich zmian architektonicznych, więc nie spodziewaj się, że będziesz w stanie.

Moje uzasadnienie na ten temat:

Ponieważ Twoja domena jest przetwarzaniem płatności, można bezpiecznie założyć, że PCI DSS i / lub PA DSS (i potencjalny stan / federalny prawo) będzie istotne dla Twojej firmy - aby być zgodnym, musisz pokazać, że jesteś bezpieczny. Aby być niepewnym, dowiedz się (poprzez testy), że nie jesteś bezpieczny, a następnie naprawiaj, ponownie testuj, etcetera, dopóki bezpieczeństwo nie zostanie zweryfikowane na odpowiednim poziomie = droga, powolna, ryzykowna droga do sukcesu. Aby zrobić właściwą rzecz, myśleć z góry, zaangażować doświadczony talent do pracy, rozwijać się w bezpieczny sposób, następnie testować, naprawiać (mniej), itd., dopóki bezpieczeństwo nie zostanie zweryfikowane na odpowiednim poziomie = niedrogi, szybki, mało ryzykowny sposób na sukces.

Inne upvoted odpowiedzi tutaj są poprawne. Chcę tylko zapewnić inną opcję.

Dla niektórych funkcji, które uznasz za ważne, możesz hostować kontrolkę WebView w swojej aplikacji. Funkcjonalność zostanie następnie zaimplementowana na twoim serwerze WWW. Będzie to wyglądało tak, jakby działało w Twojej aplikacji.

Jeśli chcemy, aby inżynieria odwrotna (prawie) była niemożliwa, możemy umieścić aplikację na wysoce odpornym na manipulacje chipie, który wykonuje wszystkie wrażliwe rzeczy wewnętrznie i komunikuje się z jakimś protokołem, aby umożliwić sterowanie GUI na hoście. Nawet odporne na manipulacje chipy nie są w 100% odporne na pękanie; po prostu ustawiają poprzeczkę znacznie wyżej niż metody programowe. Oczywiście jest to niewygodne: aplikacja wymaga trochę brodawki USB, która trzyma chip do włożenia do urządzenie.

Pytanie nie ujawnia motywacji, by tak zazdrośnie chronić tę aplikację.

Jeśli celem jest poprawa bezpieczeństwa metody płatności poprzez ukrycie wszelkich wad bezpieczeństwa aplikacji (znanych lub innych), jest to całkowicie błędne. Bity wrażliwe na bezpieczeństwo powinny być w rzeczywistości open-source, jeśli jest to wykonalne. Powinieneś ułatwić każdemu badaczowi bezpieczeństwa, który przejrzy Twoją aplikację, znalezienie tych bitów i analizować ich działanie, i skontaktować się z Tobą. Aplikacje płatnicze nie powinny zawierać żadnych wbudowanych certyfikatów. Oznacza to, że nie powinno być aplikacji serwerowej, która ufa urządzeniu po prostu dlatego, że ma stały certyfikat z fabryki. Transakcja płatnicza powinna być dokonywana wyłącznie na danych uwierzytelniających użytkownika, przy użyciu prawidłowo zaprojektowanego protokołu uwierzytelniania end-to-end, który wyklucza zaufanie do aplikacji, platformy, sieci itp.

Jeśli celem jest aby zapobiec klonowaniu, poza tym odpornym na manipulacje chipem, nie ma nic, co można zrobić, aby chronić program przed odwrotną inżynierią i skopiowaniem, tak aby ktoś włączył kompatybilną metodę płatności do własnej aplikacji, dając początek "nieautoryzowanym klientom". Istnieją sposoby na utrudnienie rozwoju nieautoryzowanych klientów. Jednym z nich byłoby utworzenie sum kontrolnych na podstawie migawek pełnego stanu programu: wszystkich zmiennych stanu, dla wszystkiego. GUI, logika, cokolwiek. Klon program nie będzie miał dokładnie tego samego stanu wewnętrznego. Oczywiście, jest to maszyna stanowa, która ma podobne widoczne na zewnątrz przejścia stanu (co można zaobserwować na wejściach i wyjściach), ale prawie taki sam stan wewnętrzny. Aplikacja serwera może przesłuchać program: jaki jest Twój szczegółowy stan? (tzn. daj mi sumę kontrolną wszystkich swoich wewnętrznych zmiennych stanu). Można to porównać z atrapy kodu klienta, który jest wykonywany na serwerze równolegle, przechodząc przez rzeczywisty stan przejścia. Klon strony trzeciej będzie musiał replikować wszystkie istotne zmiany stanu prawdziwego programu, aby dać poprawne odpowiedzi, co utrudni jego rozwój.

Jako ktoś, kto pracował intensywnie na platformach płatniczych, w tym jednej aplikacji do płatności mobilnych (MyCheck), powiedziałbym, że musisz delegować to zachowanie na serwer, żadna nazwa użytkownika lub hasło dla procesora płatności (cokolwiek to jest) nie powinny być przechowywane lub zakodowane na twardo w aplikacji mobilnej, to ostatnia rzecz, którą chcesz, ponieważ źródło może być zrozumiane nawet wtedy, gdy zaciemnisz kod.

Ponadto nie należy przechowywać kart kredytowych ani tokenów płatniczych na aplikacja, wszystko powinno być ponownie przekazane do usługi, którą zbudowałeś, to również pozwoli Ci później, być zgodne z PCI łatwiej, a firmy obsługujące karty kredytowe nie będą oddychać ci na karku(jak zrobili to dla nas).

Proponuję spojrzeć na ochrona aplikacji przed atakami. To usługa komercyjna, ale korzystała z niej firma mojego przyjaciela i chętnie z niej korzystają.

APK Signature scheme v2 in Android N

Klasa PackageManager obsługuje teraz weryfikację aplikacji przy użyciu schematu podpisu APK v2. APK signature scheme v2 to schemat podpisu całego pliku, który znacznie poprawia szybkość weryfikacji i wzmacnia Gwarancje integralności poprzez wykrywanie nieautoryzowanych zmian w plikach APK.

Aby zachować kompatybilność wsteczną, APK musi być podpisany za pomocą schematu podpisu v1 (jar signature scheme) przed podpisaniem za pomocą schemat podpisu v2. W przypadku schematu podpisu v2 weryfikacja nie powiedzie się, jeśli podpiszesz APK z dodatkowym certyfikatem po podpisaniu za pomocą schematu v2.

APK signature scheme V2 wsparcie będzie dostępne później w N Developer Preview.

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

W Zasadzie to niemożliwe. To nigdy nie będzie możliwe. Jest jednak nadzieja. Możesz użyć obfuscator , aby sprawić, że niektóre typowe ataki są o wiele trudniejsze do przeprowadzenia, w tym takie rzeczy jak:

1. Zmiana nazw metod/klas (więc w dekompilatorze dostajesz typy typu a.a)
2. zaciemnianie przepływu sterowania (więc w dekompilatorze kod jest bardzo trudny do odczytania)
3. Szyfrowanie łańcuchów i ewentualnie zasobów

Jestem pewien, że są inni, ale to główne. Pracuję dla firmy o nazwie PreEmptive Solutions na . NET obfuscator. Mają również obfuscator Java, który działa również dla Androida, o nazwie DashO .

W przeciwnym razie, jedynym wyborem jest zrobić to tak, że Twoja aplikacja na Androida przechodzi przez serwer, na którym znajduje się cała prawdziwa logika Twojej aplikacji. Ma to swój udział w problemach, ponieważ oznacza to, że użytkownicy muszą być podłączeni do Internetu, aby korzystać z aplikacji.

Jego nie można całkowicie uniknąć RE, ale poprzez ich bardziej skomplikowane wewnętrznie, można umieścić sprawiają, że trudniejsze dla atakujących, aby zobaczyć jasne działanie aplikacji, co może zmniejszyć liczbę wektorów ataku.

Jeśli aplikacja obsługuje bardzo wrażliwe dane, istnieją różne techniki, które mogą zwiększyć złożoność inżynierii odwrotnej kodu. Jedną z technik jest użycie C / C++ w celu ograniczenia łatwej manipulacji przez atakującego. Istnieje wiele bibliotek C i C++, które są bardzo dojrzałe i łatwe do integracji z Android oferuje JNI. Atakujący musi najpierw obejść ograniczenia debugowania, aby zaatakować aplikację na niskim poziomie. To jeszcze bardziej komplikuje atak. Aplikacje na Androida powinny mieć ustawiony android:debuggable="false" w manifeście aplikacji, aby zapobiec łatwej manipulacji czasem uruchamiania przez atakującego lub złośliwe oprogramowanie.

Trace Checking - aplikacja może określić, czy jest obecnie śledzona przez debugger lub inne narzędzie do debugowania. Jeśli aplikacja zostanie wyśledzona, może wykonać dowolną liczbę możliwych akcji reagowania na ataki, takich jak odrzucenie kluczy szyfrowania w celu ochrony danych użytkownika, powiadomienie administratora serwera lub inne tego typu odpowiedzi w celu obrony. Można to określić, sprawdzając flagi statusu procesu lub używając innych technik, takich jak porównywanie wartości zwracanej przez ptrace attach, sprawdzanie procesu nadrzędnego, debuggerów czarnej listy na liście procesów lub porównywanie znaczniki czasu w różnych miejscach programu.

Optymalizacje - aby ukryć zaawansowane obliczenia matematyczne i inne rodzaje skomplikowanej logiki, wykorzystanie optymalizacji kompilatora może pomóc zaciemnić kod obiektowy, aby nie mógł być łatwo zdemontowany przez atakującego, co utrudnia atakującemu zrozumienie danego kodu. W systemie Android można to łatwiej osiągnąć, wykorzystując natywnie skompilowane biblioteki z NDK. Dodatkowo, użycie Obfuscatora LLVM lub dowolnego zestawu SDK protector zapewni lepszą maskację kodu maszynowego.

Usuwanie plików binarnych – Usuwanie natywnych plików binarnych jest skutecznym sposobem na zwiększenie czasu i poziomu umiejętności wymaganego od atakującego, aby zobaczyć skład funkcji niskiego poziomu Twojej aplikacji. Przez usunięcie pliku binarnego, tablica symboli pliku binarnego jest usuwana, tak że atakujący nie może łatwo debugować ani inżynierii wstecznej aplikacji.Możesz zapoznać się z technikami stosowanymi na Systemy GNU / Linux jak sstriping czy UPX.

I w końcu musisz być świadomy o maskowaniu i narzędziach takich jak ProGuard.

Nie ma sposobu, aby całkowicie uniknąć inżynierii odwrotnej APK. Aby chronić zasoby i zasoby aplikacji, można użyć szyfrowania.

• Szyfrowanie utrudni korzystanie z niego bez deszyfrowania.wybór silnego algorytmu szyfrowania utrudni pękanie.
• dodanie jakiegoś fałszywego kodu do Głównej Logiki, aby utrudnić łamanie.
• jeśli potrafisz napisać swoją krytyczną logikę w dowolnym języku ojczystym i to z pewnością utrudnia dekompilacja.
• Korzystanie z zewnętrznych frameworków bezpieczeństwa, takich jak Quixxi

Zgadzam się z @Muhammad Saqib tutaj: https://stackoverflow.com/a/46183706/2496464

I @Mumair dają dobry początek: https://stackoverflow.com/a/35411378/474330

Zawsze można bezpiecznie założyć, że wszystko, co rozprowadzasz na urządzeniu użytkownika, należy do użytkownika. Jasne i proste. Możesz korzystać z najnowszych narzędzi i procedur, aby zaszyfrować swoje własności intelektualne, ale nie ma sposobu, aby uniemożliwić zdeterminowanej osobie "studiowanie" twojego system. I nawet jeśli obecna technologia może utrudnić im uzyskanie niechcianego dostępu, może być jakiś łatwy sposób jutro, a nawet tylko w następnej godzinie!

Oto równanie:

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

Nawet w tak prostej, jak ekonomia w grze. (Szczególnie w grach! Jest tam więcej "wyrafinowanych" użytkowników, a luki rozprzestrzeniają się w ciągu kilku sekund!)

Większość, jeśli nie wszystkie, naszych kluczowych systemów przetwarzania (i oczywiście bazy danych) znajduje się na po stronie serwera. I między Klientem a serwerem, leży szyfrowana komunikacja, walidacje, itp. To jest idea cienkiego klienta.

Czy chipy TPM (Trusted Platform Module )nie powinny zarządzać chronionym kodem? Stają się one powszechne na komputerach (zwłaszcza Apple) i mogą już istnieć w dzisiejszych chipach smartfonów. Niestety nie ma jeszcze API systemu operacyjnego, aby z niego korzystać. Mam nadzieję, że Android doda wsparcie dla tego pewnego dnia. To również klucz do czystej zawartości DRM (nad którą Google pracuje dla WebM).

Nic nie jest bezpieczne, gdy udostępniasz je użytkownikom końcowym, ale niektóre powszechne praktyki mogą utrudnić atakującemu kradzież danych.

• Umieść swoją główną logikę (algorytmy) po stronie serwera.
• komunikuj się z serwerem i klientem; upewnij się, że komunikacja z serwerem i klientem jest zabezpieczona przez SSL lub HTTPS; lub użyj innych technik algorytmów generowania par kluczy (ECC, RSA). Upewnij się, że poufne informacje pozostają szyfrowane End-to-End.
• Użyj sesji i wygasają po określonym przedziale czasu.
• Szyfruj zasoby i pobieraj je z serwera na żądanie.
• możesz też utworzyć hybrydową aplikację, która uzyskuje dostęp do systemu za pomocą webview protect resource + code on server

Wiele podejść; jest to oczywiste, że trzeba poświęcić między wydajność i bezpieczeństwo

Jak mogę chronić wszystkie zasoby, zasoby i Kod źródłowy aplikacji, aby hakerzy nie mogli zhakować pliku APK w żaden sposób?

Plik APK jest chroniony algorytmem SHA-1 . Możesz zobaczyć niektóre pliki w META-INF folderze APK. Jeśli rozpakujesz dowolny plik APK i zmienisz jego zawartość, a następnie spakujesz go ponownie, a po uruchomieniu nowego pliku APK na komputerze z Androidem, nie zadziała, ponieważ skróty SHA-1 nigdy się nie zgadzają.

Chociaż zgadzam się, że nie ma 100% rozwiązania, które ochroniłoby Twój kod, v3 z HoseDex2Jar jest teraz gotowy, jeśli chcesz spróbować.

Jeśli Twoja aplikacja jest tak wrażliwa, powinieneś rozważyć część przetwarzania płatności po stronie serwera. Spróbuj zmienić algorytmy przetwarzania płatności. Użyj aplikacji android Tylko do zbierania i wyświetlania informacji o użytkowniku (np. saldo konta) i zamiast przetwarzać płatności w ramach kodów java, wyślij to zadanie na serwer za pomocą bezpiecznego protokołu SSL z zaszyfrowanymi parametrami. Twórz w pełni zaszyfrowane i bezpieczne API do komunikacji z serwerem.

Oczywiście można też hacked też i to nie ma nic wspólnego z ochroną kodów źródłowych, ale uważają, że kolejna warstwa bezpieczeństwa, aby utrudnić hakerom oszukać aplikację.

Gdy mają aplikację w telefonie, mają pełny dostęp do jej pamięci. więc jeśli chcesz zapobiec włamaniu, możesz spróbować zrobić to tak, że nie możesz po prostu uzyskać adresu pamięci statycznej bezpośrednio za pomocą debugera. mogą zrobić przepełnienie bufora stosu, jeśli mają gdzie pisać i mają limit. więc spróbuj zrobić to tak, gdy coś napisać, jeśli musisz mieć limit, jeśli wysyłają więcej znaków niż limit, jeśli (input > limit) to ignoruj, więc nie mogą umieścić kod montażowy.

Narzędzie: Korzystanie z programu Proguard w Twojej aplikacji może być ograniczone do inżynierii wstecznej Twojej aplikacji

Widzę dobrą odpowiedź w tym wątku . Oprócz możesz użyć facebook redex, aby zoptymalizować kod. Redex pracuje na poziomie .dex, Gdzie proguard pracuje jako poziom .class.

Tylko dodatek do już dobrych odpowiedzi powyżej.

Kolejną znaną mi sztuczką jest przechowywanie cennych kodów jako biblioteki Javy. Następnie ustaw tę bibliotekę jako swój projekt na Androida. Byłby dobry jak C. więc plik, ale Android Lib zrobi.

W ten sposób cenne kody zapisane w Bibliotece Androida nie będą widoczne po dekompilacji.