Zabezpieczenie programu - odczyt ID pendriva

Hej ;-)
Napisałem program i chciałbym zabezpieczyć.
Planuję program dostarczać na jakimś PENDRIVIE, i przy starcie aplikacji sprawdzanyby był ID pendriva
Tutaj znalazłem coś takiego:
http://stackoverflow.com/questions/450009/how-to-get-serial-number-of-usb-stick-in-c-sharp
sprawdzany jest PNPDeviceID
Teraz pytanko moje, czy każdy USB ma inny numer, czy są one jednakowe dla np. danej firmy?

Albo czy macie jakiś inny sposób, aby zabezpieczyć w jakiś sposób, aby aplikacja była tylko uruchamiana z tego pendriva który dostarczę?

Czyli znowu okaże się, że albo program nie będzie wart używania go, albo wygodniej będzie używać dla zwykłego użytkownika wersję piracką niż oryginalną....

W przypadku sprzedaży programu do firm chroni cię nadgorliwość naszych urzędów skarbowych, które to lubią robić kontrole. Interesuje ich głównie czy firma posiada wszystkie programy, na które przedstawia faktury, ale jeżeli wykryją sytuację odwrotną (firma używa programu, którego nie kupiła) kierują sprawę do odpowiednich służb.
W przypadku osób prywatnych jest trudniej, nie muszą one posiadać rachunków za zakupione oprogramowanie. I nawet w przypadku kontroli jeżeli osoba się nie przyzna to nie da jej się udowodnić, że programu nie kupiła.
Moim zdaniem najuczciwszym rozwiązaniem jest powiązanie zakupu licencji z jakimiś dodatkowymi usługami, nad którymi masz kontrolę. Przykładem takiej usługi może być konsultacje telefoniczne, x godzin szkolenia z obsługi programu, automatyczny backup w chmurze (twojej chmurze). Tego typu podejście sprawia, że ludzie, którzy płacą zyskują więcej korzystając z twojego programu niż ci, którzy piracą. Oczywiście musi się ono odbić w cenie licencji.

Kolega pytał jak powiązać aplikację z pendrive a nie jaki model biznesowy obrać. Jak nie macie nic do powiedzenia to lepiej chyba nie pisać bzdur.

Dla mnie jest to typowy wątek typu:
Q: "Jak zrobić bla bla bla?"
A: "Nie rób tego."

Jeśli potrafisz to wygeneruj sobie klucz szyfrujący, kluczem szyfrującym poszyfruj metody w aplikacji .NET (przyda się np. biblioteka Mono.Cecil).

Mając klucz szyfrujący -> zaszyfruj go identyfikatorem sprzętowym tego pendrive i taką licencję udostępnij klientom.

Na pendrive możesz nagrać dowolne dane binarne i one mogą posłużyć jako ID sprzętowe, najlepiej połączyć kilka elementów np. daty utworzenia + serial urządzenia + dane z jakiegoś pliku na pendrive + np. stopień zagłębienia pliku aplikacji na dysku (jak ktoś przegra na HDD i nie będzie trzymał na tym samym poziomie zagłębienia jak na USB to wynikowy identyfikator będzie inny). Najlepiej te dane połączyć i obliczyć z tego hash, przykładowo SHA-512 (w żadnym wypadku CRC32 lub innych krótkich hashy, bo łatwo to złamać metodami brute force).

Po uruchomieniu aplikacji:

1. Wygeneruj hardware id jak opisałem wyżej
2. Odszyfruj właściwy klucz szyfrujący zawarty w pliku licencji (bez żadnego sprawdzania poprawności, sum kontrolnych, chyba, że prostych np. 16 bitowych)
3. Dynamicznie odszyfruj każdą metodę zaszyfrowanej aplikacji C# przy próbie jej wykonania.

Zalety

1. Trudne to zrzucenia z pamięci jeśli metody są indywidualnie szyfrowane i deszyfrowane jedynie przy próbie wywołania
2. Niemożliwe do złamania przy zastosowaniu odpowiedniego szyfrowania ECC/RSA + AES bez poprawnego USB

Wady

1. Wymagana jest znajomość technik modyfikacji aplikacji C# i wstrzyknięcia zaszyfrowanych fragmentów + kodu deszyfrującego
2. Ktoś, gdzieś może przechwycić ten uniwersalny klucz szyfrujący mając do dyspozycji oryginalny USB
3. Każdy pendrive musi być indywidualnie przygotowywany

