Użytkownik "AK" <n...@n...com> napisał w wiadomości
news:n2co5e$lc3$1@node2.news.atman.pl...
> Użytkownik "M.M." <m...@g...com> napisał:
>
>> Nie dasz rady, wszystko podejrzą, kwestia dobrego crakera.
>
> Prawda.
> Sama dll-ke latwo zabezpieczyc/zaszyfrowac.
> Mozna ja pozniej stricte "pluginowato" ladowac chocby
> open()-em/fopen()-em, ale niestety przed wykonaniem kodu
> musi on byc dany procesorowi jawnie/odszyfrowany.
> Nie mam pomyslu jak by to obejsc, bo wydaje sie ze to musialoby
> to byc ustkutecznione juz na poziomie rozkazow procesora (musialby
> umiec wykonywac kod zaszyfrowany po podaniu mu/procesorowi
> klucza).

Niekoniecznie musi być rozkodowany. W grze Swiv na Amidze 500 było to rozwiązane
w taki sposób. Koder zakodował prawie cały kod. Było to zrobione tak, że z pamięci
była
pobierana dana która była rozkodowywana, powstawał z tego rozkaz który był wykonywany
najlepsze było to, że procedura (mini emulator) nie tylko wiedział ile ma pobrać
danych aby
rozkodować następny rozkaz (rozkazy są różnej długości), ale potrafił wykonywać skoki
i obsługiwać stos (oczywiście cały czas mowa o zaszyfrowanym kodzie).
Byliśmy z znajomym pod wielkim wrażeniem widząc rozmiar i prędkość jej działania.

W tym rozwiązaniu mamy zakodowany kod (algorytm), który nawet podczas wykonywania
jest zakodowany
(mamy tylko jeden rozkaz rozkodowany) tak, że w tym momencie disasemblery i czy nawet
dumping
nic nie dają. Należy pamiętać tylko o dobrym zabezpieczeniu przed debugingiem.

Autor nie testował swojego rozwiązania na procesorach innych niż Motorola 68000 i
okazało się,
że gra nie działa na Amigach 1200 (problemy ze stosem), ale dzięki temu zobaczyliśmy
"co ma w środku" :)