podpisywanie aplikacji danymi odbiorcy

0

Witam.

Jak automatycznie podpisać dużą ilość plików, albo po prostu jak z poziomu Delphigo podpisywać swoje aplikacje. Głównie mam na myśli podpisywanie danymi klienta, żeby mieć możliwość sprawdzenia kto jak rozpowszechnia oprogramowanie i czy robi to zgodnie z licencją. Tak więc taki podpis:

  1. Nie musi być certyfikowany
    2. Nie może dawać się usunąć bez szkody dla funkcjonowania aplikacji!
  2. Musi być możliwość szybkiego dodania podpisu (stąd pytanie jak to zrobić z poziomu Delphiego, żeby samemu napisać aplikację podpisującą pliki i zapisującą informacje o podpisach, ale oczywiście nic nie stoi na przeszkodzie żeby rozwiązaniem problemu była jakaś gotowa aplikacja)

Pozdrawiam
C.

0
  1. Nie może dawać się usunąć bez szkody dla funkcjonowania aplikacji!

Skoro jakimś cudem twoja aplikacja działa BEZ tego, to już nie spełnia tego wymogu, czyż nie? Żądasz niemożliwego. Można to UTRUDNIĆ (szyfrowanie, sprawdzanie inne duperele) ale dobry cracker i tak to ominie.

Najlepiej chyba po prostu dodać na końcu jakieś dane autentyczności a następnie w programie je sprawdzać (coś jak serial tylko że wbudowane w program). Ale to nie jest niemożliwe do ominięcia.

0

można to zrobić, ale raczej nikt się nie będzie chwalił takimi rzeczami na forum ;)
trzeba po prostu pokombinować ;)
każde zabezpieczenie jest do ominięcia, tylko pytanie jak dochodową aplikację chcesz zabezpieczyć i ile zachodu będzie potrzeba do jej ominięcia.
powiem jedno: aplikację trzeba tak skonstruować i wycenić żeby nikomu nie chciało się jej crackować ;)

0

ukryj ze 3, 4 znaczniki w sekcji danych przez ich deklaracje jako np string "XMARKERXMARKER" (nie zapomnij sie do nich odwolywac w kodzie, bo ci optymalizator go nie umiesci w exeku), utworz program, ktory te 4 stringi markerow zamieni np. na zaszyfrowany identyfikator klienta, majac 2 tak samo oznaczone exeki mozna wykryc roznice (kazda o ile to ta sama kompilacja!), ale zwykly plebs sie nie zorientuje, ze jakis zbior bajtow w sekcji danych sie zmienil albo ze cos ukrywa, do watermarkowania exekow stosuje sie tez wymyslniejsze techniki jak np. budowanie specjalnych sekcji kodu i wykrywanie np. kolejnosci instrukcji np. call / mov / xor co pozwala stworzyc pelnego watermarka i zidentyfikowac klienta, co wymaga juz sporej wiedzy o assemblerze i strukturze programow, nie polecam ci doklejac na koncu exeka nic (tzw. overlay) bo to najbardziej widoczne, duzo jest metod watermarkowania, stuknij w google, ciekawe wyniki wyskakuja, np.:

"SOFTWARE WATERMARKING VIA ASSEMBLY CODE TRANSFORMATIONS"
http://www.cs.sjsu.edu/facult[...]students/cs298ReportSmita.pdf

daj znac co wybrales w koncu

0

można to zrobić, ale raczej nikt się nie będzie chwalił takimi rzeczami na forum

No przeciez, stwierdz ze sie da, nie powiesz jak, nawet nie powiesz kim jestes, brawo! Genialne, tylko raczej uswiadamiasz o tym ze nic nie wiesz. Więcej takich komentarzy-trawy.

ukryj ze 3, 4 znaczniki w sekcji danych przez ich deklaracje jako np string "XMARKERXMARKER"

To i tak można usunąć...

stosuje sie tez wymyslniejsze techniki jak np. budowanie specjalnych sekcji kodu i wykrywanie np. kolejnosci instrukcji np. call / mov / xor co pozwala stworzyc pelnego watermarka i zidentyfikowac klienta

I tak posiadając dwa exeki można porównać i pomieszać instrukcje... Ale technika całkiem mądra i nie banalna.

daj znac co wybrales w koncu

Czy tylko mi to wygląda na reklamę?

I tak wszystko to można usunąć (w prostszy czy trudniejszy sposób), więc problemu autora nie rozwiążemy... Zresztą wyglada na to że autor ma nas gdzieś...

0

niepotrzebnie kombinujesz… umieść w kodzie jakiś numer seryjny, a każdy klient dostanie osobnego builda z innym numerem.
zbyt pracochłonne? to wymagaj pliku-klucza (tak jak Total Commander używa pliku z rozszerzeniem .key z zaszyfrowanym nazwiskiem klienta). każdy klient dostanie inny klucz ze swoimi danymi. bez pliku klucza program nie działa (TC wtedy wyświetla okienko z przyciskami 1-2-3).