Jeśli za trudne byłoby szyfrowanie metod aplikacji, spróbuj tak zaszyfrować ważne dane aplikacji, tablice bajtów, pliki, stałe.

Pamiętaj też o odpowiednim zabezpieczeniu aplikacji .NET, bo całkiem sporo aplikacji może być użytych przeciwko takiemu zabezpieczeniu:

http://www.secnews.pl/2011/11/17/narzedzia-do-analizy-aplikacji-net/

Nie ma co wymyślać koła na nowo wymyślając zabezpieczenia które dużo łatwiej ominąć niż przygotować
Można użyć gotowych rozwiązań w postaci kluczy sprzętowych - klucze sprzętowe można kupić i rozprowadzać z aplikacją a aplikacja nie musi być indywidualnie przygotowywana

Ale KAŻDE zabezpieczenie można złamać - jeszcze nie powstał program ani gra, ani nawet platforma sprzętowa której nie złamano

Tak mówią ludzie, którzy nigdy zabezpieczeń na oczy nie widzieli. Są setki aplikacji, których zabezpieczeń nikt nigdy nie złamał, bo wymagałoby to takiego nakładu pracy, wiedzy, doświadczenia i środków finansowych, żeby jednocześnie egzystować i łamać te zabezpieczenia, na które nikogo po prostu nie stać. To tak samo jak powiedzieć, że wszystko jest możliwe. To ja się pytam dlaczego Polska nigdy nie wygrała Eurowizji skoro wszystko jest możliwe? ;)

Przykładem zabezpieczeń NIE DO ZŁAMANIA są aplikacje, których fragmenty procedur i funkcji umieszczone są na serwerze i program komunikuje się np. przez SOAP lub jakiś inny protokół. I jak to złamiesz skoro wersja demo nie posiada tej funkcjonalności, a nawet jak uzyskasz login klienta i hasło do pełnej wersji aplikacji to możesz jedynie z tego skorzystać, a nie ukraść i skopiować, żeby np. potem sprzedawać. Będziesz rozdawał login kolegi, który kupił program? To szybko Cię zbanują po stronie serwera. Kodu z serwera też nie ukradniesz, bo już widzę jak będziesz przełamywał zabezpieczenia serwerowe niczym Trinity w Matrixie.

Klucze sprzętowe są dobrym rozwiązaniem jeśli są poprawnie zastosowane. Jeśli wpiszesz w google "dongle emulator" to zobaczysz, że sporo z nich jest już tak znanych, że powstało wiele emulatorów, gdzie wystarczy zrzucić pamięć klucza i sterownik systemowy będzie udawał fizyczny klucz. Często klucze sprzętowe mimo jakichś ciekawych metod zabezpieczających są używane bezmyślnie, tzn. całe zabezpieczenie opiera się np. na 1 checku IsDonglePresent(), co jest banalne do usunięcia. Jak ktoś się już szarpnie z przeczytaniem dokumentacji klucza to oprócz sprawdzania samej obecności klucza zczyta z niej 2 zmienne GetDongleInteger() lub doda timer sprawdzający obecność klucza :), tak niestety często wyglądają realia, ponieważ programiści myślą, że sam dongle magicznie wszystko ochroni. Więc aplikacja MUSI być indywidualnie przygotowywana, bo integracja z kodem źródłowym to podstawa w tego typu zabezpieczeniach. Klucze takie jak np. HASP posiadają dodatkowo tzw. envelope czyli exe-protector, jednak zastosowanie samego "kopertowania" jak to pokracznie tłumaczy się na język polski, nie jest wystarczające. O kluczach HASP i metodach zabezpieczeń sam trochę pisałem:

http://www.secnews.pl/2009/05/06/hasp-envelope/
http://www.secnews.pl/2010/03/29/hasp-i-visual-foxpro-9/
http://www.secnews.pl/2012/01/27/datahasp/

Wymyślanie własnych zabezpieczeń, nieszablonowych jest dobrą metodą zabezpieczającą jeśli się wie co się robi i jakie są tego wady i zalety. Gotowe rozwiązania mają też to do siebie, że metody ich łamania są często udokumentowane, a czasami są po prostu dostępne gotowe programy, które pozwalają automatycznie te zabezpieczenia usuwać, przykładem niech będzie uniwersalny deobfuscator de4dot do chyba wszystkich systemów zabezpieczających aplikacje .NET

