Witam
Chodzi mi o to czy istnieja jakies mechanizmy ukrycia wartosci pewnych zmiennych np. loginu i hasla do bazy ( po wyedytowaniu binarki mozna w latwy sposob to zobaczyc )
->
HostName Database User_Name userek Password haselko DriverName MySQL
<-
??
najlepiej napisać jakiegoś packera do binarek, ew. użyj UPX'a.
To juz lepiej FSG, przynajmniej nie ma (oficjalnego) unpackera. Ale i tak zabezpieczenie to żadne.
na fsg jest.. np. o ile dobrze pamietam taki peid ma plugina od tego.. a zeby w binarce golym okiem nie bylo widac, to najprosciej sobie to jakos autorsko lekko zaszyfrowac, ot przeleciec xorem i juz nie widac tekstu..
mysle ze to dobre miejsce na moj post na ktory mi nikt nieodpowiedzial na innym forum :D chce komentarzy
Niewiedzialem gdzie zamiescic mysle ze tu moze byc (male forum);
Ok a wiec ostatnio moj program z ktorego juz "korzysta" pare osob otworzylem w programie WinHex... co sie okazalo? Wszystkie hasla byly zapisane jawnie, poniewaz byly w tablicach przed wyslaniem do socketa.
Stwierdzilem Od razu: "niezla kicha", po czym zaczolem myslec nad rozwiazaniami.
Czy to wystarczy co zrobie?
XOR --> NOT --> Base64 --> XOR
XOR <-- NOT <-- Base64 <-- XOR
Przed wypuszczeniem progzu koduje wszystkie tablice wlasnym algorytmem jak powyzej a wprogramie zamieniam miejsca w ktorych byly uzywane na rozkodowywanie w locie.
haslo logowania (jednego z wielu ale tylko w tym miejscu moge miec je w MD5) MD5.
Packer EXE, znam np. PELOCK, YODA, UPX z dostepnych za free. Ciezko powiedziec ktory najlepszy, wazna jest trudnosc zlamania a nie zmniejszenie rozmiaru dla mnie.
I tyle ... z moich pomyslow jak na razie. Teraz pytanie do Was, np. ma to sens? Jakies inne lepsze pomysly? Inne lepsze packery?
PS
4. Jeszcze jeden pomysl:
char haslo[100] ="haslo pierwsze";
char pass[100]="haslo drugie";
char dir[100] ="";
I teraz trzeba nadmienic ze to sciema, te pierwsze dwie tablice bo haslo bedzie "przepisywane" do zmiennej dir, znak po znaku z tych dwoch pierwszych tablic :P.
a wiec dir[1] = haslo[1]; dir[2] = pass[6];
i efektem mamy prawdziwe haslo w dir.... czyli 'hd' ... efekt? Niebedzie go mozna podejrzec w programach do edycji plikow .exe.... jak sie zdisambeluje to dopiero bedzie mozna zanalizowac jakie jest haslo w dir... dobrze mysle?
;C ale kombinuje
update 2
Wady i zalety wedlug mnie?
PS3
Niebojcie sie postowac ;] mozecie powiedziec ze mam glupie pomysly, poradzic, skomentowac cokolwiek ;f interesuje mnie jak inni widza moje podejscie do sprawy.
ucze_sie napisał(a)
- nikt inny takiego algorytmu niestosuje, wiec analiza bylaby unikalna dla naszego programu a wiec trzebaby na nia troche czasu poswiecic
- stosunkowo latwa implementacja
- (to przypuszczenie) przy deasemblacji, moznaby w dosc prosty sposob odczytac algorytm szyfrowania analizujac funkcje szyfrujaca i go odwrocic
to jest prawda dla wszystkich prostych, pisanych z palca algorytmow. do tego dochodzi jeszce jeden powazny minus: jesli Twoj program ma w sobie jakakolwiek zaszyfrowana informacje i musi odszyfrowac aby cos z nia zrobic (np. wyslac na serwer) to zadne szyfrowanie tak na prawde Cie nie ratuje - ktos podejrzy pakiet, ktos inny wlaczy Twoj program pod debuggerem, posledzi przez 15 minut i postawi breakpointa tuz po kodzie odszyfrowujacym etc.. mozliwosci odkrycia Twojej informacji sa wprost rowne mozliwosciom ukrycia Twojej informacji. mowiac krotko: co sie da odczytac, to sie da podejrzec. Twoj wklad w zabezpieczenie moze byc wiec trojaki:
no.. i ostatnia sprawa to to gmeranie w aplikacji klienckiej :) upx'y i inne pakery malo Ci pomoga, poniewaz (skracajac zagadnienie do pigulki) jesli tylko program sie wypakuje do pamieci, to go mozna go stamtad zrzucic do nowego exeka, ktory juz bedzie rozpakowany i na nim hulaj dusza..
podsumowujac: zastanow sie najpierw jak bardzo Ci zalezy na zabezpieczeniu programu, bo to jest studnia bez dna, w ktora mozna ladowac i ladowac i ladowac.. a i tak jest szansa ze ktos te zabezpieczenia przeskoczy w ten czy inny sposob:)
No zawarles tu wszystko o co moglym zapytac :) genialny post, pozostaje tylko kwestia
bo to jest studnia bez dna
ile wlac do tej studni :P, jak mi bardzo zalezy na bezpieczenstwie tego co sie znajduje w programie?
Znajduja tam sie dwa hasla, wlasnie do serwera i znowu do serwera, podwojne logowanie. Rozne hasla, jawne w tablicach.
Obawiam sie ze nieda sie tego ominac w postaci oddzielenia kodu od programu , bo to wlasnie ten program bedzie pelnil role serwera :/.
Koncepcja jest taka ktora niezabierze zaduzo czasu:
Wlasne kodowanie tablic, zawsze cos + utrudnienie, zasmiecenie w kodzie C funkcjami ktore nic nierobia, ale udaja ze robia. Tylko czy "smieci" z kodu C, beda smieciami w ASM? Czy juz w mniejszym stopniu.
Packer .exe z podstawowymi antydebuggerami (zawsze cos, chcemy utrudnic chociaz troche) + wstawki z ASM (gotowce) ktore tez poblokuja pare antydebugow.
Haslo logowania md5, w odroznienie od dwoch pozostalych akurat to ostatnie mnie chroni, problem w tym, ze jesli ktos zlamie pierwsze dwa... to zobaczy jawnie to w md5 :P...
Lekkie obfuscatowanie kodu : d usuniecie wiekszosci spacji, skrocenie maksymalnej dlugosci linii do X znakow, takie tam wygrzebalem do tego dobry progz dosc bo ciezko znalezc obfuscatory do C.
Finito ;f na tyle mnie stac na dzisiaj, jezeli chce ukonczyc projekt w ciagu najblizszych dwoch tygodni non stop robienia. Jesli by istnialo idealne rozwiazanie to bym sie szarpnol z czasem, ale takiego NIE MA :/. (rozwiazania)
wlasne kodowanie tablic - jak najbardziej. po skompilowaniu nic nie bedzie cleartextem. jednak nie traktuj tego powaznie, raczej jako zabezpieczenie pred gimnazjalistami z notatnikiem. jesli zrobic sobie funkcje odszyfrowujaca, to podczas sledzenia "online" jest to malo warte. co do ekstra funkcji-smieci, prakytcznie nic nikomu nie beda robic, z racji standardowych ramek funkcji generowanych przez kompilator. sa one dobrze widoczne i wylapuje je sie stosunkowo latwo. i z obserwacji samego prebiegu programu bedie wyraznie widac ktore funkcje mozna olac. ba, pewnie nawet autoanalizery wylapia ktore funkcje nigdy nie sa znikad wolane. ba2, kompilator widzac ze nie sa uzywane moze je nawet 'optimize-out'.
ta czesc zazwyczaj przy sledzeniu sprawia najwiecej trudnosci. jednak do wiekszosci pakerow sa un-packery, wiec jesli paker ma anti-debug i potraktuejsz to unpackerem, to ow antidebug sie idzie automatycznie ***. podobnie tez wiekszosc gotowcow anti-debug jest hm.. osoba odpakowujaca tez zna te gotowce. hex-search po odpakowanym kodzie i juz wiadomo co wyNOPowac. aczkolwiek, tak jak mowie, ta klasa to czesto najwiekszy spowalniacz
nie rozumiem. md5 to jest skrot, droga w jedna strone, w dodatku zlamana, sa narzedzia 'cofajace' i generujace dane o tym samym md5.. poza tym jesli ktos juz grzebie w dissasmie, to twoje porownanie podanego halsa z zapisanym w kodzie po prostu wyNOPuje albo sobie zrobi jump'a wokol tego. tak powstaja cracki ktore zmieniaja np. 1 bajt w exeku i voil'a. ale gimnazjalisci juz tego nie zrobia, niektorzy licealisci juz sobie czasem radza :)
tutaj klapa. obsfucowanie kodu nic nie daje. kompilator i tak to skompiluje tak samo. udostepniasz ten kod komus zeby go zamieniac, czy sobie samemu zaciemniasz? :)
powodzenia ;)
Samemu :), kod nawet jakby wyciekl do czego niedopuszcze, to jest ostro modyfikowany caly czas (faza rozwoju) wiec szkoda by byla mala. No md5 tak, mozna haszowac hasla i porownywac z hashem... ale to wymaga dosc duzo mocy obliczeniowej lub czasu w dodatku jest mocniejszych blowfish. Zreszta ta czesc programu mozna traktowac jako "najsilniejsza" ;P.
Najgorsza sprawa ze jesli sie dorwie jakis spec od reverse engineering to rozwali to w pare godzin max ;]. To jego praca, taka konkretna dziedzina. Wiec moge tylko liczyc na farta i ograniczyc swoje fantazje troszke :D.
Czyli jak juz obfuscatorowac to tylko kod bezposrednio ASM? np.
http://pelock.com/obfuscator/
Calkiem ladny efekt po kliknieciu ;] szkoda ze platne.
PS
Czy namiastka programu polimorf ;p byloby "inne dzialanie" co wlaczenie, tzn limit by byl srednio jakies tosamo dzialanie co 10 uruchomien programu :P . To dziecinnei proste wiec to raczej nie to chociaz z drugiej strony moze wprowadzic w blad osobe ktora sie do tego dorwie.
Hm... widzę, że quetzalcoatl nieźle daje sobie radę w tej tematyce ;).
@otello - FSG nie trybi na procesorach z DEP (trzeba dodać program do wyjątków).
ucze_sie napisał(a)
Czy namiastka programu polimorf ;p byloby "inne dzialanie" co wlaczenie, tzn limit by byl srednio jakies tosamo dzialanie co 10 uruchomien programu :P
Przyznam się, że za Chiny nie mogę tego zrozumieć. Kod polimorficzny ma to do siebie, że zawsze działa tak samo ale za każdym razem wygląda inaczej. Nie ma takiej opcji aby dane, które mają być jawne chociaż przez jeden cykl procesora były nie do odczytania :>
ucze_sie napisał(a)
Wiec moge tylko liczyc na farta i ograniczyc swoje fantazje troszke :D.
W obu dziedzinach jakimi się zajmuję byli tacy ludzie... wierz mi, że dzięki takiemu podejściu niekiedy tracili budowany przez lata autorytet. Zawsze trzeba rozpatrywać przypadek pesymistyczny.
quetzalcoatl napisał(a)
tak powstaja cracki ktore zmieniaja np. 1 bajt w exeku i voil'a. ale gimnazjalisci juz tego nie zrobia, niektorzy licealisci juz sobie czasem radza :)
A od czego sumy kontrolne pliku, pamięci? Implementacja banalna a że suma kontrolna powinna być stała to można ją zastosować do obliczania stałych - liczba iteracji pętli itd. Efekt jest taki, że program nie sprawdza sumy kontolnej - liczy ją i używa przy obliczeniach... i sypie się jak ktoś w tym grzebał. Najlepiej używać funkcji inline - proste crc wstawione w kilkudziesięciu miejscach, przemodelowane optymalizacją to już 'mały' problem.
ucze_sie napisał(a)
Czyli jak juz obfuscatorowac to tylko kod bezposrednio ASM? np.
http://pelock.com/obfuscator/
Heh, zabawki Bartosza Wójcika :> Mocna rzecz... niemal każdy kompilator ma możliwość wygenerowania listingu w asm. Jak nie ma to bierze się COFFa i IDę /Interactive Disassembler - ma też wersję freeware/ i kopiuje\zapisuje się listing potrzebnej procki lub całego pliku, przepuszcza przez obfuscator i traktuje masmem. Teraz tylko trzeba przekompilować starego COFFa bez implementacji zmielonej procki i COFFa z masma do kompilacji dorzucić. Cóż, metoda ręczna ale pokazuje, że wszytko sie da.
ucze_sie napisał(a)
No md5 tak, mozna haszowac hasla i porownywac z hashem... ale to wymaga dosc duzo mocy obliczeniowej lub czasu w dodatku jest mocniejszych blowfish. Zreszta ta czesc programu mozna traktowac jako "najsilniejsza" ;P.
Widziałem algorytmy sprawdzania seriala liczące md5 kilkanaście\kilkadziesiąt razy - wartość początkowa zmielona znakiem, cały bufor przez md5, wynik w tym samym buforze, mielenie kolejnym znakiem i znów md5... i tak dalej dla całego name'a potem deszyfrowanie RSA seriala i porównanie :> Fajne bo rawdziwego seriala za Chiny się nie wyliczy, trzeba by było wyliczyć klucz szyfrujący a faktoryzacja nadal jest 'sporym' problemem.
Kontynuujcie dyskusję bo ciekawa, potem będę miał jeszcze kilka uwag... a teraz znikam :-).
W obu dziedzinach jakimi się zajmuję byli tacy ludzie... wierz mi, że dzięki takiemu podejściu niekiedy tracili budowany przez lata autorytet. Zawsze trzeba rozpatrywać przypadek pesymistyczny.
quetzalcoatl napisał:
Wlasnie staram sie rozpatrzec wszystkie przypadki pesymistyczne :) stad ten temat i zglebianie swojej wiedzy na kazdy z tych rozleglych zagadnien. Tamto stwierdzenie bylo spowodowane tym, ze NIE MA zastosowania idealnego, perfekcyjnie bezpiecznego, jesli mowimy o moim przypadku akurat.
FSG nie trybi na procesorach z DEP
Aplikacja bedzie na systemy domowe win xp/2000/vista wiec tu raczej mozna to ominac, klopot w tym tylko ze FSG niezawiera raczej antydebuggerow, z uwagi na to ze zostal stworzony dla demosceny, liczyl sie najmniejszy rozmiar i tyle. Trzeba bedzie dodac wstawki ASM samemu w progzie. Kolejne wyzwanie :).
Efekt jest taki, że program nie sprawdza sumy kontolnej - liczy ją i używa przy obliczeniach... i sypie się jak ktoś w tym grzebał.
Hmm, mam rozumiec ze powinienem wstawic funkcje, ktora zlicza przykladowo wszystkie znaki w kodzie zrodlowym? I potem jesli ilosc znakow bedzie <> od wyliczonej to sie wysypuje? To mozna obejsc na szereg sposobow mi sie zdaje, mianowicie jak sie zmieni 1 bit na inny bit, to funkcja niewyczai zmiany. A druga grozniejsza, po prostu (gdzies to tu wyzej Quetzalcoatl pisal), wstawic wstawke blokujaca przed kazda funkcja ktora sprawdza czy suma kontrolna jest prawdziwa.
A z pamiecia? Jak to by mozna bylo zorganizowac, zliczanie ile program zajmuje pamieci, i dac mu limit na dokladnie taka wartosc? Jesli ktos bedzie chcial to zmienic to sie wysypie?
PS A to niezaszkodzi update'om? Ten server bedzie mial opcje zdalnego updejtu, bede pisal specjalne patche i wprowadzal modyfikacje automatycznie.
Teraz tylko trzeba przekompilować starego COFFa bez implementacji zmielonej procki i COFFa z masma do kompilacji dorzucić. Cóż, metoda ręczna ale pokazuje, że wszytko sie da.
A wiesz ze sprobuje? :) Wizja ASM'a mnie calkiem pociaga, a jesli po deasemblacji da sie to potem skompilowac i jeszcze objechane obfuscatorem to juz w ogole :]. Tylko tu znowu pojawia sie pytanie, jezeli ja moge to zdeasemblowac i skompilowac zmienione (obfus) to ktos inny tez moze. Chyba ze to odbywa sie na podstawie mojego zrodla C a nie samej deasemblacji.
Widziałem algorytmy sprawdzania seriala liczące md5 kilkanaście\kilkadziesiąt razy
Ogolne przeslanie bylo ze md5 jest nadal silny? Mi sie udalo aktualnie zaimplementowac SHA1, tasama zasada dzialania ale chinczycy go "zlamali" w ten sposob ze jak masz 20$-30$ mln to masz deszyfrator ktory w ciagu 56 godzin okolo potrafi zdeszyfrowac kazdy hash.
ucze_sie napisał(a)
Hmm, mam rozumiec ze powinienem wstawic funkcje, ktora zlicza przykladowo wszystkie znaki w kodzie zrodlowym? I potem jesli ilosc znakow bedzie <> od wyliczonej to sie wysypuje? To mozna obejsc na szereg sposobow mi sie zdaje, mianowicie jak sie zmieni 1 bit na inny bit, to funkcja niewyczai zmiany. A druga grozniejsza, po prostu (gdzies to tu wyzej Quetzalcoatl pisal), wstawic wstawke blokujaca przed kazda funkcja ktora sprawdza czy suma kontrolna jest prawdziwa.
A z pamiecia? Jak to by mozna bylo zorganizowac, zliczanie ile program zajmuje pamieci, i dac mu limit na dokladnie taka wartosc? Jesli ktos bedzie chcial to zmienic to sie wysypie?
PS A to niezaszkodzi update'om? Ten server bedzie mial opcje zdalnego updejtu, bede pisal specjalne patche i wprowadzal modyfikacje automatycznie.
W kodzie źródłowym? Człowieku, co ma do tego kod źródłowy? Chodziło mi o to, że program liczy sumę kontrolną sekcji kodu, i używa ją przy różnych operacjach. Ale to jest trudne do zaimplementowania nawet w asm. Liczysz CRC sekcji kodu w pliku na dysku i sekcji kodu w pamięci. Takie rzeczy można załadować w dll'kę razem z częścią kodu programu.
Aby utrudnić debugowanie można użyć swojego programu jako debugera jego kopii - uniemożliwi to debugowanie debuggerami ring3. Jak to zrobić? Tworzymy mutex, jeżeli już istnieje to program idzie dalej. Jak nie ma to program odpala swoją kopię z flaga debug i nadzoruje jej wykonywanie. Porty debuggera we właściwym procesie są otwarte więc nie można podpiąć debuggerów ring3. Aby obejście tego tricku było trudniejsze niż zmiana flagi po tworzeniu mutexa normalnie wykonujący się program powinien się w kilku miejscach wysypać /w kontrolowany sposób/ a debugger powinien to naprawić.
przyznam się, że tego nie rozumiem:
Tylko tu znowu pojawia sie pytanie, jezeli ja moge to zdeasemblowac i skompilowac zmienione (obfus) to ktos inny tez moze. Chyba ze to odbywa sie na podstawie mojego zrodla C a nie samej deasemblacji.
Ale to jest trudne do zaimplementowania nawet w asm
:) no to ja tu wysiadam, ucze sie na razie prostszych rzeczy, wszystko po kolei w zasadzie w przyszlosci bede mogl spaczowac swoj program w ten sposob ale to bardzo zaawansowana metoda
Ten drugi sposob jest juz realniejszy sprobuje co mi z tego wyjdzie, teraz koncze sha1, musze dopracowac swoje szyfrowanie potem jeszcze ogolne sprawdzanie bledow podczas dzialania bo jest ich sporo i wybor packera.
Jak znasz Bartosza Wójcika to mi zalatw przy okazji orgialna kopie Pelock'a moze byc bez kluczy licencyjnych :P.
Pozdro!
Łacha cha chyba pękne ,,,
Jak masz jakiś super produkt programistyczny
do sprzedania to możesz się martwić o zabezpiecznia.
Ciekawe dlaczego Microsoft tak bardzo dba
o zabezbieczenie Windows , może bardziej opłaca się
postawienie na popyt ... reszta jest milczeniem,
Nie isntieje metoda która zabezpieczy program
przed ingerencją , zawsze można to zrobić w pamięci
lub w pliku (crack) ...
dzejo, a widziałeś może cracka do programu zabezpieczonego jakimś nowszym PELockiem?
A może to wszystko jest g.. warte
Dlaczego bill nie zabezpieczy instalki Windows , wiesz że można
rozpoznać dysk poprzez program instalacyjny i nie trzeba robić nic więcej
,może to sie opłaca że jest lipa .. :)
@deus
PELockiem
nie widziałem ... ale na pewno ktoś to przełamie .... :-D
Aplikacja bedzie na systemy domowe win xp/2000/vista wiec tu raczej mozna to ominac
Dygresja: Jeżeli to będzie na domowe wersje Windows, to DEP jest domyślnie włączony od XP SP2 (najstarszy wspierany dziś system) i ciekawy jestem jak wytłumaczyć domowemu użytkownikowi, że "musisz sobie kliknąć właściwości systemu, ochrona.... i dodać do wyjątków". Kto nieobeznany z komputerem będzie wiedział, co należy zrobić, gdy DEP się czepia? A który z tych mitycznych ZU przeczyta pomoc do programu - przecież to ostateczność? ;-)
A osobiście stałbym się podejrzliwy przy takim czymś ;)
deus napisał(a)
Hm... widzę, że quetzalcoatl nieźle daje sobie radę w tej tematyce ;)
jakby to powiedziec, lubie na rowni i 'forward' i 'reverse', niestety po polsku to brzmi tak ze by sie wszystkim kojarzylo nieprzyzwoicie :)
deus napisał(a)
quetzalcoatl napisał(a)
tak powstaja cracki ktore zmieniaja np. 1 bajt w exeku i voil'a
A od czego sumy kontrolne pliku, pamięci? Implementacja banalna a że suma kontrolna powinna być stała to można ją zastosować do obliczania stałych - liczba iteracji pętli itd. Efekt jest taki, że program nie sprawdza sumy kontolnej - liczy ją i używa przy obliczeniach... i sypie się jak ktoś w tym grzebał.
racja. z tym, ze kod musi miec gdzies fragmencik ktory te sume kontrolna poraz piewszy z danego bloku pamieci wyliczy i umiesci gdzies, skad reszta kodu moze jej uzywac, tak? w takim razie wystarczy podmienic kod wyliczajacy sume kontrolna z bloku pamieci na duzo nopow i dwa mov'y umieszczajace te-prawidlowa sume w-tym-wlasciwym miejscu.. oczywiscie na takiego patchyka tez sa sposoby. a na te sposoby tez sa sposoby :) to jest bitwa w ktorej o wygranej decyduje jedynie ilosc czasu poswiecona oraz spryt obu stron.. ale nigdy nie jest tak ze sie nie da czegos zabezpieczyc lepiej albo obejsc szybciej
btw. to co pisales o sumach kontrolnych przypomnialo mi ciekawe zabezpieczenie przed .... debugowaniem aplikacji i stawianiem breakpointow softwareowych. te ostatnie to nic innego jak wymiana dwoch bajtow kodu aplikacji w danym miejscu na INT 3. tak wiec software breakpoint zmienia aplikacje! i tym samym kazda jedna suma kontrolna najtrywialniejsza wylapie ze w tym bloku jest zmiana.. kontra: z hardware breakpoint'em juz tak nie tak latwo ;)
No wlasnie, na sposoby sa sposoby. Pelock faktycznie jest aktualnie niewykrywalny + nielamliwy (chyba) ale co z tego, jesli stalby sie popularniejszy, to Od razu by go zmalali i wykrywali.
Wedlug mnie najlepsza ochrona to szyfry, tam gdzie sie da jednostronne, a tam gdzie sie nieda jakis dobry dwu-stronny. Osoba z reversem bedzie sie musiala troche nameczyc i miec odpowiedni sprzet do dekodowania, co zajmie przy dobrym szyfrze bardzo duzo czasu. A jednostronnych niezlamie wiec i tak ostatnia linia obrony przetrwa.
I teraz pytanie, jest duzo szyfrow dwustronnych, jaki byscie polecili, aby mozna bylo nim szyfrowac i deszyfrowac w locie. Mam na mysli ze program jest w stanie zakodowac/rozkodowac sam w sobie.
po co komu szyfr jednostronny, skoro to defacto checksuma i mozna ja wynopowac, przeskoczyc itp :) najgorsze dla odpakowywacza sa przypadki z dynamicznym deszyfrowaniem calego kodu
np. 1) program pyta o haslo i_uzywa_go_jako_klucza deszyfrujacego cala reszte programu. efekt: szum. zupelnie jak zahaslowany .zip. nie znasz hasla, to dostajesz losowe ciagi bajtow zamiast kodu
np. 2) program deszyfruje sie nie w calosci, ale po kawalkach, tylko kod ktory jest aktualnie uzywany. ten sam klucz, ale pierwsze bloczki sa prostym, a dalsze trudniejszymi algorytmami. efekt: irytacja. zlamiesz pierwszy algorytm, wygenerowales sobie pasujace haslo, a tu ups, do dalszej czesci programu nie pasuje, znowu trzeba czas tracic
No wlasnie taka metode stosuje w swoim programie. Mam 10 funkcji ktore w rozny sposob mieszaja znaki, nastepnie stworzylem pare funkcji, ktore korzystaja z np. 1,2,5 funkcji kodujacej, druga funkcja korzysta z 7,5,3 funkcji kodujacej.
I teraz kazda z tych funkcji ktore maja inne algorymtmy szyfrowania zakodowuje bloki programu, po czym usuwam funkcje szyfrujaca ze zrodla i zostawiam tylko te deszyfrujace w locie przed uzyciem zmiennej. Efekt? Ktos wkoncu dojdzie jak rozkodowuje pierwsza, to zostanie mu jeszze troche roboty :P.