Dekompilace .jar

[Palem]

Ahoj,
v Jave sem si udelal jednoduchy program, ktery spolupracuje s DB. Program obsahuje pristupove udaje k MYSQL. Pomoci Build project v NetBeans jsem vytvoril .jar soubor a zajimalo by me jestli je mozne provest dekompilaci a precist prihlasovaci udaje k DB? Pripadne jak muzu ochranit program proti precteni kodu

[Reklama]

[Radek]

Ahoj,

ano je to mozne. Dokonce mi to prijde jednodussi nez u jinych jazyku.

Radek

[Palem]

Jak tedy muzu aplikaci ochranit proti precteni kodu

[anonym]

jedina moznost je obfuskace, tedy zakryti

vetsinou se to dela tak ze udaje nemas ulozene jako text, ale "vyrabis" je nejakym silenym vypoctem. diky tomu se pak nedaji najit v kodu jako textova konstanta, ne li jako pribaleny soubor vedle

porad ale nezabranis nekomu aby tvoji aplikaci zapnul, a pak zastavil ve chvili kdy mas ty udaje poskladany v pameti, a tam si je v pohode precet

[h7]

Proč by uživatel toho programu neměl mít možnost přečíst přihlašovací údaje do DB? Naopak tyto údaje bývají součástí konfiguračního souboru, aby byly snadno nastavitelné.

[Reklama]

[Palem]

Nehci aby uzivatele zbytecne zkouseli hrabat na DB...

[Papouch]

otazka je co je "jednoduchy program" a jak zdatnemu uzivateli se ma zabranit v ziskani hesla

jestli je to nejaky udelator, ktery do db leze pres jdbc, tak si v pripade neschudnosti dekompilace heslo odchytim cestou, v jdbc driveru pripadne wiresharkem

z meho pohledu robustni reseni je pro autentikaci do db pouzit ssl klientsky certifikat ulozeny na tokenu (ten lze fyzicky umistit i mimo serverovnu + logovat pristupy)

[Ondra Satai Nekola]

Tak to musis mezi ne a databazi dat nejakou aplikacni vrstvu, kterou mas pod palcem ty (aka software as a service). Coz asi zase neni to, co chce zakaznik.

[filip]

Omezit danemu uzivateli pristup jen na nekolik stored procedures a zadne tabulky

[Palem]

V DB mam tabluku kde radek nese vsechno info u uzivateli ....
Coz pokud nejaky koumak program stahne a otevre dostane plne kredence a muze cokoliv ...

Takze asi nejlip udelat usera a specialni tabulku jenom s username a passwd v md5hash

[neruda]

Jar bez obfuskace jde dekompilovat zpetne vicemene do stejne podoby jako byl zdrojak.

Nicmene retezec je stejne vzdy citelny, i kdyby byl kod obfuskovan.

Jak bylo psano, muzes nejak prevest retezec na nejaky kodovany tvar, ten mit ulozeny v promene/ konfiguracnim souboru
a pri cteni ho rozkodovat. To je ale jenom zabrana pred ctenim pro nejvic nahodne vetrelce. Ten dekodovaci algoritmus je porad soucasti kodu klienta a i kdyby pouzival nejakou metodu komunikujici se servrem, vzdycky musi program to heslo k databazi nakonec znat a to heslo bude v pameti pocitace - pujde ziskat.

Spavny postup (smer) pro zabezpecene pripojeni do databaze (pro mysql asi tezko, pro pgsql jo) by byl (napriklad) nasledujici:
- klient ma uzivatele, ktery nema pravo cist tabulky, ale jen volat ulozene procedury
- klient se musi na databazi autentizovat uzivatelskym jmenem a heslem (ruzne od uctu k db pripojeni), databaze nastavi uzivatelskou session cookie na dane pripojeni
- klient vola ulozene procedury (na nic jineho nema pravo), ty nejprve zkontroluji prava pro daneho prihlaseneho uzivatele

[Krysa1]

soubor jar je normální zip a dá se rozbalit. Pokud máte proměné jako login a heslo v kódu jako text, pravděpodobně budou v nezměněné formě i .class souboru a nebude nutná ani dekompilace. Která je u javy snadná, takže není důvod ji neudělat tak jako tak.

[Ondra Satai Nekola]

Takze asi nejlip udelat usera a specialni tabulku jenom s username a passwd v md5hash

md5 urcite ne. Mozna scrypt?

[hawran diskuse]

Ahoj,
v Jave sem si udelal jednoduchy program, ktery spolupracuje s DB. Program obsahuje pristupove udaje k MYSQL. Pomoci Build project v NetBeans jsem vytvoril .jar soubor a zajimalo by me jestli je mozne provest dekompilaci a precist prihlasovaci udaje k DB? Pripadne jak muzu ochranit program proti precteni kodu

Čí .jar se snažíš rozlousknout?
Nehledáš náhodou v db nechtěně odeslanou url nějaké fotky?
 

[Radek]

Ahoj,
problem je asi v navrhu aplikace. Pokud mam aplikaci s nativnim pristupem do DB, musim resit veskere zabezpeceni v databazi. To znamena ze kazdy uzivatel musi mit svuj login a pokud nema mit pravo cist urcita data tak se to musi osetrit pravama na tabulkach. Napriklad jeden ERP system mel primy login na MSSQL, a tak pro kazdeho uzivatele se musel zakladat ucet na serveru. Nasledne byly veskere operace kontrolovany trigery a nektere veci slo resit jen pres ulozene procedury. Proste autentizacni/autorizacni logika je na strane DB.

Naopak v <dosadte oblibenou serverovou technologii> je zvykem mit jedno prihlaseni do db a nasledne v palikaci si resit veskerout autentizaci. Proto staci v DB tabulka, jmeno a heslo(nejlepe nejaky hash primo na hesla). Uzivatel nema moznost se pripomo pripojit na datbazi a tak muze aplikace omezit veskery pristup a pripadne nektere akce povolit/zakazat.

Radek