[C++ Builder] Ochrona Binarki

0

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

??

0

najlepiej napisać jakiegoś packera do binarek, ew. użyj UPX'a.

0

To juz lepiej FSG, przynajmniej nie ma (oficjalnego) unpackera. Ale i tak zabezpieczenie to żadne.

0

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

0

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?

  1. Wlasny system szyfrowania opierajacy sie na banalach typu XOR, NOT, Rot13, base64. W polaczeniu typu:

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.

  1. haslo logowania (jednego z wielu ale tylko w tym miejscu moge miec je w MD5) MD5.

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

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

  1. Jeszcze jeden, mianowicie funkcja kodujaca zawieralaby okolo 50 do 100 roznych przeksztalcen znakow w tablicach ... przepisanie od tylu, przedsuniecie wszystkich znakow o 5, potem przesuniecie co drugiego znaku o 2 a to dopiero poczatek... pomiedzy takimi by sie zawieraly XOR, NOT i pare innych...

Wady i zalety wedlug mnie?

  • 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

PS3

Niebojcie sie postowac ;] mozecie powiedziec ze mam glupie pomysly, poradzic, skomentowac cokolwiek ;f interesuje mnie jak inni widza moje podejscie do sprawy.

0
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:

  • zaciemnianiac informacje tajna, a takze rozpraszac i utrudniac znalezienie owego fragmentu kodu ktory bedzie ja udszyfrowywal i skladal z powrotem.. wchodza w to bardzo silne szyfry, szyfrowanie kodu deszyfratora, kody samomodyfikujace sie, kod maszynowy mozna przetworzyc tak, aby byl bardzo nieczytelny, mozna wstrzykiwac co chwila jakeis totalne bzdury, ktore w pewnych specjalnych warunkach po prostu beda przeskoczone, a w innych nie beda nic wnosic, tylko zajmowac czas obserwatorowi.. itede
  • zabezpieczyc program przed mozliwosciami sledzenia jego pracy, ew. utrudniac to sledznie ile sie tylko da. jest ladnych kilka sposobow na wykrycie czy program jest aktualnie objety debuggerem i wtedy mozna omijac krytyczny blok kodu, tak ze obserwator nie bedzie mial szansy go przesledzic. tyle ze: sposoby te sa czesto wycelowane w dany debugger, sposobow na ominiecie tych sposobow jest rowniez wiele itp
  • postarac sie, aby w ogole nie bylo potrzebne umieszczanie ani informacji tajnej, ani krytycznego bloku kodu w aplikacji ktora bezdie wykonywana w nie-bezpiecznym srodowisku.. to jest jednoczesnie najskuteczniejsze i najtrudniejsze do osiagniecia. chyba najprostszym w przypadku aplikacji on-line sa indywidualne konta uzytkownikow. kazdy uzytkownik ma jakis zestaw swoich unikatowych kodow (np. login-haslo) ktore go jednoznacznie identyfikuja. w samej aplikacji nie ma nic, wszystko prez nia 'przelatuje' i leci do serwera. serwer dopuszcza tylko jedno polaczenie z danym uzytkwonikiem, jak sie pojawi naraz wiecej - znaczy ze te dane identyfikacyjne wyciekly, np. blokujemy konto.. mozliwosci tez jest sporo, a mozliwosci na obejscie - malo, poniewaz intruzi nie maja dostepu do programu serwera i moga gmerac jedynie w aplikacji klienckiej

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

0

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:

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

  2. Packer .exe z podstawowymi antydebuggerami (zawsze cos, chcemy utrudnic chociaz troche) + wstawki z ASM (gotowce) ktore tez poblokuja pare antydebugow.

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

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

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

0

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

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

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

4) 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? :)

5) powodzenia ;)

0

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.

0

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

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0