Databinding i zaciemnianie kodu

Question

Mój pracodawca używa Dotfuscatora we wszystkich naszych programach do produkcji .Net. Z tego powodu absolutnie zabronione jest używanie DOWOLNEGO wbudowanego wiązania danych lub czegokolwiek, co odzwierciedla nazwy właściwości/funkcji - ponieważ dotfuscator zmienia je, a zatem wszystko natychmiastowo i nieodwracalnie się zrywa.

Kontynuuję tę logikę w moim umyśle i zaczyna boleć. Aby uniknąć tego impasu, trzeba być pewnym sposobem uniknięcia tego impasu, jest to zbyt szeroki i podstawowy problem, aby nie mieć oczywistego rozwiązania, które nam umknęło.

A więc, jak się robi Odbicie z Obfuskacją? Co to za sztuczka? Przypuszczalnie muszą istnieć komercyjne obfuscators, które są wystarczająco inteligentne, aby obejść problem. Jakie są opcje naszej wersji (co jest dość głupie)?

Answer 1

Wprowadziliśmy wiele ulepszeń do programu Dotfuscator, które powinny pomóc w złagodzeniu problemów związanych z wiązaniem danych. Funkcja Smart Obfuscation została dodana w wersji 4.3.100 w marcu 2008 r. W celu statycznej analizy złożeń i automatycznego wykluczania elementów ze zmiany nazwy/usunięcia, o których wiadomo, że powodują błędy w czasie wykonywania. Konsekwentnie rozbudowywaliśmy i ulepszaliśmy tę funkcjonalność, a dzisiejszy Dotfuscator działa w oparciu o standardowe scenariusze wiązania danych z zazwyczaj zerową lub minimalną dodatkową konfiguracją.

Nawet jeśli funkcja Smart Obfuscation nie przechwytuje każdego ze scenariuszy, bardzo łatwo jest zdefiniować reguły niestandardowe w celu wykluczenia właściwości niektórych typów lub hierarchii dziedziczenia za pomocą niestandardowych reguł wykluczania (w tym dopasowywania typów według wzorców RegEx). Elementy można również ozdobić atrybutem System.Reflection.ObfuscationAttribute, aby zapewnić, że zostaną one wyłączone z zmiany nazwy lub usunięcia podczas działania przez Dotfuscator.

Jeśli wiążesz znaczniki XAML z typami w kodzie, ostatnie kilka wersji obsługuje zmiany nazwy XAML/BAML, aby dopasować kod z tyłu. Poprawia to ogólne hartowanie, a także eliminuje cały zakres problemów, gdy symbole w znaczniku nie pasują do definicji kodu.

Polecam wykonanie kilku prostych aplikacji koncepcyjnych wykorzystujących wiązanie danych, podobnych do tego, czego chcesz używać w swoich aplikacjach, i uruchamianie ich za pomocą aplikacji Dotfuscator, aby sprawdzić, jak dobrze sobie z nimi radzi. Jeśli znajdziesz jakieś scenariusze, w których funkcja Smart Obfuscation nie wyklucza automatycznie celów wiązania danych, wyślij je na adres support@preemptive.com. Zawsze szukamy dobrze zdefiniowanych scenariuszy, aby ulepszyć produkt.

Answer 2

Zadaniem obfuscatora jest rozbicie relacji widocznych w kodzie źródłowym, aby nie były widoczne w wynikowym kodzie programu. Refleksja opiera się na relacjach takich jak "właściwość żądana przez ten fragment kodu jest tą określoną przez ten fragment kodu". Nic więc dziwnego, że zaciemnianie i odbijanie nie współgrają ze sobą.

Właściwości zmiany nazwy to zaledwie stopień zero zaciemniania. Nieprzenikalny obfuscator będzie także robił rzeczy takie jak dzielenie własności na dwie części, tak że tam, gdzie kod źródłowy wspomina tylko właściwość P, część kodu środowiska wykonawczego będzie używała P1, a część kodu środowiska wykonawczego będzie używała P2, a będzie wystarczająca przypisania między nimi, tak aby właściwości miały odpowiednią wartość w razie potrzeby, ale także pasożytnicze przypisania, aby nie miały odpowiedniej wartości, gdy nie są potrzebne. To nie tylko, że P została zmieniona: nie ma już jest własność P.

Nie wiem, dlaczego uważasz, że odbicie także zaciemniania jest „szeroko zakrojone i fundamentalna”: zarówno odbicie i zaciemniania są dość rzadko w wielkim schemacie programowania i nie ma korelacji między ich użyciem, więc nie sądzę, że wiele osób próbuje je mieć.

Brak refleksji to tylko jeden element na długiej liście rzeczy, za które zaciemnienie cię kosztuje. Jeśli osoba, która zdecydowała się użyć zaciemniania, nie jest specjalistą od zabezpieczeń, spróbuj wbijać w nie, że zaciemnianie wiąże się z bardzo wysokimi kosztami, które z pewnością nie zostałyby oszacowane.