Nie obfuskuj kodu… nigdy

Po raz kolejny na 4p pojawił się temat „jaki obfuskator”. I po raz kolejny odpowiedź brzmi „najlepiej żaden”.

Generalnie współczesne obfuskatory potrafią robić kilka rzeczy poza samym zaciemnianiem nazw. Te są przydatne:

  • Usuwanie nieużywanego kodu.
  • Usuwanie informacji dla debuggera.
  • Upraszczanie niektórych wyrażeń (shriking).
  • Optymalizacja kodu m.n. wykorzystania zmiennych lokalnych.

W efekcie możemy dostać kod mniejszy i trochę wydajniejszy, ale będziemy musieli za to zapłacić bardzo wysoką cenę. Jest nią możliwość utrzymania kodu. Skoro kod wyjściowy zostanie potraktowany refaktoryzacją Zmiana nazwy to w efekcie gdy otrzymany od klienta stacktrace stanie się ciekawą łamigłówką pt. „Co to za klasa się wyjebała”.
Kolejną wadą jest utrata możliwości powtórnego użycia kodu. Obfuskowany jar, który zawiera zestaw metod narzędziowych… a ty siedzisz i piszesz wszytko od nowa 😀
Na koniec należy też dodać utratę powiązania pomiędzy kodem, a dokumentacją. Wdrożenie nowego człowieka w projekt będzie bolesne… szczególnie jak mu się trafi obfuskowany stacktrace.

Zalety? Tak są. Obfuskatorów należy używać jeżeli piszemy na platformę JME albo Java Card i mamy ograniczenia co do ilości wyprodukowanego kodu. W takim wypadku warto użyć obfuskatora. Kolejną jest użycie obfuskatora z wyłączonym modułem zmiany nazw w celu optymalizacji kodu. Zazwyczaj jest to upraszczanie wyrażeń (np. dodawania Stringów) lepsze wykorzystanie zmiennych lokalnych, usuwanie informacji dla debuggera czy martwego kodu. Czasami niewielkie zyski w tym zakresie są jak najbardziej pożądane. Przykładowo jeżeli uda nam się zmniejszyć wielkość paczki pobieranej przez klienta o 10% to dla 100MB jara wynik 10MB mniej na pobranie jest już znaczący zarówno dla naszych dysków jak i łączy.

Ale najważniejsze. Nie używajcie obfiskatorów. Najlepiej nigdy.

5 myśli na temat “Nie obfuskuj kodu… nigdy

  1. Muszę się niezgodzie z twoją opinią, bo albo nie używałeś obfuskator-ów albo ktoś ci zapłacił za ta krytykę.

    Po pierwsze – Primo:
    “Co to za klasa się wyjebała” – jest coś takiego jak „Stack Trace Translate” który bardzo ładnie przywróci stacktrace do stanu początkowego.

    Po drugie – Primo:
    „Kolejną wadą jest utrata możliwości powtórnego użycia kodu.” – rozumiem że zaraz po spakowaniu kodu do jara, wyrzucasz wszystkie kody źródłowe ?

    Ja korzystam z ofuskator-a i jest on ostatnim etapem zaraz przed wypuszczeniem aplikacji w świat. Nigdy nie miałem problemów z niezrozumieniem stactrace, czy innych opisanych tutaj.

  2. Coz… czasem nie ma jednak wyjscia i trzeba uzywac obfuscatorow. I to nie z przyczyn o ktorych piszesz (czyli ogolnie optymalizacja) ale z czysto komercyjnego powodu. Aplikacja ktora dostarczamy klientowi moze zawierac oryginalne rozwiazania, ktore stanowia przewage konkurencyjna firmy.
    Z samym stack-tracem nie jest tak zle – taki np. ProGuard tworzy pliki mappingu, dzieki ktorym mozna odtworzyc (deobfuscate) oryginalny stack-trace.
    Podobnie z powtornym uzyciem kodu – ProGuard pozwala okreslic, ktore klasy (metody, pakiety) nie maja zostac poddane obfuskacji i w ten sposob wykluczyc API naszego modulu z procesu zaciemniania kodu.

  3. @Cezary, STT fajne, ale nie zawsze. Miałem do czynienia z takim kodem i powiem szczerze, że przy kilkuset klasach i kilkunastu modułach zawsze była zgadywanka co się wywaliło. A i jeszcze jedno – mi nikt nie płaci za wyrażanie opinii. I proszę mi tu takich rzeczy nie imputować.

    @Domingo, najlepszym dowodem na to, że obfuskacja nic nie daje jest kod minecrafta. Obfuskowany do bólu, doprowadzony do czytelnej postaci.

    Swoją drogą mi na ten przykład nie przeszkadza zbytnio sama obfuskacja. Jeżeli nie gonią mnie terminy to nie mam jakiś obiekcji gdy czytam zaciemniony kod. Dobre IDE plus kilka prostych refaktoryzacji na początek i sprawa się wyjaśnia.

  4. Cezary to ‚obfuscował’ swoją wypowiedź. Nie ma ni pierwszego ni drugiego prima. Jeszcze może bym się nie czepiał pierwszego, ale to drugie już wybitnie w oczy kuje.

  5. @ Michał Gruca, Primo wprowadziłem da rozluźnienia wypowiedzi tzw. żart, przecież wiadomo że jest: primo, secundo, tertio itd.
    Kiedyś bodajże w „Alternatyw 4” była taka wypowiedź z użyciem Primo.

Napisz odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax