"Wypakowanie" pliku exe do ramu i odpalenie go tam

Chcę zabezpieczyć mój program przed crackowaniem. Wymyśliłem b. dobrą metodę - główny plik exe będzie zaszyfrowany, a kluczem będzie numer seryjny. Uruchamiany przez użytkownika plik exe będzie odszyfrowywał główny plik jako klucza używając numeru seryjnego.

Tylko po odszyfrowaniu trzeba będzie ten główny plik exe gdzieś zapisać przed uruchomieniem. I tu zaczynają się schody - jeśli zrobię to na dysku to ktoś odszyfruje to prawidłowym numerem seryjnym, uzyska odszyfrowany plik i owy plik będzie udostępniał dalej. Czytałem gdzieś o uruchamianiu pliku exe bezpośrednio z pamięci RAM - czy jest to możliwe? I jeśli tak to czy nie jest to kosmicznie trudne?

BTW.
Jeśli znacie jakieś inne ciekawe metody zabezpieczania przed crackowaniem to z chęcią bym je poznał.

Tak, jest możliwe... Jest też możliwe zrzucenie bloku z pamięci procesu i takie go skorygowanie aby otrzymać normalny plik exe - to główna metoda walki z packerami\protectorami. Wrzuć w szukajkę 'protector', bo to raz o tym była mowa?

Dzięki za szybką reakcję. Wrzuciłem w szukajkę i rzeczywiście była o tym mowa kilka razy. Niestety były to dyskusje na temat komercyjnych protektorów. Poszukałem w necie i najczęściej były tam mało użyteczne wypowiedzi. Znalazłem co prawda jeden rzeczowy poradnik, ale mnie z lekka przytłoczył, bo gościu w nim opisuje wszystko - kompresję, obsługę dll'ek, ocx'ow itd. Mi wystarczy coś co pozwoli mi uruchomić tablicę bajtów, w której będę miał plik exe. Niemniej jednak nie ustaję w dalszych poszukiwaniach.

Aha i odpowiedzcie - czy jest jakikolwiek sens próbowania napisania protectora bez znajomości assemblera? Bo jeśli samo C++ nie wystarczy to już teraz dam sobie spokój :)

Słuchaj, protector szyfruje kod oraz dane i dorzuca do binarki kod odbudowujący. Przy uruchamianiu system odpala normalnie binarkę i wykonuje się kod odbudowujący, tyle w skrócie. Tworzenie nowego procesu 'z niczego' (ew. uruchamianie we własnej przestrzeni adresowej) to już delikatnie mówiąc skomplikowana sprawa - bez hookowania kupy funkcji się nie obejdzie. Powiedziałbym, że to trudniejsze niż stworzenie prostego protectora, tak działają najlepsze bindery.

Protectora bez asma nie ruszysz, nie ma szans.

No ok, to takiego prostego bindera sobie zrobiłem, jest stub, a za nim jest zapisany plik od tyłu. Później będzie oczywiście pomieszany bardziej skomplikowanie niż zapis od tyłu, teraz po prostu sobie napisałem dla zabawy. Niestety, takie zabezpieczenie nic mi nie daje, bo stub wypakuje oryginalny plik i będzie chciał go uruchomić. Wtedy user skopiuje sobie ten oryginalny plik(wypakowany i odszyfrowany już przez stub) i go wrzuci na warezowe strony. Czy jestem w stanie się przed tym zabezpieczyć? A jeśli bez ASMa się nie da to co mogę zrobić używając tylko C++ żeby maksymalnie utrudnić crackowanie aplikacji? Bo super skomplikowany oparty na kryptografii algorytm generujący seriale jestem w stanie zrobić(i zrobiłem takowy), ale co mi on daje skoro cracker podmieni kilka bajtów i mój program nawet nie skorzysta z owego super skomplikowanego algorytmu :)

