Hoe om die slot saamgestel Java klasse om te verhoed dat decompilatie?

Question

Hoe kan ek sluit saamgestel Java klasse om te verhoed dat decompilatie?

Ek weet dit moet baie goed bespreek onderwerp op die Internet, maar ek kon nie kom tot'n gevolgtrekking verwys na hulle.

Baie mense doen voor obfuscator, maar hulle het net nie die hernoeming van klasse, metodes, en velde met taai-om-te-onthou karakter rye maar wat oor sensitiewe konstante waardes?

Byvoorbeeld, jy het die enkripsie en dekripsie komponent gebaseer op'n wagwoord gebaseer enkripsie tegniek.Nou in hierdie geval, enige gemiddelde Java persoon kan gebruik JAD om die afbreek van die klas lêer en maklik haal die wagwoord waarde (gedefinieer as konstante) sowel as sout en op sy beurt kan decrypt die data deur die skryf van klein, onafhanklike program!

Of moet sulke sensitiewe komponente gebou word in inheemse kode (byvoorbeeld, VC++) en noem hulle via JNI?

Answer 1

Van die meer gevorderde Java bytecode obfuscators doen veel meer as net 'n klas naam mangling. Zelix KlassMaster , byvoorbeeld, kan ook klouter jou kode vloei in 'n manier wat maak dit regtig moeilik om te volg en werke as 'n uitstekende kode optimizer ...

Ook baie van die obfuscators is ook in staat om jou string konstantes klouter en verwyder ongebruikte kode.

Nog 'n moontlike oplossing (nie noodwendig uitgesluit die obfuscation) is om geïnkripteer JAR lêers gebruik en 'n persoonlike classloader dat die dekripsie doen (verkieslik gebruik van inheemse runtime biblioteek).

Derde (en moontlik die aanbied van die sterkste beskerming) is om voort te moedertaal gebruik van tyd opstellers soos GCC of Excelsior JET , byvoorbeeld, wat stel jou Java-kode direk na 'n platform spesifieke moedertaal binêre.

In elk geval Jy het om te onthou dat soos die spreekwoord sê in Estnies "slotte is vir diere". Dit beteken dat elke bietjie van die kode is beskikbaar tydens die runtime (gelaai in die geheue) en gegewe genoeg vaardigheid, vasberadenheid en motivering, kan mense en sal afbreek, ontleden en kap jou kode ... Jou taak is bloot om die proses so ongemaklik soos maak jy kan en nog steeds die ding werk ...

Answer 2

So lank As wat hulle het toegang tot beide die geënkripteerde data en die sagteware wat ontsyfer dit, daar is basies geen manier wat jy kan maak dit heeltemal veilig.Maniere om dit opgelos is voor is om te gebruik om'n vorm van eksterne swart boks te hanteer enkripsie/dekripsie, soos usb, remote verifikasie bedieners, ens.Maar selfs dan, gegee dat die gebruiker het volle toegang tot hul eie stelsel, is dit net maak dinge moeilik, nie onmoontlik nie -tensy jy kan bind jou produk direk na die funksie gestoor in die "black box", as, sê, online gaming bedieners.

Answer 3

Disclaimer: Ek is nie 'n sekuriteit deskundige

.

Dit klink soos 'n slegte idee: Jy is laat iemand enkripteer dinge met 'n "verborge" sleutel wat jy hom gee. Ek dink nie dit kan veilig gemaak word.

Miskien asimmetriese sleutels kon werk:

• ontplooi 'n geënkripteerde lisensie met 'n publieke sleutel tot decrypt
• laat die kliënt 'n nuwe lisensie en stuur dit aan jou vir enkripsie
• stuur 'n nuwe lisensie terug na die kliënt.

Ek is nie seker nie, maar ek glo die kliënt kan die lisensie sleutel met die openbare sleutel jy hom gegee het eintlik enkripteer. Jy kan dan decrypt dit met jou private sleutel en re-enkripteer sowel.

Jy kan 'n aparte openbare / private sleutel paar per kliënt hou om seker te maak jy eintlik kry dinge van die reg kliënt - nou jy is verantwoordelik vir die sleutels ...

Answer 4

Dit maak nie saak wat jy doen, dit kan 'decompiled. Heck, jy kan net onderwerp aan dit. Of kyk na 'n geheue dump om jou konstantes vind. Jy sien, die rekenaar moet hulle weet, so jou kode sal moet ook.

Wat om te doen?

Probeer die sleutel nie op die skip as 'n hardcoded konstante in jou kode: Hou dit as 'n instelling per gebruiker. Maak die gebruiker verantwoordelik vir die versorging van daardie sleutel.

Answer 5

@jatanp: of nog beter, kan hulle afbreek, verwyder die lisensiëring kode, en heropstel. Met Java, weet ek nie regtig dink daar is 'n behoorlike, hack-proof oplossing vir hierdie probleem. Nie eens 'n bose bietjie dongle kan dit te voorkom met Java.

My eie biz bestuurders is bekommerd oor hierdie, en ek dink te veel. Maar dan weer, verkoop ons ons aansoek in groot maatskappye wat geneig is om te hou by lisensievoorwaardes - oor die algemeen 'n veilige omgewing te danke aan die boontjie tellers en prokureurs. Die daad van decompiling self kan onwettig wees as jou lisensie korrek geskryf.

