Ochrona pliku wykonywalnego przed inżynierią wsteczną?

210

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?

graphitemaster
źródło
172
„jednak obecny protokół, nad którym pracuję, nie może być nigdy sprawdzany ani zrozumiały dla bezpieczeństwa różnych osób”. -- Powodzenia z tym.
Amber
62
Możesz sprawić, że Twoja aplikacja będzie trudna do odtworzenia. Nie możesz tego uniemożliwić, dopóki ten drugi facet ma znaczną część twoich bitów w swoich rękach. Ostrożnie, aby zagwarantować pełne bezpieczeństwo, zwłaszcza jeśli w grę wchodzi życie - nie możesz tego zrobić.
Michael Petrotta
127
Jeśli Twój komputer może zrozumieć kod, może to zrobić osoba.
Wyścigi lekkości na orbicie
78
Uczyń kod Open Source, a nikt go nie odtworzy.
użytkownik nieznany
28
„Bezpieczeństwo przez zaciemnienie nigdy nie działało”.
bot47

Odpowiedzi:

151

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.

Stephen Canon
źródło
14
Rozumiem to i przeczytałem kilka artykułów na temat bezpieczeństwa Skype'a i zastanawiałem się nad tymi samymi pomysłami, które Skype wypróbował już jako metodę nie zapobiegania, ale raczej ochrony mojego protokołu. Coś, co okazało się wystarczająco godne, biorąc pod uwagę oczywiste okoliczności dotyczące Skype.
graphitemaster,
8
Skype jest właściwie pierwszym przykładem, który przyszedł mi do głowy, więc cieszę się, że już starasz się naśladować ich metody.
Ricket
176

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.

Bursztyn
źródło
113
+1. Przeczytaj o czasach świetności ochrony przed kopiowaniem na Apple II, wciąż eskalującej się wojnie między obfuscatorami i crackerami, szalonych sztuczkach z silnikiem krokowym dyskietki i nieudokumentowanych instrukcjach 6502 i tak dalej ... A potem płacz śpijcie, bo nie zamierzacie wdrożyć niczego, co byłoby tak skomplikowane i ostatecznie wszyscy się załamali.
Nemo
2
łatwiej jest korzystać z symulatora i uzyskać lepszą widoczność niż próbować wykonać inżynierię wizualną lub dezasembler. Jeśli zabezpieczenia nie są wbudowane w sprzęt, którego używasz, myślę, że świat zajmuje średnio od dwóch dni do dwóch tygodni, aby dokonać inżynierii wstecznej i pokonać prawie wszystko, co się pojawi. Jeśli stworzenie i wdrożenie tego zajmuje więcej niż dwa dni, spędziłeś zbyt wiele czasu.
old_timer
5
Jedynym obecnie właściwie działającym DRM jest kombinacja klucza i serwera internetowego sprawdzających, czy tylko jedna instancja klucza jest aktywna w jednym czasie.
Thorbjørn Ravn Andersen
2
@Rotsor: Komputer nie może tego zrozumieć, ponieważ nie byliśmy w stanie zredukować tego rodzaju inteligencji do algorytmu (jeszcze), nie dlatego, że istnieje jakaś bariera fizyczna lub technologiczna. Człowiek może to zrozumieć, ponieważ może zrobić wszystko, co komputer może (choć wolniej), a także rozum .
Adam Robinson
3
W tym momencie ktoś spróbuje przebudować komputer, chyba że jest on dostępny tylko w środowisku, które kontrolujesz.
Amber
41

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ść.

RyanR
źródło
19
Uwaga moderatora: Komentarze pod tą odpowiedzią zostały usunięte z powodu dygresji w antagonistyczny hałas.
Tim Post
2
+1 za doświadczenie, ale chciałbym powtórzyć, że to nie jest idealne. Maya (pakiet 3D) użyła klucza sprzętowego (nie jestem pewien, czy to HASP), co nie powstrzymało piratów zbyt długo. Kiedy jest wola, jest sposób.
Robert Fraser
1
AutoCAD używa podobnego systemu, który był wielokrotnie łamany. HASP i inni podobni utrzymają uczciwych ludzi uczciwych i zapobiegną przypadkowemu piractwu. Jeśli budujesz kolejny produkt o wartości wielu miliardów dolarów, zawsze będziesz miał do czynienia z krakersami. Chodzi o zmniejszenie zysków - ile godzin wysiłku warto złamać ochronę oprogramowania, a nie tylko płacić za to.
RyanR
6
Chcę również włączyć się z perspektywy kogoś, kto używał zabezpieczonego oprogramowania HASP. HASP to królewski ból w tyłek dla użytkownika końcowego . Miałem do czynienia z Dallas iButton i Aladdin HASP, i oba były naprawdę błędne i spowodowały, że oprogramowanie losowo przestało działać, wymagając odłączenia i ponownego połączenia HASP.
Fałszywe imię
4
Warto również zauważyć, że środki bezpieczeństwa HASP niekoniecznie są bardziej bezpieczne niż zaciemnianie kodu - na pewno wymagają innej metodologii, aby je odtworzyć , ale bardzo możliwe jest ich odwrócenie - patrz: flylogic.net/blog/?p=14 flylogic.net/blog/?p=16 flylogic.net/blog/?p=11
Fałszywe imię
22

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.

