Narzędzia / strategia zaciemniania .NET [zamknięte]

Mój produkt ma kilka składników: ASP.NET, aplikację Windows Forms i usługę Windows. Około 95% kodu jest napisanych w języku VB.NET.

Ze względu na własność intelektualną muszę zaciemnić kod i do tej pory korzystałem z wersji dotfuscatora, która ma już ponad 5 lat. Myślę, że czas przejść na narzędzie nowej generacji. To, czego szukam, to lista wymagań, które powinienem wziąć pod uwagę szukając nowego obfuskatora.

Co wiem, na razie powinienem szukać:

• Serializacja / De-serializacja . W moim obecnym rozwiązaniu po prostu mówię narzędziu,aby nie zaciemniło żadnych członków danych klasy, ponieważ ból związany z niemożnością załadowania danych, które zostały wcześniej serializowane, jest po prostu zbyt duży.
• Integracja z procesem kompilacji
• Praca z ASP.NET . W przeszłości stwierdzałem ten problem z powodu zmiany nazw .dll (często masz jedną na stronę) - z czym nie wszystkie narzędzia sobie radzą.

Wracając z .Net 1.1 zaciemnianie było niezbędne: dekompilacja kodu była łatwa i można było przejść od asemblera do IL, do kodu C # i skompilować go ponownie przy niewielkim wysiłku.

Teraz z .Net 3.5 nie jestem wcale pewien. Spróbuj zdekompilować zestaw 3.5; to, co otrzymujesz, jest dalekie od kompilacji.

Dodaj optymalizacje z 3.5 (znacznie lepsze niż 1.1) i sposób, w jaki anonimowe typy, delegaci i tak dalej są obsługiwane przez odbicie (są koszmarem dla ponownej kompilacji). Dodaj wyrażenia lambda, „magię” kompilatora, taką jak składnia Linq i var, oraz funkcje języka C # 2, takie jak yield(co skutkuje nowymi klasami o nieczytelnych nazwach). Twój zdekompilowany kod kończy się bardzo daleko od kompilacji.

Profesjonalny zespół, który ma dużo czasu, nadal mógłby go odtworzyć, ale to samo dotyczy każdego zaciemnionego kodu. Kod, który z tego wyciągnęli, byłby nie do utrzymania i prawdopodobnie byłby bardzo błędny.

Poleciłbym podpisywanie swoich zestawów kluczem (co oznacza, że ​​jeśli hakerzy mogą przekompilować jeden, muszą ponownie skompilować wszystkie), ale nie sądzę, aby zaciemnianie było tego warte.

Wypróbowaliśmy wiele obfuskatorów. Żaden z nich nie działa w dużej aplikacji klient / serwer, która korzysta z usług zdalnych. Problem polega na tym, że klient i serwer współużytkują niektóre biblioteki DLL, a nie znaleźliśmy żadnego obfuskatora, który mógłby to obsłużyć.

Wypróbowaliśmy DotFuscator Pro, SmartAssembly, XenoCode, Salamander i kilka małych aplikacji, których nazwy wymykają mi się.

Szczerze mówiąc, jestem przekonany, że zaciemnianie to wielki hack.

Nawet problemy, których dotyczy, nie są do końca prawdziwym problemem. Jedyne, co naprawdę musisz chronić, to parametry połączenia, kody aktywacyjne i tego typu rzeczy wrażliwe na bezpieczeństwo. Ten nonsens, że inna firma zamierza dokonać inżynierii wstecznej całego kodu i stworzyć z niego konkurencyjny produkt, to coś z koszmaru paranoicznego managera, a nie z rzeczywistości.

Jestem w tym teraz „po kolana”, próbując znaleźć dobre rozwiązanie. Oto moje dotychczasowe wrażenia.

