Ochrona pliku wykonywalnego przed inżynierią odwrotną?

Ale wszystkie mogą być obejrzane i lub zorientowane przez analityków kodu, biorąc pod uwagę odpowiednie ramy czasowe.

Jeśli dasz ludziom program, który są w stanie uruchomić, wtedy będą również w stanie go odtworzyć z odpowiednią ilością czasu. Taka jest natura programów. Gdy tylko plik binarny będzie dostępny dla kogoś, kto chce go odszyfrować, nie można zapobiec ewentualnej inżynierii odwrotnej. Wszakże komputer musi być w stanie go rozszyfrować aby go uruchomić, a człowiek jest po prostu wolniejszym komputerem.

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

Zanim wdrożyliśmy ochronę HASP HL, było 7 znanych piratów, którzy usunęli "zabezpieczenia" dotfuscator z produktu. Dodaliśmy ochronę HASP w tym samym czasie, co duża aktualizacja oprogramowania, która wykonuje ciężkie obliczenia na wideo w czasie rzeczywistym. Jak najlepiej mogę stwierdzić z profilowania i benchmarkingu, Ochrona HASP HL tylko spowolniła intensywne obliczenia o około 3%. Od kiedy to oprogramowanie zostało wydane około 5 lat temu, ani jeden nowy znaleziono pirata tego produktu. Oprogramowanie, które chroni, cieszy się dużym popytem w swoim segmencie rynku, a klient jest świadomy, że kilku konkurentów aktywnie próbuje inżynierii wstecznej (jak dotąd bez powodzenia). Wiemy, że próbowali uzyskać pomoc od kilku grup w Rosji, które reklamują usługę przerwania ochrony oprogramowania, ponieważ liczne posty na różnych grupach dyskusyjnych i forach zawierały nowsze wersje chronionego produktu.

Ostatnio wypróbowaliśmy ich oprogramowanie rozwiązanie licencyjne (HASP SL) na mniejszym projekcie, które było wystarczająco proste, aby zacząć działać, jeśli jesteś już zaznajomiony z produktem HL. Wydaje się, że działa; nie odnotowano żadnych incydentów piractwa, ale ten produkt jest o wiele niższy popyt..

Oczywiście żadna Ochrona nie może być doskonała. Jeśli ktoś jest wystarczająco zmotywowany i ma poważne pieniądze do spalenia, jestem pewien, że zabezpieczenia oferowane przez HASP można obejść.

Weźmy na przykład algorytm AES . To bardzo, bardzo publiczny algorytm i jest bardzo bezpieczny. Dlaczego? Dwa powody: został sprawdzony przez wielu inteligentnych ludzi, a" tajna " część nie jest sam algorytm - tajna część jest kluczem, który jest jednym z wejść do algorytmu. Jest to znacznie lepsze podejście do zaprojektowania protokołu z wygenerowanym "sekretem", który znajduje się poza twoim kodem, a nie do uczynienia samego kodu tajnym. Kod można zawsze interpretować bez względu na wszystko tak, a (najlepiej) wygenerowany sekret może być zagrożony tylko przez masowe podejście brute force lub przez kradzież.

Myślę, że ciekawym pytaniem jest " Dlaczego chcesz zaciemnić swój kod?"Chcesz utrudnić atakującym złamanie Twoich algorytmów? Aby utrudnić im znalezienie wykorzystywalnych błędów w Twoim kodzie? Nie musiałbyś zaciemniać kodu, gdyby kod był nie do złamania. Źródłem problemu jest oprogramowanie, które można złamać. Fix the root of twój problem, nie zaciemniaj go.

Ponadto, im bardziej zagmatwany będzie Twój kod, tym trudniej będzie Ci znaleźć błędy bezpieczeństwa. Tak, to będzie trudne dla hakerów, ale trzeba znaleźć błędy też. Kod powinien być łatwy w utrzymaniu przez wiele lat, a nawet dobrze napisany i przejrzysty kod może być trudny do utrzymania. Nie pogarszaj sprawy.

