Chronić kod .NET przed inżynierią wsteczną?

Zaciemnianie jest jednym ze sposobów, ale nie może chronić przed złamaniem bezpieczeństwa ochrony przed piractwem aplikacji. Jak upewnić się, że aplikacja nie jest modyfikowana, i jak upewnić się, że mechanizm rejestracji nie może być poddany inżynierii wstecznej?

Możliwe jest również przekonwertowanie aplikacji C # na kod macierzysty, a Xenocode jest zbyt kosztowny.

C # zapewnia wiele funkcji i jest idealnym językiem dla mojego kodu, więc ponowne napisanie całej bazy kodu w C ++ nie wchodzi w rachubę.

Bezpieczne certyfikaty można łatwo usunąć z podpisanych zestawów w .NET.

Nie możesz

Istnieją kroki, które możesz podjąć, aby uczynić to nieco trudniejszym, ale ostatecznie każdy plik wykonywalny na komputerze lokalnym jest podatny na pękanie. Ostatecznie kod ten musi zostać przekonwertowany na natywny kod maszynowy, a każda uruchamiana aplikacja jest podatna na ataki.

To, co chcesz zrobić, to po prostu utrudnić włamanie, aby nie było warte kłopotów ludzi.

Mam kilka sugestii, które pomogą ci chronić twoją aplikację:

• Ukryj kod. Dotfuscator ma bezpłatną edycję i jest dostarczany z Visual Studio.
• Użyj klucza publicznego / prywatnego lub szyfrowania asymetrycznego do wygenerowania licencji produktu. Zapewnia to, że tylko Ty możesz wygenerować kody licencji. Nawet jeśli twoja aplikacja jest pęknięta, możesz być pewien, że nie zwolni ona generatora kluczy dla twojej aplikacji, ponieważ nie jest możliwe odwrócenie algorytmu generowania klucza.
• Użyj pakera innej firmy, aby spakować plik wykonywalny .NET w zaszyfrowanej aplikacji opakowania Win32. Themida jest jedną z lepszych. To powstrzymuje ludzi przed odbijaniem twojej aplikacji w .NET Reflector i sprawia, że ​​rozpakowanie do cofania jest uciążliwe.
• Napisz własny niestandardowy program pakujący . Jeśli programy pakujące innych firm są zbyt drogie, rozważ napisanie własnego. Czasami niestandardowe programy pakujące mogą być bardzo skuteczne, ponieważ nie ma dobrze opublikowanych metod ich rozpakowywania. Samouczek Jak napisać własny program pakujący zawiera mnóstwo dobrych informacji na temat pisania własnego programu pakującego Win32.

Ostatecznie jednak, jeśli ludzie chcą złamać twoją aplikację, zrobią to. Spójrz na całe oprogramowanie komercyjne, które ma ogromną ilość zasobów do ochrony swoich aplikacji, a jednak są one łamane, zanim aplikacje zostaną udostępnione publicznie.

Wykwalifikowany inżynier wsteczny może odpalić IDA-Pro i pokroić twoją aplikację jak masło, bez względu na to, co robisz. Spakowaną aplikację można rozpakować, a zaciemnienie nie pozwala jej na spacer po parku. Całą ciężką pracę ze złożonym kodem licencyjnym można cofnąć za pomocą łatki o jednym bajcie.

Musisz tylko zaakceptować fakt, że istnieje bardzo realna szansa, że ​​ludzie będą pirować twoje oprogramowanie. Są ludzie, którzy nigdy nie zapłacą za twoje podanie, bez względu na wszystko i są to ludzie, o których nie musisz się martwić.

Istnieje jednak wiele firm, które nigdy nie ryzykowałyby procesu i chętnie kupiłyby licencje na oprogramowanie, oraz wielu użytkowników komputerów, którzy albo nie chcą ryzykować, uznają to za niewłaściwe, albo nie mają wystarczającej wiedzy technicznej na piractwo. To są Twoi prawdziwi klienci i powinieneś skoncentrować swoje wysiłki na zapewnieniu im dobrej obsługi użytkowników i zignorować osoby, które łamią twoje oprogramowanie.

Moja aplikacja była już piracka i wziąłem ją za osobistą afront. Oto ja, mały programista, wlewając moje serce i duszę do aplikacji, a ci ludzie mieli ochotę mnie pirować ?! Brali pieniądze bezpośrednio z mojej kieszeni!

Natychmiast dodałem paczkę drakońskiego kodu DRM i próbowałem sabotować każdą osobę przy użyciu nielegalnej lub pękniętej kopii. Powinienem oczywiście pracować nad ulepszeniem mojej aplikacji, zamiast próbować powstrzymać nieuniknione. Mało tego, ale krzywdziłem moich prawdziwych klientów, że zapewnią mi wszystkie te dodatkowe zabezpieczenia.

Po długiej walce zdałem sobie sprawę, że walczę z przypływami i cały ten czas zmarnowany był na nic. Wyjąłem cały domowy kod telefonu, z wyjątkiem funkcji licencyjnych, i nigdy nie oglądałem się za siebie.

