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?

do góry

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.

do góry

Użytkownik "Borneq" <b...@a...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/Yas
on/Whitepaper/bh-usa-07-yason-WP.pdf

do góry

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-Re
verse-Engineering-Guide
--
Robert

do góry

On Sun, 15 Nov 2015 06:38:09 +0100, Borneq
<b...@a...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.

do góry

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.

do góry

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

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

do góry

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

do góry

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

do góry

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

do góry