Zazwyczaj obfuskatorzy zmieniają nazwy klas, metod i pól na nazwy, które nie mają znaczenia. Tak więc, jeśli masz "ScoreCalculator.computeScore (Player p, Match m)", kończysz na "Azk (F f, R r)". Jest to podobne do tego, co robi kompilator Uglify lub Closure dla javascript, z tym wyjątkiem, że w javascriptu ma on zmniejszyć długość źródła.
Możliwe jest zrozumienie, co metoda ma, i tak jest tylko trudniejsze.
Aslo, Java używa późnego wiązania (jako pliki DLL lub SO). Tak więc połączenia wychodzące poza twój kod (jak na przykład java.util, java.lang itd.) Nie mogą być zaciemniane. Ponadto, jeśli twój kod musi odbierać połączenia z zewnątrz (typowy przykład, zarejestruj słuchacza na przycisku), ten kod nie może być zaciemniony. To samo dzieje się w przypadku biblioteki DLL, w której wyraźnie widać nazwę metody, która musi zostać wywołana poza biblioteką DLL i wywołuje inne biblioteki DLL.
Jednak odwzorowanie między określonym kodem źródłowym a skompilowanym kodem niekoniecznie musi być jedno do jednego. Starsze kompilatory języka C używane do tworzenia tego samego kodu operacyjnego dla danej dyrektywy źródłowej, więc dekompilatory były bardzo skuteczne. Następnie kompilatory C dodały wiele optymalizacji do powstałego kodu operacyjnego, a te optymalizacje spowodowały, że dekompilator stał się w większości nieskuteczny. [1]
Java nigdy nie zaimplementowała (dużo) optymalizacji w czasie kompilacji, ponieważ do uruchamiania na różnych platformach (w tym różnych urządzeniach z systemem Android), Java postanowiła zastosować poważne optymalizacje później, w czasie wykonywania, w oparciu o architekturę i właściwości sprzętowe uruchomionego urządzenia (właśnie to "HotSpot" dotyczy głównie [2]).
Dobrzy obfuscatorzy zazwyczaj również zmieniają instrukcje kodu bajtowego lub wstawiają niektóre bezużyteczne, lub stosują pewne optymalizacje z góry, aby dekompilatory nie były w stanie (lub w mniejszym stopniu) wyprowadzić kodu źródłowego tak łatwo.
Ta technika jest bezużyteczna, jeśli chodzi o ludzi, którzy potrafią czytać kod bajtowy, ponieważ jakakolwiek możliwa enkfulacja C jest bezużyteczna, jeśli dana osoba może odczytać kod asemblera.
Jak wiele programów do krakowania demonstruje, inżynieria odwrotna jest zawsze możliwa, nawet z C lub innymi laguages, nawet na firmware (pomyśl o oprogramowaniu układowym iPhone'a), ponieważ klient, na którym działa twój kod, jest zawsze niezaufany i zawsze może zostać zmieniony z.
Jeśli masz bardzo krytyczny kod misji, coś wartego dużo pieniędzy, które ktoś może ukraść, proponuję uruchomić go po stronie serwera, lub jakoś przetestować serwer.
LOL! Czy nie zastosowałeś proguard do swojego apk? Jeśli odpowiedź brzmi "nie", to jest twoja odpowiedź! :) – t0mm13b
Użyłem Proguard i edytowałem plik project.properties przed rel; łagodzenie mojej aplikacji. Powinienem wspomnieć, że nazwy klas nie są moje oryginalne, ale wszystkie nazwy metod wydają się być oryginalne. To znaczy. cofanie mojej aplikacji jest łatwe, ponieważ zmieniły się tylko nazwy klas. EDYCJA: Wydaje się również, że zmieniono nazwy statycznych metod. Ale odwrócenie tego nie jest naukową rakietą. –
Czy możesz zamieścić swój proguard.cfg? A czy sprawdziłeś [przykłady] (http://proguard.sourceforge.net/index.html#manual/examples.html) – t0mm13b