Ochrona pliku wykonywalnego przed inżynierią wsteczną?

Zastanawiałem się, jak chronić mój kod C / C ++ przed dezasemblacją i inżynierią wsteczną. Zwykle nigdy nie przyzwalam na takie zachowanie w moim kodzie; jednak obecny protokół, nad którym pracuję, nie może być nigdy sprawdzany ani zrozumiały dla bezpieczeństwa różnych osób.

Teraz jest to dla mnie nowy temat, a Internet nie jest tak naprawdę zasobny w zapobieganie inżynierii wstecznej, ale raczej przedstawia mnóstwo informacji na temat inżynierii wstecznej

Niektóre rzeczy, o których do tej pory myślałem, to:

• Wstrzykiwanie kodu (wywoływanie fałszywych funkcji przed i po rzeczywistych wywołaniach funkcji)
• Utajnienie kodu (zakłóca demontaż pliku binarnego)

• Napisz własne procedury uruchamiania (trudniejsze do powiązania z debuggerami)

  void startup();  
  int _start()   
  {  
      startup( );  
      exit   (0)   
  }  
  void startup()  
  {  
      /* code here */  
  }
  

• Sprawdzanie w czasie wykonywania dla debuggerów (i wymuszanie wyjścia, jeśli zostanie wykryte)

• Funkcjonalne trampoliny

   void trampoline(void (*fnptr)(), bool ping = false)  
   {  
     if(ping)  
       fnptr();  
     else  
       trampoline(fnptr, true);  
   }
  

• Bezcelowe alokacje i dezalokacje (stos bardzo się zmienia)

• Bezcelowe wywołania manekinów i trampoliny (mnóstwo skoków w wyniku demontażu)
• Tony odlewania (do zaciemnionego demontażu)

Mam na myśli, że są to niektóre z rzeczy, o których myślałem, ale można je wszystkie rozpracować i / lub ustalić przez analityków kodu we właściwych ramach czasowych. Czy mam coś jeszcze alternatywnego?

To, co powiedziała Amber, jest dokładnie słuszne. Możesz utrudnić inżynierię odwrotną, ale nigdy nie możesz temu zapobiec. Nigdy nie należy ufać „bezpieczeństwu”, które polega na zapobieganiu inżynierii odwrotnej .

To powiedziawszy, najlepsze techniki inżynierii wstecznej, jakie widziałem, nie skupiały się na zaciemnianiu kodu, ale na łamaniu narzędzi, których ludzie zwykle używają do zrozumienia, jak działa kod. Znalezienie kreatywnych sposobów na rozbicie deasemblerów, debuggerów itp. Może być zarówno bardziej skuteczne, jak i bardziej satysfakcjonujące intelektualnie niż generowanie ryz okropnego kodu spaghetti. Nie blokuje to zdecydowanego napastnika, ale zwiększa prawdopodobieństwo, że J Random Cracker odejdzie i będzie pracował nad czymś łatwiejszym.

ale wszystkie mogą być omówione i / lub ustalone przez analityków kodu we właściwych ramach czasowych.

Jeśli dasz ludziom program, który są w stanie uruchomić, będą mogli go również poddać inżynierii wstecznej, mając wystarczająco dużo czasu. Taka jest natura programów. Jak tylko plik binarny jest dostępny dla kogoś, kto chce go rozszyfrować, nie można zapobiec ewentualnej inżynierii wstecznej. W końcu komputer musi być w stanie go rozszyfrować, aby go uruchomić, a człowiek jest po prostu wolniejszym komputerem.

Safe Net Sentinel (wcześniej Aladdin). Zastrzeżenia - ich API jest do bani, dokumentacja do bani, a oba są świetne w porównaniu do narzędzi SDK.

Od wielu lat stosuję metodę ochrony sprzętu ( Sentinel HASP HL ). Wymaga zastrzeżonego breloka USB, który działa jak „licencja” na oprogramowanie. Ich zestaw SDK szyfruje i zaciemnia pliki wykonywalne i biblioteki oraz umożliwia powiązanie różnych funkcji aplikacji z funkcjami wypalonymi w kluczu. Bez klucza USB dostarczonego i aktywowanego przez licencjodawcę oprogramowanie nie może odszyfrować, a zatem nie będzie działać. Klucz używa nawet niestandardowego protokołu komunikacyjnego USB (poza moją wiedzą, nie jestem facetem od sterownika urządzenia), aby utrudnić zbudowanie klucza wirtualnego lub manipulowanie komunikacją między opakowaniem środowiska wykonawczego a kluczem. Ich zestaw SDK nie jest zbyt przyjazny dla programistów i integracja dodawania ochrony z automatycznym procesem kompilacji jest dość bolesna (ale możliwe).