Nie można w pełni zabezpieczyć żadnej aplikacji (zarządzanej lub nie). Jeśli systemy takie jak Playstation i iPad mogą zostać złamane - gdzie sprzedawca nawet kontroluje sprzęt - jaka jest nadzieja Twojej aplikacji? Na szczęście tak naprawdę nie chcesz. Moim zdaniem, musisz zabezpieczyć swoją aplikację na tyle, aby ktoś nie mógł przypadkowo pirować twojego produktu i nie więcej.

Na przykład, jeśli używasz licencji na jeden komputer, nie powinna ona działać tylko podczas instalacji na nowym drugim komputerze. Będziesz potrzebować dobrego komunikatu o błędzie, aby zapobiec dodatkowym połączeniom z pomocą techniczną, ale nie spiesz się, utrudniając obejście i nie uderzając w niego użytkownikami.

Innym przykładem jest ograniczony czasowo proces. Nie martw się nawet o proste rzeczy, takie jak to, że użytkownicy mogą po prostu cofnąć zegar systemowy. Ktoś, kto to robi, wie, że łamie twoją licencję, i dopóki użytkownik wie, kiedy narusza prawo, zrobiłeś wystarczająco dużo.

Musisz to zrobić dużo, ponieważ użytkownicy nie dbają o twoją licencję. Licencje są wymyślonymi rzeczami, o których nikt nie dba, dopóki nie będą musieli. Nikt ich nie czyta i naprawdę nie powinien. Dlatego najlepszym sposobem, aby powiedzieć użytkownikowi, gdzie są granice, jest to, czy gotowe działanie aplikacji jest zgodne z licencją. W tym pierwszym przypadku oznacza to albo nieudaną instalację, albo instalację w trybie próbnym drugi raz. W tym drugim przypadku może to po prostu oznaczać sprawdzenie zwykłego tekstu w pliku konfiguracyjnym. Tak czy inaczej, upewnij się, że postępujesz z nim w elegancki, pomocny i pełen szacunku sposób.

To tłumaczy, co to znaczy tyle robić. Ale dlaczego nie pójść dalej? Dlaczego nie zatkać każdej małej dziury, którą możesz znaleźć? Odpowiedź składa się z dwóch części. Po pierwsze, jeśli ktoś przekroczy etyczny próg świadomego łamania warunków licencji - nawet w prosty sposób - będzie również gotów zrobić coś trudniejszego lub bardziej niebezpiecznego, jak wyciągnięcie aplikacji z torrentawitryna - a uruchamianie aplikacji pobranych z niezaufanych źródeł wiąże się z pewnym ryzykiem. Utrudnianie pracy jest tylko niewielką uciążliwością dla tych użytkowników i grozi problemami z płatnymi klientami. Uproszczenie może uniemożliwić komuś wkopanie się w twoją aplikację i wydanie bardziej kompleksowego cracku. Po drugie, masz niewiele oczu, aby szukać wad; hakerzy mają ich wielu i więcej praktyki w ich znajdowaniu. Musisz tylko przegapić jedną małą wadę, a Twoja aplikacja będzie miała taką samą dystrybucję na stronach pirackich, jakbyś nic nie zrobił. Musisz mieć rację za każdym razem; muszą mieć szczęście tylko raz. Wymagany wysiłek jest więc bardzo wysoki, a prawdopodobieństwo jakiejkolwiek miary sukcesu bardzo małe.

Ostatecznie, jeśli ktoś chce pirować twoją aplikację (a nie tylko jej używać), a to jest ich główny cel, zrobią to. Nic nie możesz zrobić, aby ich powstrzymać. Taka jest natura oprogramowania; gdy pliki tworzące produkt znajdą się na komputerze użytkownika, będą mogły z nimi zrobić, co zechcą. Jest to szczególnie istotne w środowiskach zarządzanych, takich jak Java lub .NET , ale zdecydowanie dotyczy to również kodu natywnego. Czas jest po ich stronie, a przy wystarczającej ilości czasu wszelkie cyfrowe zabezpieczenia mogą zostać złamane.

Ponieważ nie możesz powstrzymać użytkowników przed piractwem Twojego produktu, najlepszym rozwiązaniem jest zaangażowanie tej klasy użytkowników w taki sposób, aby wykorzystali ich na Twoją korzyść. Często można sprawić, aby działali dla ciebie, a nie przeciwko tobie. Mając to na uwadze, bez względu na to, jaka jest twoja aplikacja, prawdopodobnie warto zachować bezpłatną wersję, która jest prawie całkowicie funkcjonalna i nie wygasa. Różnica między ceną nawet 1 USD a darmową jest ogromna, jeśli tylko z tego powodu klient nie musi ufać Ci swoją kartą kredytową. Darmowa edycja Twojego produktu nie tylko skutecznie zabije piracką dystrybucję (po co ryzykować piracką wersję, skoro możesz być uprawniony za tę samą cenę?), Ale może znacznie zwiększyć twoją publiczność.

W rezultacie może być konieczne podniesienie ceny wersji płatnej, aby ostatecznie zamiast 2000 użytkowników za 20 USD każdy miał 100 000 bezpłatnych użytkowników, z czego 500 jest gotowych zapłacić 99 USD za edycję „profesjonalną” . Dzięki temu zyskujesz więcej pieniędzy, niż gdybyś spędził mnóstwo czasu na zamykaniu swojego produktu. Co więcej, możesz zaangażować tych bezpłatnych użytkowników i wykorzystać związek na kilka ważnych sposobów.