@Bartosz Wójcik Są aplikacje, których po prostu nie opłacało się po łamać. Teoretycznie złamać można każde zabezpieczenie, ale musi to być opłacalne. Jeśli chodzi o SOAP (jak i inne usługi dostępne online) też złamać się da, ale jest to trudniejsze - bo najpierw trzeba by wiedzieć, co dane funkcje robią. Dodatkowo włamanie jest łatwiejsze do wykrycia i zmiany na serwerze mogą spowodować, że nasze obejście nie będzie działać, stąd też i opłacalność mniejsza, bo po wykryciu trzeba będzie znowu uaktualniać obejścia.

Dodatkowo - o czym pisałem, zrezygnowałem z używania niektórych gier/programów właśnie ze względu na to, że było to niewygodne w użyciu - jednego programu np używałem wersję piracką (mając kupioną oryginalną), właśnie z tego względu, że zabezpieczenia były upierdliwe w używaniu.

Bartosz Wójcik napisał(a):

Przykładem zabezpieczeń NIE DO ZŁAMANIA są aplikacje, których fragmenty procedur i funkcji umieszczone są na serwerze i program komunikuje się np. przez SOAP lub jakiś inny protokół. I jak to złamiesz skoro wersja demo nie posiada tej funkcjonalności, a nawet jak uzyskasz login klienta i hasło do pełnej wersji aplikacji to możesz jedynie z tego skorzystać, a nie ukraść i skopiować, żeby np. potem sprzedawać.

mówimy o łamaniu zabezpieczeń aplikacji i urządzeń do których mamy dostęp fizyczny (czyli aplikacje lokalne)
wiadomo że jeżeli aplikacja jest tak naprawdę na serwerze to nie ma czego do łamania, więc jej nie złamiemy

zgadzam się - aplikacji online się nie da złamać (chyba że mają błędy na to pozwalające), ale nie wszystkie aplikacje mogą być tylko online (żadna firma nie będzie chciała korzystać z programu od którego zależna jest firma jeżeli ta aplikacja będzie zależna od dostępu do Internetu - awaria dostępu do sieci nie może znaczyć przestoju w funkcjonowaniu firmy)

To ja się pytam dlaczego Polska nigdy nie wygrała Eurowizji skoro wszystko jest możliwe?

możliwe = musiało się już zdarzyć? :| jakieś problemy z logiką?

@kaczus czy ty wiesz o czym mówisz? Masz funkcję na serwerze "Calculate()", która przetwarza binarne dane i po wejściu i wyjściu będziesz wiedział co robi? Masz kryształową kulę, która Ci to podpowie? Jesteś tak genialnym analitykiem, że potrafisz z samego spojrzenia na dane wejściowe i jakiś kontekst odtworzyć w myślach algorytmy, które utworzyły zlepek wyjściowych danych? Włamanie na serwer też nie jest taką łatwą sprawą.

To o czym piszesz nie ma nic wspólnego z łamaniem aplikacji tylko z dostępem do usługi (w tym przypadku usługa polega na policzeniu czegoś)
Tak jakbyś porównywał ograbienie kogoś z portfela do zmuszania go do sprzątania w Twoim domu za darmo - całkowicie dwie różne rzeczy

Do świadczenia usług za darmo jeszcze nikt nikogo nie przekonał, ale mało to ma wspólnego z zabezpieczeniami

Za to na przykład takie usługi jak serwery multiplayerowe o ile nie zostały "złamane" bo nie da się z nich korzystać bez wykupienia abonamentu na usługę to jednak powstają alternatywne pirackie serwery i klienty pozwalające się do nich łączyć

Usługi oparte np. na SOAP to rzeczywistość i możesz nie wierzyć, ale są zintegrowane z aplikacjami ;), jeśli na tym oparty jest model zabezpieczenia to jak to nie ma nic wspólnego z łamaniem aplikacji? To, że coś się nie mieści w twoich schematach myślenia, nie znaczy, że nie istnieje

Aplikacje online, przeglądarkowe - też mogą korzystać z SOAP do wymiany danych z serwerem jeżeli ma to jakiekolwiek znaczenie

Uważasz że "łamanie" facebooka (który jakby nie było jest aplikacją) można porównywać ze złamaniem programu który masz na komputerze i że ma to cokolwiek ze sobą wspólnego?

Wszystko da się złamać jeśli jest to opłacalne - zazwyczaj najsłabszym ogniwem jest człowiek - w przypadku który opisujesz można na przykład zatrudnić się w firmie wytwarzającej te oprogramowanie lub odpowiednio dużo zapłacić obecnemu pracownikowi za wykradnięcie kawałka kodu.
Można też zorganizować DDoS i oduczyć firmę tworzenia oprogramowania w 100% polegającego na dostępności serwera