Zanim wdrożyliśmy ochronę HASP HL, było 7 znanych piratów, którzy zdjęli „zabezpieczenia” dotfuscatora z produktu. Dodaliśmy ochronę HASP w tym samym czasie, co ważną aktualizację oprogramowania, która wykonuje pewne ciężkie obliczenia wideo w czasie rzeczywistym. Jak najlepiej mogę powiedzieć z profilowania i testów porównawczych, ochrona HASP HL ​​spowolniła intensywne obliczenia tylko o około 3%. Od czasu wydania tego oprogramowania około 5 lat temu nie znaleziono żadnego nowego pirata produktu. Oprogramowanie, które chroni, jest bardzo poszukiwane w swoim segmencie rynku, a klient ma świadomość, że kilku konkurentów aktywnie próbuje dokonać inżynierii wstecznej (jak dotąd bez powodzenia). Wiemy, że próbowali poprosić o pomoc kilka grup w Rosji, które reklamują usługę łamania ochrony oprogramowania,

Ostatnio wypróbowaliśmy ich rozwiązanie licencyjne na oprogramowanie (HASP SL) w mniejszym projekcie, co było wystarczająco proste, aby zacząć działać, jeśli znasz już produkt HL. Wydaje się działać; nie zgłoszono żadnych przypadków piractwa, ale popyt na ten produkt jest znacznie niższy.

Oczywiście żadna ochrona nie może być idealna. Jeśli ktoś jest wystarczająco zmotywowany i ma poważne pieniądze do wypalenia, jestem pewien, że ochrony zapewniane przez HASP można obejść.

Najlepsze sztuczki przeciw deasemblerowi, szczególnie w zestawach instrukcji o zmiennej długości słów, znajdują się w asemblerze / kodzie maszynowym, a nie w C. Na przykład

CLC
BCC over
.byte 0x09
over:

Deasembler musi rozwiązać problem polegający na tym, że miejsce docelowe gałęzi jest drugim bajtem w instrukcji wielobajtowej. Symulator zestawu instrukcji nie będzie jednak miał problemu. Rozgałęzienie do obliczonych adresów, które możesz spowodować z C, również utrudnia lub uniemożliwia demontaż. Symulator zestawu instrukcji nie będzie miał z tym problemu. Użycie symulatora do ustalenia miejsc docelowych oddziałów może pomóc w procesie demontażu. Skompilowany kod jest stosunkowo czysty i łatwy dla deasemblera. Myślę więc, że wymagany jest montaż.

Myślę, że to było blisko początku Zen of asemblera Michaela Abrasha, w którym pokazał prostą sztuczkę przeciw deasemblerowi i debuggerowi. 8088/6 miał kolejkę pobierania wstępnego. To, co zrobiłeś, miało instrukcję, która zmodyfikowała następną instrukcję lub parę z przodu. Jeśli wykonałeś jednoetapowo, wykonałeś zmodyfikowaną instrukcję, a jeśli twój zestaw instrukcji nie symulował całkowicie sprzętu, wykonałeś zmodyfikowaną instrukcję. Na prawdziwym sprzęcie działającym normalnie prawdziwa instrukcja byłaby już w kolejce, a zmodyfikowana lokalizacja pamięci nie spowodowałaby żadnych szkód, o ile nie wykonałeś ponownie tego ciągu instrukcji. Prawdopodobnie nadal możesz użyć takiej sztuczki dzisiaj, ponieważ procesory potokowe pobierają następną instrukcję. Lub jeśli wiesz, że sprzęt ma osobną pamięć podręczną instrukcji i danych, możesz zmodyfikować liczbę bajtów z wyprzedzeniem, jeśli odpowiednio wyrównasz ten kod w wierszu pamięci podręcznej, zmodyfikowany bajt nie zostanie zapisany w pamięci podręcznej instrukcji, ale w pamięci podręcznej danych i symulator zestawu instrukcji, który nie miał odpowiednich symulatorów pamięci podręcznej, nie wykonałby się poprawnie. Myślę, że rozwiązania oparte wyłącznie na oprogramowaniu nie zaprowadzą cię daleko.

Powyższe są stare i dobrze znane, nie wiem wystarczająco dużo o aktualnych narzędziach, aby wiedzieć, czy już działają wokół takich rzeczy. Kod samodmodyfikujący może / uruchomi debugger, ale człowiek może / zawęzi problem, a następnie zobaczy kod samodmodyfikujący i obejdzie go.

