System do sprawdzania licencji w aplikacjach stworzonych w Lazarus / Delphi czy ma sens? Kod źródłowy

Ciekawe rozwiązanie, muszę przyznać. Ale ma słabe punkty:

pahacfd napisał(a):

2. Do klucza 1 po wpisaniu w aplikacji KL - tworzymy dodatkowy klucz dynamiczny z Suma kontrolna podzespołów: CPU, Płyta Głowna, serial dysku

Liczenie sumy kontrolnej z podzespołów innych niż dysk twardy jest rozwiązaniem inwazyjnym i szkodliwym, bo przez to użytkownik traci możliwość wymiany podzespołów komputera. Jeśli wymieni choćby jeden podzespół lub po prostu kupi nowy komputer i przepnie do niego dysk, to licencję szlag trafi i będzie musiał przechodzić przez cały proces rejestracji od nowa.

5. I tutaj najwalniejsze, aplikacja jest zaszyfrowana, a w zasadzie podziurawiona, komendy nie są kompletne, po otrzymaniu zgody od serwera licencji wgrywa się zaszorowywana cześć kodu do aplikacji z serwera licencji jest to kilka KB.
6. i teraz nawet jeśli ktoś to scrakuje aplikacje, to aplikacja i tak nie będzie działać poprawnie bo aplikacja jest podziurawiona"

Ciekawe utrudnienie, ale nadal do obejścia — w końcu brakujący puzel przysyłany jest przez serwer.

pkt. 5. wygląda strasznie, ale jest to bananie proste, kilka najwinniejszych procedur trzymasz po prostu zdalnie i wstrzykujesz to w aplikacje oczywiscie po walidacji klucza.

Napiszesz coś więcej o tym? W jaki sposób zaimplementowane jest to wstrzykiwanie procedur?

@furious programming
Ad.1. To akurat uważam za atut, na serwerze można określić ile kolejnych zmian sprzętu można dokonać:
Wszak jest klucz statyczny licencyjny (TGAS7a-XyZgJ%K-.. wymagany do rejestracji aplikacji), a dynamiczny jest tylko klucz sprzętowy (suma cpu, plyta, dysk) przypisywany do klucza statycznego na serwerze.

Więc można to ograniczać dozwoli np. kl może dokonać 3 zmian ale każda zmiana nadpisuje ostatni klucz dynamiczny, także nadal korzysta z jednego sprzętu. Można ograniczyć to czasowo, tutaj ogranicza Nas wyobraźnia. U Mnie zmiana nie wymaga ponownej rejestracji jeśli zmiana sprzętu mieści się w limitach to wpuszcza to serwer i zmienia dynamiczny klucz (sumę) na serwerze i dysku kl. Ale bądźmy szczerzy 3 zmiany to i tak dużo zazwyczaj po takiej ilości zmian mminie co najmniej 6-7 lat. Pora na zakup nowej wersji :)

