Nyt tulee sellainen kysymys, että entisen hiihtovalmentajan Kari-Pekka Kyrön lausahdus "taas ovat amatöörit asialla" puhuu puolestaan. Nimittäin tästä Javan tavukoodista. Voiko siitä saada helposti palautettua alkuperäisen lähdekielisen ohjelman. Ei tietenkään täysin alkuperäiseen muotoon, mutta niin, että ohjelman logiikka aukeaa kuin teatterin esirippu. Takana tässä on se, että kun olet onistunut tekemään tappajasovelluksen ja haluat suojella lähdekoodin. Itse lähdekoodin voi tietysti kryptata jollain salausohjelmalla, tai pistää piiloon kassakaappiin.
Esim. 100 kilon sorsasta tulee noin 10 kiloa tavukoodia. Ja 10 kilon tavukoodissa on vielä iso osa noita selväkielisiä kirjastoviittauksia. Jos teet jollain C :lla saman koodin, niin binääritiedosto on äkkiä megan luokkaa, joten ei siitä kovin äkkiä revitä sovelluksen logiikkaa auki.
Ei minulla tätä killer applikaatiota ole, joten en ole vielä yöuniani menettämässä ...
Esim. 100 kilon sorsasta tulee noin 10 kiloa tavukoodia. Ja 10 kilon tavukoodissa on vielä iso osa noita selväkielisiä kirjastoviittauksia. Jos teet jollain C :lla saman koodin, niin binääritiedosto on äkkiä megan luokkaa, joten ei siitä kovin äkkiä revitä sovelluksen logiikkaa auki.
Ei minulla tätä killer applikaatiota ole, joten en ole vielä yöuniani menettämässä ...
Vastaukset 2
Vanhimmat
Tavukoodin palauttaminen takaisin kähdekoodiksi on erittäin helppoa, eikä sitä voi kokonaan estää.
Javan reflection -paketti on nk. itsetutkiskelupaketti koodille, ehdottomasti varminta olisi käyttää toista kieltä.
Javasorsalle on saatavissa erilaisia obfuskkointi-softia ja joissakin sovelluskehittimissä näitä on valmiina. Hyvällä (kaupallisella)tällaisella päästään erittäin tehokkaasti "sotkettuun" sorsaan.
Mikäli ohjelmasi ei "juttele" muiden luokkien kanssa, eli sitä ei sulauteta osaksi suurempaa kokonaisuutta, ja tarpeesi ei ole tehdä alaspäin yhteensopivaa koodia, niin silloin voit sotkea myös muutkin kuin privaatit metodit (public & protected)---> suojaus on kohtalaisen tehokas.
Jos "sotket" pelkästään privaatit osat ja luokkakohtaiset lohkot (esim. metodien paikalliset muuttujat) koodi on kohtalaisen helppo tulkita "reverce engineering" -prosessilla.
Tämä mahdollisuus on otettava huomioon koodin tuotteistusvaiheessa, valmistuskustannuksiin kannattaa lisätä obfuskoinnista aiheutuva lisä. Toisaalta kyllä olen hieman "skeptinen" sen suhteen että kukaan tekisi NIIN hyvän sorsakoodin että se olisi erittäin tuottavaa repiä auki.
Itse ideahan (se mitä ohjelmasi tekee) valkenee koko maailmalle jo siinä vaiheessa kun ohjelmaasi aletaan markkinoida.
Tuon kokoisen lähdekoodin tekeminen ei vaadi vuosien totekehitystyötä, eikä siis mahdollisilta kilpailijoilta kulu kohtuuttomasti varoja saman ratkaisun tuottamiseksi alusta loppuun omalla koodillaan, eri asia olisi jos tuotekehittely vaatisi kymmeniä-satoja megoja lähdekoodia, jolloin tuotteen tekemiseen käytetty aika venyisi vuosiksi ja sinun tuotteesi saisi vahvan teknologisen etumatkan.
Nyrkkituntumalla sanoisin että oikein hi-tech koodi, jonka salaamiseen kannattaa jo tuhlata aikaa, alkaa olla parinsadan kilon luokkaa java-tavukoodina.
Kuten ProIT tuossa räppäsikin niin noiden koodinsekoittajien käyttö on suht' toimiva tapa tehdä ns. reverse engineering-tekniikan käyttö niin vaikeaksi, että ennemmin koodin tekee alusta loppuun saakka uusiksi. Hyviä koodinsekoittajia joita käytetään mm. J2ME-koodaamisessa ovat Retroguard ja Proguard.
Henkilökohtaisesti olen sitä mieltä, että tuo koodin tuottaminen on harvoin sen killerisovelluksen taustalla. Yleensä näissä päällimmäisenä on esim. kahden/usean eri tekniikan yhteiskäyttö jollain uudella tavalla. Eli, keksimisen jälkeen matkiminen on suht' helppoa oli sorsa käytettävissä tai ei. Koodin sekoittamisella voidaan aiheuttaa pientä kiusaa, mutta eipä paljon muuta, ja näin se yleensä vain pukkaa olemaan.
Joskus toimiva tapa on suojata ohjelman nimi tavaramerkkisuojalla, jolloin kilpailijat eivät voi ilman lupaa hyödyntää sitä omaa tuotettaan mainostaessaan. Tämän suojauksen hyväksikäyttö ja onnistuminen toimii vain silloin, kun oma liiketoimintamallisi on kilpailukykyisemmällä, rehellisemmällä ja uskottavammalla pohjalla kuin kilpailijasi. Hyvä esimerkki tästä on Java itse ja jolle on olemassa kilpailija C#, mutta valitettavasti kovin moni ei halua siihen sitoutua em. syistä johtuen.
-Jonttu-