Lucky patcher, jak mogę go chronić?

Question

Wiem, że ten temat był wielokrotnie otwierany i wiele się nauczyłem, ale natknąłem się na problem, który naprawdę potrzebuję porady.

Używam LVL z Obfuskacja. Zmieniłem domyślny ALOT LVL, aby anty-LVL go nie złamał. Jednak Lucky Patcher jednym kliknięciem go łamie! Próbowałem zobaczyć nowy uszkodzony APK. Tak, po prostu nazwałem moją "metodą zezwalającą".

Moje pytanie brzmi, czy ktoś może polecić sposób, aby zapobiec złamaniu go przez Lucky Patchera? Wiem, że nie mogę sprawić, że będzie to bezpieczne, ale chcę, żeby to nie było tak proste dla oprogramowania z jednym kliknięciem.

Answer 1

Code by sprawdzić certyfikat

public void checkSignature(final Context context) 
{ 
    try 
    { 
     Signature[] signatures = context.getPackageManager().getPackageInfo(context.getPackageName(), PackageManager.GET_SIGNATURES).signatures; 

     if (signatures[0].toCharsString() != <YOUR CERTIFICATE STRING GOES HERE>) 
     { 
      // Kill the process without warning. If someone changed the certificate 
      // is better not to give a hint about why the app stopped working 
      android.os.Process.killProcess(android.os.Process.myPid()); 
     } 
    } 
    catch (NameNotFoundException ex) 
    { 
     // Must never fail, so if it does, means someone played with the apk, so kill the process 
     android.os.Process.killProcess(android.os.Process.myPid()); 
    } 
} 

i jak znaleźć których jeden jest certyfikat, zbyt proste. Musisz utworzyć plik APK w trybie zwolnienia, ponieważ certyfikat debugowania zawsze różni się od wydania. Wypisz ciąg certyfikatu do tymczasowego widoku tekstowego, aby go skopiować, lub do pliku tekstowego z następnym wywołaniem, WAŻNE: NIE WYDAWAJ go logcat, ponieważ ciąg znaków jest zbyt duży i logcat nie pokaże go wszystkie i odciąć ostatni znak znaków:

signatures[0].toCharsString(); 

example: YourTextView.setText(signatures[0].toCharsString()); 

teraz należy pamiętać, że kiedy jesteś z powrotem do trybu debugowania, certyfikat jest jeszcze inny, a czasami może być inna na każdej budowie, więc dostaniesz piekło debugowania. Wtedy lepiej jest użyć następną linię mieć łatwiej, kiedy się rozwija, i umieścić go tuż przed wywołaniem testowanie certyfikatu:

if ((context.getApplicationContext().getApplicationInfo().flags &= ApplicationInfo.FLAG_DEBUGGABLE) != 0) 
{ 
    return; 
} 

więc unikać wywoływania ten kod certyfikacyjny, jeśli w trybie debugowania

A teraz szczęśliwy patcher checker

Ten kod sprawdzi jego istnienie. Dekompilowałem wszystkie wersje Lucky Patchera i odkryłem, że jego twórca używał 2 nazw paczek między wszystkimi realeases. Musisz tylko śledzić nowe wersje i dodawać przyszłe nazwy pakietów patcha do funkcji sprawdzania.

Polecamy również szyfrowanie ciągów nazw paczek zamiast ich harcodować, tak jak w przykładzie, więc lucky patcher nie wychodzi z nową wersją, która po prostu zamienia łańcuchy na łatanie ich. Ułatwmy krakersy.

private boolean checkLuckyPatcher() 
{ 
    if (packageExists("com.dimonvideo.luckypatcher")) 
    { 
     return true; 
    } 

    if (packageExists("com.chelpus.lackypatch")) 
    { 
     return true; 
    } 

    if (packageExists("com.android.vending.billing.InAppBillingService.LACK")) 
    { 
     return true; 
    } 

    return false; 
} 

private boolean packageExists(final String packageName) 
{ 
    try 
    { 
     ApplicationInfo info = this.getPackageManager().getApplicationInfo(packageName, 0); 

     if (info == null) 
     { 
      // No need really to test for null, if the package does not 
      // exist it will really rise an exception. but in case Google 
      // changes the API in the future lets be safe and test it 
      return false; 
     } 

     return true; 
    } 
    catch (Exception ex) 
    { 
     // If we get here only means the Package does not exist 
    } 

    return false; 
} 

