Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #27740 > unrolled thread

Antydebug i zaciemnianie Exe

Back to article view | Back to pl.comp.programming

Contents

  Antydebug i zaciemnianie Exe Borneq <borneq@antyspam.hidden.pl> - 2015-11-15 06:38 +0100
    Re: Antydebug i zaciemnianie Exe Wojciech Muła <wojtek.mula@gmail.com> - 2015-11-15 09:50 -0800
    Re: Antydebug i zaciemnianie Exe "Radoslaw Szwed" <radekszwed@pochta.fm> - 2015-11-16 08:36 +0100
    Re: Antydebug i zaciemnianie Exe Robert Winkler <noone@nowhere.org> - 2015-11-16 08:57 +0100
    Re: Antydebug i zaciemnianie Exe slawek <fake@fakeemail.com> - 2015-11-16 09:08 +0100
    Re: Antydebug i zaciemnianie Exe "M.M." <mmarszik@gmail.com> - 2015-11-16 03:36 -0800
      Re: Antydebug i zaciemnianie Exe "AK" <nobody@nowhere.com> - 2015-11-16 15:10 +0100
        Re: Antydebug i zaciemnianie Exe "M.M." <mmarszik@gmail.com> - 2015-11-16 06:26 -0800
          Re: Antydebug i zaciemnianie Exe szemrany <szemrany@offline.off> - 2015-11-16 20:32 +0100
            Re: Antydebug i zaciemnianie Exe "M.M." <mmarszik@gmail.com> - 2015-11-16 11:41 -0800
          Re: Antydebug i zaciemnianie Exe "AK" <nobody@nowhere.com> - 2015-11-16 21:09 +0100
        Re: Antydebug i zaciemnianie Exe "Radoslaw Szwed" <radekszwed@pochta.fm> - 2015-11-17 06:35 +0100
          Re: Antydebug i zaciemnianie Exe szemrany <szemrany@offline.off> - 2015-11-17 14:21 +0100
            Re: Antydebug i zaciemnianie Exe "Radoslaw Szwed" <radekszwed@pochta.fm> - 2015-11-18 07:49 +0100
          Re: Antydebug i zaciemnianie Exe "AK" <nobody@nowhere.com> - 2015-11-17 14:55 +0100
            Re: Antydebug i zaciemnianie Exe "Radoslaw Szwed" <radekszwed@pochta.fm> - 2015-11-18 07:59 +0100
    Re: Antydebug i zaciemnianie Exe platformowe głupki <NOSPAMtestowanije@go2.pl> - 2015-11-23 18:36 +0100

#27740 — Antydebug i zaciemnianie Exe

Cały kod może być nawet otwarty z wyjątkiem newralgicznych procedur, 
które będą w DLL. Już samo to że będą skompilowane z C++ do exe utrudni 
działanie, ale DLL będzie niewielka, nie chcę podejrzenia algorytmu.
Jakie są techniki zaciemniania i walczenia z debugowaniem, aby poszukać 
potem ich opis w Google?

[toc] | [next] | [standalone]

#27745

On Sunday, November 15, 2015 at 6:38:11 AM UTC+1, Borneq wrote:
> Cały kod może być nawet otwarty z wyjątkiem newralgicznych procedur, 
> które będą w DLL. Już samo to że będą skompilowane z C++ do exe utrudni 
> działanie, ale DLL będzie niewielka, nie chcę podejrzenia algorytmu.
> Jakie są techniki zaciemniania i walczenia z debugowaniem, aby poszukać 
> potem ich opis w Google?

To nie ma najmniejszego sensu, szkoda czasu i pieniędzy. Przyjdzie
100 Chińczyków albo 5 Rosjan i złamią. Albo przyjdzie arabski szejk
i kupi źródła za worek złota. :)

w.

[toc] | [prev] | [next] | [standalone]

#27748

Użytkownik "Borneq" <borneq@antyspam.hidden.pl> napisał w wiadomości news:n295o1$c4j$1@node1.news.atman.pl...
> Cały kod może być nawet otwarty z wyjątkiem newralgicznych procedur, które będą w DLL. Już samo to że będą skompilowane z C++ do 
> exe utrudni działanie, ale DLL będzie niewielka, nie chcę podejrzenia algorytmu.
> Jakie są techniki zaciemniania i walczenia z debugowaniem, aby poszukać potem ich opis w Google?

Polecam poniższy pdf szczególnie rozdział 4.

https://www.blackhat.com/presentations/bh-usa-07/Yason/Whitepaper/bh-usa-07-yason-WP.pdf

[toc] | [prev] | [next] | [standalone]

#27749

W dniu 15.11.2015 o 06:38, Borneq pisze:
> Cały kod może być nawet otwarty z wyjątkiem newralgicznych procedur,
> które będą w DLL. Już samo to że będą skompilowane z C++ do exe utrudni
> działanie, ale DLL będzie niewielka, nie chcę podejrzenia algorytmu.
> Jakie są techniki zaciemniania i walczenia z debugowaniem, aby poszukać
> potem ich opis w Google?