Najlepsze sztuczki anty-disassembler, w szczególności w zestawach instrukcji o zmiennej długości słowa, są w asemblerze / kodzie maszynowym, a nie w C. na przykład

CLC
BCC over
.byte 0x09
over:

Disassembler musi rozwiązać problem, że docelową gałęzią jest drugi bajt w instrukcji wielobajtowej. Symulator zestawu instrukcji nie będzie miał jednak problemu. Rozgałęzianie się na obliczone adresy, które można wywołać z języka C, również utrudnia demontaż. Symulator zestawu instrukcji nie będzie miał problem z tym. Korzystanie z symulatora do sortowania miejsc docelowych gałęzi może pomóc w procesie demontażu. Skompilowany kod jest stosunkowo czysty i łatwy dla disassemblera. Więc myślę, że potrzebny jest montaż.

Myślę, że było to blisko początku języka Zen of Assembly Michaela Abrasha, gdzie pokazał prosty trick anty-disassembler i anty-debugger. 8088/6 miał kolejkę prefetch to co zrobiłeś było instrukcją, która zmodyfikowała następną instrukcję lub parę przed. Jeśli pojedynczy krok następnie wykonałeś zmodyfikowaną instrukcję, jeśli twój symulator zestawu 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 uszkodzeń, o ile nie wykonasz tego ciągu instrukcji ponownie. Prawdopodobnie nadal możesz użyć takiej sztuczki, ponieważ procesory pipelined pobierają następną instrukcję. Lub jeśli wiesz, że sprzęt ma oddzielną instrukcję i pamięć podręczną danych możesz zmodyfikować kilka bajtów przed sobą, jeśli odpowiednio wyrównasz ten kod w linii pamięci podręcznej, zmodyfikowany bajt nie zostanie zapisany przez pamięć podręczną instrukcji, ale pamięć podręczną danych, a symulator zestawu instrukcji, który nie miał odpowiedniej pamięci podręcznej, nie wykonałby poprawnie. Myślę, że rozwiązania tylko dla oprogramowania nie zaprowadzą cię daleko.

Powyższe są stare i dobrze znane, Nie wiem wystarczająco dużo o aktualne narzędzia, aby wiedzieć, czy już działają wokół takich rzeczy. Samoodtwarzający się kod może / może potknąć się o debugger, ale człowiek może / zawęzić problem, a następnie zobaczyć samoodtwarzający się kod i obejść go.

Kiedyś hakerzy zajmowali około 18 miesięcy, aby coś wypracować, na przykład DVD. Teraz są one średnio około 2 dni do 2 tygodni (jeśli motywowane) (blue ray, iPhone, itp). Oznacza to dla mnie, że jeśli spędzę więcej niż kilka dni na ochronie, prawdopodobnie marnuję czas. Jedynym prawdziwym zabezpieczeniem jest sprzęt (na przykład instrukcje są szyfrowane i tylko rdzeń PROCESORA dobrze wewnątrz Chipa odszyfrowuje tuż przed wykonaniem, w sposób, który nie może ujawnić odszyfrowanych instrukcji). To może kupić miesiące zamiast dni.

[[8]} utrudnianie inżynierii wstecznej kodu nazywa się zaciemnieniem kodu.

Większość technik, o których wspomniałeś, jest dość łatwa do obejścia. Skupiają się na dodaniu jakiegoś bezużytecznego kodu. Ale bezużyteczny kod jest łatwy do wykrycia i usunięcia, pozostawiając czysty program.

Aby skutecznie zaciemniać, musisz uzależnić zachowanie programu od wykonywanych bezużytecznych bitów. Na przykład zamiast tego:

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;