Xenocode - Mam starą licencję na Xenocode2005, której używałem do zaciemniania moich zestawów .net 2.0. Działało dobrze na XP i było przyzwoitym rozwiązaniem. Mój obecny projekt to .net 3.5 i korzystam z Visty, wsparcie podpowiedziało mi, żebym go wypróbował, ale wersja 2005 nawet nie działa w systemie Vista (awarie), więc ja i teraz muszę kupić „PostBuild2008” w niesamowitej cenie 1900 $. To może być dobre narzędzie, ale nie zamierzam się tego dowiedzieć. Za drogie.

Reactor.Net - Jest to znacznie bardziej atrakcyjny punkt cenowy i działał dobrze na moim samodzielnym pliku wykonywalnym. Moduł licencjonowania również był fajny i zaoszczędziłby mi sporo wysiłku. Niestety brakuje kluczowej funkcji, a jest to możliwość wykluczenia rzeczy z zaciemniania. Uniemożliwia to osiągnięcie rezultatu, którego potrzebowałem (scalanie wielu złożeń razem, zaciemnianie niektórych, nie zaciemnianie innych).

SmartAssembly - ściągnąłem w tym celu Eval i działało bez zarzutu. Udało mi się osiągnąć wszystko, co chciałem, a interfejs był pierwszej klasy. Cena jest nadal trochę wysoka.

Dotfuscator Pro - nie można znaleźć ceny na stronie internetowej. Obecnie w dyskusjach o wycenę. Brzmi złowieszczo.

Confuser - projekt open source, który działa całkiem nieźle (aby zmylić ppl, tak jak sugeruje nazwa).

Uwaga: ConfuserEx jest podobno „uszkodzony” zgodnie z numerem 498 w repozytorium GitHub.

Jeśli szukasz darmowego, możesz wypróbować DotObfuscator Community Edition, który jest dostarczany z Visual Studio lub Eazfuscator.NET .

Od 29 czerwca 2012 r. Eazfuscator.NET jest teraz komercyjny. Ostatnia bezpłatna dostępna wersja to 3.3.

Używam smartassembly. Zasadniczo wybierasz bibliotekę dll i zwraca ją zaciemnioną. Wygląda na to, że działa dobrze i do tej pory nie miałem żadnych problemów. Bardzo, bardzo łatwy w użyciu.

Wypróbowałem prawie każdy obfuscator na rynku i moim zdaniem SmartAssembly jest najlepszy.

Używam też SmartAssembly. Zauważyłem, że Ezrinz .Net Reactor jest znacznie lepszy dla mnie w aplikacjach .net. Maskuje, obsługuje Mono, scala zestawy, a także ma bardzo fajny moduł licencjonowania do tworzenia wersji próbnej lub łączenia licencji z konkretną maszyną (bardzo łatwy do wdrożenia). Cena jest również bardzo konkurencyjna, a kiedy potrzebowałem wsparcia, szybko. Eziriz

Żeby było jasne, jestem tylko klientem, który lubi produkt i nie jest w żaden sposób związany z firmą.

Krótka odpowiedź brzmi: nie możesz.

Istnieją różne narzędzia, które utrudnią komuś odczytanie twojego kodu - niektóre z nich zostały wskazane w innych odpowiedziach.

Jednak wszystko to utrudnia czytanie - zwiększają wymagany wysiłek i to wszystko. Często to wystarczy, aby odstraszyć przypadkowych czytelników, ale ktoś, kto jest zdeterminowany, aby zagłębić się w twój kod, zawsze będzie w stanie to zrobić.

Mamy aplikację wielowarstwową z interfejsem asp.net i winform, który obsługuje również usługi zdalne. Nie miałem żadnych problemów z używaniem jakiegokolwiek obfuskatora, z wyjątkiem typu szyfrowania, który generuje program ładujący, który może być problematyczny na wiele nieoczekiwanych sposobów i po prostu nie jest tego wart. Właściwie moja rada byłaby bardziej zbliżona do „Unikaj szyfrowania obfuskatorów typu loader, takich jak plaga”. :)