Jednym z nich jest wsparcie. Pesymista skorzystałby z tej okazji, aby narzekać na wzrost kosztów obsługi 100 000 bezpłatnych użytkowników, ale zamiast tego dzieje się coś niesamowitego: twój produkt staje się w dużej mierze samowystarczalny. Widać to cały czas w dużych projektach open source, które nie mają pieniędzy na koszty wsparcia. Użytkownicy przyspieszą i sprawią, że to się stanie.

Bezpłatni użytkownicy generalnie zmniejszyli oczekiwania dotyczące wsparcia na początek i nie bez powodu. Wszystko, co musisz zrobić, to oznaczyć bezpłatną edycję jako kwalifikującą się tylko do wsparcia społeczności i założyć moderowane przez użytkowników forum online w tym celu. Twoja baza wiedzy wsparcia generuje się samodzielnie, a zaawansowani użytkownicy będą opiekować się tymi, którzy potrzebują dodatkowego trzymania ręki w Twoim imieniu. Co ważniejsze, pozwoli to szybciej zidentyfikować i poprawić błędy, ostatecznie poprawiając jakość produktu i obniżając całkowite koszty wsparcia. Nie było to wcześniej możliwe, ponieważ baza użytkowników nie była wystarczająco duża, ale jeśli traktujesz bezpłatnych użytkowników jako klientów, może to działać bardzo dobrze.

Kolejnym jest informacja zwrotna. Oglądając forum, poznajesz ważne pomysły na ulepszenia, których być może nigdy nie pomyślałeś inaczej. Dzięki temu możesz ostatecznie przekształcić więcej bezpłatnych użytkowników w płatnych użytkowników i stworzyć bardziej atrakcyjny produkt, który przyciągnie jeszcze większą liczbę odbiorców.

Wreszcie musisz rozważyć marketing. Wszyscy ci darmowi użytkownicy są teraz fanami, a nie przeciwnikami, i będą działać odpowiednio. Co więcej, jeśli przyjdzie czas na wydanie następnej wersji, wszyscy użytkownicy przejdą przez zatwierdzony kanał dystrybucji, a nie jakiś inny nieznany mechanizm. Oznacza to, że w kolejnej wersji zaczniesz od większej, bardzo zainteresowanej i wspierającej publiczności.

Najlepsze funkcje, które można zarezerwować w wersji profesjonalnej, to narzędzia mające na celu ułatwienie wdrożenia i zarządzania w firmie. Łamacz nie uzna tego za wystarczający powód, aby włamać się do niego na własny użytek, ale dla firmy, która chce kupić 300 licencji i wypchnąć go z całej firmy, jest to konieczność. Oczywiście profesjonalna edycja i tak będzie piracka, ale znowu: nie przejmuj się, ponieważ prawdopodobnie nie będziesz w stanie sprzedać produktu piratom bez względu na to, co zrobiłeś, więc nie kosztuje to żadnego przychodu.

Chociaż psychologicznie może być tak trudno rozdać swój produkt, mam nadzieję, że zrozumiesz, jak to naprawdę jest najlepsza droga. Co więcej, jest to jedyna droga na dłuższą metę. Wiem, że ktoś tam jest i myśli, że nie chce tego robić w ten sposób. W końcu dobrze sprzedają swój zablokowany produkt za 20 USD od lat. Ale to szkoda, ponieważ jeśli nie zrobisz tego w ten sposób, w końcu zrobi to ktoś inny . A ich produkt będzie tak samo dobry, jak twój, lub wystarczająco blisko, by uciec od tego. Nagle ceny wyglądają oburzająco, sprzedaż gwałtownie spada i nie można nic więcej zrobić. Jeśli chcesz, możesz wybrać dodatkowy środkowy poziom, ale raczej nie pomoże ci to.

Z mojego doświadczenia wynika, że ​​utrudnienie złamania twojej aplikacji lub biblioteki szkodzi uczciwym klientom, a jedynie nieznacznie opóźnia nieuczciwych. Skoncentruj się na stworzeniu świetnego produktu o niskim tarciu zamiast wkładać wiele wysiłku w opóźnianie nieuniknionego.

Sekret, który dzielisz z wieloma ludźmi, nie jest tajemnicą. Jeśli masz w kodzie tajne rzeczy, zaciemnianie go nie stanowi ochrony; należy go odszyfrować tylko raz . Jeśli masz sekret, którego nie chcesz udostępniać klientom, nie udostępniaj go swoim klientom . Napisz swój kod jako usługę internetową i przechowuj swój super tajny kod na własnym serwerze, gdzie tylko Ty go widzisz.

Ogólnie rzecz biorąc, są tam trzy grupy ludzi.

• Ci, którzy nie kupią twojego oprogramowania i nie uciekną się do pęknięć, lub jeśli go nie znajdą, w ogóle nie używają twojego oprogramowania. Nie spodziewaj się zarabiać na tej grupie. Opierają się albo na własnych umiejętnościach, albo na crackerach (którzy zwykle ustalają priorytet czasu w zależności od twojego przydatności i tego, jak duża jest twoja publiczność. Im bardziej przydatne, tym szybciej dostępny będzie crack).

