Wykradanie kodu

Witam,
mam pytanie, czy istnieje możliwość ukraść kod ze skompilowanego programu .jar? I czy jest może jakaś opcja zabezpieczenia się przed tym?

W pliku jar masz bytecode i raczej się przed kradnięciem go nie zabezpieczysz :P

Udostępnij kod na licencji GPL w jakimś popularnym miejscu, np. github.
Jeżeli ktoś wyda Twój kod (zmieniony lub nie) na innej licencji, to będziesz mógł go podać do sądu.

I w czym mu to pomoże niby? nawet jeszcze ułatwi sprawę potencjalnym złodziejom... też mi sposób...
Zwykły copyright daje Ci takie samo prawo do pozwania kogoś do sądu. Ale co z tego, skoro nikt o zdrowych zmysłach nie przyzna się, że kradł kod albo że zcrackował aplikację i umieścił ją w sieci...

Nie da się przed tym zabezpieczyć całkowicie... w jakim byś języku nie pisał, jak się znajdzie uparty, to złamie zabezpieczenia.

Można kod zobfuscować, np ProGuardem...
http://proguard.sourceforge.net/ - utrudni to sprawę, ale wciąż będzie możliwe i (w porównaniu do RE kody natywnego) łatwe

Można kod zaszyfrować i napisać natywny launcher, który go odszyfruje. (launcher zabezpieczyć packerami i wszelkim takim szitem) - utrudni to sprawę, ale nie uniemożliwi. Wciąż, ktoś kto siedzi w RE będzie to w stanie ukraść... ale już na pewno nie byle jaki script-kiddie.

Najlepszym przykładem na to są gry wydawane przez duże firmy... tyle inwestują w zabezpieczenia, a wszystko i tak jest łamane po kilku tygodniach.

Ktoś mi mówił, że istnieją firmy, które specjalizują się w wyłapywaniu złamań postanowień licencyjnych, czyli np łamaniem GPLa.

Dzięki za odpowiedzi, swój kod będę starał się zabezpieczyć jak się da, bo wolę poświęcić kilkanaście godzin i wiedzieć, że zrobiłem wszystko co się dało by tego uniknąć. Dzisiaj byłem świadkiem złamania jednego kodu w c++ i właśnie ten precedens bardzo mnie zaniepokoił. Koleś zdobył cały kod w jeden dzień.

@Kerai wspomniał o szyfrowaniu i natywnym launcherze. Tego typu rozwiązaniem jest np. ClassGuard Kod Javy jest potraktowany AESem 128bit. Testowałem na dużej, ciężkiej aplikacji - uruchamia się bez opóźnień. Jest też JarCrypt

Co do obfuskacji - trzeba uważać. Wiele rzeczy może nagle przestać działać, więc trzeba dobrze przetestować zobfuskowany program.

Po co zabezpieczać? Ponosić koszty skoro i tak jak ktoś będzie chciał to uzyska dostęp? Szkoda zasobów na takie zabawy.

Stwórz aplikację serwerową i niech działający klienci logują się do niej (oczywiście dostęp do indywidualnych paczek danych przez konto usera) i niech ściągają w locie zabezpieczony kod od razu do pamięci i do wykonania. Nie ma na dzisiaj lepszego zabezpieczenia niż sieciowe "DRM". Jak myślisz skąd się wziął taki wysyp różnych gier MMO?

@Olamagato, mylisz trochę pojęcia. SaaS to faktycznie dobra metoda na zabezpieczenie, gdy klient dostaje wynik. Całe przetwarzanie jest po stronie serwera. Tak jak i w MMO, które robią tylko i wyłącznie za interfejs.
Ściąganie w locie zabezpieczonego (?) kodu od razu do pamięci nie różni się w ogóle od scrackowania normalnej aplikacji. Wszak też musi być wczytana do pamięci i wykonana.

Nie napisałem o tym, żeby całe przetwarzanie było po stronie serwera. Wręcz przeciwnie - najlepiej aby 99% przetwarzania było po stronie klienta. Klient MMO też robi całkiem sporo dzięki czemu bardzo często można go przerobić na serwer (vide "prywatne serwery"). Chodzi o to że każdy kod uruchamiany u klienta można złamać, ale niewielka ilość kodu uruchamianego na serwerze może spowodować, że cały "kod" klienta może stać się bardzo mało wartościowy. Np. można potraktować serwer jako generator tokenów bez których większość składowanego u klienta jest po prostu śmieciem. Znajomość samej metody deszyfrującej jest bezwartościowa, jeżeli nie znasz klucza. A klucz może być generowany w zależności od od usera jak, od momentu jego generowania i od dowolnych czynników jakie się wykombinuje. Kod u klienta nie musi też być statyczny - może się nieustannie zmieniać zarówno pod wpływem serwera jak i na zasadzie samo modyfikującego się kodu (a tutaj Java ma spore możliwości). Pewnie, że i to da się złamać - ale koszt złamania znacząco przewyższy wartość tak zabezpieczonego kodu. A o to przecież chodzi.

Właśnie w ten sposób Ubisoft przez jakiś czas zabezpieczał swoje gry. Przed wydaniem scenowych cracków, amatorzy na cs.rin.ru stworzyli działające emulatory w ~dwa dni.
Kod wykonywany u klienta nigdy nie będzie bezpieczny i odpowiednio zmotywowany zapaleniec RE poradzi sobie z tym w jeden dzień.

Jeżeli chcemy myśleć o bezpieczeństwie i możemy zastosować SaaS to jest to najlepszy wybór.

Na UBI zastawiła się cała śmietanka ludzi, którzy przez ponad dwa miesiące nie robili nic innego tylko próbowali złamać ich zabezpieczenia do skutku. Liczyłeś ile musiałbyś zapłacić za tyle roboczogodzin? :) Poza tym zabezpieczenia UBI miały kilka wad wynikających ze zwykłej arogancji i lekceważenia crackerów.