old_timer
źródło
1
Ponadto nie musisz mieć dostępu do kodu źródłowego (ani nawet zdemontowanego kodu źródłowego), aby znaleźć lukę w zabezpieczeniach. Może to być przypadek lub fakt, że większość dziur wynika z tych samych problemów w kodzie (takich jak przepełnienie bufora).
asmeurer
2
Istnieją duże problemy z kodem do samodzielnej modyfikacji. Większość współczesnych systemów operacyjnych / sprzętowych nie pozwoli ci tego zrobić bez bardzo wysokich uprawnień, mogą wystąpić problemy z pamięcią podręczną, a kod nie jest bezpieczny dla wątków.
Martin James
1
W nowoczesnych procesorach x86 takie sztuczki są często niekorzystne dla wydajności. Używanie tej samej lokalizacji pamięci jako części więcej niż jednej instrukcji prawdopodobnie ma efekt podobny do nieprzewidzianej gałęzi. Kod samomodyfikujący powoduje, że procesor odrzuca wiersze pamięci podręcznej, aby zachować spójność między instrukcją a pamięciami podręcznymi danych (jeśli zmodyfikujesz kod znacznie częściej niż go zmodyfikujesz, nadal może być wygrany).
jilles
2
Wpadłem na to 20 lat temu. Zajęło nam prawie pół godziny, aby dowiedzieć się, co się stało. Niezbyt dobre, jeśli potrzebujesz dłuższej ochrony.
Bo Persson
1
„prawdziwa instrukcja byłaby już w kolejce, a zmodyfikowana lokalizacja pamięci nie spowodowałaby żadnych szkód”, dopóki nie nastąpi przerwanie, opróżniając potok instrukcji i powodując, że nowy kod stanie się widoczny. Teraz twoje zaciemnienie spowodowało błąd dla twoich legalnych użytkowników.
Ben Voigt,
21

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.

Phil
źródło
3
+1 dla zdrowego rozsądku: po co utrudniać sobie życie, skoro można po prostu zaprojektować lepszy system.
Necrolis
1
Jak zawsze mówię, jeśli utrzymujesz wszystko po stronie serwera, jest to bardziej bezpieczne
liamzebedee
20

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:

Gilles „SO- przestań być zły”
źródło
1
@Gilles, to twoje stwierdzenie, które jest bardzo silne, więc ciężar dowodu spoczywa na tobie. Podam jednak prosty przykład: 2+2kompilator może go uprościć 4, ale dekompilator nie może go przywrócić 2+2(a jeśli tak naprawdę był 1+3?).
Rotsor
7
@Rotsor 4i 2+2są obserwacyjnie równoważne, więc są takie same w tym celu, a mianowicie, aby dowiedzieć się, co robi program. Tak, oczywiście dekompilator nie może zrekonstruować kodu źródłowego, ale to nie ma znaczenia. To pytanie dotyczy rekonstrukcji zachowania (tj. Algorytmu, a dokładniej protokołu).
Gilles 'SO - przestań być zły'
1
Nie musisz nic robić, aby zrekonstruować zachowanie. Masz już program! Zwykle potrzebujesz zrozumieć protokół i coś w nim zmienić (np. 2+2Zastąpić 2 na 3 lub zastąpić na +a *).
Rotsor
1
Jeśli uważasz, że wszystkie równoważne behawioralnie programy są takie same, to tak, kompilator nie może nic zrobić, ponieważ wykonuje tylko transformację wcięcia. Dekompilator również jest bezużyteczny, ponieważ ponownie przekształca tożsamość. Jeśli tego nie zrobisz, to 2+2-> 4jest prawidłowym przykładem nieodwracalnej transformacji wykonanej przez kompilator. Czy to sprawia, że ​​zrozumienie jest łatwiejsze, czy trudniejsze, to osobny argument.
Rotsor
2
@Gilles Nie mogę rozszerzyć twojej analogii z jabłkiem, ponieważ nie wyobrażam sobie strukturalnie odmiennego, ale behawioralnie równoważnego jabłka. :)
Rotsor
13

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.

iammilind
źródło
1
Chodzi mi o to, że jest to realna i odpowiednia odpowiedź, ale linia, którą rysujesz między ochroną a zarabianiem kilku milionów dolarów, aby inni mogli chronić twój produkt, jest naprawdę długa.
graphitemaster,
12

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ć).

asmeurer
źródło
2
Zgodziłbym się z tym. Myślę, że możesz mieć problem koncepcyjny lub projektowy. Czy istnieje analog z rozwiązaniem pary kluczy prywatny-publiczny? Nigdy nie ujawniasz klucza prywatnego, pozostaje on u właściciela, którego bezpieczny klient przetwarza go. Czy możesz trzymać bezpieczny kod poza komputerem i przekazywać wyniki tylko użytkownikowi?
Dizzley
8

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 .

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.

tne
źródło
7

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.