• Grupa legalnych użytkowników, którzy kupią (zapłacą) za twoje oprogramowanie, niezależnie od używanego mechanizmu ochrony. Nie utrudniaj życia swoim legalnym użytkownikom, stosując skomplikowany mechanizm ochronny, ponieważ i tak za to zapłacą. Złożony mechanizm ochronny może łatwo zepsuć wrażenia użytkownika i nie chcesz, aby stało się tak w tej grupie. Osobiście głosowałbym przeciwko dowolnemu rozwiązaniu sprzętowemu, które zwiększa koszt twojego oprogramowania.

• Mniejszość, która ucieknie się do „nieetycznego” włamania i zapłaci tylko za twoje oprogramowanie, ponieważ jego funkcje są chronione przez mechanizm licencjonowania. Prawdopodobnie nie chcesz, aby ta grupa bardzo łatwo obchodziła twoją ochronę. Jednak cały wysiłek włożony w ochronę twojego oprogramowania zwróci się, w zależności od tego, jak duża jest ta grupa ludzi. Zależy to całkowicie od rodzaju tworzonego oprogramowania.

Biorąc pod uwagę to, co powiedziałeś, jeśli uważasz, że istnieje wystarczająco duża mniejszość, której można zmusić do zakupu twojego oprogramowania, śmiało i zaimplementuj jakąś formę ochrony. Zastanów się, ile pieniędzy możesz zarobić na tej mniejszości w porównaniu do czasu spędzonego na pracy nad ochroną lub kwoty, jaką wydajesz na interfejs API / narzędzie ochrony innej firmy.

Jeśli chcesz wdrożyć własne rozwiązanie, dobrym rozwiązaniem jest (w przeciwieństwie do algorytmów symetrycznych) szyfrowanie z kluczem publicznym, aby zapobiec łatwym włamaniom. Możesz na przykład podpisać cyfrowo swoją licencję (nr seryjny lub plik licencji). Jedynym sposobem na obejście tego byłoby dekompilacja, modyfikacja i rekompilacja kodu (co mogłoby być trudniejsze przy użyciu technik takich jak te sugerowane w odpowiedzi Simucala).

Nie możesz zapobiec łamaniu oprogramowania przez ludzi.

Możesz jednak sprawić, by tworzyły pęknięcia, które mniej zaszkodzą twojej sprzedaży. Generatory kluczy, które mogą wydawać prawidłowy kod rejestracyjny dla twojego oprogramowania, są znacznie gorsze niż proste łaty, które usuwają zachęty rejestracyjne z twojego oprogramowania. Wynika to z faktu, że crack będzie działał tylko dla jednej wersji oprogramowania i przestanie działać z następną wydaną aktualizacją oprogramowania. Generator kluczy będzie działał, dopóki nie zmienisz algorytmu klucza rejestracyjnego, a tego nie chcesz robić często, ponieważ zniechęci to uczciwych klientów.

Tak więc, jeśli szukasz metody walki z nielegalnymi generatorami kluczy dla swojego oprogramowania i nie chcesz używać szyfrowania asymetrycznego z powodu generowania długich kodów rejestracyjnych, możesz rzucić okiem na Częściową weryfikację klucza.

Częściowa weryfikacja klucza gwarantuje, że każdy nielegalny generator klucza działa tylko dla jednej konkretnej wersji oprogramowania. Zasadniczo musisz upewnić się, że każda wersja oprogramowania łączy się tylko z kodem do sprawdzania NIEKTÓRYCH cyfr kodu rejestracyjnego. Które cyfry są dokładnie losowe, więc crackerzy musieliby dokonać inżynierii wstecznej wielu różnych wersji oprogramowania i połączyć to wszystko w jeden generator klucza, aby zwolnić generator klucza, który działa dla wszystkich wersji oprogramowania.

Jeśli regularnie wydajesz nowe wersje oprogramowania, prowadzi to do powstania wielu generatorów kluczy rozpowszechnianych na wszelkiego rodzaju archiwach piractwa komputerowego, które już nie działają. Potencjalni piraci komputerowi zwykle szukają pęknięcia lub keygen dla najnowszej wersji, więc prawdopodobnie spróbują kilku z nich i ostatecznie się poddadzą.

Używałem Częściowej Weryfikacji w moich nowszych (C ++) grach shareware i było bardzo skuteczne. Wcześniej mieliśmy wiele problemów z generatorami kluczy, z którymi nie mogliśmy walczyć. Następnie pojawiło się wiele pęknięć i kilka generatorów kluczy, które działały tylko dla tej konkretnej wersji gry, ale brak generatora kluczy, który działałby ze wszystkimi wersjami. Regularnie wypuszczaliśmy bardzo niewielkie aktualizacje gry, aby wszystkie wcześniejsze pęknięcia były bezużyteczne.

Wygląda na to, że istnieje platforma .NET o otwartym kodzie źródłowym do częściowej weryfikacji klucza , chociaż jej nie próbowałem.