Kiedyś hakerzy potrzebowali około 18 miesięcy, aby coś wymyślić, na przykład DVD. Teraz wynoszą średnio od 2 dni do 2 tygodni (jeśli są zmotywowani) (Blue Ray, iPhone'y itp.). To dla mnie znaczy, że jeśli spędzę więcej niż kilka dni na bezpieczeństwie, prawdopodobnie marnuję czas. Jedynym prawdziwym zabezpieczeniem, które uzyskasz, jest sprzęt (na przykład instrukcje są szyfrowane, a tylko rdzeń procesora wewnątrz mikroukładu odszyfrowuje tuż przed wykonaniem, w sposób uniemożliwiający ujawnienie odszyfrowanych instrukcji). To może kupić ci miesiące zamiast dni.

Przeczytaj także książkę Kevina Mitnicka The Art of Deception. Taka osoba może odebrać telefon i poprosić Ciebie lub współpracownika o przekazanie tajemnic systemowi, myśląc, że jest to menedżer lub inny współpracownik lub inżynier sprzętu w innej części firmy. I twoje bezpieczeństwo jest wysadzone w powietrze. Bezpieczeństwo to nie tylko zarządzanie technologią, ale także zarządzanie ludźmi.

Weźmy na przykład algorytm AES . Jest to bardzo, bardzo publiczny algorytm i jest BARDZO bezpieczny. Czemu? Dwa powody: zostało sprawdzone przez wielu inteligentnych ludzi, a „tajna” część nie jest samym algorytmem - tajna część jest kluczem, który jest jednym z danych wejściowych do algorytmu. Jest to znacznie lepsze podejście do projektowania protokołu z wygenerowanym „sekretem”, który znajduje się poza twoim kodem, niż do tworzenia samego kodu tajnego. Kod zawsze może być interpretowany bez względu na to, co robisz, a (najlepiej) wygenerowany sekret może zostać zagrożony tylko przez masywne podejście z użyciem siły lub kradzież.

Myślę, że interesujące pytanie brzmi: „ Dlaczego chcesz zaciemnić swój kod?” Chcesz utrudnić atakującym złamanie algorytmów? Czy może im być trudniej znaleźć błędy, które można wykorzystać w kodzie? Nie musisz zaciemniać kodu, jeśli kod byłby niemożliwy do odczytania. Źródłem problemu jest oprogramowanie do krakowania. Napraw źródło problemu, nie tylko zaciemniaj go.

Ponadto, im bardziej wprowadzasz zamieszanie w kodzie, tym trudniej będzie Ci znaleźć błędy bezpieczeństwa. Tak, będzie to trudne dla hakerów, ale musisz też znaleźć błędy. Kod powinien być łatwy do utrzymania za lata, a nawet dobrze napisany, przejrzysty kod może być trudny do utrzymania. Nie pogarszaj tego.

Utrudnianie inżynierii wstecznej kodu nazywa się zaciemnianiem kodu.

Większość wspomnianych technik jest dość łatwa do obejścia. Koncentrują się na dodaniu niepotrzebnego kodu. Ale bezużyteczny kod można łatwo wykryć i usunąć, pozostawiając czysty program.

W celu skutecznego zaciemnienia należy uzależnić zachowanie programu od wykonywanych bezużytecznych bitów. Na przykład zamiast robić to:

a = useless_computation();
a = 42;

Zrób to:

a = complicated_computation_that_uses_many_inputs_but_always_returns_42();

Lub zamiast tego:

if (running_under_a_debugger()) abort();
a = 42;

Wykonaj tę running_under_a_debuggerczynność (gdzie nie powinna być łatwo identyfikowalna jako funkcja testująca, czy kod działa pod debuggerem - powinna łączyć użyteczne obliczenia z wykrywaniem debuggera):

a = 42 - running_under_a_debugger();

Skuteczne zaciemnianie nie jest czymś, co można zrobić wyłącznie na etapie kompilacji. Cokolwiek kompilator może zrobić, dekompilator może to zrobić. Jasne, możesz zwiększyć obciążenie dekompilatorów, ale nie zajdzie to daleko. Skuteczne techniki zaciemniania, o ile istnieją, polegają na pisaniu zaciemnionego źródła od 1. dnia. Zmodyfikuj kod. Zaśmieć swój kod obliczonymi skokami, pochodzącymi z dużej liczby danych wejściowych. Na przykład zamiast zwykłego połączenia

some_function();

zrób to, jeśli znasz dokładny oczekiwany układ bitów w some_data_structure:

goto (md5sum(&some_data_structure, 42) & 0xffffffff) + MAGIC_CONSTANT;

Jeśli poważnie myślisz o zaciemnianiu, dodaj kilka miesięcy do swojego planowania; zaciemnianie nie jest tanie. I uważaj, że zdecydowanie najlepszym sposobem na uniknięcie ponownej inżynierii kodu jest uczynienie go bezużytecznym, aby nie zawracał sobie głowy. Jest to prosta uwaga ekonomiczna: dokonają inżynierii odwrotnej, jeśli ich wartość jest wyższa niż koszt; ale podniesienie ich kosztu również znacznie podnosi koszt, więc spróbuj obniżyć ich wartość.

Teraz, gdy powiedziałem ci, że zaciemnianie jest trudne i kosztowne, powiem ci, że i tak nie jest dla ciebie . Ty piszesz

Obecny protokół, nad którym pracuję, nie może być nigdy sprawdzany ani zrozumiały dla bezpieczeństwa różnych osób

To podnosi czerwoną flagę. Jest to bezpieczeństwo przez zaciemnienie , które ma bardzo słabą historię. Jeśli bezpieczeństwo protokołu zależy od osób, które go nie znają, już go straciłeś .

Rekomendowane lektury:

• Biblia bezpieczeństwa: Inżynieria bezpieczeństwa Rossa Andersona
• Biblia zaciemniająca: ukradkowe oprogramowanie Christian Collberg i Jasvir Nagra

Wiele razy strach przed inżynierią wsteczną produktu jest niewłaściwy. Tak, może zostać poddany inżynierii wstecznej; ale stanie się tak sławny w krótkim czasie, że hakerzy uznają, że warto go odwrócić. to ? (ta praca nie jest niewielką czynnością czasową dla znacznych linii kodu).

Jeśli naprawdę zarabia, powinieneś zebrać wystarczającą ilość pieniędzy, aby je chronić, korzystając z legalnych sposobów, takich jak patent, prawa autorskie .

IMHO, podejmij podstawowe środki ostrożności, które zamierzasz podjąć i zwolnij je. Jeśli stanie się to punktem inżynierii odwrotnej, co oznacza, że ​​wykonałeś naprawdę dobrą robotę, sam znajdziesz lepsze sposoby na pokonanie tego. Powodzenia.

Przeczytaj http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_against . Jestem pewien, że inni mogliby prawdopodobnie podać lepsze źródła, dlaczego bezpieczeństwo przez zaciemnienie jest złe.

Korzystanie z nowoczesnych technik kryptograficznych powinno być całkowicie możliwe, aby twój system był otwarty (nie mówię, że powinien być otwarty, tylko tak, że mógłby być), i nadal mieć całkowite bezpieczeństwo, dopóki algorytm kryptograficzny nie masz w nim dziurę (mało prawdopodobne, jeśli wybierzesz dobry), twoje prywatne klucze / hasła pozostaną prywatne i nie masz dziur w zabezpieczeniach w kodzie (o to powinieneś się martwić).

Od lipca 2013 r. Ponownie pojawiło się zainteresowanie kryptograficznie solidnym zaciemnianiem (w postaci niezróżnialności zaciemniania ), które wydaje się być inspirowane oryginalnymi badaniami Amit Sahai .

• Sahai, Garg, Gentry, Halevi, Raykova, Waters, Candidate Nierozróżnialność zaciemnianie i szyfrowanie funkcjonalne dla wszystkich obwodów (21 lipca 2013 r.).
• Sahai, Wody, Jak korzystać z nierozróżnialności Obfuscation: Deniable Encryption i więcej .
• Sahai, Barak, Garg, Kalai, Paneth, Ochrona zaciemniania przed atakami algebraicznymi (4 lutego 2014 r.).

Niektóre destylowane informacje można znaleźć w tym artykule Quanta Magazine oraz w artykule IEEE Spectrum .

Obecnie ilość zasobów potrzebnych do wykorzystania tej techniki czyni ją niepraktyczną, ale AFAICT konsensus jest raczej optymistyczny co do przyszłości.

Mówię to bardzo od niechcenia, ale każdemu, kto instynktownie odrzuca technologię zaciemniania - jest inaczej. Jeśli okaże się, że naprawdę działa i jest praktyczny, jest to naprawdę ważne, a nie tylko zaciemnianie.

Aby się dowiedzieć, przeczytaj literaturę akademicką na temat zaciemniania kodu . Christian Collberg z University of Arizona jest renomowanym uczonym w tej dziedzinie; Salil Vadhan z Harvard University również wykonał kawał dobrej roboty.

Mam zaległości w tej literaturze, ale podstawową ideą, o której wiem, jest to, że nie możesz uniemożliwić atakującemu zobaczenia kodu, który wykonasz, ale możesz otoczyć go kodem, który nie jest wykonywany, i kosztuje wykładniczy czas atakującego (przy użyciu najbardziej znanych technik) na wykrycie, które fragmenty kodu są wykonywane, a które nie.

Istnieje niedawny artykuł zatytułowany „ zaciemnianie programu i programy jednorazowe ”. Jeśli naprawdę poważnie podchodzisz do ochrony swojej aplikacji. Artykuł ogólnie omawia teoretyczne wyniki niemożliwości przy użyciu prostego i uniwersalnego sprzętu.

Jeśli nie możesz sobie pozwolić na dodatkowy sprzęt, to jest też inny papier, który daje teoretycznie najlepsze możliwe zaciemnienie „ O najlepszym możliwym zaciemnieniu ”, spośród wszystkich programów o tej samej funkcjonalności i tym samym rozmiarze. Jednak artykuł pokazuje, że najlepiej teoretyczna informacja implikuje załamanie hierarchii wielomianowej.

Artykuły te powinny przynajmniej dać ci wystarczającą liczbę wskazówek bibliograficznych, aby przejść do pokrewnej literatury, jeśli wyniki te nie działają na twoje potrzeby.

Aktualizacja: Nowe pojęcie zaciemnienia, zwane zaciemnianiem nierozróżnialnym, może złagodzić wynik niemożliwości (artykuł)

Jeśli ktoś chce poświęcić czas na odwrócenie pliku binarnego, nie ma absolutnie nic, co można zrobić, aby go zatrzymać. Możesz sprawić, że umiarkowanie trudniejsze, ale o to chodzi. Jeśli naprawdę chcesz się o tym dowiedzieć, pobierz kopię http://www.hex-rays.com/idapro/ i zdemontuj kilka plików binarnych.

Fakt, że procesor musi wykonać kod, jest twoją zgubą. CPU wykonuje tylko kod maszynowy ... a programiści mogą odczytać kod maszynowy.

Biorąc to pod uwagę ... prawdopodobnie masz inny problem, który można rozwiązać w inny sposób. Co próbujesz chronić? W zależności od problemu możesz użyć szyfrowania, aby chronić swój produkt.

Aby móc wybrać właściwą opcję, należy pomyśleć o następujących aspektach:

1. Czy prawdopodobne jest, że „nowi użytkownicy” nie chcą płacić, ale korzystają z Twojego oprogramowania?
2. Czy prawdopodobne jest, że obecni klienci potrzebują więcej licencji niż oni?
3. Ile potencjalni użytkownicy są skłonni zapłacić?
4. Czy chcesz udzielać licencji na użytkownika / współbieżnych użytkowników / stację roboczą / firmę?
5. Czy Twoje oprogramowanie wymaga szkolenia / dostosowania, aby było przydatne?

Jeśli odpowiedź na pytanie 5 brzmi „tak”, nie martw się o nielegalne kopie. I tak by się nie przydały.

Jeśli odpowiedź na pytanie 1 brzmi „tak”, najpierw pomyśl o cenach (patrz pytanie 3).

Jeśli odpowiesz na pytania 2 „tak”, model „pay per use” może być dla Ciebie odpowiedni.

Z mojego doświadczenia wynika, że ​​płatność za użycie + dostosowanie i szkolenie to najlepsza ochrona Twojego oprogramowania, ponieważ:

• Nowych użytkowników przyciąga model wyceny (niewielkie wykorzystanie -> niewielkie wynagrodzenie)
• Prawie nie ma „anonimowych użytkowników”, ponieważ potrzebują szkolenia i dostosowywania.
• Brak ograniczeń oprogramowania odstrasza potencjalnych klientów.
• Istnieje ciągły strumień pieniędzy od obecnych klientów.
• Otrzymujesz cenne informacje zwrotne od swoich klientów ze względu na długoterminowe relacje biznesowe.

Zanim pomyślisz o wprowadzeniu DRM lub zaciemnieniu, możesz pomyśleć o tych punktach i czy dotyczą one Twojego oprogramowania.

Zabezpieczony kod na maszynie wirtualnej wydawał się początkowo niemożliwy do odtworzenia. Themida Packer

Ale nie jest już tak bezpieczne. I bez względu na to, jak spakujesz kod, zawsze możesz zrobić zrzut pamięci dowolnego załadowanego pliku wykonywalnego i zdemontować go za pomocą dowolnego dezasemblera, takiego jak IDA Pro.

IDA Pro zawiera także sprytny kod asemblera do transformatora kodu źródłowego C, chociaż wygenerowany kod będzie bardziej przypominał matematyczny bałagan po wskaźniku / adresie .. jeśli porównasz go z oryginałem, możesz naprawić wszystkie błędy i wyrwać wszystko.

Żadnych kości, nie możesz chronić swojego kodu przed dezasemblacją. Co możesz zrobić, to skonfigurować serwer dla logiki biznesowej i użyć usługi sieciowej, aby zapewnić go dla swojej aplikacji. Oczywiście ten scenariusz nie zawsze jest możliwy.

Aby uniknąć inżynierii wstecznej, nie wolno przekazywać kodu użytkownikom. To powiedziawszy, polecam korzystanie z aplikacji online ... jednak (ponieważ nie podałeś kontekstu), która może być bezcelowa dla ciebie.

Być może twoją najlepszą alternatywą jest nadal wirtualizacja, która wprowadza kolejny poziom pośredni / zaciemnienia potrzebny do ominięcia, ale jak powiedział SSpoke w swojej odpowiedzi , ta technika również nie jest w 100% bezpieczna.

Chodzi o to, że nie uzyskasz najwyższej ochrony, ponieważ nie ma czegoś takiego, a jeśli kiedykolwiek będzie, to nie potrwa długo, co oznacza, że ​​nie była to ostateczna ochrona.

Cokolwiek zgromadzą ludzie, można je zdemontować.

Zwykle prawdą jest, że (właściwy) demontaż jest często (nieco lub więcej) trudniejszym zadaniem, więc twój przeciwnik musi być bardziej wykwalifikowany , ale możesz założyć, że zawsze jest ktoś takiej jakości i jest to bezpieczny zakład.

Jeśli chcesz chronić coś przed RE, musisz znać przynajmniej popularne techniki stosowane przez RE.

Tak więc słowa

Internet nie jest tak naprawdę zasobny w zapobieganie inżynierii odwrotnej, ale przedstawia mnóstwo informacji na temat inżynierii wstecznej

okaż swoje złe nastawienie. Nie mówię, że aby używać lub osadzać ochronę, musisz wiedzieć, jak ją złamać, ale aby mądrze z niej korzystać, powinieneś znać jej słabości i pułapki. Powinieneś to zrozumieć .

(Istnieją przykłady oprogramowania wykorzystującego ochronę w niewłaściwy sposób, przez co taka ochrona praktycznie nie istnieje. Aby uniknąć niejasnego mówienia, dam ci przykład krótko opisany w Internecie: Oxford English Dictionary Second Edition na CD-ROM v4. Możesz przeczytać o nieudane użycie SecuROM na następującej stronie: Oxford English Dictionary (OED) na płycie CD-ROM w 16-, 32- lub 64-bitowym środowisku Windows: instalacja na dysku twardym, błędy, makra edytorów tekstu, sieci, czcionki i itd. )

Wszystko wymaga czasu.

Jeśli jesteś nowy w tym temacie i nie masz miesięcy, a raczej lat, aby właściwie zająć się materiałami RE, skorzystaj z dostępnych rozwiązań innych. Problem tutaj jest oczywisty, już tam są, więc już wiesz, że nie są w 100% bezpieczne, ale stworzenie własnej nowej ochrony dałoby ci tylko fałszywe poczucie ochrony, chyba że naprawdę dobrze znasz stan techniki inżynieria wsteczna i ochrona (ale ty nie, przynajmniej w tym momencie).

Celem ochrony oprogramowania jest odstraszanie nowicjuszy, zatrzymywanie typowych RE i wywoływanie uśmiechu na twarzy wytrawnego RE po jej / jego (miejmy nadzieję interesującej) podróży do centrum Twojej aplikacji.

W rozmowach biznesowych można powiedzieć, że w największym możliwym stopniu chodzi o opóźnianie konkurencji.

(Spójrz na ładną prezentację Silver Needle w Skype autorstwa Philippe'a Biondiego i Fabrice Desclaux na Black Hat 2006).

Zdajesz sobie sprawę, że istnieje wiele rzeczy na temat RE, więc zacznij go czytać. :)

Powiedziałem o wirtualizacji, więc dam ci link do jednego przykładowego wątku z EXETOOLS FORUM : Najlepszy program do ochrony: Themida czy Enigma Protector? . Może ci to nieco pomóc w dalszych poszukiwaniach.

Nie sądzę, że żadnego kodu nie da się zhakować, ale nagrody muszą być świetne, aby ktoś chciał go wypróbować.

Powiedziawszy, że powinieneś zrobić takie rzeczy, jak:

• Użyj najwyższego możliwego poziomu optymalizacji (inżynieria odwrotna to nie tylko uzyskanie sekwencji asemblacji, ale także zrozumienie kodu i przeniesienie go do języka wyższego poziomu, takiego jak C). Wysoce zoptymalizowany kod może być b --- h do naśladowania.
• Zagęszczaj struktury, nie posiadając większych typów danych niż to konieczne. Zmień układ elementów między oficjalnymi wydaniami kodu. Zmienione pola bitów w strukturach są również czymś, czego możesz użyć.
• Możesz sprawdzić obecność pewnych wartości, których nie należy zmieniać (przykładem jest informacja o prawach autorskich). Jeśli wektor bajtów zawiera „vwxyz”, możesz mieć inny wektor bajtów zawierający „abcde” i porównać różnice. Funkcja, która to robi, nie powinna przekazywać wskaźników do wektorów, ale używać wskaźników zewnętrznych zdefiniowanych w innych modułach jako (kod pseudo-C) „char * p1 = & string1 [539];” i „char p2 = & string2 [-11731];”. W ten sposób nie będzie żadnych wskaźników wskazujących dokładnie na dwa ciągi. W kodzie porównawczym porównujesz następnie dla „ (p1-539 + i) - * (p2 + 11731 + i) == pewna wartość”. Cracker będzie myślał, że zmiana łańcucha znaków jest bezpieczna, ponieważ nikt się do niego nie odwołuje. Zakop test w nieoczekiwanym miejscu.

Spróbuj samodzielnie zhakować kod asemblera, aby zobaczyć, co jest łatwe, a co trudne. Powinny wyskoczyć pomysły, z którymi możesz eksperymentować, aby utrudnić kod inżynierii wstecznej i utrudnić debugowanie.

Jak wielu już powiedziało: na zwykłym procesorze nie możesz ich powstrzymać, możesz je po prostu opóźnić. Jak powiedział mi mój stary nauczyciel kryptografii: Nie potrzebujesz doskonałego szyfrowania, złamanie kodu musi być po prostu droższe niż zysk. To samo dotyczy zaciemnienia.

Ale 3 dodatkowe uwagi:

1. Możliwe jest uniemożliwienie inżynierii odwrotnej, ALE (a to jest bardzo, ale bardzo duże), nie można tego zrobić na konwencjonalnym procesorze. Dużo pracowałem również nad sprzętem i często wykorzystywane są układy FPGA. Np. Virtex 5 FX ma na sobie procesor PowerPC i możesz użyć APU do implementacji własnych kodów procesora w swoim sprzęcie. Możesz użyć tego narzędzia, aby naprawdę odszyfrować polecenia PowerPC, które nie są dostępne przez oprogramowanie zewnętrzne lub inne, a nawet wykonać polecenie w sprzęcie. Ponieważ FPGA ma wbudowane szyfrowanie AES dla swojego strumienia bitów konfiguracji, nie można go poddać inżynierii wstecznej (z wyjątkiem tego, że komuś uda się przerwać AES, ale sądzę, że mamy inne problemy ...). W ten sposób dostawcy sprzętu IP chronią również swoją pracę.

2. Mówisz z protokołu. Nie mówisz, jaki to protokół, ale kiedy jest to protokół sieciowy, powinieneś przynajmniej chronić go przed wąchaniem sieci. Można to zrobić za pomocą szyfrowania. Ale jeśli chcesz zabezpieczyć szyfrowanie / deszyfrowanie przed właścicielem oprogramowania, wrócisz do zaciemniania.

3. Spraw, aby twój program był niemożliwy do uruchomienia / uruchomienia. Spróbuj użyć pewnego rodzaju detekcji debugowania i zastosuj ją np. W jakiejś formule lub dodając zawartość rejestru debugowania do magicznej stałej. Znacznie trudniej jest, jeśli Twój program wygląda w trybie debugowania, jeśli działa normalnie, ale wykonuje całkowicie niepoprawne obliczenia, operacje lub inne. Np. Znam niektóre gry ekologiczne, które miały naprawdę paskudną ochronę przed kopiowaniem (wiem, że nie chcesz ochrony przed kopiowaniem, ale jest podobnie): Skradziona wersja zmieniła wydobyte zasoby po 30 minutach gry i nagle masz tylko jedną ratunek. Pirat właśnie go złamał (tj. Poddał go inżynierii wstecznej) - sprawdził, czy działa, a Volia go zwolniła. Takie niewielkie zmiany zachowań są bardzo trudne do wykrycia, szczególnie. jeśli nie pojawiają się natychmiast po wykryciu, a jedynie z opóźnieniem.

Na koniec zasugerowałbym: oszacuj, jaki jest zysk ludzi z inżynierii wstecznej twojego oprogramowania, przetłumacz to na pewien czas (np. Używając najtańszej pensji indyjskiej) i spraw, aby inżynieria odwrotna była tak kosztowna, że ​​jest większa.

W przeciwieństwie do tego, co większość ludzi mówi, opierając się na intuicji i osobistym doświadczeniu, nie sądzę, aby kryptograficznie bezpieczne zaciemnianie programu okazało się w ogóle niemożliwe.

To jest jeden przykład doskonale zaciemnionego oświadczenia programu, aby pokazać mój punkt widzenia:

printf("1677741794\n");

Nigdy nie można zgadywać, że tak naprawdę to robi

printf("%d\n", 0xBAADF00D ^ 0xDEADBEEF);

Istnieje ciekawy artykuł na ten temat, który dowodzi pewnych niemożliwości. Nazywa się to „W przypadku (Im) możliwości zaciemniania programów” .

Mimo że dokument dowodzi, że zaciemnienie czyniące program nierozróżnialnym od realizowanej przez niego funkcji jest niemożliwe, zaciemnienie zdefiniowane w nieco słabszy sposób może być nadal możliwe!

Bezpieczeństwo wynikające z niejasności nie działa, co wykazali ludzie znacznie sprytniejsi niż my oboje. Jeśli musisz chronić protokół komunikacyjny swoich klientów, jesteś moralnie zobowiązany do korzystania z najlepszego kodu, który jest otwarty i w pełni sprawdzony przez ekspertów.

Dotyczy to sytuacji, w których ludzie mogą sprawdzić kod. Jeśli twoja aplikacja ma działać na wbudowanym mikroprocesorze, możesz wybrać taki, który ma funkcję pieczętowania, co uniemożliwia sprawdzenie kodu lub obserwowanie ponad trywialnych parametrów, takich jak bieżące użycie podczas jego działania. (Jest to, z wyjątkiem technik inwazji sprzętowej, gdy ostrożnie demontujesz układ i używasz zaawansowanego sprzętu do kontroli prądów na poszczególnych tranzystorach.)

Jestem autorem asemblera inżynierii odwrotnej dla x86. Jeśli jesteś gotowy na zimną niespodziankę, wyślij mi wynik swoich najlepszych starań. (Skontaktuj się ze mną przez moje strony internetowe.) Niewiele widziałem w odpowiedziach, które stanowiłyby dla mnie znaczącą przeszkodę. Jeśli chcesz zobaczyć, jak działa wyrafinowany kod inżynierii wstecznej, powinieneś naprawdę przestudiować strony internetowe z wyzwaniami inżynierii odwrotnej.

Twoje pytanie może zawierać pewne wyjaśnienia. Jak spodziewasz się zachować protokół w tajemnicy, jeśli kod komputera nadaje się do inżynierii wstecznej? Jeśli moim protokołem byłoby wysłanie zaszyfrowanej wiadomości RSA (nawet klucza publicznego), co zyskasz, utrzymując protokół w tajemnicy? Dla wszystkich praktycznych celów inspektor miałby do czynienia z sekwencją losowych bitów.

Groetjes Albert

Tradycyjne techniki inżynierii wstecznej zależą od umiejętności inteligentnego agenta używającego dezasemblera do odpowiedzi na pytania dotyczące kodu. Jeśli chcesz silnego bezpieczeństwa, musisz zrobić rzeczy, które w sposób pewny uniemożliwiają agentowi uzyskanie takich odpowiedzi.

Możesz to zrobić, opierając się na programie zatrzymania („czy program X się zatrzymuje?”), Którego na ogół nie można rozwiązać. Dodanie programów trudnych do uzasadnienia powoduje, że program jest trudny do uzasadnienia. Łatwiej jest budować takie programy niż je rozrywać. Możesz także dodać kod do programu, który ma różne stopnie trudności w uzasadnieniu; doskonałym kandydatem jest program rozumowania aliasów („wskaźników”).

Collberg i wsp. Mają artykuł („Produkcja tanie, odporne i ukrywalne nieprzezroczyste konstrukcje”), który omawia te tematy i definiuje różne „nieprzejrzyste” predykaty, które mogą bardzo utrudnić rozumowanie kodu:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.1946&rep=rep1&type=pdf

Nie widziałem specyficznych metod Collberga stosowanych w kodzie produkcyjnym, szczególnie nie kodu źródłowego C lub C ++.

Obfuscator Java DashO wydaje się wykorzystywać podobne pomysły. http://www.cs.arizona.edu/~collberg/Teaching/620/2008/Assignments/tools/DashO/

PIERWSZA RZECZ, KTÓRA PAMIĘTAĆ O UKRYWANIU KODU : Nie cały kod musi być ukryty.

CEL KOŃCOWY : Moim ostatecznym celem w przypadku większości programów jest możliwość sprzedaży różnych licencji, które włączają i wyłączają określone funkcje w moich programach.

NAJLEPSZA TECHNIKA : Uważam, że budowanie w systemie haków i filtrów, takich jak WordPress, jest absolutnie najlepszą metodą, gdy próbujesz zmylić przeciwników. Umożliwia to szyfrowanie niektórych powiązań wyzwalaczy bez faktycznego szyfrowania kodu.

Powodem tego jest to, że będziesz chciał zaszyfrować możliwie najmniejszą ilość kodu.

POZNAJ SWOICH ŁAMACZY : Wiedz o tym: Głównym powodem złamania kodu nie jest złośliwa dystrybucja licencji, to w rzeczywistości POTRZEBUJE zmiany kodu i tak naprawdę NIE POTRZEBUJE rozpowszechniać bezpłatnych kopii.

ROZPOCZĘCIE PRACY : Odłóż na bok niewielką ilość kodu, który zamierzasz zaszyfrować, reszta kodu powinna zostać wciśnięta w JEDEN plik, aby zwiększyć złożoność i zrozumienie.

PRZYGOTOWANIE DO SZYFROWANIA : Będziesz szyfrował warstwy w moim systemie, będzie to również bardzo złożona procedura, więc zbuduj inny program, który będzie odpowiedzialny za proces szyfrowania.

KROK PIERWSZY : zaciemnij za pomocą nazw base64 do wszystkiego. Po zakończeniu, base64 zaciemniony kod i zapisz go w pliku tymczasowym, który później zostanie użyty do odszyfrowania i uruchomienia tego kodu. Ma sens?

Powtórzę, ponieważ będziesz to robić raz po raz. Zamierzasz utworzyć ciąg base64 i zapisać go w innym pliku jako zmienną, która zostanie odszyfrowana i renderowana.

KROK DRUGI : Będziesz czytać ten plik tymczasowy jako ciąg i zaciemniać go, a następnie base64 i zapisać w drugim pliku tymczasowym, który będzie używany do odszyfrowania i renderowania dla użytkownika końcowego.

KROK TRZECI : Powtórz krok dwa razy tyle razy, ile chcesz. Kiedy już będziesz działał poprawnie bez odszyfrowywania błędów, będziesz chciał zacząć budować miny przeciwników.

LAND MINE ONE : Będziesz chciał zachować fakt, że otrzymałeś powiadomienie o absolutnej tajemnicy. Zbuduj więc system poczty próbnej krakersowania z ostrzeżeniem bezpieczeństwa dla warstwy 2. Zostanie on uruchomiony, informując cię o szczegółach dotyczących przeciwnika, jeśli coś pójdzie nie tak.

LAND MINE TWO : Zależności. Nie chcesz, aby Twój przeciwnik mógł uruchomić warstwę pierwszą, bez warstwy 3, 4 lub 5, ani nawet programu, dla którego został zaprojektowany. Upewnij się więc, że w warstwie pierwszej znajduje się jakiś skrypt zabijania, który uaktywni się, jeśli program nie będzie obecny, lub pozostałe warstwy.

Jestem pewien, że możesz wymyślić własne miny, baw się dobrze.

RZECZ PAMIĘTAJ : Możesz faktycznie zaszyfrować swój kod zamiast base64. W ten sposób prosty base64 nie odszyfruje programu.

NAGRODA : Pamiętaj, że może to być symbiotyczny związek między tobą a twoim przeciwnikiem. Zawsze umieszczam komentarz w warstwie pierwszej, komentarz gratuluje crackerowi i daje mu kod promocyjny do użycia, aby otrzymać od ciebie nagrodę pieniężną.

Spraw, aby nagroda pieniężna była znacząca bez żadnych uprzedzeń. Zwykle mówię około 500 USD. Jeśli twój facet jako pierwszy złamie kod, zapłać mu pieniądze i zostań jego przyjacielem. Jeśli jest twoim przyjacielem, nie będzie rozpowszechniał twojego oprogramowania. Zapytaj go, jak to zrobił i jak możesz to poprawić!

POWODZENIA!

Czy ktoś próbował CodeMorth: http://www.sourceformat.com/code-obfuscator.htm ? Lub Themida: http://www.oreans.com/themida_features.php ?

Później wygląda to bardziej obiecująco.