So, ek het om te vra, doen jy regtig hoef geharde beskerming soos jy is op soek na jou aansoek? Wat beteken jou kliëntebasis lyk? (Maatskappye? Of die tiener gamer massas, waar dit sou meer van 'n probleem te wees?)

Answer 6

As jy op soek is na 'n lisensie oplossing, kan jy check out die TrueLicense API . Dit is gebaseer op die gebruik van asimmetriese sleutels. Dit beteken egter nie dat jou aansoek kan nie gekraak. Elke aansoek kan gekraak met genoeg moeite. Wat regtig belangrik is, as Stu beantwoord , uitzoeken hoe sterk beskerming wat jy nodig het.

Answer 7

Ek dink nie daar bestaan enige effektief op die regte pad computer is vergrendeld metode.Die videogame bedryf het probeer om uit te vind dat baie keer en hul programme het altyd gekraak.Die enigste oplossing is dat die program moet uitgevoer word aanlyn verbind met jou bedieners, sodat jy kan kontroleer die lincense sleutel, en dat daar net een aktiewe connecion deur die lisensiehouer op'n tyd.Dit is hoe Wêreld van Warcraft of Diablo werke.Selfs taai daar is private bedieners wat ontwikkel is vir hulle om te omseil die sekuriteit.

Noudat dit gesê is, ek glo nie dat die middel/groot korporasies gebruik onwettig gekopieerde sagteware, omdat die koste van die lisensie vir hulle is minimaal (miskien, ek weet nie hoe baie jy is goig om te vra vir jou program) in vergelyking met die koste van'n proef weergawe.

Answer 8

Jy kan byte-kode enkripsie gebruik met geen vrees.

Die feit is dat die hierbo aangehaal papier "Cracking Java byte-kode enkripsie" bevat 'n logika dwaling. Die belangrikste eis van die papier is voordat jy alle klasse moet Ontcijferde en geslaag om die ClassLoader.defineClass(...) metode . Maar dit is nie waar nie.

Die aanname hier gemis is met dien verstande dat hulle nog aktief in outentieke, of standaard, Java run-time omgewing . Niks kan die beskermde java app nie net verplig om hierdie klasse van stapel te stuur, maar selfs decrypt en slaag hulle om ClassLoader. Met ander woorde, as jy in standaard JRE jy kan nie onderskep defineClass(...) metode omdat die standaard Java geen API vir hierdie doel, en as jy gebruik gemodifiseerde JRE met gelapte ClassLoader of enige ander "hacker truuk" kan jy dit nie doen omdat beskerm java app glad nie sal werk nie, en daarom sal jy niks om te onderskep het. En absoluut maak nie saak wat "kol finder" gebruik word of wat truuk gebruik word deur hackers. Hierdie tegniese besonderhede is 'n heel ander storie.

Answer 9

Q: As ek enkripteer my CLASS lêers en gebruik 'n persoonlike classloader te laai en decrypt hulle op die vlieg, sal dit te verhoed decompilatie

A: Die probleem van die voorkoming van Java byte-kode decompilatie is amper so oud die taal self. Ten spyte van 'n verskeidenheid van obfuscation gereedskap wat beskikbaar is op die mark, beginner Java programmeerders voortgaan om te dink aan nuwe en slim maniere om hul intellektuele eiendom te beskerm. In hierdie Java Q & A paaiement, ek verdryf sommige mites rondom 'n idee dikwels rehashed in gespreksforums.

Die uiterste gemak waarmee Java CLASS lêers kan herbou in Java bronne wat die oorspronklike nou lyk het 'n baie te doen met Java byte-kode ontwerp doelwitte en trade-offs. Onder andere, is Java byte kode wat ontwerp is vir kompaktheid, platform onafhanklikheid, mobiliteit netwerk, en gemak van analise deur byte-kode tolke en JIT (just-in-time) / HotSpot dinamiese opstellers. Waarskynlik, die saamgestel CLASS lêers te druk bedoeling die programmeerder se so duidelik hulle makliker kan wees om te ontleed as die oorspronklike bronkode.

Verskeie dinge gedoen kan word, indien dit nie aan decompilatie heeltemal voorkom, ten minste om dit moeiliker te maak. Byvoorbeeld, as 'n post-samestelling stap wat jy kan die CLASS data masseer om die byte kode óf moeiliker om te lees wanneer decompiled of moeiliker om afbreek in geldig Java-kode (of albei) maak. Tegnieke soos die uitvoering van uiterste metode naam oorlading werk goed vir die voormalige, en manipuleer beheer vloei te beheer strukture nie moontlik om verteenwoordig deur Java syntax werk goed vir die laasgenoemde skep. Die meer suksesvolle kommersiële obfuscators gebruik 'n mengsel van hierdie en ander tegnieke.

Ongelukkig beide benaderings moet eintlik die kode die JVM sal loop verander, en baie gebruikers is bang (tereg so) dat hierdie transformasie nuwe foute kan voeg tot hul aansoeke. Verder metode en veld herbenaming kan weerspieëling veroorsaak noem om op te hou werk. Veranderende werklike klas en pakket name kan 'n hele paar ander Java API (JNDI (Java Naming en Gids Interface), URL verskaffers, ens) te breek. In bykomend tot veranderde name, indien die verband tussen klas byte-kode neutraliseer en bron lyn nommers verander, herstel die oorspronklike uitsondering stapel spore kan moeilik raak.

Dan is daar die opsie van obfuscating die oorspronklike Java bronkode. Maar fundamenteel dit veroorsaak 'n soortgelyke stel probleme. Encrypt, nie verduisteren?

Miskien is die bogenoemde gemaak het wat jy dink, "Wel, wat as plaas van te manipuleer byte kode wat ek al my klasse na samestelling enkripteer en decrypt hulle op die vlieg in die JVM (wat gedoen kan word met 'n persoonlike classloader)? Toe die JVM voer my oorspronklike byte kode en tog is daar niks om afbreek of reverse engineering, reg? "

Ongelukkig sal jy verkeerd wees, beide in te dink dat jy was die eerste om te kom met hierdie idee en in te dink dat dit eintlik werk. En die rede het niks te doen met die krag van jou enkripsie skema.