Podtrzymuję że nie ma to nic wspólnego z łamaniem oprogramowania - jeśli klient działa i porozumiewa się z serwerem to nie ma tu niczego do łamania; można się jedynie włamywać

Potwierdziłeś właśnie to co pisałem od samego początku, że takie zabezpieczenia oparte o zapytania do serwera są niemożliwe do złamania bez ingerencji w serwer

Nie - jeśli zabezpieczenie polega na odpytaniu serwera czy mamy uprawnienia to wystarczy zmockować serwer lub wyrzucić ten fragment kodu z aplikacji - wtedy aplikacja jest do złamania
Jeśli aplikacja jest tylko pustą powłoką, klientem wysyłającym żądania do serwera a właściwa aplikacja jest po stronie serwera to nie da się jej złamać bo nie mamy do niej dostępu
Nie możemy jej złamać z tego samego powodu z jakiego nie możemy złamać aplikacji której w ogóle nie posiadamy

Tak więc podtrzymuję

1. Każdą aplikację da się złamać jeśli mamy do niej dostęp
2. Nie da się wymusić nieautoryzowanego dostępu do zdalnej usługi (to o czym cały czas piszesz twierdząc że usługa = zabezpieczenie aplikacji)

Rozumiesz w ogóle jak działają zapytania RPC czy SOAP i że mogą za tym stać całe algorytmy przetwarzania danych, a nie jedynie jakieś sprawdzanie uprawnień? I że aplikacja może być podzielona i jedynie kilka kluczowych elementów może być po stronie serwera

No to właśnie nosi znamiona usługi
Nie każdą aplikację da się tak zorganizować i znacznie to podnosi koszty programisty - praktycznie niemożliwe jest sprzedawanie pojedynczych licencji tylko licencji ograniczonych czasowo - musisz ze swojej kieszeni płacić za prąd który zużyją serwery do prowadzenia kluczowych obliczeń - coś co normalnie działoby się po stronie klienta. Poza tym dochodzi samo utrzymywanie serwerów przez x lat, wsparcie, cała infrastruktura jeżeli chcemy obsługiwać w rozsądnym czasie dużą liczbę zapytań

Tak jak wspominałem nie każda aplikacja może być jedynie klientem usługi (nie ma znaczenia czy oprócz bycia klientem usługi ma jeszcze jakąś funkcjonalność czy nie) choć jest to najlepszy sposób na ograniczenie funkcjonalności nielicencjonowanym użytkownikom (nie ma nic wspólnego z zabezpieczeniami aplikacji)

No oczywiście, że to nosi znamiona usługi, ale nie do końca. Pokaż mi dzisiaj firmę bez zaplecza serwerowego. Obsługa kilku kluczowych elementów przetwarzania danych w programie wcale nie musi być takim obciążeniem dla serwerów, a potencjalny zysk w postaci naprawdę solidnego zabezpieczenia powinien wynagrodzić te dodatkowe koszty programistyczne. Jeśli faktycznie takim obciążeniem byłyby obliczenia to mamy Heroku, Azure i AWS.

Nawet małe firmy byłoby stać przerzucić np. jedną funkcję obliczeniową na serwer i udostępnić ją jedynie licencjonowanym użytkownikom, dla przykładu jakaś firma produkująca oprogramowanie do księgowania mogłaby przerzucić kalkulacje z oprogramowania desktopowego na serwer. Realizacja jakichś obliczeń byłaby banalna do zrealizowania nawet w PHP, obciążenie znikome (większe obciążenia na serwerach generują spamboty), zapytania przez POST, komunikacja/autoryzacja przez HTTPS, a efektem końcowym jest to, że żaden crack / keygen / serial by do tego nie wyszedł, nikt by też nie publikował swoich danych licencyjnych publicznie, bo równie szybko by został zablokowany przez producenta. Jedyną opcją byłoby to, że jakiś geniusz-analityk by się "domyślił" jak dokładnie w 100% działają te kalkulacje i dopisał kod do programu (co już samo w sobie byłoby trudne) lub Trinity z Matrixa by się włamała na serwer :)

Żadna aplikacja księgowa nie może działać tylko przy dostępie do Internetu
Mało która firma w ogóle zgodzi się żeby jej dane księgowe (czy jakiekolwiek) były przesyłane wte i wewte przez Internet przez politykę ochrony danych, a co chcesz liczyć na zewnętrznym serwerze bez dostępu do tych danych?

