Zabezpieczenia programu procedur - czy jest sens sie w to bawić?

Jest kilka wątków na forum odnośnie zabezpieczeń. I wiadomo że każde da się złamać to tylko kwestia czasu ale po kolei.

1. Nasza aplikacja zarządza magazynem przez różnych pracowników. np Ania, Robert, Jacek

w programie mamy mniej więcej coś takiego

If Edit1.Text = Ania Then Zaloguj; //Po zalogowaniu mogę usuwać i dodawać produkty na magazynie;

**Pytanie: ** Czy jest sens aby próbować zabezpieczyć chociaż trochę tak banalne złamanie instrukcji if ?

2. Zabezpieczenie przed piractwem - nasza aplikacja podczas instalacji prosi o klucz produktu.

If Edit1.Text = Klucz then Zainstaluj

Takie zabezpieczenie to prawie takie co nic: ale kilka pomysłów i pytań wpadło mi do głowy.

a) czy zagnieżdzanie if-ów coś daje (utrudnia crackowanie) tzn

if Edit1.Text= Klucz then
  if procedure then
   if procedura2 then Zainstaluj

b) skakanie po plikach.

{aplikacja}
if Edit1.Text = Klucz then Procedura_Z_Biblioteki_DLL(parametry);

{biblioteka dll}
if Parametry = Stałe then Procedura_Instalacji_w_Programie //Biblioteka zmusi skoczenie aplikacji głównej do właściwego miejsca gdzie ma się rozpocząć instalacja;

c) tworzenie wątku sprawdzających czy kod pliku exe jest niezgodny z oryginałem jeśli nie to zamykanie instalatora.

d) tworzenie dużej ilości wątków wprowadzających chaos w danych programu a tylko jeden poprzez wstawkę w assemblerze zmieni skok instrukcji if zamiast do then to gdzieś indziej do określonej procedury.

Czy któryś z tych pomysłów ma jakiś sens? Gdzie można poczytać jak powinny wyglądać dobre zabezpieczenia programu?

Nie wiem czy wiesz, ale zwykle stringi sa widoczne jak np otworzysz plik exe w notatniku. Więc można odgadnąć i loginy i hasła tak samo jak i zabezpieczenie przez piractwem. Co do loginów i haseł, to najlepiej hashowac np sha1 i można trzymać w lokalnej bazie SQLlite, co do klucza produktu... weryfikowany przez internet, przypisany do jakiegoś numeru indywidualnego komputera np odzyskać numer seryjny jakiegoś podzespołu.

Nie wiem czy wiesz, ale zwykle stringi sa widoczne jak np otworzysz plik exe w notatniku.

Nie wiem czy wiesz, ale są do tego lepsze programy niż notatnik :]

@Rafał D:

1. Taka instrukcja warunkowa to nie zabezpieczenie - przecież każdy może wpisać dowolną nazwę i jeśli dostęp nie jest blokowany hasłem to dowolny pracownik może zalogować się na dowolne konto w programie; Poza tym nie wiem, czy podałeś jedynie przykład, jednak lepiej jest nazwę użytkownika wybrać z listy (np. TComboBox z ustawionym Style na csDropDownList), niż ręcznie wpisywać ją w pole edycyjne; Dostęp do każdego konta powinien być umożliwiony jedynie po podaniu hasła, żeby wykluczyć pracę z programem na nie swoim koncie i uniknąć nieporozumień/pomyłek; Jeśli chodzi o łańcuchy, to można je bardzo łatwo odczytać edytorem zasobów, więc jeśli chcesz cokolwiek utrudnić to musisz je zaszyfrować;
2. Zwykły jeden if raczej nic nie da - co innego zagnieżdżone pętle (przy porównywaniu łańcuchów itd.), jednak to i tak można w dalszym ciągu prześledzić - wystarczy cierpliwość; Można się bawić w różne blokady jak np. pobieranie numeru seryjnego jakiegoś podzespołu i sprawdzanie go podczas rozruchu aplikacji, jednak trzeba brać pod uwagę fakt, że jeśli dany podzespół zostanie wymieniony to program dalej musi działać; Tutaj jedyne co przychodzi do głowy to informacje o dysku twardym, bo nawet jeśli ktoś go wymieni to w nowym już programu nie będzie; Jednak takie informacje trzeba gdzieś przechowywać, dlatego czy wybierze się pliki, czy rejestr to i tak można zapis/odczyt prześledzić odpowiednim oprogramowaniem;
   Podsumowując - jeśli program będzie wartościowy to znajdzie się cracker, który poradzi sobie ze złamaniem zabezpieczeń; Jedyne co można zrobić, to mu to utrudnić; Sam jeden nie jesteś w stanie zrobić bardzo dobrego zabezpieczenia, skoro nawet większość sporych korporacji nie daje rady - pełno jest crack'ów, keygen'ów i seriali do prawie wszystkich wartościowych aplikacji komercyjnych;

Wiem że przykład

 if Edit.Text = Ania then Zaloguj

jest prosty bo łatwo odczytać stringi ze skompilowanego programu. Chodziło mi jedynie o instrukcje warunkową if i jej zagnieżdzanie.

