Użytkownik "M.M." <m...@g...com> napisał:

> Po po daniu klucza by rozszyfrował, czyli też pozostaje możliwość
> deszyfrowania.

Tak , ale mozna sobie wybrazic ze mozna to nawet sprzetowo (poza osem)
uskuteczniac, lub przynajmniej w taki sposob przez os jak certyfikaty itp.

Wszystko reszta IMHO racja.
Pewnej metody IMHO na x86 nie ma.

PS: Juz daawno dalem sobie spokoj z security (za skomplikowane dla mnie:)
ale nei ma ktos informacji jak to wyglada na wiekszych/powazniejszych
maszynach (AS400, maiframes itp) ?
Wydaje sie ze jedyna pewna mozliwoscia jest umiejetnosc wykonania
zaszyfrowanego kodu przez sam procesor.

AK


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
https://www.avast.com/antivirus

do góry

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" :)

do góry

On Tue, 17 Nov 2015 06:35:57 +0100, Radoslaw Szwed wrote:

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

A to przypadkiem nie było po prostu tak, że np. zrobił coś a la xorowanie
rozkazów i de facto struktura kodu pozostała taka sama tylko była
reprezentowana innymi "bajtami"?

--
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

do góry

Użytkownik "Radoslaw Szwed" <r...@p...fm> napisał:

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

Tak naprawde byl to wiec emulator procesora naprawiajacy jego wade
(brak mozliwosci wykonywania szyfrowanego kodu).
Oczywiscie jestem pod wrazeniem masy roboty programistycznej
(zapewne w wiekszosci w assemblerze), ale jednak to "łata" ktora powinien
"zacerować: sam procesor.
W dodatku takie dosc prymitywne (bo krotkie, na kilka rozkazow max)
rozkodowywanie implikuje uzycie dosc prymitywnych algorytmow kryktograficznych
wiec zapewne (zwlaszcza dzis) nawet brute forces by sobie z takim kodem
"na boku" poradzily.

PS: Naprawde nie krytykuje, (zwlaszac ze sam daaaawno temu przymierzalem sie
do zabawy w kryptografie - i poddalem sie:), i podtrzymuje ze jestem pod wrazeniem,
ale jednak same procesory sa tu wciaz "do tyłu".

AK


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
https://www.avast.com/antivirus

do góry

Użytkownik "szemrany" <s...@o...off> napisał w wiadomości
news:1322mx96iix8s$.3nfhcyp871s1$.dlg@40tude.net...
> On Tue, 17 Nov 2015 06:35:57 +0100, Radoslaw Szwed wrote:
>
>> 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.
>
> A to przypadkiem nie było po prostu tak, że np. zrobił coś a la xorowanie
> rozkazów i de facto struktura kodu pozostała taka sama tylko była
> reprezentowana innymi "bajtami"?

W wielkim uproszczeniu można napisać, że kod był eor'owany (xor na Motoroli)
plus jeszcze kilka innych operacji na kodzie. Autor gry napisał sobie emulator
króry wykonywał zakodowany program. Czyli tak jak chodziło autorowi wątku
algorytm jest cały czas ukryty.

do góry

Użytkownik "AK" <n...@n...com> napisał w wiadomości
news:n2fbkg$a9s$1@speranza.aioe.org...
> Tak naprawde byl to wiec emulator procesora naprawiajacy jego wade
> (brak mozliwosci wykonywania szyfrowanego kodu).
> Oczywiscie jestem pod wrazeniem masy roboty programistycznej
> (zapewne w wiekszosci w assemblerze), ale jednak to "łata" ktora powinien
> "zacerować: sam procesor.
> W dodatku takie dosc prymitywne (bo krotkie, na kilka rozkazow max)
> rozkodowywanie implikuje uzycie dosc prymitywnych algorytmow kryktograficznych
> wiec zapewne (zwlaszcza dzis) nawet brute forces by sobie z takim kodem
> "na boku" poradzily.

Może i prymitywne, ale proszę pamiętać o tym, że Motorola 68000 na Amidze miała zegar
o częstotliwości 7MHz wiec za bardzo nie było czasu na to aby w jakiś wyszukany
sposób
zakodować rozkazy, które musiały być odkodowywane i wykonane w czasie rzeczywistym
w przeciwnym wypadku animacja na ekranie nie mieściłaby się w jednej ramce.

> PS: Naprawde nie krytykuje, (zwlaszac ze sam daaaawno temu przymierzalem sie
> do zabawy w kryptografie - i poddalem sie:), i podtrzymuje ze jestem pod wrazeniem,
> ale jednak same procesory sa tu wciaz "do tyłu".

Co tu krytykować :)
To tylko jeden z pomysłów dla autora wątku jak zabezpieczyć kod w bibliotece.

Pozdrawiam
RS

do góry

to może kod samo modyfikujący się?
jak to sie robi tak przy okazji?

do góry