Tak mówią ludzie, którzy nigdy zabezpieczeń na oczy nie widzieli. Są setki aplikacji, których zabezpieczeń nikt nigdy nie złamał, bo wymagałoby to takiego nakładu pracy, wiedzy, doświadczenia i środków finansowych, żeby jednocześnie egzystować i łamać te zabezpieczenia, na które nikogo po prostu nie stać. To tak samo jak powiedzieć, że wszystko jest możliwe. To ja się pytam dlaczego Polska nigdy nie wygrała Eurowizji skoro wszystko jest możliwe? ;)
Przykładem zabezpieczeń NIE DO ZŁAMANIA są aplikacje, których fragmenty procedur i funkcji umieszczone są na serwerze i program komunikuje się np. przez SOAP lub jakiś inny protokół. I jak to złamiesz skoro wersja demo nie posiada tej funkcjonalności, a nawet jak uzyskasz login klienta i hasło do pełnej wersji aplikacji to możesz jedynie z tego skorzystać, a nie ukraść i skopiować, żeby np. potem sprzedawać. Będziesz rozdawał login kolegi, który kupił program? To szybko Cię zbanują po stronie serwera. Kodu z serwera też nie ukradniesz, bo już widzę jak będziesz przełamywał zabezpieczenia serwerowe niczym Trinity w Matrixie.
Klucze sprzętowe są dobrym rozwiązaniem jeśli są poprawnie zastosowane. Jeśli wpiszesz w google "dongle emulator" to zobaczysz, że sporo z nich jest już tak znanych, że powstało wiele emulatorów, gdzie wystarczy zrzucić pamięć klucza i sterownik systemowy będzie udawał fizyczny klucz. Często klucze sprzętowe mimo jakichś ciekawych metod zabezpieczających są używane bezmyślnie, tzn. całe zabezpieczenie opiera się np. na 1 checku IsDonglePresent()
, co jest banalne do usunięcia. Jak ktoś się już szarpnie z przeczytaniem dokumentacji klucza to oprócz sprawdzania samej obecności klucza zczyta z niej 2 zmienne GetDongleInteger()
lub doda timer sprawdzający obecność klucza :), tak niestety często wyglądają realia, ponieważ programiści myślą, że sam dongle magicznie wszystko ochroni. Więc aplikacja MUSI być indywidualnie przygotowywana, bo integracja z kodem źródłowym to podstawa w tego typu zabezpieczeniach. Klucze takie jak np. HASP posiadają dodatkowo tzw. envelope czyli exe-protector, jednak zastosowanie samego "kopertowania" jak to pokracznie tłumaczy się na język polski, nie jest wystarczające. O kluczach HASP i metodach zabezpieczeń sam trochę pisałem:
http://www.secnews.pl/2009/05/06/hasp-envelope/
http://www.secnews.pl/2010/03/29/hasp-i-visual-foxpro-9/
http://www.secnews.pl/2012/01/27/datahasp/
Wymyślanie własnych zabezpieczeń, nieszablonowych jest dobrą metodą zabezpieczającą jeśli się wie co się robi i jakie są tego wady i zalety. Gotowe rozwiązania mają też to do siebie, że metody ich łamania są często udokumentowane, a czasami są po prostu dostępne gotowe programy, które pozwalają automatycznie te zabezpieczenia usuwać, przykładem niech będzie uniwersalny deobfuscator de4dot do chyba wszystkich systemów zabezpieczających aplikacje .NET