• Użyj aktualizacji online, aby zablokować te nielicencjonowane kopie.

• Sprawdź numer seryjny z różnych modułów aplikacji i nie używaj pojedynczego wywołania funkcji do weryfikacji (aby crackerzy nie mogli łatwo ominąć weryfikacji).

• Nie tylko sprawdzaj numer seryjny podczas uruchamiania, wykonaj weryfikację podczas zapisywania danych, rób to w każdy piątek wieczorem, rób to, gdy użytkownik jest bezczynny ...

• Sprawdź sumę kontrolną pliku aplikacji, przechowuj sumę kontroli bezpieczeństwa w różnych miejscach.

• Nie sięgaj zbyt daleko w takie sztuczki, upewnij się, że twoja aplikacja nigdy nie ulega awarii / awarii podczas weryfikacji kodu rejestracyjnego.

• Zbudowanie użytecznej aplikacji dla użytkowników jest o wiele ważniejsze niż stworzenie
  niezniszczalnego pliku binarnego dla crackerów.

Możesz..

Usługi Microsoft SLP Potencjał oprogramowania InishTech oferuje możliwość ochrony kodu bez wpływu na funkcjonalność aplikacji.

AKTUALIZACJA: (Ujawnienie: Pracuję na Eazfuscator.NET) To, co wyróżnia potencjał oprogramowania Microsoft SLP Services, to możliwość wirtualizacji kodu, więc zdecydowanie możesz . Minęło kilka lat od pierwszego pytania; dziś dostępnych jest więcej produktów, które działają na podobnych zasadach, takich jak:

• Agile.NET
• Eazfuscator.NET

.NET Reflector może otwierać tylko „kod zarządzany”, co w zasadzie oznacza „kod .NET”. Dlatego nie można go używać do dezasemblacji plików COM DLL, natywnego C ++, klasycznego kodu Visual Basic 6.0 itp. Struktura skompilowanego kodu .NET sprawia, że ​​jest on bardzo wygodny, przenośny, wykrywalny, weryfikowalny itp. .NET Reflector wykorzystuje pozwala to zajrzeć do skompilowanych zestawów, ale dekompilatory i deasemblery w żadnym wypadku nie są specyficzne dla platformy .NET i są dostępne tak długo, jak istnieją kompilatory.

Możesz użyć obfuscatorów, aby uczynić kod trudniejszym do odczytania, ale nie możesz dokładnie zapobiec jego dekompilacji bez spowodowania, że ​​będzie nieczytelny dla .NET. Istnieje kilka produktów (zwykle drogich), które twierdzą, że „łączą” aplikację kodu zarządzanego z aplikacją kodu natywnego, ale nawet jeśli faktycznie działają, zdeterminowana osoba zawsze znajdzie sposób.

Jeśli jednak chodzi o zaciemnianie, dostajesz za co płacisz. Więc jeśli twój kod jest tak zastrzeżony, że musisz dołożyć wszelkich starań, aby go chronić, powinieneś być gotów zainwestować pieniądze w dobry zaciemniacz.

Jednak w ciągu 15 lat pisania kodu zdałem sobie sprawę, że nadmierna ochrona kodu źródłowego jest stratą czasu i ma niewielkie zalety. Próba odczytania oryginalnego kodu źródłowego bez poparcia dokumentacji, komentarzy itp. Może być bardzo trudna do zrozumienia. Dodaj do tego bezsensowne nazwy zmiennych, które wymyślają dekompilatory, oraz kod spaghetti tworzony przez współczesne zaciemniacze - prawdopodobnie nie musisz się zbytnio martwić o ludzi kradnących twoją własność intelektualną.

Czy to naprawdę jest tego warte? Każdy mechanizm ochronny można złamać z wystarczającą determinacją. Weź pod uwagę rynek, cenę produktu, liczbę klientów itp.

Jeśli chcesz czegoś bardziej niezawodnego, przejdź ścieżką kluczy sprzętowych, ale jest to raczej kłopotliwe (dla użytkownika) i droższe. Rozwiązania programowe byłyby prawdopodobnie stratą czasu i zasobów, a jedyne, co by ci dały, to fałszywe poczucie „bezpieczeństwa”.

Jeszcze kilka pomysłów (żaden nie jest idealny, ponieważ nie ma jednego idealnego).

• AntiDuplicate
• Zmień język, korzystaj z fajnych sztuczek, których używali autorzy Skype
• Serwer licencji

I nie marnuj na to zbyt wiele czasu, ponieważ crackerzy mają duże doświadczenie z typowymi technikami i są o kilka kroków przed tobą. O ile nie chcesz używać wielu zasobów, prawdopodobnie zmień język programowania (zrób to na Skype).

Jeśli chcesz, aby ludzie mogli uruchomić Twój kod (a jeśli nie, to dlaczego go napisałeś?), To jego procesor musi być w stanie wykonać Twój kod. Aby móc wykonać kod, CPU musi być w stanie go zrozumieć .

Ponieważ procesory są głupie, a ludzie nie, oznacza to, że ludzie również mogą zrozumieć kod.

Jest tylko jeden sposób, aby upewnić się, że Twoi użytkownicy nie dostają Twojego kodu: nie dawaj mu swojego kodu.