Answer 2

Sposób, to sprawdzenie, czy zainstalowany jest szczęśliwy patcher, a jeśli tak, to wyświetl komunikat użytkownikowi, a następnie zabij proces. Jeśli użytkownik go posiada, oznacza, że ​​próbuje złamać oprogramowanie lub oprogramowanie innego dewelopera. Lepiej nie pozwolić na używanie aplikacji w telefonie, który ją zainstalował. Walcz z piractwem.

Answer 3

Tak, i to jest spryt mojej sugestii. W swoim kodzie, zaimplementuj funkcję, która zostanie wywołana w określonych akcjach, w tej akcji musisz sprawdzić pakiet szczęśliwego patcha, jeśli jest zainstalowany, czy nie. jest to dość łatwe i mogę udostępnić kod, jeśli nie wiesz jak. Jeśli ją wykryjesz, zatrzymaj aplikację. Po prostu nie zezwalaj na korzystanie z niego, nawet jeśli użytkownik zapłacił za niego, lepiej jego złą recenzję niż 10000 nielegalnych kopii. Wtedy również, nawet jeśli twoje aplikacje zostaną złamane, będzie to tylko dla LVL, szczęśliwy patcher nie może znać każdej aplikacji na rynku, która ma taki algorytm, i uniemożliwiłoby stworzenie szczęśliwej wersji patchera, która obejmowałaby wszystkie aplikacje na rynku, jak zawsze programista pisałby na swój własny sposób, aby to wykryć. Więc na końcu Twoja aplikacja może być popękana i nie ma już ochrony lvl, ale nigdy nie pozwolisz jej uruchomić, jeśli telefon ma zainstalowany szczęśliwy instalator. Co więcej, zachowaj flagę w pliku ustawień, aby wykryć, czy podczas pierwszego uruchomienia aplikacji wykryto ci szczęśliwego patchera, na wypadek gdyby go złamał, a następnie odinstalował szczęśliwego patchera. W ten sposób, nawet jeśli po odinstalowaniu przez użytkownika luckypatchera nadal będziesz mógł wstrzymać wykonywanie aplikacji, użytkownik będzie musiał ponownie zainstalować niespakowaną aplikację. I będzie obwiniać szczęśliwego patchera przez cały czas.

Answer 4

Ilekroć Szczęście Patcher tworzy modded plik APK, to zawsze kończy się z inną nazwą pakietu, ponieważ nie można uruchomić dwie aplikacje pod tą samą nazwą pakietu.

Oto proste rozwiązanie, które sprawdza, czy kod działa pod niewłaściwą nazwą pakietu:

PackageManager pm = getPackageManager(); 

try { 
    PackageInfo packageInfo = pm.getPackageInfo("YOUR_PACKAGE_NAME",PackageManager.GET_ACTIVITIES); 
} catch (PackageManager.NameNotFoundException e){ 
    finish(); 
    //If you get here, your code is running under a different package name... Kill the process! 
} 

po prostu zadzwonić finish(); na mojej aplikacji i nie mogę się przełamać, ale to może być najlepiej użyć android.os.Process.killProcess(android.os.Process.myPid()); jak zasugerował @PerracoLabs.

Answer 5

W bieżącej wersji (6.4.6) Lucky Patcher generuje bardzo krótki znacznik. Na przykład, rzeczywisty zakup tokena:

felihnbdiljiajicjhdpcgbb.AO-J1OyQgD6gEBTUHhduDpATg3hLkTYSWyVZUvFwe4KzT3r-O7o5kdt_PbG7sSUuoC1l6dtqsYZW0ZuoEkVUOq5TMi8LO1MvDwdx5Kr7vIHCVBDcjCl3CKP4UigtKmXotCUd6znJ0KfW 

I to ma szczęście Token:

kvfmqjhewuojbsfiwqngqqmc 

Dość proste rozwiązanie do przodu jest, aby sprawdzić długość łańcucha znaków tokena

@Override public void onIabPurchaseFinished(IabResult result, Purchase info) { 
    if (info.getToken().length < 25) { 
     Log.wtf("PIRATE", "PIRATE DETECTED"); 
     return; 
    } 
}