Zrób to (gdzie running_under_a_debugger nie powinna być łatwo rozpoznawalna jako funkcja sprawdzająca, czy kod działa pod debuggerem - powinna łączyć przydatne 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ć, dekompiler może zrobić. Pewnie, możesz zwiększyć obciążenie dekompilatorów, ale to nie zajdzie daleko. Skuteczne techniki zaciemniania, o ile istnieją, to od pierwszego dnia należy pisać zaciemnione źródła. Samododaj swój kod. Zaśmiecaj swój kod obliczonymi skokami, pochodzącymi z dużej liczby wejść. Na przykład zamiast prostego wywołania

some_function();

Zrób to, gdy zdarzy ci się znać 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 planowania; zaciemnianie nie jest tanie. I uważam, że zdecydowanie najlepszym sposobem, aby uniknąć ludzi odwrócona Inżynieria kodu ma sprawić, że będzie bezużyteczny, aby nie przeszkadzał. Jest to prosta ekonomiczna kwestia: będą inżynierami odwrotnymi, jeśli wartość dla nich jest większa niż koszt; ale podniesienie ich kosztu znacznie podnosi koszt, więc spróbuj obniżyć wartość dla nich.

Aktualny protokół, nad którym pracowałem musi nigdy nie być sprawdzane lub zrozumiałe, dla bezpieczeństwa różnych ludzi

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

Zalecana lektura:

• Biblia bezpieczeństwa: Inżynieria Bezpieczeństwa Autor: Ross Anderson
• Biblia zaciemnienia: Surreptitious oprogramowanie autor: Christian Collberg i Jasvir Nagra

Wiele razy strach przed odwrotną inżynierią Twojego produktu jest niewłaściwy. Tak, może zostać odwrócony; ale czy stanie się tak sławny w krótkim czasie, że hakerzy uznają, że warto odwrócić engg. to ? (Ta praca nie jest małą aktywnością czasową, dla znacznych linii kodu).

Jeśli naprawdę będzie zarabiać pieniądze, powinieneś zebrać wystarczająco dużo pieniędzy, aby chronić je za pomocą legalnych sposobów, takich jak, patent i / lub prawa autorskie .

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

Zapoznaj się z http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_against. jestem pewien, że inni mogliby również podać lepsze źródła, dlaczego bezpieczeństwo przez ciemność jest złą rzeczą.

Powinno być całkowicie możliwe, przy użyciu nowoczesnych technik kryptograficznych, aby Twój system był otwarty (Nie mówię, że powinien być otwarty, tylko, że może być), i nadal mieć całkowite bezpieczeństwo, tak długo, jak algorytm kryptograficzny nie ma dziury w nim (nie jest prawdopodobne, jeśli wybierz dobry), twoje prywatne klucze/hasła pozostają prywatne i nie masz luk w zabezpieczeniach w kodzie (to jest tym, czym powinieneś się martwić).

Od lipca 2013 r. ponownie pojawia się zainteresowanie kryptograficznie odpornym zaciemnieniem (w formie nie do odróżnienia zaciemnienia), które wydaje się być inspirowane oryginalnymi badaniami z Amit Sahai.

/ Align = "Center" Bgcolor = "# E0ffe0 " / Cesarz Chin / / Align = Center / i funkcjonalne szyfrowanie dla wszystkich obwodów (21 lipca 2013).
• Sahai, Waters, Jak korzystać z: Denyable Szyfrowanie i nie tylko .
W 2014 R., W 2015 R., W 2016 R., W 2017 R., W 2018 R., W 2019 R., W 2019 R., W 2019 R., W 2019 R., W 2019 R., W 2019 R., W 2019 R., W 2019 R.

Możesz znaleźć trochę informacji w tym artykule magazynu Quanta oraz w tym artykule IEEE Spectrum .

Obecnie ilość zasobów potrzebnych do wykorzystania tej techniki sprawia, że jest ona niepraktyczna, ale zgoda jest raczej optymistyczna co do przyszłości.

I say this bardzo przypadkowo, ale dla każdego, kto jest przyzwyczajony do instynktownego odrzucania technologii zaciemniania ... to co innego.Jeśli okaże się, że jest naprawdę skuteczny i praktyczny, jest to naprawdę ważne, i nie tylko dla zaciemnienia.

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

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

That being said... 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 prawdopodobnie użyć szyfrowania, aby chronić swój produkt.

Aby się dowiedzieć, przeczytaj literaturę akademicką na temat code obfuscation . Christian Collberg z University of Arizona jest renomowanym uczonym w tej dziedzinie; Salil Vadhan z Uniwersytetu Harvarda również wykonał dobrą pracę.

Zalegam z tą literaturą, ale zasadniczą ideą, o której wiem, Jest to, że nie możesz uniemożliwić atakującemu zobaczenia kodu, który wykonasz, ale możesz go otoczyć kodem, który jest , a nie wykonywany, a to kosztuje atakującego czas wykładniczy (przy użyciu najbardziej znanych technik), aby odkryć, które fragmenty kodu są wykonywane, a które nie.

Jest ostatnio artykuł o nazwie "program obfuscation i jednorazowe programy ". Jeśli naprawdę poważnie myślisz o ochronie swojej aplikacji. W artykule ogólnie omówiono teoretyczne wyniki niemożności za pomocą prostego i uniwersalnego sprzętu.

Jeśli nie stać Cię na Wymaganie dodatkowego sprzętu, istnieje również inny dokument, który daje teoretycznie najlepszą możliwą zaciemnienie " On best-possible zaciemnienie ", wśród wszystkich programów z tym samym funkcjonalność i ten sam rozmiar. Jednak praca pokazuje, że informacja-teoretyczne najlepsze możliwe implikuje upadek hierarchii wielomianów.

Te prace powinny przynajmniej dać ci wystarczającą ilość wskazówek bibliograficznych do chodzenia w pokrewnej literaturze, jeśli te wyniki nie działają na twoje potrzeby.

Aktualizacja: nowe pojęcie zaciemnienia, zwane nieodróżnialnym zaciemnieniem, może złagodzić wynik niemożliwości (papier)

No dice, nie możesz zabezpieczyć kodu przed demontażem. Możesz skonfigurować serwer dla logiki biznesowej i użyć webservice, aby zapewnić go dla swojej aplikacji. Oczywiście ten scenariusz nie zawsze jest możliwy.

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

1. czy jest prawdopodobne, że "nowi użytkownicy"nie chcą płacić, ale korzystać z oprogramowania?
2. czy jest prawdopodobne, że obecni klienci potrzebują więcej licencji niż mają?
3. Ile potencjalni użytkownicy są skłonni zapłacić?
4. Czy chcesz dać licencje na użytkownika / współbieżnych użytkowników / stację roboczą / firmę?
5. Czy Twoje oprogramowanie wymaga treningu / personalizacji, aby być 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 pytanie 2 "tak", to model "pay per use" może bądź odpowiedni dla Ciebie.

Z mojego doświadczenia wynika, że pay per use + personalizacja i trening to najlepsza ochrona dla Twojego oprogramowania, ponieważ:

• przyciągają nowych użytkowników według modelu cenowego (małe użycie -> małe wynagrodzenie)
• nie ma prawie żadnych "anonimowych użytkowników", ponieważ potrzebują szkolenia i personalizacji.
• żadne ograniczenia oprogramowania nie odstraszają potencjalnych klientów.
• istnieje ciągły strumień pieniędzy od istniejących klientów.
• otrzymujesz cenne informacje zwrotne na temat rozwoju od swoich klientów, ze względu na długoterminowe relacje biznesowe.

Zanim pomyślisz o wprowadzeniu DRM lub zaciemnienia, możesz pomyśleć o tych punktów i jeśli mają one zastosowanie do Oprogramowania użytkownika.

Zabezpieczony kod w maszynie wirtualnej wydawał się początkowo niemożliwy do odwrócenia. Themida Packer

Ale to już nie jest 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 disassemblera, takiego jak IDA Pro.

IDA Pro jest również wyposażony w sprytny kod montażowy do transformatora kodu źródłowego C, chociaż wygenerowany kod będzie wyglądał bardziej jak wskaźnik/adres matematycznego bałaganu.. jeśli porównasz to z oryginałem możesz naprawić wszystkie błędy i wyrwać wszystko.

Być może najlepszą alternatywą jest nadal Korzystanie z wirtualizacji, która wprowadza inny poziom indrection / zaciemnienia potrzebne by bypassed, ale jak sspoke powiedział w jego ODPOWIEDŹ , Ta technika również nie jest w 100% bezpieczny.

Chodzi o to, że nie otrzymasz ostatecznej ochrony, ponieważ nie ma takiej rzeczy, a jeśli kiedykolwiek będzie, to nie potrwa to długo, co oznacza, że nie była to ostateczna ochrona w pierwszej kolejności.

cokolwiek człowiek zbierze, może być zdemontowany.

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

Jeśli chcesz zabezpieczyć coś przed OZE, musisz znać przynajmniej typowe techniki stosowane przez OZE.

Tak więc słowa

Internet nie jest tak naprawdę zaradny w zapobieganiu odwrotnemu Inżynieria, ale raczej przedstawia mnóstwo informacji o tym, jak inżynieria odwrotna

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

(istnieją przykłady oprogramowania używającego ochrony w niewłaściwy sposób, czyniąc taką ochronę praktycznie nieistniejącą. Aby nie mówić niejasno podam przykład krótko opisany w Internecie: Oxford English Dictionary Second Edition on CD-ROM v4. O nieudanym użyciu SecuROM można przeczytać na następującej stronie: Oxford English Dictionary (Oed) na płycie CD-ROM w 16 -, 32-lub 64-bitowym środowisku Windows: instalacja dysku twardego, błędy, makra edytora tekstu, sieci, czcionki itp. )

wszystko wymaga czasu.

Jeśli jesteś nowy w temacie i nie masz miesięcy, a raczej lat, aby odpowiednio się dostać do RE rzeczy, to przejdź z dostępnych rozwiązania stworzone przez innych. Problem tutaj jest oczywisty, są one już tam, więc już wiesz, że nie są w 100% bezpieczne, ale tworzenie własnej nowej ochrony dałoby ci tylko fałszywe poczucie bycia chronionym, chyba że znasz naprawdę dobrze Stan techniki w inżynierii odwrotnej i ochronie(ale nie wiesz, przynajmniej w tej chwili).

celem ochrony oprogramowania jest przestraszenie początkujących, powstrzymanie wspólnego OZE i wywołanie uśmiechu na twarzy doświadczonego RE po jej/jego (miejmy nadzieję ciekawe) podróż do centrum aplikacji.

W rozmowach biznesowych można powiedzieć, że chodzi o opóźnianie konkurencji, tak bardzo, jak to możliwe.

Mówiłem o wirtualizacji, więc podam ci link do jednego przykładowego wątek z forum EXETOOLS: najlepszy software protector: Themida czy Enigma Protector?. To może pomóc ci trochę w dalszych poszukiwaniach.

Nie sądzę, że jakikolwiek kod jest nie do złamania, ale nagrody muszą być świetne dla kogoś, kto chce spróbować.

Powiedziawszy, że są rzeczy, które powinieneś zrobić, takie jak:

• Użyj najwyższego możliwego poziomu optymalizacji(inżynieria odwrotna to nie tylko uzyskanie sekwencji złożenia, 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.
• Utwórz struktury gęste przez nie posiadając większych typów danych niż jest to konieczne. Zmiana struktury pomiędzy oficjalnymi wydaniami kodu. Przestawione pola bitowe w strukturach są również czymś, czego możesz użyć.
• Możesz sprawdzić obecność pewnych wartości, które nie powinny być zmieniane (przykładem jest wiadomość o prawach autorskich). Jeśli wektor bajtowy zawiera "vwxyz", możesz mieć inny wektor bajtowy zawierający "abcde" i porównać różnice. Wykonująca ją funkcja nie powinna być przekazywana do wektorów, lecz używać zewnętrznych wskaźniki zdefiniowane 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 " (P1-539 + i) - *(p2+11731+i)==jakaś wartość". Cracker pomyśli, że zmiana string1 jest bezpieczna, ponieważ nikt nie wydaje się do niej odwoływać. Zakopać test w jakimś nieoczekiwanym miejscu.

Spróbuj zhakować kod montażu, aby zobaczyć, co jest łatwe i co to trudne do zrobienia. Powinny pojawić się pomysły, z którymi możesz eksperymentować, aby utrudnić inżynierię wsteczną kodu i utrudnić jego debugowanie.

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

Ale 3 Dodatkowe uwagi:

1. Jest to możliwe, aby inżynieria odwrotna niemożliwe, ale (a to jest bardzo, bardzo duże ale), nie można tego zrobić na konwencjonalnym procesorze. Zrobiłem też dużo sprzętu rozwoju, a często stosuje się FPGA. Na przykład Virtex 5 FX ma na sobie procesor PowerPC i możesz użyć APU do zaimplementowania własnych kodów OPCODÓW CPU w swoim sprzęcie. Możesz użyć tej funkcji, aby naprawdę odszyfrować incstuctions dla PowerPC, który nie jest dostępny przez zewnętrzne lub inne oprogramowanie, a nawet wykonać polecenie w sprzęcie. Jako, że FPGA ma wbudowane szyfrowanie AES dla swojej konfiguracji bitstream, nie można go odwrócić (chyba, że komuś uda się złamać AES, ale wtedy chyba mamy inne problemy...). W ten sposób dostawcy sprzętu IP również chronią swoją pracę.

2. Mówisz zgodnie z protokołem. Nie mówisz, jaki to jest protokół, ale jeśli jest to protokół sieciowy, powinieneś przynajmniej chronić go przed sniffingiem sieciowym. Można to zrobić za pomocą szyfrowania. Ale jeśli chcesz chronić en / deszyfrowanie przed właścicielem oprogramowania, jesteś z powrotem do zaciemniania.

3. Uczyń swój program niezniszczalnym/niezniszczalnym. Spróbuj użyć jakiegoś wykrycie debugowania i zastosowanie go np. w jakiejś formule dodawania zawartości rejestru debugowania do magicznej stałej. Jest to o wiele trudniejsze, jeśli program wygląda w trybie debugowania jest, jeśli działa normalnie, ale wykonuje kompletne błędne obliczenia, operacja lub inne. Np. znam kilka gier eco, które miały naprawdę paskudną ochronę przed kopiowaniem( wiem, że nie chcesz copyprotection, ale jest podobna): skradziona wersja zmieniła wydobyte zasoby po 30 minutach gry i nagle dostałaś tylko jeden zasób. Pirat po prostu go złamał ( tzn. reverse engineered it) - sprawdzał czy działa, a volia go wypuściła. Takie niewielkie zmiany zachowania są bardzo trudne do wykrycia, esp. jeśli nie pojawiają się natychmiast do wykrycia, ale tylko opóźnione.

Więc w końcu proponuję: Oszacować, jaki jest zysk ludzi reverse engineering swoje oprogramowanie, przetłumaczyć to na jakiś czas (np. za pomocą najtańszego Indyjskiego wynagrodzenia) i zrobić inżynierii odwrotnej tak czas kosztuje, że jest większy.

Aby uniknąć inżynierii odwrotnej, nie wolno podawać kodu użytkownikom. To powiedziawszy, polecam korzystanie z aplikacji online...jednak (skoro nie podałeś kontekstu) to może być bezcelowe na Twoim.

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

Jest to jeden z przykładów doskonale zaciemnionej instrukcji programu, aby zademonstrować mój punkt widzenia:

printf("1677741794\n");

Nigdy nie można się domyślić, że to, co naprawdę robi, jest

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

Jest ciekawy artykuł na ten temat, który dowodzi pewnych rezultatów niemożliwości. Nazywa się " na (Im)możliwość zaciemniania programów".

Chociaż artykuł dowodzi, że zaciemnienie uniemożliwiające odróżnienie programu od funkcji, którą implementuje, jest niemożliwe, zaciemnienie zdefiniowane w jakiś słabszy sposób może być nadal możliwe!

Bezpieczeństwo przez zaciemnienie nie działa, co udowodnili ludzie znacznie mądrzejsi od oboje. Jeśli musisz chronić protokół komunikacyjny swoich klientów, to jesteś moralnie zobowiązany do korzystania z najlepszego kodu, który jest otwarty i w pełni zbadany przez ekspertów.

Jest to sytuacja, w której ludzie mogą sprawdzić kod. Jeśli Twoja aplikacja ma działać na wbudowanym mikroprocesorze, możesz wybrać taki, który ma funkcję uszczelniania, co uniemożliwia sprawdź kod lub obserwuj więcej niż trywialne parametry, takie jak bieżące użycie podczas jego działania. (Jest, z wyjątkiem technik inwazyjnych sprzętowych, gdzie ostrożnie rozmontowujesz 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 przeziębienie niespodzianka, wyślij mi wynik swoich najlepszych starań. (Skontaktuj się ze mną za pośrednictwem moich stron internetowych.) Kilka, które widziałem w odpowiedziach przedstawiłoby znaczną / align = "left" / Jeśli chcesz zobaczyć jak wyrafinowany kod reverse engineering działa, naprawdę powinieneś studiować strony internetowe z wyzwania inżynierii odwrotnej.

Twoje pytanie wymaga wyjaśnienia. Jak można oczekiwać, aby utrzymać protokół w tajemnicy, jeśli kod komputerowy jest podatny na inżynierię odwrotną? Jeśli moim protokołem byłoby wysłanie zaszyfrowanej wiadomości RSA (nawet klucza publicznego) co zyskasz, utrzymując protokół w tajemnicy? Ze wszystkich praktycznych względów inspektor będzie miał do czynienia z sekwencją losowych bitów.

Groetjes Albert

Tradycyjne techniki inżynierii odwrotnej zależą od zdolności inteligentnego agenta używającego disassemblera do odpowiedzi na pytania dotyczące kodu. Jeśli chcesz silnego bezpieczeństwa, musisz zrobić rzeczy, które provably uniemożliwiają agentowi uzyskanie takich odpowiedzi.

Możesz to zrobić, opierając się na programie zatrzymującym ("czy program x zatrzymuje?"), których w ogóle nie można rozwiązać. Dodawanie programów, które są trudne do rozumowania do twojego programu, sprawia, że twój program jest trudny do rozumowania. On łatwiej konstruować takie programy, niż je rozszarpywać. Można również dodać kod do programu o różnym stopniu trudności w rozumowaniu; świetnym kandydatem jest program rozumowania o aliasach ("wskaźnikach").

Collberg et al mają papier ("produkcja Tanie, odporne i ukradkiem nieprzezroczyste konstrukcje"), który omawia te tematy i definiuje różne" nieprzezroczyste " predykaty, które mogą sprawić, że bardzo trudno rozumować o kod:

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, zwłaszcza kodu źródłowego C lub c++.

Dasho Java obfuscator wydaje się używać podobnych pomysłów. http://www.cs.arizona.edu / ~ collberg / Nauczanie/620/2008/zadania / narzędzia / DashO /

Pierwsze co należy pamiętać o ukrywaniu kodu : nie cały kod musi być ukryty.

Cel końcowy: moim celem końcowym dla 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 haczyków i filtrów, takich jak WordPress oferuje, jest absolutną najlepszą metodą, gdy próbuje zmylić przeciwników. Pozwala to na szyfrowanie niektóre wywołują skojarzenia bez rzeczywistego szyfrowania kodu.

Powodem, dla którego to robisz, jest to, że będziesz chciał zaszyfrować jak najmniejszą ilość kodu.

KNOW YOUR CRACKERS : wiedz jedno: głównym powodem łamania kodu nie jest złośliwa Dystrybucja licencji, a w rzeczywistości konieczność zmiany kodu i tak naprawdę nie ma potrzeby rozpowszechniania darmowych kopii.

Pierwsze kroki: odłóż na bok niewielką ilość kodu, który masz zamiar zaszyfrować, reszta kodu powinna spróbować być zapchana do jednego pliku, aby zwiększyć złożoność i zrozumienie.

Przygotowanie do szyfrowania: będziesz szyfrować warstwami z moim systemem, będzie to również bardzo złożona procedura, więc zbuduj kolejny program, który będzie odpowiedzialny za proces szyfrowania.

Krok pierwszy: zaciemnianie za pomocą nazw base64 dla wszystkiego. Po zakończeniu, base64 zasłonięty kod i zapisać go do tymczasowego plik, który zostanie później użyty do odszyfrowania i uruchomienia tego kodu. To ma sens?

Powtórzę, ponieważ będziesz to robić raz za razem. Utworzysz łańcuch base64 i zapiszesz go do innego pliku jako zmienną, która zostanie odszyfrowana i wyrenderowana.

Krok drugi: przeczytasz w tym pliku tymczasowym jako ciąg znaków i zaciemnisz go, a następnie base64 i zapiszesz go w drugim pliku tymczasowym, który zostanie użyty do odszyfrowania i wyrenderowania go dla użytkownika końcowego.

Krok Trzy : Powtórz krok drugi tyle razy, ile chcesz. Gdy już to działa poprawnie bez błędów odszyfrowywania, będziesz chciał zacząć budować miny lądowe dla swoich przeciwników.

Mina lądowa 1: będziesz chciał utrzymać fakt, że zostałeś powiadomiony w absolutnej tajemnicy. Więc zbuduj w cracker próba zabezpieczenia systemu ostrzegania poczty dla warstwy 2. Zostanie to zwolnione, informując Cię o szczegółach dotyczących przeciwnika, jeśli cokolwiek ma się udać źle.

Mina lądowa druga : zależności. Nie chcesz, aby twój przeciwnik mógł uruchomić warstwę pierwszą, bez warstwy 3, 4 lub 5, a nawet rzeczywistego programu, do którego został zaprojektowany. Upewnij się więc, że w pierwszej warstwie umieścisz jakiś skrypt kill, który aktywuje się, jeśli program nie jest obecny, lub inne warstwy.

Jestem pewien, że możesz wymyślić własne miny lądowe, baw się z tym.

THING to REMEMBER: możesz faktycznie zaszyfrować swój kod zamiast base64 ' ING it. W ten sposób prosty base64 nie odszyfruje programu.

REWARD: Pamiętaj, że może to być symbiotyczna relacja między tobą a twoim przeciwnikiem. Zawsze umieszczam komentarz wewnątrz warstwy pierwszej, komentarz gratuluje cracker i daje im kod promocyjny, aby otrzymać nagrodę pieniężną od Ciebie.

Uczyń nagrodę pieniężną znaczącą bez żadnych uprzedzeń. Zwykle mówię coś w stylu $500. Jeśli twój facet jest pierwszy do złamania kod, potem Zapłać mu pieniądze i zostań jego przyjacielem. Jeśli jest twoim przyjacielem, nie będzie rozprowadzał Twojego oprogramowania. Zapytaj go, jak to zrobił i jak możesz poprawić!

POWODZENIA!

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

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