Można to osiągnąć na dwa sposoby: oprogramowanie jako usługa (SaaS), to znaczy, należy uruchomić oprogramowanie na swoim serwerze, a jedynie pozwolić użytkownikom dostęp zdalnie. Jest to model, na przykład używany przez przepełnienie stosu. Jestem pewien, że Stack Overflow nie zaciemnia ich kodu, ale nie można go zdekompilować.

Innym sposobem jest model urządzenia: zamiast dawać swoim użytkownikom kod, dajesz komputer zawierający ten kod. Jest to model, z którego korzystają konsole do gier, większość telefonów komórkowych i TiVo . Pamiętaj, że działa to tylko wtedy, gdy „posiadasz” całą ścieżkę wykonania: musisz zbudować własny procesor, własny komputer, napisać własny system operacyjny i własny implementację interfejsu CLI . Wtedy i tylko wtedy można chronić swój kod. (Pamiętaj jednak, że nawet najmniejszy błąd sprawi, że wszystkie twoje zabezpieczenia będą bezużyteczne. Microsoft, Apple, Sony, przemysł muzyczny i przemysł filmowy mogą to potwierdzić.)

Możesz też nic nie robić, co oznacza, że ​​Twój kod będzie automatycznie chroniony prawem autorskim.

Niestety nie uciekniesz od tego. Najlepiej jest napisać kod w C i P / Invoke go.

Jest mały catch-22, ktoś mógłby po prostu zdekompilować twoją aplikację do CIL i zabić dowolny kod weryfikacyjny / aktywacyjny (na przykład wywołanie twojej biblioteki C). Pamiętaj, że aplikacje napisane w C są również poddawane inżynierii wstecznej przez bardziej wytrwałych hakerów (wystarczy spojrzeć na to, jak szybko gry są obecnie łamane). Nic nie ochroni twojej aplikacji.

W końcu działa bardzo podobnie do twojego domu, chroń go wystarczająco dobrze, aby był zbyt duży wysiłek (tutaj pomoże kod spaghetti) i aby napastnik po prostu przeniósł się na sąsiada (konkurencja :)). Spójrz na Windows Vista, musi istnieć 10 różnych sposobów na złamanie go.

Istnieją pakiety, które zaszyfrują plik EXE i odszyfrują go, gdy użytkownik będzie mógł go użyć, ale jeszcze raz, używając ogólnego rozwiązania, które bez wątpienia zostało złamane.

Mechanizmy aktywacji i rejestracji są skierowane do „przeciętnego Joe:” ludzi, którzy nie mają wystarczającej wiedzy technicznej, aby to ominąć (lub, jeśli o to chodzi, wiedzą, że mogą to ominąć). Nie zawracaj sobie głowy krakersami, mają o wiele za dużo czasu.

Oprócz ochrony zakupu, Ty (lub Twoi programiści) możesz nauczyć się ochrony przed kopiowaniem.

Oto pomysły:

Najpierw spróbuj napisać program, który zapisuje się na konsoli. To znany problem. Podstawowym celem tego zadania jest ćwiczenie pisania kodu, do którego odwołuje się sam.

Po drugie, musisz opracować technologię, która przepisze kod w sposób zależny od CIL innych metod .

Możesz napisać maszynę wirtualną (jeszcze w .NET ). I wstaw tam trochę kodu. Ostatecznie maszyna wirtualna uruchamia inną maszynę wirtualną, która uruchamia kod. Dotyczy to części rzadko wywoływanych funkcji, aby nie spowalniać zbytnio wydajności.

Przepisz trochę logiki do C ++ / CLI i mieszaj zarządzany kod z niezarządzanym. Utrudni to demontaż. W takim przypadku nie zapomnij również podać plików binarnych x64 .

Tak. To prawda. Kod .NET jest wyjątkowo łatwy do odtworzenia, jeśli kod nie jest zaciemniony.

Obfuscation doda warstwę irytacji osobom próbującym odtworzyć oprogramowanie. W zależności od wybranej wersji otrzymasz różne poziomy ochrony.

Visual Studio zawiera wersję Dotfuscator . Ponieważ jest to wersja dołączona, zdecydowanie nie otrzymujesz najsilniejszego możliwego zaciemnienia. Jeśli spojrzysz na ich listę funkcji, zobaczysz dokładnie to, czego brakuje (i dokładnie to, co zrobi aplikacja, aby twój kod był bezpieczniejszy).

Istnieje kilka innych darmowych lub open source'owych obfuscatorów .NET (ale nie mogę wypowiedzieć się na temat jakości ani różnych metod, których używają):

• Obfuscar
• Babel.NET

W końcu nic nie jest idealne. Jeśli ktoś naprawdę chce zobaczyć, jak działa twoje oprogramowanie, to zrobi to.

Cóż, nie możesz W PEŁNI chronić swojego produktu przed pękaniem, ale możesz zmaksymalizować / poprawić poziomy bezpieczeństwa i sprawić, że będzie trochę trudniejszy do złamania przez początkujących i pośrednich crackerów.