Jeśli chodzi o zaciemnianie kodu, to szukaj hasła "obfuscator".
Chociaż to raczej dotyczy javy, php, javascriptu lub c#,
w przypadku C++ możesz przy dekompilacji dostać
w większości przypadków co najwyżej ASM-a.

Przeczytaj też:
http://www.codeproject.com/Articles/30815/An-Anti-Reverse-Engineering-Guide
--
Robert

[toc] | [prev] | [next] | [standalone]

#27751

On Sun, 15 Nov 2015 06:38:09 +0100, Borneq 
<borneq@antyspam.hidden.pl> wrote:
> działanie, ale DLL będzie niewielka, nie chcę podejrzenia algorytmu.

Idealne rozwiązanie to umieszczenie tego na serwerze jako usługi. 
Tzn. nie ma DLL, natywny skompilowany jest na twoim własnym serwerze, 
program wysyła dane i twój serwer odsyła wyniki.

[toc] | [prev] | [next] | [standalone]

#27755

On Sunday, November 15, 2015 at 6:38:11 AM UTC+1, Borneq wrote:
> Cały kod może być nawet otwarty z wyjątkiem newralgicznych procedur, 
> które będą w DLL. Już samo to że będą skompilowane z C++ do exe utrudni 
> działanie, ale DLL będzie niewielka, nie chcę podejrzenia algorytmu.
> Jakie są techniki zaciemniania i walczenia z debugowaniem, aby poszukać 
> potem ich opis w Google?

Nie dasz rady, wszystko podejrzą, kwestia dobrego crakera.

[toc] | [prev] | [next] | [standalone]

#27756

Użytkownik "M.M." <mmarszik@gmail.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).

PS: No chyba, ze uskuteczniac funcjonalnosc tego zaszyfroanego liba/dll-ki
      w postaci service/uslugi kernela/drivera ? Tak tylko gdybam. Nie ma pomyslu 100%
     dobrego.

AK 


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

[toc] | [prev] | [next] | [standalone]

#27757

On Monday, November 16, 2015 at 3:10:56 PM UTC+1, AK wrote:
> Użytkownik "M.M."  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.
Nom.


> 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).
Po po daniu klucza by rozszyfrował, czyli też pozostaje możliwość
deszyfrowania.

> 
> PS: No chyba, ze uskuteczniac funcjonalnosc tego zaszyfroanego liba/dll-ki
>       w postaci service/uslugi kernela/drivera ? Tak tylko gdybam. Nie ma pomyslu 100%
>      dobrego.
To wszystko tylko lekko utrudni. Każdy program można w sieci znaleźć
ze złamanymi zabezpieczeniami. 


Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#27762

On Mon, 16 Nov 2015 06:26:34 -0800 (PST), M.M. wrote:

>> PS: No chyba, ze uskuteczniac funcjonalnosc tego zaszyfroanego liba/dll-ki
>>       w postaci service/uslugi kernela/drivera ? Tak tylko gdybam. Nie ma pomyslu 100%
>>      dobrego.
> To wszystko tylko lekko utrudni. Każdy program można w sieci znaleźć
> ze złamanymi zabezpieczeniami. 

Żeby skutecznie zabezpieczyć trzeba część logiki mieć "w chmurze". Bez tego
"szczegółu" każdy inny patent da się obejść.

-- 
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ę"

[toc] | [prev] | [next] | [standalone]

#27763

On Monday, November 16, 2015 at 8:32:15 PM UTC+1, szemrany wrote:
> On Mon, 16 Nov 2015 06:26:34 -0800 (PST), M.M. wrote:
> 
> >> PS: No chyba, ze uskuteczniac funcjonalnosc tego zaszyfroanego liba/dll-ki
> >>       w postaci service/uslugi kernela/drivera ? Tak tylko gdybam. Nie ma pomyslu 100%
> >>      dobrego.
> > To wszystko tylko lekko utrudni. Każdy program można w sieci znaleźć
> > ze złamanymi zabezpieczeniami. 
> 
> Żeby skutecznie zabezpieczyć trzeba część logiki mieć "w chmurze". Bez tego
> "szczegółu" każdy inny patent da się obejść.

Nom. Można jedynie utrudnić, albo, jak napisałeś, nie dawać 
użytkownikowi programu.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#27764

Użytkownik "M.M." <mmarszik@gmail.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

[toc] | [prev] | [next] | [standalone]

#27771

Użytkownik "AK" <nobody@nowhere.com> napisał w wiadomości news:n2co5e$lc3$1@node2.news.atman.pl...
> Użytkownik "M.M." <mmarszik@gmail.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" :)

[toc] | [prev] | [next] | [standalone]

#27782

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ę"

[toc] | [prev] | [next] | [standalone]

#27810

Użytkownik "szemrany" <szemrany@offline.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. 

[toc] | [prev] | [next] | [standalone]

#27783

Użytkownik "Radoslaw Szwed" <radekszwed@pochta.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

[toc] | [prev] | [next] | [standalone]

#27811

Użytkownik "AK" <nobody@nowhere.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

[toc] | [prev] | [next] | [standalone]

#28035

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

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web