Dzisiaj rozmawiałem z twórcą obfuscatora dla .NET – Eazfuscator i przyznam szczerze, że trochę zdębiałem. Interesowało mnie jak obecnie radzi sobie Eazfuscator z deobfuscatorem de4dot. Po pierwszej odmowie udzielenia mi odpowiedzi, gdyż reprezentuję firmę sprzedającą zabezpieczenia oprogramowania, poinformowałem go, że interesuje mnie sam obfuscator dla moich prywatnych celów, jednak odpowiedź jaką uzyskałem postanowiłem opublikować, w sumie jako ostrzeżenie dla innych klientów.
Rozmowa zeszła na techniki zabezpieczające aplikacje .NET przed inżynierią wsteczną i uzyskałem odpowiedź, że najlepszą techniką zabezpieczającą jest zmiana nazw klas, zmiennych i nazw funkcji… Dopytałem z ciekawości, czy sobie nie żartuje, ale najwidoczniej nie:
> Renaming is the best obfuscation technique? I hope you’re kidding 🙂
No pun intended. Renaming is the best technique because it is completely
*irreversible *— a Holy Grail property of any protection scheme.Oleksiy Gapotchenko
Jak widać cała moja wiedza o zabezpieczeniach oprogramowania była jak dotąd uboga, a najlepszą metodą ochrony obfuscatora za 399 USD jest zmiana nazw w skompilowanym pliku. Doh!? Nie mutacja kodu, nie wirtualizacja, żadne dynamiczne szyfrowanie, JITtowanie… tylko zmiana nazw! Nie muszę chyba tłumaczyć nikomu, że nazwy klas, zmiennych czy funkcji nie są nikomu potrzebne przy próbie łamania zabezpieczenia, dotyczy to zarówno aplikacji .NET, natywnych czy Java po zastosowaniu obfusatora i takie stwierdzenia jak powyżej twórcy jednego z najpopularniejszych obfuscatorów stawiają duży znak zapytania nad poziomem ich wiedzy o tym czym są zabezpieczenia oprogramowania.
Rynek obfuscatorów dla .NET, których ceny są astronomicznie wysokie w porównaniu do systemów zabezpieczających 32 i 64 bitowe natywne aplikacje, a poziom skomplikowania zabezpieczeń natywnych wykracza technicznie daleko poza metody stosowane w zabezpieczeniach aplikacji .NET zawsze mnie zastanawiał. Zwłaszcza w obliczu aplikacji takich jak de4dot, które jednym klikiem sprawiają, że wszystkie te drogie zabezpieczenia znikają niczym pieniądze z portfeli klientów, którzy inwestują w tak słomianą ochronę.
Te chore ceny wynikaja pewnie, że przyjeło się że .net używany jest w korporacjach które mogą płacić tyle. Inaczej tego nie umiem wytłumaczyć.
@Krzysiek: Te chore ceny wynikają ze zmowy cenowej jak przypuszczam i ogólnego przyzwolenia na kosmiczne wycenianie tego typu badziewia, które odbezpiecza de4dot
http://www.wiseowl.com/purchase/purchase.aspx – 800 USD
http://www.red-gate.com/products/dotnet-development/smartassembly/pricing – 1493 USD
http://www.9rays.net/Buynow.aspx?CategoryID=53 – 1199 USD
http://xheo.com/products/code-protection/pricing – 899 USD
itp. etc., a wszystko to nic niewarte, pieniądze wyrzucone w błoto 😉
No ladne ceny. Marketing swoje robi. Z drugiej strony kto im zabroni. To tak jak z frytkami za 20zł. Bartek napisz takie coś i sam sprzedawaj za takie ceny:)
@Krzysiek: nikt nie zabroni, jednak jeśli orientujesz się w tematyce zabezpieczeń, łatwo zobaczyć, że dużo bardziej zaawansowane systemy ochrony natywnych aplikacji są dostępne o wiele taniej, a techniczna wiedza potrzebna do ich stworzenia przekracza o wiele bardziej obsługę Mono.Cecil ;). Warto zajrzeć w źródła de4dot zwłaszca https://github.com/0xd4d/de4dot/tree/master/de4dot.code/deobfuscators żeby zobaczyć jakie metody wykorzystywane są do ochrony .NET, można się zdziwić co do relacji cena -> jakość
Rozumiem o co Ci chodzi. Masz racje, że natywne zabezpieczenia wymagają o wiele większą wiedzę.
Najlepsza metoda czy jedyna? Robisz gównoburzę o nic. Przecież Eazfuscator wspiera wszystkie techniki o których piszesz ale chyba każdy kto zajmował się RE zgodzi się, że nic tak nie pomaga przy tym jak znajomość nazw funkcji.
@MDobak nie wiem czym ty się zajmowałeś, ale znajomość nazw funkcji, a konkretnie ich brak w niczym nie przeszkadza, no chyba, że jedyne co robiłeś to analiza .NETowych binarek pod Reflectorem i nigdy w życiu na oczy nie widziałeś skompilowanego kodu x86 bez jakichkolwiek dodatkowych informacji.
„nie wiem czym ty się zajmowałeś, ale znajomość nazw funkcji, a konkretnie ich brak w niczym nie przeszkadza”
XD
W niczym… zupełnie. Idąc tą logiką, to w sumie wirtualizacja, dynamiczne szyfrowanie, mutacja kodu to też w niczym nie przeszkadza. Ot tylko trochę więcej czasu potrzeba na analizę…
Oleksiy wytłumaczył swój punkt widzenia jasno. Dla niego dobra metoda to taka, która jest nieodwracalna ale jak widać jego programie stosuje różne techniki aby utrudnić zadanie RE więc innych technik nie bagatelizuje. Czepianie się takich głupot i produkowanie takich artykułów uważam za słabe po prostu.
@MDobak nazwy funkcji, klas czy zmiennych i ich brak nie przeszkadzają w reversingu, chyba nigdy nie analizowałeś binarek z x86/x64, gdzie w ogóle nie masz żadnych nazw do niczego jeśli nie były dodane w postaci bazy *.pdb do aplikacji i brak nazw nie jest jakąkolwiek przeszkodą do analizy, no chyba, że dopiero zaczynasz i kompletnie nie wiesz od czego zacząć albo jesteś przyzwyczajony do wygód, które oferuje .NET. To samo tyczy się analizy zabezpieczonych aplikacji Java ze zmienionymi nazwami, tylko idiota by porzucił analizę tylko dlatego, że nazwy są pozmieniane :). Ta nieodwracalna metoda nie jest żadnym zabezpieczeniem i jeśli Oleksiy stwierdził, że to najlepsze zabezpieczenie, to strach pomyśleć jak dobre są pozostałe. Polecam Ci, żebyś siadł kilka razy nad binariami natywnych aplikacji to może zrozumiesz o co chodzi z brakiem nazw funkcji czy czegokolwiek innego.
Kiepsko idzie Ci ta analiza mnie i moich przyzwyczajeń, bo z .NET ani Javą nie mam w sumie nic wspólnego i prawie całe moje doświadczenie RE opiera się na x86/x64/arm.
> tylko idiota by porzucił analizę tylko dlatego, że nazwy są pozmieniane :). Ta nieodwracalna metoda nie jest żadnym zabezpieczeniem
A istnieją metody które są faktycznym zabezpieczeniem? Metody, dla których nie da się stworzyć zautomatyzowanego narzędzia jak de4dot? Chyba jedynie dobra mutacja kodu może dać taki efekt.
To dobrze, że wypowiadasz się w kwestiach, z którymi nie masz nic wspólnego. Nie znam się, ale się wypowiem…
Istnieje wiele dobrych metod ochrony kodu, mutacja jest jedną z nich. Zmiana nazw nie jest żadnym zabezpieczeniem i dziwi mnie, że twoje doświadczenie w RE: opiera się jak sam mówisz na x86/x64/arm i brak poprawnych nazw funkcji uważasz za jakąkolwiek przeszkodę? Certyfikat ze swojego kursu RE: znalazłeś w kinder niespodziance?
ja uważam że wynikają one z tego że dużych firmach poziom merytoryczny jest tak żenująco niski
że można sobie pozwolić na takie windowanie cen bo nawet gdyby to czy inne narzędzie nie robiło kompletnie nic poza zmianą nazw funkcji to wielu ekspertów i tak by je kupiło mimo tysięcy dolarów jakie musieli by wydać. Wystarczy tylko dobrze zapakować. Znam przypadki gdzie odnawia się licencje na komercyjne dekompilatory .NET które nie mają żadnych funkcji nad rozwiązania dostępne za darmo.