Ale pamiętaj, że nic nie jest niemożliwe do wykrycia, tylko oprogramowanie po stronie serwera jest dobrze chronione i nie można go złamać. W każdym razie, aby podnieść poziom bezpieczeństwa aplikacji, możesz wykonać kilka prostych kroków, aby zapobiec łamaniu aplikacji przez niektórych crackerów. Te kroki sprawią, że te krakersy oszaleją i być może będą desperackie:

• Ukryj kod źródłowy, oczywiście spowoduje to, że kod źródłowy będzie wyglądał na bałagan i będzie nieczytelny.
• Uruchom kilka losowych procedur sprawdzania w aplikacji, np. Co dwie godziny, 24 godziny, jeden dzień, tydzień itp., A może po każdym działaniu użytkownika.
• Zapisz wydaną aplikację MD5 sumę kontrolną na serwerze i zaimplementuj procedurę, która może sprawdzić bieżącą sumę kontrolną MD5 pliku z rzeczywistą sumą kontrolną po stronie serwera i sprawić, że zostanie ona losowo uruchomiona. Jeśli suma kontrolna MD5 została zmieniona, oznacza to, że ta kopia została piracka. Teraz możesz go po prostu zablokować lub wydać aktualizację, aby go zablokować itp.
• Spróbuj stworzyć procedurę, która sprawdzi, czy niektóre kody (funkcje, klasy lub określone procedury) zostały faktycznie zmodyfikowane, zmienione, a nawet usunięte. Nazywam to (sprawdzanie integralności kodu).
• Użyj darmowych nieznanych programów pakujących do spakowania aplikacji. Lub, jeśli masz pieniądze, wybierz rozwiązania komercyjne, takie jak Thamida lub .NET Reactor . Aplikacje te są regularnie aktualizowane, a gdy cracker rozpakuje aplikację, możesz po prostu pobrać nową aktualizację od tych firm, a gdy ją otrzymasz, po prostu spakuj swój program i wydaj nową.
• Regularnie wypuszczaj aktualizacje i zmuszaj klienta do pobrania najnowszej aktualizacji.
• Na koniec spraw, aby Twoja aplikacja była bardzo tania. Nie rób tego zbyt drogo. Uwierz mi, zyskasz więcej zadowolonych klientów, a crackerzy po prostu opuszczą twoją aplikację, ponieważ nie warto poświęcać czasu na bardzo tanią aplikację.

To tylko proste metody zapobiegania pękaniu aplikacji przez początkujących i pośrednich crackerów. Jeśli masz więcej pomysłów na ochronę aplikacji, nie wahaj się ich wdrożyć. To tylko utrudni krakersom życie, a oni sfrustrują się, a ostatecznie porzucą twoją aplikację, ponieważ to po prostu nie jest warte ich czasu.

Na koniec należy również rozważyć poświęcenie czasu na kodowanie dobrej jakości aplikacji. Nie trać czasu na kodowanie skomplikowanych warstw zabezpieczeń. Jeśli dobry cracker chce złamać twoją aplikację, zrobi to bez względu na to, co zrobisz ...

Teraz idź i zaimplementuj zabawki dla krakersów ...

Istnieje Salamander , który jest natywnym kompilatorem .NET i linkerem firmy Remotesoft, który może wdrażać aplikacje bez frameworku .NET. Nie wiem, jak dobrze spełnia swoje roszczenia.

Jeśli Microsoft mógłby wymyślić rozwiązanie, nie mielibyśmy pirackich wersji systemu Windows, więc nic nie jest bardzo bezpieczne. Oto kilka podobnych pytań z Przepełnienia stosu i możesz wdrożyć własny sposób ich ochrony. Jeśli wydajesz różne wersje, możesz zastosować różne techniki dla różnych wersji, więc zanim pierwsza zostanie złamana, druga może przejąć kontrolę.

• Zarządzanie funkcjami na podstawie licencji dla aplikacji C ++

• Zabezpiecz plik DLL za pomocą pliku licencji

• Oprogramowanie do licencjonowania / ochrony?

Reaktor .NET

Aktualizacja

Jared zwrócił uwagę, że de4dot twierdzi, że jest w stanie go zdekompilować .

.NET Reactor zapewnia pełną ochronę wrażliwej własności intelektualnej poprzez konwersję zestawów .NET w niezarządzane procesy, których nie można rozumieć jako CIL i których żadne istniejące narzędzie nie może dekompilować. Hakerzy nie mają dostępu do żadnej zrozumiałej formy Twojego źródła.

Wydajne i elastyczne funkcje licencjonowania .NET Reactor umożliwiają egzekwowanie warunków licencji i ochronę strumienia przychodów za pomocą blokad sprzętowych i programowych. Menedżer licencji może zbudować licencje próbne lub stałe w ciągu kilku sekund. W pełni udokumentowany zestaw programistyczny (SDK), wraz z przykładami, pozwala na wywołanie systemu licencyjnego bezpośrednio z kodu, umożliwiając tworzenie niestandardowych rozszerzeń systemu licencyjnego.