Z mojego doświadczenia wynika, że ​​każdy obfuscator będzie działał dobrze z każdym aspektem .net, w tym asp.net i zdalnym, po prostu musisz zapoznać się z ustawieniami i dowiedzieć się, jak daleko możesz go przesunąć w których obszarach kodu. Poświęć trochę czasu na wypróbowanie inżynierii wstecznej na tym, co otrzymujesz, i zobacz, jak to działa z różnymi ustawieniami.

Przez kilka lat korzystaliśmy z naszych komercyjnych aplikacji i zdecydowaliśmy się na obfuscator Spices z 9rays.net, ponieważ cena jest odpowiednia, spełnia swoje zadanie i mają dobre wsparcie, chociaż tak naprawdę nie potrzebowaliśmy wsparcia od lat, ale szczerze mówiąc Nie sądzę, że naprawdę ma znaczenie, jakiego obfuscatora używasz, problemy i krzywa uczenia się są takie same, jeśli chcesz, aby działał poprawnie z usługami zdalnymi i asp.net.

Jak wspominali inni, wszystko, co tak naprawdę robisz, jest odpowiednikiem kłódki, która chroni innych uczciwych ludzi i utrudnia po prostu ponowną kompilację aplikacji.

Licencjonowanie jest zwykle kluczowym obszarem dla większości ludzi i zdecydowanie powinieneś używać jakiegoś systemu certyfikatów podpisanych cyfrowo do licencjonowania. Twoja największa strata będzie wynikać z przypadkowego dzielenia się licencjami, jeśli nie masz inteligentnego systemu, a ludzie, którzy łamią system licencji, nigdy nie zamierzali kupować.

Naprawdę łatwo jest posunąć się za daleko i mieć negatywny wpływ na klientów i firmę, rób to, co jest proste i rozsądne, a potem nie martw się o to.

Przez ostatnie dwa dni eksperymentowałem z Dotfuscator Community Edition advanced (do pobrania za darmo po zarejestrowaniu podstawowego CE, który jest dostarczany w pakiecie z Visual Studio).

Myślę, że powodem, dla którego większość ludzi nie używa zaciemniania jako opcji domyślnej, jest to, że jest to poważny problem w porównaniu z ryzykiem. W mniejszych projektach testowych mogłem uruchomić zaciemniony kod z dużym wysiłkiem. Wdrożenie prostego projektu przez ClickOnce było kłopotliwe, ale możliwe do osiągnięcia po ręcznym podpisaniu manifestów z magiem. Jedynym problemem było to, że po błędzie ślad stosu wrócił zaciemniony, a CE nie ma zapakowanego deobfuskatora ani klarującego.

Próbowałem zaciemnić prawdziwy projekt, który jest oparty na VSTO w Excelu, z integracją Virtual Earth, wieloma wywołaniami usług sieciowych, kontenerem IOC i wieloma refleksjami. To było niemożliwe.

Jeśli zaciemnianie jest naprawdę krytycznym wymaganiem, powinieneś projektować aplikację mając to na uwadze od samego początku, testując zaciemnione kompilacje w miarę postępów. W przeciwnym razie, jeśli jest to dość złożony projekt, skończysz z poważnym bólem.

Crypto Obfuscator rozwiąże wszystkie Twoje obawy i scenariusze. To :

1. Automatycznie wyklucza typy / członków z zaciemniania na podstawie reguł. Typy / pola zserializowane są jednym z nich.
2. Można go zintegrować z procesem kompilacji przy użyciu programu MSBUild.
3. Obsługuje projekty ASP.Net.

Niedawno próbowałem przekierować wyjście jednego darmowego obfuskatora do innego darmowego obfuskatora - mianowicie Dotfuscator CE i nowego obfuskatora Babel na CodePlex. Więcej szczegółów na moim blogu .

Jeśli chodzi o serializację, przeniosłem ten kod do innej biblioteki DLL i umieściłem go w projekcie. Doszedłem do wniosku, że nie ma tam żadnych tajemnic, których i tak nie ma w XML, więc nie trzeba zaciemniać. Jeśli istnieje jakiś poważny kod w tych klasach, użycie klas częściowych w głównym asemblerze powinno go pokryć.