Ad. 2.
Dobrze przepraszam, w zasadzie wstrzykiwanie kodu to mocne nagięcie faktów, ponieważ w Moim przypadku procedura ma zmienne trzymane w statycznej tablicy, które procedura wykorzystuje do wykonywania komend. I właśnie w statycznej tablicy są zaszyfrowane wartości, własnym szyfrowaniem z dodanymi losowanymi przestawnymi znakami (szyfrowana tablica ma zawsze tą samą długość, dla rozjaśnienia:
zmienna_a[1,1]:='zaszyfrowany';
procedure wykonaj_komende_x(odszyfruj(zmienna_a[1,1])) >> komenda_ssh

WAŻNE: Tablica jest pobierana z serwera. Bez tej tablicy aplikacja nie jest wstanie działać. W tej tablicy jest tez specjalny id połączenia (suma), wiec nie da się je wykorzystać snifując pakiety bo pakiet nie będzie pasował w aplikacji.

W Moim przypadku to działa, ale tą prostą zasadę można wykorzystać do woli i do większości rzeczy, ponieważ zawsze coś należy przekazać czy się odwołać w procedurach.

Proste ale skuteczne.

pahacfd napisał(a):

Ad. 2.
Dobrze przepraszam, w zasadzie wstrzykiwanie kodu to mocne nagięcie faktów, ponieważ w Moim przypadku procedura ma zmienne trzymane w statycznej tablicy, które procedura wykorzystuje do wykonywania komend. I właśnie w statycznej tablicy są zaszyfrowane wartości, własnym szyfrowaniem z dodanymi losowanymi przestawnymi znakami (szyfrowana tablica ma zawsze tą samą długość, dla rozjaśnienia:
zmienna_a[1,1]:='zaszyfrowany';
procedure wykonaj_komende_x(odszyfruj(zmienna_a[1,1])) >> komenda_ssh

Spoko, pytam z czystej ciekawości.

Tutaj jest taka sama podatność, jak w każdym innym przypadku — RE i wycięcie całego tego odszyfrowywania.

WAŻNE: Tablica jest pobierana z serwera. Bez tej tablicy aplikacja nie jest wstanie działać. W tej tablicy jest tez specjalny id połączenia (suma), wiec nie da się je wykorzystać snifując pakiety bo pakiet nie będzie pasował w aplikacji.

Tyle że nadal nie zmienia to faktu, że istotne dane są po prostu w pamięci, a tę można swobodnie przeglądać różnymi specjalistycznymi narzędziami, choćby głupim Cheat Engine. Złamanie tych zabezpieczeń nie będzie wcale takie trudne, jak się wydaje.

Proste ale skuteczne.

Tak, to powinno wystarczająco skutecznie zniechęcić do kombinowania. Szkoda tylko, że ten system zabezpieczeń zmusza użytkownika do bycia podłączonym do Internetu, aby w ogóle mógł uruchomić program. Coś takiego nie jest mile widziane przez użytkowników. :P

Chyba nie ma idealnych rozwiązań. Ale co do tego pozostawania online to w zasadzie wystarczy tylko jedno połączenie z internetem, później można być już offline. Kto dziś nie ma internetu:) a do pracy zdecydowanej większość aplikacji jest on stety/niestety wymagany, więc te parę KB raczej nie zaszkodzi. Ale jeśli komuś się podoba koncepcja można rozbudowywać wg woli u Mnie się to sprawdza

furious programming napisał(a):

Ile razy jeszcze trzeba powtarzać, że jeśli użytkownik ma fizycznie dostęp do pliku wykonywalnego, to może dowolnie go zmodyfikować i wyciąć cały ten misternie przygotowany ”komponent walidujący”? Ile byś tego badziewia nie naładował do exe, to i tak za pomocą RE da się to wszystko wywalić i przygotować wersję piracką, darmową dla każdego.

To że się czyta bez zrozumienia to nie wstyd. To że się do tego pośrednio przyznaje odpowiadając interlokutorowi w ramach argumentacji już trochę tak...

Do rzeczy

ma fizycznie dostęp do pliku wykonywalnego, to może dowolnie go zmodyfikować i wyciąć cały ten misternie przygotowany ”komponent walidujący”`

loza_prowizoryczna napisał(a):

• dodajesz do swojego programu dummy kernel driver, driver ma zaszyty klucz publiczny którym weryfikujesz swój certyfikat oraz jakąś krytyczną część logiki bez której aplikacja staje się bezużyteczna

pahacfd napisał(a):

@furious programming
Ad.1. To akurat uważam za atut, na serwerze można określić ile kolejnych zmian sprzętu można dokonać:
Wszak jest klucz statyczny licencyjny (TGAS7a-XyZgJ%K-.. wymagany do rejestracji aplikacji), a dynamiczny jest tylko klucz sprzętowy (suma cpu, plyta, dysk) przypisywany do klucza statycznego na serwerze.

Więc można to ograniczać dozwoli np. kl może dokonać 3 zmian ale każda zmiana nadpisuje ostatni klucz dynamiczny, także nadal korzysta z jednego sprzętu. Można ograniczyć to czasowo, tutaj ogranicza Nas wyobraźnia. U Mnie zmiana nie wymaga ponownej rejestracji jeśli zmiana sprzętu mieści się w limitach to wpuszcza to serwer i zmienia dynamiczny klucz (sumę) na serwerze i dysku kl. Ale bądźmy szczerzy 3 zmiany to i tak dużo zazwyczaj po takiej ilości zmian mminie co najmniej 6-7 lat. Pora na zakup nowej wersji :)

Ad. 2.
Dobrze przepraszam, w zasadzie wstrzykiwanie kodu to mocne nagięcie faktów, ponieważ w Moim przypadku procedura ma zmienne trzymane w statycznej tablicy, które procedura wykorzystuje do wykonywania komend. I właśnie w statycznej tablicy są zaszyfrowane wartości, własnym szyfrowaniem z dodanymi losowanymi przestawnymi znakami (szyfrowana tablica ma zawsze tą samą długość, dla rozjaśnienia:
zmienna_a[1,1]:='zaszyfrowany';
procedure wykonaj_komende_x(odszyfruj(zmienna_a[1,1])) >> komenda_ssh

WAŻNE: Tablica jest pobierana z serwera. Bez tej tablicy aplikacja nie jest wstanie działać. W tej tablicy jest tez specjalny id połączenia (suma), wiec nie da się je wykorzystać snifując pakiety bo pakiet nie będzie pasował w aplikacji.

W Moim przypadku to działa, ale tą prostą zasadę można wykorzystać do woli i do większości rzeczy, ponieważ zawsze coś należy przekazać czy się odwołać w procedurach.

Proste ale skuteczne.

Jeśli chodzi o serwer to wszystko odgrywa się w bazie danych? czy zrobiłeś jakiś system zarządzania kluczami w php

Ja u siebie wczytuje to do pamięci, z prostej przyczyny - operacje są nieporównywalnie szybsze. Możesz wykorzystać list view, stworzy tablic rekordów to zawsze będzie szybsze od odpytań do zewnętrznej bazy mysql i niezależne od jej stabilności, połączenia, usługi. Wszystko zależy od skali.

Nie padło tu słowo: PELock, projekt polskiego programisty, który stworzył zabezpieczenie i to w Delphi z tego co wiem.
O projekcie można poczytać na stronie, w tym wszystkich możliwych obejść zabezpieczeń przed którymi chroni PELock.

Zastanawia mnie tylko sens przechowywanie kluczy w zaszytym/zaszyfrowanym programie. W momencie dodania klucza na czarną listę, musi być wydana nowa wersja aplikacji, która ma zaktualizowaną bazę kluczy. Tym samym program w wersji v1.0 będzie nadal działał z kluczem z czarnej listy, który posiada program w wersji v.1.1.

Opi napisał(a):

Nie padło tu słowo: PELock, projekt polskiego programisty, który stworzył zabezpieczenie i to w Delphi z tego co wiem.
O projekcie można poczytać na stronie, w tym wszystkich możliwych obejść zabezpieczeń przed którymi chroni PELock.

Zastanawia mnie tylko sens przechowywanie kluczy w zaszytym/zaszyfrowanym programie. W momencie dodania klucza na czarną listę, musi być wydana nowa wersja aplikacji, która ma zaktualizowaną bazę kluczy. Tym samym program w wersji v1.0 będzie nadal działał z kluczem z czarnej listy, który posiada program w wersji v.1.1.

Jednak robię, system który sprawdza na serwerze licencję, Poniżej screen jak wygląda Aktywacja programu,