Oto jeden pomysł: możesz mieć serwer obsługiwany przez Twoją firmę, z którym muszą się łączyć wszystkie wystąpienia oprogramowania. Samo połączenie i zweryfikowanie klucza rejestracyjnego nie jest wystarczające - po prostu usuną czek. Oprócz sprawdzania klucza musisz także zlecić serwerowi wykonanie ważnego zadania, którego klient nie może sam wykonać, więc nie można go usunąć. Prawdopodobnie oznaczałoby to dużo intensywnego przetwarzania po stronie serwera, ale utrudniłoby to kradzież oprogramowania i przy założeniu, że masz dobry schemat kluczy (sprawdź własność itp.), Klucze będą również trudne do zdobycia skraść. Jest to prawdopodobnie bardziej inwazyjne niż chcesz, ponieważ będzie wymagać od użytkowników połączenia z Internetem w celu korzystania z oprogramowania.

Wszystko, co działa na kliencie, można zdekompilować i złamać. Zmarnowanie tylko utrudnia. Nie znam twojej aplikacji, ale 99% czasu po prostu nie uważam, że warto.

Przykro nam, nie można w pełni zabezpieczyć aplikacji.

Ukryj kod! Istnieje przykład w zaciemnianiu kodu C # .

Pamiętaj, że ponad 99% użytkowników nie będzie zainteresowanych badaniem pliku wykonywalnego, aby zobaczyć, jak to działa.

Biorąc pod uwagę, że tak niewielu ludzi będzie nawet męczyć się z próbowaniem i że większość zaciemniaczy można obejść, czy warto poświęcić swój czas i wysiłek?

Lepiej zainwestuj czas w ulepszanie produktu, aby więcej osób chciało z niego korzystać.

Wystarczy dodać ostrzeżenie: jeśli zamierzasz użyć zaciemnienia, sprawdź, czy wszystko nadal działa! Zaciemnianie może zmienić takie rzeczy, jak nazwy klas i metod. Jeśli więc używasz refleksji do wywoływania określonych metod i / lub klas (jak w architekturze wtyczek), aplikacja może przestać działać po zaciemnieniu. Również Stacktrace mogą być bezużyteczne do śledzenia błędów.

Jeśli jest napisany w .NET i skompilowany do CIL , może zostać odzwierciedlony. Jeśli chodzi o bezpieczeństwo i należy unikać zaciemniania, zalecamy napisanie aplikacji w języku innym niż zarządzany, co z natury jest trudniejsze do odtworzenia.

Jak upewnić się, że aplikacja nie jest modyfikowana, i jak upewnić się, że mechanizm rejestracji nie może być poddany inżynierii wstecznej.

Oba mają tę samą bardzo prostą odpowiedź: nie rozdawaj kodu obiektowego niezaufanym podmiotom, takim jak (najwyraźniej) Twoi klienci. To, czy możliwe jest hostowanie aplikacji na twoich komputerach, zależy tylko od tego, co ona robi.

Jeśli nie jest to aplikacja internetowa , być może możesz zezwolić na logowanie SSH z X przekierowaniem na serwer aplikacji (lub , jak sądzę, w przypadku Windows Remote Connection Connection Remote Desktop ).

Jeśli podasz kod obiektowy osobom typu nerdy, a oni myślą, że twój program może być fajny do złamania, zostanie złamany. Nie da się tego obejść.

Jeśli mi nie wierzysz, wskaż głośną aplikację, która nie została złamana i piracka.

Jeśli użyjesz kluczy sprzętowych, spowoduje to, że produkcja będzie droższa, a twoi użytkownicy będą cię za to nienawidzić. To prawdziwa dziwka, czołgać się po podłodze, podłączając i odłączając 27 różnych urządzeń USB, ponieważ twórcy oprogramowania ci nie ufają (wyobrażam sobie).

Istnieją pakiety, które będą szyfrować plik EXE i odszyfrować go, gdy użytkownik będzie mógł go używać

Oczywiście istnieje sposób, aby złamać test „can-I-use-it”, aby zawsze zwracał wartość true.

Paskudną sztuczką może być użycie wartości bajtowych kodów operacyjnych, które przeprowadzają test gdzieś indziej w programie, w nieprzyzwoity sposób, który spowoduje awarię programu z dużym prawdopodobieństwem, chyba że wartość jest właściwa. To jednak powoduje, że jesteś powiązany z określoną architekturą :-(

Uczyń dobrą aplikację i kod prostym systemem ochrony. Nie ma znaczenia, jaką ochronę wybierzesz, zostanie ona odwrócona ... Więc nie marnuj zbyt wiele czasu / pieniędzy.

Jeśli chodzi o .NET, jeśli wypuszczasz aplikację Windows Forms (lub dowolną aplikację, w której klient ma przenośny plik wykonywalny), można ją złamać.

Jeśli chcesz pozostać przy .NET i zminimalizować szansę na pobranie kodu źródłowego, możesz rozważyć wdrożenie go jako aplikacji ASP.NET na serwerze WWW, zamiast uczynić go aplikacją Windows Forms.

Szczerze mówiąc, czasami musimy zaciemnić kod (na przykład zarejestrować klasy licencji i tak dalej). W takim przypadku twój projekt nie jest darmowy. IMO, powinieneś zapłacić za dobrego obfucatora.

Dotfuscator ukrywa twój kod, a .NET Reflector wyświetla błąd podczas próby jego dekompilacji.

Mogę polecić użycie Obfuscatora .