Narzędzia

Dewirtualizer dla VMprotect

przez

No i stało się. Ktoś w końcu opublikował dewirtualizer dla popularnego systemu zabezpieczającego VMprotect, obsługujący jego najnowsze wersje z pełnymi kodami źródłowymi.

Repozytorium https://github.com/can1357/NoVmp

Wraz z jego publikacją pojawiły się powiązane narzędzia do zrzucania pamięci i naprawy importów aplikacji zabezpieczonych VMprotectem:

Wszyscy, którzy polegali jedynie na wirtualizacji kodu chyba muszą się poważnie zastanowić nad bezpieczeństwem swoich aplikacji.

Być może to dobra pora przerzucić się na inny system zabezpieczający aplikacje ze znacznie bardziej bogatym wachlarzem zabezpieczeń i SDK, do którego jeszcze nikomu nie udało się zrobić unpakera 🙂

Przegląd narzędzi do reverse engineeringu (inżynierii wstecznej / odwrotnej)

przez

rysunek-25-dnspyNa odświeżonej stronie PELock-a, znalazły się moje artykuły, które wcześniej były opublikowane jedynie w Magazynie Programista.

Jako pierwszy polecam zaktualizowany artykuł, w którym znajdziecie opisy popularnych narzędzi wykorzystywanych w reversingu czy też inżynierii wstecznej oprogramowania, ich wady, zalety oraz alternatywne rozwiązania.

https://www.pelock.com/pl/artykuly/przeglad-narzedzi-do-reverse-engineeringu

W razie jakichkolwiek uwag lub propozycji kolejnych narzędzi, proszę o komentarze.

Wrzuciłem też link na Wykop, jakby ktoś chciał wspomóc kopniakiem to:

http://www.wykop.pl/link/3254817/przeglad-narzedzi-do-reverse-engineeringu-inzynierii-wstecznej-odwrotnej/

Obfuscator Eazfuscator i zabezpieczenia aplikacji .NET

przez

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.

Obfuscator Eazfuscator

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ę.