Osobiście stosuję tak jak ktoś wspomniał Login i Hasło.

Natomiast jeśli mój program wykonuje aktualizacje automatyczne to dane do ftp zabezpieczam mniejwiecej tak:

FTP.Password := WłasnyAlgorytmDekodowania(Stała); 

przyczym hasło ma 10-20 znaków typu ('As234Ds32v_g') a po zaszyfrowaniu ok 1000 znaków.

Poza tym wydaje mi się że codzienny update to najlepsze zabezpieczenie przeciw crackowaniu.

Natknęła mnie jeszcze jedna ciekawa myśl. Mianowicie stworzenie instrukcji warunkowej typu if ze zmiennym skokiem (adresem pamięci) Poniżej jakby to miało działać

InstrukcjaIFasm(warunek) then Random(tablica adresów pamięci) -> skok do procedury pod wylosowanym adresem;   //Procedura ze wstawką w asemblerze 

{Zasada działania:

 warunek - jak zwykły If np  Edit.Text = 'Ania'  po tym jak warunek jest True zostają zmodyfikowane dane na podstawie wylosowanego adresu (ten staje się kluczem) i następuje skok pod wskazany adres.  Czyli

if warunek then exit;
{czesc kodu programu powodująca zawieszenie się aplikacji}
zaloguj1;
{czesc kodu programu}
zaloguj2
......

(Kod Klucz jest używany potem w innych procedurach nawet nie związanych z logowaniem.)

W takim układzie jeśli warunek zostanie spełniony to napisana instrukcja warunkowa nie wykona polecenia exit tylko skoczy pod zaloguj1 lub zaloguj2



 

Zamiast martwić się bezpieczeństwem swojej aplikacji najpierw zajmij się bezpieczeństwem danych, które ta aplikacja przetwarza.
Kombinowanie z zabezpieczeniami aplikacji zawsze źle się kończy i prowadzi do irytacji uczciwego klienta.
Jeśli dasz ciała z bezpieczeństwem danych możesz ponieść znacznie większe straty, niż to, że ktoś na lewo korzysta z twojej aplikacji.

Twoje zabezpieczenie...

If Haslo = edit1.text then Loguj;

łamie się w ciągu pięciu sekund zmieniając jeden bajt w execu nawet jak ukryjesz stringi... radzę Ci wymyślić coś bardziej skomplikowanego opartego na algorytmie kodowania...

Ify nie powodują utrudnienia łamania hasła.

Pozdrawiam

przyczym hasło ma 10-20 znaków typu ('As234Ds32v_g') a po zaszyfrowaniu ok 1000 znaków.

Przy czym wystarczy przeskoczyć na koniec tej funkcji dekodującej i odczytać rozszyfrowany string z pamięci. Najwyżej paręnaście minut roboty.

Rafał D napisał(a)

łatwo odczytać stringi ze skompilowanego programu.

Owszem - łańcuchy można łatwo znaleźć, ale niekoniecznie można je wykorzystać od razu; Jeśli dane porządnie zaszyfrujesz to nawet, jeśli wyciągnie się szyfrogram/hash będzie problem, żeby przetworzyć je na np. gotowe hasło; Wszystko zależy od sposobu przetwarzania i przechowywania tychże łańcuchów;

Rafał D napisał(a)

Poza tym wydaje mi się że codzienny update to najlepsze zabezpieczenie przeciw crackowaniu.

Nie rozumiem - co dokładnie miałoby być aktualizowane? Chcesz codziennie zamieniać pliki programu pobierając z sieci takie, ze zmodyfikowanymi zabezpieczeniami..? IMHO codzienna aktualizacja to bolączka - odstrasza tylko użytkowników; Mnie osobiście denerwują programy, które trzeba co kilka dni aktualizować - lepiej zrobić większą modyfikację i dopiero spowodować update, niż dorzucać po trochę i zabierać czas użytkownikowi;

Ogólnie to nie zastanawiałbym się nad zabezpieczeniem przed crack'owaniem aż tak, bo ważniejsze jest bezpieczeństwo przechowywanych i przetwarzanych przez program danych; Według mnie jeśli trzeba się zabezpieczyć, to albo zrobić porządne zabezpieczenie przed wszystkimi cracker'ami (tymi dobrymi jak i newbie) i włożyć w to dużo czasu, albo zrobić bardzo proste (tylko przed pseudo-cracker'ami) - np. sprawdzanie samego klucza produktu; Jeśli ktoś będzie chciał złamać zabezpieczenia to to zrobi prędzej czy później, ale blokady przed crack'owaniem nie mogą być ważniejsze, niż klienci - nie możesz ich w kółko dręczyć aktualizacjami;

Kiedyś też głowiłem się nad idealnym zabezpieczeniem, i choć miałem wrażenie, że jest nie do złamania, to było by zbyt uciążliwe dla użytkownika/klienta - coś na zasadzie przeglądarki i sesji, jednak przy każdym uruchomieniu musiałby się łączyć z siecią, co na pewno było by denerwujące.