Powinieneś użyć tego, co jest najtańsze i najbardziej znane dla Twojej platformy i nazwać to jednym dniem. Zaciemnianie języków wysokiego poziomu jest trudnym problemem, ponieważ strumienie kodu operacji VM nie cierpią z powodu dwóch największych problemów, jakie natywne strumienie kodu operacji powodują: identyfikacja funkcji / metody i aliasowanie rejestrów.

To, co powinieneś wiedzieć o odwracaniu kodu bajtowego, to fakt, że standardową praktyką testerów bezpieczeństwa jest już przeglądanie prostego kodu X86 i znajdowanie w nim luk. W surowym X86 nie możesz koniecznie nawet znaleźć prawidłowych funkcji, nie mówiąc już o śledzeniu zmiennej lokalnej w trakcie wywołania funkcji. W prawie żadnych okolicznościach natywne programy odwracające kod nie mają dostępu do nazw funkcji i zmiennych - chyba że przeglądają kod firmy Microsoft, dla którego MSFT z łatwością udostępnia te informacje publicznie.

„Dotfuscation” działa głównie na zasadzie szyfrowania funkcji i nazw zmiennych. Prawdopodobnie lepiej to zrobić niż publikować kod z informacjami na poziomie debugowania, gdzie Reflector dosłownie rezygnuje z kodu źródłowego. Ale wszystko, co zrobisz poza tym, prawdopodobnie przyniesie malejące korzyści.

Nie miałem żadnych problemów ze Smartassembly.

Możesz użyć „Dotfuscator Community Edition” - jest ona domyślnie dostępna w programie Visual Studio 2008 Professional. Możesz o tym przeczytać na:

http://msdn.microsoft.com/en-us/library/ms227240%28VS.80%29.aspx
http://www.preemptive.com/dotfuscator.html

Wersja „Professional” produktu kosztuje, ale jest lepsza.

Czy naprawdę potrzebujesz zaciemnionego kodu? Zwykle dekompilacja aplikacji jest bardzo mała, chyba że jest używana ze względów bezpieczeństwa. Jeśli martwisz się, że ludzie „ukradną” Twój kod, nie bądź; zdecydowana większość osób, które będą patrzeć na Twój kod, będzie służyła celom edukacyjnym. W każdym razie, nie ma całkowicie skutecznej strategii zaciemniania .NET - ktoś z wystarczającymi umiejętnościami zawsze będzie w stanie zdekompilować / zmienić Twoją aplikację.

Unikaj Reactor. Jest całkowicie bezużyteczny (i tak, zapłaciłem za licencję). Xenocode był najlepszym, na jaki się natknąłem i kupiłem licencję. Wsparcie było bardzo dobre, ale nie potrzebowałem go zbytnio, ponieważ po prostu działało. Przetestowałem każdy obfuscator, jaki mogłem znaleźć i doszedłem do wniosku, że xenocode był zdecydowanie najbardziej niezawodny i wykonał najlepszą robotę (również możliwość przetworzenia twojego .NET exe na natywny exe, którego nie widziałem nigdzie indziej).

Istnieją dwie główne różnice między reaktorem a ksenokodem. Po pierwsze, Xenocode faktycznie działa. Po drugie, szybkość wykonywania zestawów nie różni się. Z reaktorem był około 6 milionów razy wolniejszy. Odniosłem też wrażenie, że reaktor to operacja jednoosobowa.

Odkryłem, że Agile.Net zapewnia całkiem dobrą ochronę dla twojego zestawu .Net, ponieważ oferuje nie tylko zaciemnianie, ale także szyfrowanie. Pobierz darmowy szlak.
http://secureteam.net/NET-Code-Protection.aspx http://secureteam.net/downloads.aspx