Norman Ramsey
źródło
7

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ł)

Mohammad Alaggan
źródło
6

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.

Brian Makin
źródło
6

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.

czarny
źródło
Bardzo dobra rada (i głosowałem za nią), ale tak naprawdę nie odnosi się do tego konkretnego pytania
Mawg mówi o przywróceniu Moniki
5

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.

SSpoke
źródło
5

Ż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.

Łukasz Madon
źródło
8
dobrze powiedziane, jedynym sposobem na uniknięcie dezasemblowania kodu przez ludzi jest całkowity dostęp do niego, co oznacza oferowanie aplikacji wyłącznie jako SAAS, przyjmowanie żądań od zdalnych klientów i przekazywanie przetworzonych danych. Umieść serwer w zamkniętym pokoju w podziemnym bunkrze otoczonym rowem aligatora i zelektryfikowanym drutem o wysokości 5 m, na który wyrzucasz klucz, zanim zakryjesz go wszystkim 10 m zbrojonego betonu, a następnie miej nadzieję, że nie zapomnisz zainstalować ton systemów oprogramowania, aby zapobiec wtargnięciu do sieci.
jwenting
6
Mam nadzieję, że nigdy nie dostanę kontraktu na utrzymanie waszych serwerów
Colin Pickard
5

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.

Azotek galu
źródło
to jest prawdziwe rozwiązanie ... mianowicie umieścić klejnoty koronne na własnym serwerze na własnej maszynie VPS i ujawniać połączenia API na tym serwerze tylko od klienta (przeglądarki lub klienta interfejsu API)
Scott Stensland
5

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.

przemoc
źródło
4

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.

Olof Forshell
źródło
2
twój pierwszy punkt nie ma sensu, zoptymalizowany kod odcina cruft, to ułatwia odwrócenie (mówię z doświadczenia). twój trzeci punkt to także strata czasu, a inżynier odwrotny wart swojej soli wie, jak zrobić punkt przerwania dostępu do pamięci. dlatego prawdopodobnie najlepiej nie projektować systemu samemu, ale nam biblioteki stron trzecich, które jeszcze nie zostały „spękane”, ponieważ może trwać nieco dłużej niż cokolwiek, co może stworzyć „nowicjusz” ...
Necrolis
Ponieważ wydaje się, że nie wiem nic na ten temat, być może powinienem zwrócić się do takiego specjalisty, jak ty, o moje potrzeby w zakresie tworzenia oprogramowania, zamiast pisać kod samodzielnie.
Olof Forshell
4

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.

flolo
źródło
3

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!

Rotsor
źródło
7
1. Twój przykład nie ma tu znaczenia; dwa pokazywane programy są behawioralnie równoważne, a to pytanie dotyczy ustalenia zachowania programu, a nie rekonstrukcji jego kodu źródłowego (co oczywiście jest niemożliwe). 2. Niniejszy artykuł jest referatem teoretycznym; niemożliwe jest napisanie idealnego obfuscatora, ale niemożliwe jest również napisanie idealnego dekompilatora (z tych samych powodów, dla których niemożliwe jest napisanie idealnego analizatora programu). W praktyce jest to wyścig zbrojeń: kto może napisać lepszy (de) obfuscator.
Gilles 'SO - przestań być zły'
1
@Gilles, wynik (poprawnej) deobfuskacji zawsze będzie behawioralnie równoważny zaciemnionemu kodowi. Nie rozumiem, jak podważa to znaczenie problemu.
Rotsor
Także o wyścigu zbrojeń: nie chodzi o to, kto więcej inwestuje w badania, ale o to, kto ma rację. Prawidłowe dowody matematyczne nie popełniają błędu tylko dlatego, że ktoś bardzo chce ich.
Rotsor
1
Okej, może masz rację co do wyścigu zbrojeń w praktyce. Myślę, że źle to zrozumiałem. :) Mam nadzieję, że możliwe jest pewne bezpieczne kryptograficznie zaciemnianie.
Rotsor
W przypadku interesującego przypadku zaciemnienia spróbuj kart inteligentnych, w których problem polega na tym, że osoba atakująca ma fizyczny dostęp (zaciemnianie białej skrzynki). Część odpowiedzi polega na ograniczeniu dostępu środkami fizycznymi (atakujący nie może bezpośrednio odczytać tajnych kluczy); ale zaciemnianie oprogramowania również odgrywa ważną rolę, głównie po to, aby ataki takie jak DPA nie dawały użytecznych rezultatów. Przepraszam, nie mam dobrego odniesienia do oferty. Przykłady w mojej odpowiedzi są niejasno inspirowane technikami stosowanymi w tej dziedzinie.
Gilles „SO- przestań być zły”
3

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

Albert van der Horst
źródło
3

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/

Ira Baxter
źródło
2

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!

Architekt Przedsiębiorczości
źródło
4
Czy w ogóle przeczytałeś pytanie? Nigdy nie prosiłem o metody ochrony przed piractwem. Aplikacja będzie bezpłatna, to podstawowy protokół, który musi być chroniony ze względu na naturę bezpieczeństwa.
graphitemaster