Wiekszosc protectorow mozna tak oszukac, bo gdzies kiedys rozszyfrowany program musi w pamieci wyladowac. Glownym zadaniem jest a) zniechecic b) zniechecic po kilku probach c) oszukac co do wlasciwej lokalizacji rozpakowanego programu.

johny_bravo: Co do zniechęcania - jak to uzyskać? Co do zamaskowania prawdziwego miejsca rozpakowania - też nie wiem za bardzo jak. Wypakować tysiące plików spreparowanych jako exe, a wypełnionych losowymi śmieciami? Wśród nich oczywiście ten dobry. I tak będzie to dość łatwe do złamania.

Taki binder nie ma sensu.

johny_bravo, nie pisz bzdur, to ma sens w przypadku packerów jedynie.

Program odbudowany przez protector i tak nie jest zdolny do samodzielnego działania, a ląduje zawsze tam, gdzie byłby oryginalnie. Fragmenty kodu są wycinane i dynamicznie rozrzucane po losowych miejscach w pamięci, odwołania do zewnętrznych funkcji przekierowywane bądź wręcz zastępowane kopią oryginalnego kodu, zasoby są wywalane i emulowane... Oczywiście część nagłówków pliku (i inne takie) są delikatnie mówiąc uszkadzane, sporo struktur systemowych jest modyfikowanych, ingerencja w proces jest bardzo mocno utrudniona. O protectorach odpalających drugą kopię procesu i debugujących ją nawet nie mówię - bez nadzorowania program się po prostu wywali bo np. nie ma kluczowych fragmentów kodu.

Gdyby to było takie proste jak skopiowanie pliku albo kawałka pamięci to nasze kochane polskie antywirusy (MKS i ArcaVir) nie miałyby problemów z analizą binarek potraktowanych nieco lepszymi protectorami, w przypadku dobrze użytej np. Themidy będą ślepe. Przecież w branży AV pracują byli crackerzy... no dobra, wszyscy sensowni byli crackerzy robią dla firm zagranicznych, dla naszych pracują sieroty i studenci.

To będzie bardzo łatwe do złamania, starczy monitorować uruchomione procesy i zobaczyć skąd się ten konkretny w systemie wziął - process explorer albo process monitor i pozamiatane, w tym nawet grama crackingu nie ma.

OK, czyli jak mogę się ratować jako programista-amator? Rozumiem, że przed pro-ultimate-mastah crackerami się nie zabezpieczę (bo nawet firmy dysponujące milionami dolarów takie jak Adobe czy Microsoft się przed nimi nie zabezpieczyły). Co jednak mogę zrobić jako amator aby maksymalnie utrudnić crackowanie mojej aplikacji?

Użyć protectora, jest trochę darmowych, powiedzmy polski PESpin albo Yoda's Protector, chociaż ten drugi jest dosyć stary, nie wiem jak się ma sprawa Visty\Seven w nim. Z tego co na tym forum widać to ręcznie robione zabezpieczenia padają błyskawicznie, za jakość tych protectorów zaś nie ręczę.

A co do Adobe - chłopaki sami swojego softu nie zabezpieczają bezpośrednio, oni po prostu kupują licencję na któryś protector. Chociaż... chyba koło 2003 wydali kilka triali\wtf zrobionych po swojemu, jeżeli to zajęło 5 minut to tylko dlatego, że w międzyczasie trzeba było kawę 'obsługiwać'.

PEspin wygląda nawet fajnie, widzę, że dużo dobrej roboty zostało tam wykonane. Niestety AV strasznie się burzą na pliki nim potraktowane. Wolałbym aby tego nie było. Niemniej jednak już jakieś tam rozwiązanie jest.

Najchętniej oczywiście sam bym to zrobił. Jeśli ktoś zna jakieś w miarę dobre techniki zabezpieczania, które nie wymagają nadludzkiego wysiłku przy implementacji to niech oczywiście pisze.

Freeware.
//quetz: ew. opensource ]:>