Witajcie,
potrzebuję wiedzieć w jaki sposób można zabezpieczyć plik exe przed jego modyfikowaniem. Będzie mi naprawdę miło jeśli napiszecie chociażby hasła klucze, które mógłbym sobie następnie wygooglować. Oczywiście, jeśli ktoś zechcę się rozpisać, to będę jeszcze szczęśliwszy. :) Pozdrawiam i z góry dziękuję za odpowiedzi.
Nie da się zrobić czegoś takiego, można co najwyżej możliwie to utrudnić. http://pl.wikipedia.org/wiki/Zaciemnianie_kodu
Jesteś pewien, że się nie da? Bo mi do głowy przychodzi już kilka prostych pomysłów jak sprawdzanie daty modyfikacji pliku, czy też sumy pewnych obszarów kodu(o ile to wykonalne, bo nigdy tego nie robiłem) ale wydaje mi się, że jest tego więcej.
I czym to będziesz sprawdzał? Dodatkowa dllką? No to ktoś dopadnie dll. No to dodajmy też sprawdzanie dllki za pomocą exe. hmmm no to ktoś usunie i jedno i drugie ;) Jak mówię da się tylko w nieskończoność utrudniać zmiany ale nie ma 100% szans na zabezpieczenie, gdyby tak było to najbogatsze firmy już dawno by umiały zabezpieczyć swoje exe przed modyfikacją, żeby nie móc tworzyć cracków ;) No chyba, że potrafisz zrobić takie mega zabezpieczenie to wtedy zarobisz miliony na sprzedaży tego patentu :p
Jeżeli autor tworzy exe lub go modyfikuje to wie kiedy to robi i może stworzyć zmienną w swoim programie przechowującą ową datę, która będzie porównywana z właściwą datą modyfikacji pliku. Wówczas jeżeli ktoś zmodyfikuje plik a nie wpisze odpowiedniej wartości do tej zmiennej to np. możemy zrobić że proces będzie popełniał samobójstwo :D. To samo z sumą o której mówiłem, przecież jej wartość można przechowywać gdzieś w pliku. I nie mówię, że istnieją zabezpieczenia których nie można złamać. Po prostu chcę znać nawet te najbanalniejsze, coby pogłębić swoją wiedzę w tym temacie :)
Tak jak pisze @mr_jaro -> Jeśli dodasz sprawdzenie w rodzaju if (plik_zmodyfikowany) { zabij_proces(); } (swoją drogą, lepiej sprawdzać checksum niż datę modyfikacji, to pierwsze trudniej ominąć) - modyfikujący wycina też tego ifa i całe zabezpieczenie pada.
Nie ma niczego czego nie da się ominąć, możesz najwyżej dążyć do tego, żeby modyfikacja była nieopłacalna (tzn. trudniejsza niż wartość zyskiwana z modyfikacji) - czyli utrudniać analizę i edycje.
Jeśli chciałbyś wiedzieć więcej na ten temat - polecam zainteresowanie się:
anti debugging techniques - czyli jak utrudnić dynamiczną analizę.
E tam się nie da - kiedyś się dziury (przepraszam, otwory :D) w dyskietce robiło, żeby odpowiedni fragment był nieczytelny, to i pewnie jakoś by dało radę jakieś sumy kontrolne sobie odpowiednich fragmentów policzyć... ;-)
Właściwie to co napisali poprzednicy wyczerpuje temat tzn. nie da się stworzyć zabezpieczenia, którego obejście jest niemożliwe. Da się jedynie opóźnić stworzenie cracka. Z praktycznego punktu widzenia, mam tu na myśli małe i średnie firmy deweloperskie, lepiej jest zastosować najnowszą wersję komercyjnego rozwiązania np. Themida/Winlicense, VMProtect, etc. Dodatkowo można zaimplementować jakieś proste własne zabezpieczenie nie informujące wprost o tym, że wykryty został crack np. jeśli zabezpieczamy kalkulator to po kilku dniach może uruchomić się sprawdzenie sumy kontrolnej i jeśli nie jest poprawna to od tej pory kalkulator zacznie zwracać drobne błędy w obliczeniach.
Jak chcesz poczytać o różnych sztuczkach stosowanych do walki z crackerami to jakiś czas temu pisałem o tym magisterkę, fragmenty mogę Ci podesłać na PW.
//EDIT
Tak właściwie to mogę udostępnić wszystkim, może jeszcze komuś się przyda.
Domowe metody szybko zostaną usunięte, bez dedykowanego exe-protectora daleko nie zajedziesz.
Samo sprawdzanie sum np. CRC32 czy dat modyfikacji pliku to bardzo słabe podejście. I bardzo widoczne, istnieją dedykowane wtyczki do deasemblerów jak IDA, które przeszukują cały obszar analizowanych aplikacji i szybko wyłapią tablice CRC32 itp.
Jeśli już upierasz się przy takim rozwiązaniu, obliczaj te sumy i szyfruj nimi jakieś dodatkowe stałe w programie, dane lub zewnętrzne pliki, z których korzysta aplikacja, nie informuj użytkownika o tym, że sumy się nie zgadzają, w ogóle nie sprawdzaj czy się zgadzają czy nie, po prostu ich wartości potraktuj jak klucze szyfrujące do innych komponentów. W takim wypadku atakujący będzie musiał albo całkowicie odszyfrować te pozostałe elementy albo odszyfrować i na nowo zaszyfrować korzystając ze zmodyfikowanych sum kontrolnych.
Pamiętaj także, że proste sumy CRC32 mogą być równie prosto skolidowane, tzn. jeśli np. ktoś Ci zmodyfikuje plik i zmieni się ta oczekiwana wartość CRC32 można "dołożyć" do pliku dodatkowe bajty, które sprawią, że wynikowa CRC32 będzie odpowiadał oryginałowi, dlatego warto zastosować hashe np. SHA-256, Whirlpool, czy SHA3.
A kto powiedział, że chcę cokolwiek zabezpieczać :)
Zabezpieczanie EXE stosuje się z kilku powodów:
W takim celu wystarczy zwykła suma kontrolna CRC32.
Kolejny etap to zabezpieczenie stałych jak opisał BW powyżej: http://4programmers.net/Forum/1069119
Pozwoli to zabezpieczyć się przed domorosłymi amatorami łamania aplikacji, którzy nie wiedzą co to disassembler.
Kolejny etap to HMAC: http://www.drdobbs.com/licensing-using-symmetric-and-asymmetric/184401687
Kolejny etap to kompresja (najlepiej zaciemniona).
Kolejny etap to rozwiązania w rodzaju tych oferowanych przez @Bartosz Wójcik (PeLock).
Bawiąc się w zabezpieczenia warto mieć na uwadze że skądś się brały, biorą i będą brały pakiety oprogramowania ze złamanymi zabezpieczeniami.
Często wystarczy odpowiednia ilość czasu na analizę. Są ludzie którzy łamią zabezpieczenia dla samej frajdy łamania.
Czasami zabezpieczenia są bardzo mocne, ale i tak znajdzie się sposób na ich obejście.
http://en.wikipedia.org/wiki/DeCSS
https://www.schneier.com/essays/archives/1999/11/dvd_encryption_broke.html
Czasami można spotkać aplikacje, które wysyłają wpisane klucze i hasła na serwer.
Jeżeli klucz i hasło zgadza się, to serwer wysyła dane do wykonania (Język skryptowy).
W przypadku, gdy zalogowanych jest więcej użytkowników z tym samym kluczem i hasłem oba procesy kończą się.
Nigdy nie jest wysyłany cały plik skryptowy (ze wszystkimi danymi).
Rozwiązanie to ma wiele wad.
Innym ciekawym wyjściem z sytuacji był program pokroju hiew'a, który to instalował rootkita do sprawdzania czy coś przypadkiem nie chce podejrzeć kodu, przy tym podmieniając dane deassemblingu.
Oba rozwiązania da się obejść, jest to tylko utrudnienie.
Można wyprawiać cuda wianki, wysyłać na serwer, robić serwery licencji itp, robić klucze hardware'owe, szyfrować 50-krotnie 65536-bitowym AESem, zabezpieczać przed debuggerami itp. tylko ja się pytam PO CO?
Nie da się zabezpieczyć całkowicie; crackerzy i tak to złamią wczesniej czy później - zwykle w kilka dni, jeśli będą mieć odpowiednią motywację i będzie się opłacać. Jeżeli zabezpieczysz gotowym komercyjnym protectorem, to tylko będą mieć łatwiej, bo protectory są rozpracowywane w pierwszej kolejności.
Jeżeli crackerom nie będzie się opłacać odpalać nawet deasemblera, to i tak na tym programie Ty nie zarobisz; no może na bilet autobusowy i bułkę Ci starczy; a jak dobrze biznes pójdzie to na utrzymanie domeny w .com.pl.
Użytkownicy nie cierpią DRMów - im mocniej zabezpieczysz (utrudnisz życie crackerom), tym mocniej wkurzasz potencjalnych użytkowników i tym mniejszy sukces odniesie Twój produkt. Ja np. nawet nie spojrzę na program, który jest zabezpieczony DRMem czy innym exe protectorem. Program zabezpieczony DRMem to jak strona WWW z wielkim banerem reklamowym z uciekającym krzyżykiem - mówi legalnemu użytkownikowi: "mamy Cię drogi użytkowniku w d***ie, liczy się tylko nasz biznes".
Paradoksalnie najbardziej g***ane programy są zwykle napakowane wszelkimi DRMami; dlatego patrz p. 3. W 99.9999% przypadków to co jest zabezpieczane DRM nie jest warte takiego zabezpieczenia. Często początkujący zaczynają myśleć o DRM jeszcze zanim napiszą sensowny program i zdobędą pierwszych użytkowników.
Skoro DRM nie działa (p. 2.), a wkurza legalnych użytkowników (p. 3), to nie ma sensu go stosować.
Jedyny sensowny sposób zapezpieczenia nie dający się teoretycznie piracić (przy założeniu, że nie mamy dziur kodzie), to umieszczenie kluczowej logiki programu poza maszyną użytkownika. Innymi słowy, SAAS. Tylko dostawca ma dostęp do całości kodu, więc użytkownik nie może go fizycznie zmienić - no bo jak można zmienić coś, czego się nigdy nie ma. I żadne protectory nie są potrzebne. Dlatego aplikacje webowe są tak popularne, a desktop umiera. :).