W ogóle nie może dojść do sytuacji że brak Internetu = brak firmy, dla niektórych firm byłyby to straty rzędu setek tysięcy

Takie "zabezpieczenia" sprawdzą się raczej w aplikacjach których zaprzestanie działania nikomu nie wyrządzi krzywdy

Internet jest podstawą działania wielu firm i argumentacja, że wszystko ma działać bez dostępu do internetu byłaby prawdziwa z 15 lat temu. Firmy bazują na kontaktach email, VPN, bazach danych, usługach SaaS, płatnościach online, dlaczego by nie miały funkcjonować z jeszcze jednym elementem, który wymaga dostępu do sieci? Skoro sam mówisz, że brak internetu = brak firmy to znaczy, że ten internet jest i dba się o to, żeby dostęp do niego był bezawaryjny. Poza tym jak internet "padnie" to te pozostałe usługi też, polecisz na pocztę polską wysłać zapytanie SQL telegramem? :)

Po pierwsze - proszę, zacznij odpowiadać normalnie - komentarze nie są od tego

Zapytania SQL lecą do lokalnego serwera więc nie potrzeba łączności z zewnątrz - mail, płatności mogą godzinę / dwie poczekać, ale klient który właśnie przyszedł i złożył zamówienie nie może
Dąży się do bezawaryjności ale nie da się tego w praktyce osiągnąć.
Obecnie pracuję właśnie nad aplikacją która ma opcję synchronizacji danych pomiędzy oddziałami firmy w wielu miastach - jednym z głównych założeń jest to że wszystko ma działać na najnowszych danych, ale jednocześnie musi działać bez Internetu; dane mają się kumulować podczas przerwy w dostawie - gdy Internet powróci dane mają się zsynchronizować (zmergować) z powrotem
I takie przestoje w działaniu zdarzają się i to dość często (co najmniej raz na pół roku) mimo że Internet jest z dwóch niezależnych źródeł

@myśleżejestem: obudź się, mamy 2015 rok. Co druga firma wymaga dzisiaj internetu do działania i jakoś nie widzę, żeby upadały bo uptime łączności wynosi 99,9% zamiast 100%.

Rev napisał(a):

Co druga firma wymaga dzisiaj internetu do działania i jakoś nie widzę, żeby upadały bo uptime łączności wynosi 99,9% zamiast 100%.

no tak, bo nie mają oprogramowania które je wtedy praliżuje

Poza tym jak sobie to wyobrażacie? Pada firma która dostarczała oprogramowanie i padają wszystkie programy które tworzyła dla wszystkich firm?
Jak daleko może pójść zaufanie do firmy dostarczającej oprogramowanie?
Mamy przesyłać do firmy trzeciej jakieś dane o których sami nic nie wiemy, ta firma będzie je dla nas przetwarzać i zwracać a działanie naszej firmy ma być uzależnione od działania tamtej firmy?

A to wszystko tylko po to żeby tamta firma miała pewność że to my nie próbujemy się połączyć bez licencji?
Mówiąc prosto: mamy im zaufać w 100% tylko po to żeby oni mogli nie ufać nam

Jeju, jeju - przecież istnieją takie aplikacje jak https://wfirma.pl czy kurczę nawet https://www.paypal.com/pl/home dostępne jedynie jako SaaS i nikt nie narzeka, firmy z tego korzystają, osoby prywatne również :P

O à propos tego, że pada firma. Pamiętacie zmianę VATu? Wiele firm nie wiedziało co robić, bo korzystali ze starych aplikacji księgowych, czasami jeszcze DOSowych, a producent już nie istniał. I co się działo? Ano dwie rzeczy. Migracja na inne oprogramowanie lub szukanie kogoś, kto zmodyfikuje takie stare oprogramowanie. Migracja wydaje się najrozsądniejszym rozwiązaniem ze względu na przyszłe aktualizacje i nie ma w tym chyba nic aż tak złego skoro do tego zmusza sytuacja.

Bartosz Wójcik napisał(a):

Migracja wydaje się najrozsądniejszym rozwiązaniem ze względu na przyszłe aktualizacje i nie ma w tym chyba nic aż tak złego skoro do tego zmusza sytuacja.

a co jeśli migracja jest niemożliwa bo dane w bazie są bezużyteczne bez przetworzenia przez serwer który już nie istnieje?