Czy zaciemnianie kodu .NET naprawdę jest tego warte?

Question

Z tego co przeczytałem, zaciemnianie kodu nie jest tak trudne do "złamania", a opóźni to nieuchronne. W takim razie jaki jest jej cel?

Jeśli ktoś naprawdę chce ukraść twoje źródło, może.

Jeśli ktoś potrzebuje zobaczyć swój kod źródłowy dla nieszkodliwych/pomocnych celów, nie może tego zrobić.

Prawdopodobnie nie powinno się przechowywać w kodzie nic wrażliwego, więc nie powinno to stanowić problemu.

Jeśli nie zamazujesz, nadal nie podajesz pełnego kodu źródłowego, więc możesz sprzedać "licencję kodu źródłowego".

Zabawne jest to, że jedyny kod, jaki kiedykolwiek widziałem zaciemniony, to okropny kod, który zawiera błędy. Jedynym powodem, dla którego muszę spojrzeć na kod, jest ustalenie, na czym polega problem i co mogę zrobić, aby go naprawić.

Na przykład, muszę zamienić niektóre obrazy w ASPDotNetStoreFront. Szukając lokalizacji tagów, stwierdziłem, że są one zawarte w skompilowanym kodzie. BZDURY. Pomyślałem więc, że będę dekompilował kod, aby dowiedzieć się, które znaczniki img można zastąpić przez Regex. Próbowałem wyświetlić kod źródłowy, aby zobaczyć, jakie obrazy mogłyby pochodzić z podanej metody kompilacji, a reflektor nie poradzi sobie z tym, jak sądzę, z powodu zaciemniania. Naprawdę nie mam czasu rozglądać się za dilerami/obłudnikami.

Answer 1

Myślę, że warto. Koszt dla ciebie to praktycznie nic, a życie hakera znacznie cię utrudnia. Nawet jeśli je złamią, masz satysfakcję ze świadomości, że marnujesz czas od kilku godzin do kilku tygodni swojego życia. Tylko dlatego, że zamek nie jest idealny, nie oznacza, że ​​nie zamykasz drzwi.

Answer 2

Nie wiem, czy warto "zaciemnić", ale mogę powiedzieć, że istnieją alternatywy dla zaciemniania, które są bezpieczniejsze.

Na przykład XHEO udostępnia narzędzie (CodeVeil) do szyfrowania zestawów .NET, zamiast je po prostu zaciemniać.

Answer 3

Tylko jeśli Twój projekt jest długotrwały i wymagałoby poświęcenia dużej ilości czasu, warto. Jest to oczywiście opinia tutaj, ale nie znalazłem zaciemnionej biblioteki .Net, ale nie mogłem dowiedzieć się, co się dzieje, używając tylko Reflectora.

To odstraszające nic więcej. Jeśli koszt kogoś, kto dokona inżynierii wstecznej kodu, jest większy niż koszt jego implementacji, jest to jedyny prawnie uzasadniony przypadek, jaki widzę, ale jeśli ktoś chce zobaczyć, jak twój kod się klika, nie jest to zbyt dobre w zapobieganiu temu.

Jednym z typowych przypadków, które widzę, jest to, jak produkujesz i/lub odszyfrowujesz klucz licencyjny. Każdy, kto jest zmotywowany, aby to zrozumieć i zagłębić się w sondowanie dla was metodami solnymi/odszyfrowującymi, nie zostanie powstrzymany przez zaciemnianie, ośmieliłbym się powiedzieć, że tak naprawdę nie spowolni ich zbyt wiele.

Answer 4

Moim zdaniem, nie. Widziałem facetów hakujących programy napisane w różnych językach. Dzięki profesjonalnym narzędziom, takim jak IDA (działa na niezarządzanym kodzie), nic nie jest w 100% bezpieczne. Zfałszowane złożenia są jeszcze łatwiejsze do zhakowania ze względu na wciąż obecne metadane.

Answer 5

Dla aplikacji .Net, NIE zaciemnianie jest równoznaczne z udostępnieniem produktu open source, ponieważ tak łatwo można go zobaczyć i przeanalizować za pomocą Reflectora. Możesz mieć umowę licencyjną, ale tylko kilka firm ma czas i pieniądze na obronę umowy licencyjnej przed sądem. Dla takich firm najlepszym rozwiązaniem jest zaciemnianie. Oczywiście, musisz przetestować zaciemnione złożenia, ale potem już testujesz swój produkt, więc dlaczego nie przetestować ostatecznych zaciemnionych złożeń.

Zależy również od tego, jak pomocny jest obfuscator.Pomyśl o naszej Crypto Obfuscator - obsługuje łatwą integrację z Visual Studio, więc zawsze używasz zaciemnionych złożeń. Ma również wiele automatycznych wykluczeń, więc nie zamazuje klas/członków, które spowodują nieprawidłowe działanie zaciemnionego zespołu. Wyświetli również ostrzeżenia (w tym numer linii) dla kodu, który może spowodować błędne uruchomienie zaciemnionego zespołu. To ogromna oszczędność czasu.

Answer 6

Oczywiście nic nie jest w 100% chronione. Ale nie zaciemnianie z tego powodu jest jak zamknięcie drzwi domu, ponieważ "każdy zdeterminowany złodziej może go otworzyć". I tak blokujesz drzwi !!

Uważam, że głównym zagrożeniem jest dekompilacja aplikacji za pomocą ildazmów, wykrywanie zdań SQL, manipulowanie nimi, a następnie kompilacja. W ten sposób może wyeliminować ograniczenia i uzyskać pełną listę klientów, lub po prostu zrobić zwykłą szkodę.

Ty, jako dostawcy aplikacji, zostanie pociągnięty do odpowiedzialności w pierwszej kolejności ...

kolesiami BitHelmet wyjaśniają go dość dobrze w http://www.bithelmet.com/Overview.html.

Pracowałem w średniej wielkości firmie wydającej karty kredytowe kilka lat temu. Były trzy kradzieże (duże pieniądze) z udziałem pracowników, z których się wywodziliśmy, i wszystkie zostały wykonane nie przez rosyjskiego lub chińskiego hakera światowej klasy, ale przez kwnow-tylko wystarczająco programistów, którzy zrobili tylko trochę zwroty akcji do oprogramowania kasjerów.

Byłem wtedy młodszy :), mój szef musiał sobie z tym poradzić. Zawsze się zastanawiam, ile z tych kradzieży nigdy nie zostało odkrytych ;-). Mogłem to zrobić, ale nigdy tego nie zrobiłem!

Faktem jest, że musisz myśleć na pewnym poziomie ochrony i musisz wziąć pod uwagę osobę atakującą. I sprawi, że życie będzie trudniejsze dla zdecydowanego inżyniera odwrotnego.