0

Tylko, że w przypadku pliku klucza można go sobie kopiować na inne komputery (do innych użytkowników) i co wtedy ?
Ja bym widział tu metodę opartą o wyliczenie klucza na podstawie sprzętu użytkownika.

0

Na początku sprostuję, że nie mam Was gdzieś. Nie wiem skąd ten pomysł.

Klucz na podstawie sprzętu - ok ale user może zmienić sprzęt

fragment sprawdzający klucz można z aplikacji usunąć

inne pomysły już zostały obalone

chyba, że każda funkcja i procedura będzie się odwoływała do sekcji określającej klienta, ale to na upartego też się da wyciąć i byłby problem bo przecież te sekcje muszą się różnić, kurde.

a jak się podpisuje np audiobooki? z tego chyba jeszcze łatwiej info o właścicielu usunąć? ;>

0

Na początku sprostuję, że nie mam Was gdzieś. Nie wiem skąd ten pomysł.

Tak jakoś nie odzywałeś się, nie komentowałeś, jak widać myliłem się.

fragment sprawdzający klucz można z aplikacji usunąć

Skoro teraz ta aplikacja działa, bez sprawdzania, to ciężko żeby było to niemożliwe. Ale niemożliwe, nie znaczy że łatwe. Można to mocno utrudnić.

Klucz na podstawie sprzętu - ok ale user może zmienić sprzęt

No, ale wtedy napisze Ci na meila i mu wyślesz nowy serial. I Hint: To też można ominąć.

chyba, że każda funkcja i procedura będzie się odwoływała do sekcji określającej klienta, ale to na upartego też się da wyciąć i byłby problem bo przecież te sekcje muszą się różnić, kurde.

To już rozumiesz dlaczego nie ma gry offlajn której nie da się scrackować?

a jak się podpisuje np audiobooki? z tego chyba jeszcze łatwiej info o właścicielu usunąć? ;>

Jeśli uda ci się cokolwiek odczytać, bo tego typu dane są szyfrowane z kluczem który znają tylko aplikacje do ich odczytania. Ale, jeśli np. jesteś dobrym crackerem to uda ci się odczytać z takiej aplikacji algorytm szyfrowania i zrobisz własną aplikację do konwersji do txt... Nothing is impossible. To, że wystarczy znać algorytm odczytu/zapisu nie znaczy że ten algorytm jest łatwy.

Sumując: Nie ma idealnego, niezłamanego systemu zabezpieczeń. Można zrobić ekstremalnie trudny system do złamania, ale koszty jego stworzenia i obsługi byłyby większe niż samej aplikacji (a i tak ktoś by złamał). Grunt to zrobić system zabezpieczeń o odpowiednim poziomie, żeby nie irytował użyszkodników, ale również nie był banalny do złamania.

0

Tylko, że w przypadku pliku klucza można go sobie kopiować na inne komputery (do innych użytkowników) i co wtedy ?

Jak to co wtedy? Użytkownik powinien mieć możliwość przeniesienia na inny komputer. Licencje oparte o konkretną maszynę są denerwujące. Dobre tylko do systemu operacyjnego.

Tu jeszcze raz przytoczę Total Commandera: nazwa klienta pojawia się w pasku tytułowym aplikacji. Żaden klient nie chciałby wypuszczać z rąk klucza, który zawiera jego imię i nazwisko. Założenie tego jest takie: nie powstrzymywać crackerów (bo to walka z wiatrakami), tylko zniechęcać legalnych klientów do rozdawania klucza. Zresztą nie widzę innego powodu, by w aplikacji trzymać dane klienta.

chyba, że każda funkcja i procedura będzie się odwoływała do sekcji określającej klienta, ale to na upartego też się da wyciąć i byłby problem bo przecież te sekcje muszą się różnić, kurde.
"sekcja klienta" może zawierać fragment kodu lub dane niezbędne do uruchomienia aplikacji.
Na przykład: po odkodowaniu klucza, jego fragment to kolejny klucz służący do odkodowania jakiejś części kodu aplikacji.
Gdyby użyć mocnego szyfru, niemożliwe stanie się skrakowanie programu przez osobę, która nie ma dostępu do działającego klucza - a samą aplikację (bez licencji) można spokojnie klientom udostępniać do ściągnięcia z internetu. Szyfr asymetryczny uniemożliwi też stworzenie keygena.

Złamać może to osoba mająca działający klucz licencyjny - ale przy dobrej implementacji mechanizmu można tak to zrobić, że będziemy w stanie potem zidentyfikować, który klucz wyciekł. Opracowanie mechanizmu blokowania konkretnych kluczy pozostawiamy czytelnikowi ;-)

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