Zabezpieczenie sprzętowe - Rockey2, klucze USB

0

Witam

Mam pytanie. Czy miał ktoś do czynienia z takim zabezpieczeniem:

http://rockey.pl/pl/rockey2-pakiet-10szt.html

http://www.rockey.com.my/dl-dongle-rockey2.php

W sumie taniocha. A ja szukam czegoś w ten deseń. To co mnie ciekawi to to jaka jest tego skuteczność ? Nie chodzi mi o zabezpieczenie przed "Panią Basią", tylko przed gościem, który programuje w jakimś języku, i wie że można popróbować zrobić z tym różne rzeczy (podmienić dll'kę na swoją, odczytać z jednego klucza i zapisać na drugi ...) ? Albo czy polecicie coś w rozsądnej cenie i w miarę "dobrego" ?

Tak się zastanawiałem, jak bym dostał aplikację zabezpieczoną takim kluczem, to zrobił bym tak:

  1. Napisał bym swoją dll'kę. Funkcja TRY2_Find zwracała by 1
  2. W pierwszym czytaniu, TRY2_Open wywalała by komunikat jaki user przekazuje UID
  3. W drugim czytaniu, sam wywołał bym TRY2_Open, z tym UID'em żeby dostać HID
  4. W końcu napisał bym funkcję TRY2_Open która zwraca poznany HID.
  5. Potem For i := 0 to 4 TRY2_Read odczyt zawartości klucza
  6. I podszycie się pod funkcję TRY2_Read i zwrócenie przeczytanej zawartości.

W ten prosty sposób mam kopię klucza w postaci samej dll'ki. Podmieniam tą dostarczaną z aplikacją i już : )

A może ja źle to rozumie, jak trzeba takie zabezpieczenie wykorzystać ? To w programie powinienem mieć zaszyte HID'y z którymi mój program działa ? Czy jak ?

0

nie zaglebialem sie w dokumentacje, wiec polegam na tym co piszesz:

jezeli ten klucz naprawde pozwala odczytac wszystkie swoje dane potrzebne do identyfikacji to pewnie ze tak mozna zrobic. podejrzewam ze nie musisz w aplikacji miec zaszytych hid - raczej sprawdzisz ich ogolne wlasnosci - sume kontrolna itp - albo tez 'enveloper' wymaga aby podczas instalacji klucz byl obecny i wtedy jakas jego szczatkowa informacje sobie gdzies w .ini czy w rejestrze zapisuje i porownuje przy kolejnych uruchomieniach

z szybkiego opisu na stronie, nie wyglada sensownie i pewnie taki trick wlasnie mozna zrobic. ten usb wyglada po prostu jak mala pamiec zewnetrzna bez zadnego szyfrowania czy autoryzacji:/ ale to bym musial poczytac dokladnie dokumentacje, nie mam teraz czasu.. w kazdym badz razie - klucze sprzetowe ktore sa kiepsko zrobione wlasnie w podobny sposob jak opisujesz sie skanuje i dostarcza stuby bibliotek ktore potem sa nie do odroznienia.. zreszta, wez zerknij sobie na API do hyyymmm.. podajze HASP 5? z Alladin? kurcze, nie pamietam.. ale one maja swietnie opisane w dokumentacji jak autoryzuja wzajemnie z aplikacja tak zeby samemu swoich krytycznych danych nie ujawnic - i jest to swietny przyklad jak skonsturowac klucz tak, aby juz sama proba podsluchania komunikacji byla ciezka i nie wiele dawala.

0

Dzięki za odpowiedź. Coś muszę wymyślić, moje dotychczasowe rozwiązania (serial HDD zaszyty w kodzie) choć sprawdzają się idealnie są mało wygodne dla klienta. Z drugiej strony nie chcę inwestować (potrzebne mi na start ze 20 tych kluczy) kasy w coś co - przynajmniej w teorii - wydaje się być strasznie słabe. Z drugiej strony, myślałem też jak to moje rozumowanie obejść. Może zaszyć dll'kę oryginalną w zasobach exe i wypakowywać ją na czas kiedy będzie potrzebna. Albo sprawdzać jakieś MD5/CRC tej dll'ki. Na pierwszy rzut oka wydaje się to być rozwiązanie mojego sposobu na obejście. No ale ze mnie cracker jak z koziej d**y trąbka więc podejrzewam że i wtedy by się ktoś znalazł kto by znalazł jakiś workaround. Ciekawe, czy można np napisać jakiś program który będzie symulował taki klucz...

b

0
b0bik napisał(a)

Dzięki za odpowiedź. Coś muszę wymyślić, moje dotychczasowe rozwiązania (serial HDD zaszyty w kodzie) choć sprawdzają się idealnie są mało wygodne dla klienta. Z drugiej strony nie chcę inwestować (potrzebne mi na start ze 20 tych kluczy) kasy w coś co - przynajmniej w teorii - wydaje się być strasznie słabe. Z drugiej strony, myślałem też jak to moje rozumowanie obejść. Może zaszyć dll'kę oryginalną w zasobach exe i wypakowywać ją na czas kiedy będzie potrzebna. Albo sprawdzać jakieś MD5/CRC tej dll'ki. Na pierwszy rzut oka wydaje się to być rozwiązanie mojego sposobu na obejście. No ale ze mnie cracker jak z koziej d**y trąbka więc podejrzewam że i wtedy by się ktoś znalazł kto by znalazł jakiś workaround. Ciekawe, czy można np napisać jakiś program który będzie symulował taki klucz...

b

Przyjdzie deus i podstawi w odpowiednim stringu CRC swojej biblioteki...

0

Nie będzie nawet musiał. Wystarczy że w odpowiednim miejscu wyNOPuje calla do metody sprawdzającej CRC i już może wstawiać dowolną bibliotekę.

Problem jest taki, że jak ktoś ma dostęp do programu i może go uruchomić to może zrobić zrzut pamięci w odpowiednim momencie i po sprawie. Kiedyś widziałem takie zdanie (napisane przez dobrego hackera / crackera): "If it can run, it can be defeated". (chyba nie przekręciłem)

0

Jesteś pewien, że to ma w ogóle sens?
Moim zdaniem lepiej byś zrobił robiąc jakieś normalne zabezpieczenie (generowanie klucza z nazwy, itd) i potraktowanie wszystkego themidą ze wszystkimi bajerami.
Widziałem dwóch gości (w miarę dobrych crackerów) którzy zaczynali łamać program z nią i po kilku dniach się po prostu poddawali.
Każde zabezpieczenie da się w końcu złamać (nawet chip można reversować!), ale zabezpieczenie programowe jest o wiele mniej uciążliwe dla klienta.

0

Dziwne że na Ajo znalazłem pod 2 linkiem w google crackniętą themidę...

0

Przeczytaj mój post jeszcze raz bo go nie zrozumiałeś.

0
Demonical Monk napisał(a)

Przyjdzie deus i podstawi w odpowiednim stringu CRC swojej biblioteki...

Ale jak w stringu ? Że w jakimś hex editorze poszuka tego CRC w exe'ku i zmieni ? To przecież mogę porównywać CRC od tyłu czytane : )

b

0

Zresztą chyba suma sumarum nie ma takiego bola żeby zabezpieczyć tak żeby się nie dało złamać. Może nie potrzebnie schizuje że od razu ktoś mój soft próbował hackować, może się przeceniam że w ogóle będzie warto...

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