Odkąd .Net 1 zaciemniłem kod w tej samej aplikacji i był to poważny ból głowy z punktu widzenia konserwacji. Jak już wspomniałeś, problemu serializacji można uniknąć, ale naprawdę łatwo jest popełnić błąd i zaciemnić coś, czego nie chcesz zaciemniać. Łatwo jest złamać kompilację lub zmienić wzorzec zaciemniania i nie można otworzyć starych plików. Poza tym ustalenie, co poszło nie tak i gdzie, może być trudne.

Naszym wyborem był Xenocode, a gdybym miał dokonać wyboru ponownie dzisiaj, wolałbym nie zaciemniać kodu ani nie używać Dotfuscatora.

Oto dokument od samego Microsoft. Mam nadzieję, że to pomoże ... pochodzi z 2003 roku, ale nadal może być aktualne.

Używamy SmartAssembly na naszym kliencie Windows. Działa dobrze.

Dodaje też dodatkowe problemy. Wydrukowanie nazw klas w plikach dziennika / wyjątkach musi zostać odszyfrowane. I oczywiście nie można utworzyć klasy na podstawie jej nazwy. Dlatego warto przyjrzeć się klientowi i sprawdzić, jakie problemy można napotkać, stosując zaciemnianie.

Wszystko zależy od języka programowania, którego używasz. Przeczytaj artykuł: Zamaskowany kod

darmowym sposobem byłoby użycie dotfuscatora w Visual Studio, w przeciwnym razie musiałbyś wyjść i kupić obfuscator, taki jak Postbuild ( http://www.xenocode.com/Landing/Obfuscation.aspx )

Musiałem użyć zaciemnienia / ochrony zasobów w moim najnowszym rpojekcie i odkryłem, że Crypto Obfuscator jest przyjemnym i prostym w użyciu narzędziem. Problem serializacji to tylko kwestia ustawień w tym narzędziu.

Jest dobra wersja open source o nazwie Obfuscar. Wydaje się, że działa dobrze. Można wykluczyć typy, właściwości, pola, metody. Oryginał jest tutaj: https://code.google.com/p/obfuscar/ , ale ponieważ wydaje się, że nie jest już aktualizowany

Możesz również przyjrzeć się nowym technologiom ochrony kodu, takim jak Metaforic i ViLabs, oraz nowym technologiom ochrony przed kopiowaniem oprogramowania, takim jak ByteShield . Ujawnienie: pracuję dla ByteShield.

Używam też smartassembly. Jednak nie wiem, jak to działa w przypadku aplikacji internetowej. Chciałbym jednak zaznaczyć, że jeśli Twoja aplikacja korzysta z ochrony typu shareware, upewnij się, że nie sprawdza licencji ze zwrotem logicznym. zbyt łatwo jest złamać bajt. http://blogs.compdj.com/post/Binary-hack-a-NET-executable.aspx

SmartAssembly jest świetna, byłem używany w większości moich projektów

Wypróbowałem wersję demo Eziriz ... Podobało mi się. Ale nigdy nie przyniosłem oprogramowania.

Maskowanie nie jest prawdziwą ochroną.

Jeśli masz plik .NET Exe, jest o wiele lepsze rozwiązanie.

Używam Themidy i mogę powiedzieć, że działa bardzo dobrze.

Jedyną wadą programu Themida jest to, że nie może chronić bibliotek DLL .NET. (Chroni również kod C ++ w plikach Exe i DLL)

Themida jest zdecydowanie tańsze niż tutaj wymienione obfuscators i jest najlepszy anty piractwa ochrony na rynku. Tworzy maszynę wirtualną, na której uruchamiane są krytyczne części kodu, i uruchamia kilka wątków, które wykrywają manipulacje lub punkty przerwania ustawione przez crackera. Konwertuje .NET Exe na coś, czego Reflector nie rozpoznaje już nawet jako zestaw .NET.

Przeczytaj szczegółowy opis na ich stronie internetowej: http://www.oreans.com/themida_features.php

Wypróbowałem produkt o nazwie Rummage i robi dobrą robotę, dając ci pewną kontrolę ... Chociaż brakuje mu wielu rzeczy, które oferuje Eziriz, ale cena za Rummage jest zbyt dobra ...